Business Process Management (BPM)

Prévia do material em texto

ELISAMARA DE OLIVEIRA
JOSÉ DO CARMO RODRIGUES
Professora autora/conteudista
Atualizado e revisado por
É vedada, terminantemente, a cópia do material didático sob qualquer 
forma, o seu fornecimento para fotocópia ou gravação, para alunos 
ou terceiros, bem como o seu fornecimento para divulgação em 
locais públicos, telessalas ou qualquer outra forma de divulgação 
pública, sob pena de responsabilização civil e criminal.
SUMÁRIO
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 . Business Process Management (BPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Gestão por funções x Gestão por processos nas organizações . . . . . . . . . . . . . . . .6
1.2 Processos orquestrando as atividades de negócios . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.3. Gerenciamento de processos de negócio/Business process management 
(BPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Áreas de conhecimento em BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
2 . Modelagem de processos com BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Modelagem de processos de negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 A notação BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Principais elementos do BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Pools, lanes, objetos de conexão e artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Objetos de fluxo: eventos, atividades e gateways . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 Exemplos de diagramas BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 . Normas de qualidade ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Modelos e normas de qualidade de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Norma ISO 14598 - Avaliação de produtos de software . . . . . . . . . . . . . . . . . . . . . 40
3.3 Norma ISO 9126 – Modelo de qualidade de software . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Normas ISO 25000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 A norma ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1 Processos fundamentais (primários) . . . . . . . . . . . . . . . . . . . . . 47
3.5.2 Processos de apoio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.3 Processos organizacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6 A norma ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
4 . CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Antecedentes históricos: modelos CMM para qualidade de processo de software 
51
4.2 Visão geral do modelo CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Componentes do modelo CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 Representações do CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Seleção de uma representação do modelo CMMI . . . . . . . . . . . . . . 59
4.5 Representação contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
4.6 Representação por estágio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
4.7 Níveis de maturidade do CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.7.1 Nível de maturidade 1: Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.7.2 Nível de maturidade 2: Gerenciado. . . . . . . . . . . . . . . . . . . . . . . 66
4.7.3 Nível de maturidade 3: Definido . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7.4 Nível de maturidade 4: Gerenciado. . . . . . . . . . . . . . . . . . . . . . . 68
4.7.5 Nível de maturidade 5: Em otimização. . . . . . . . . . . . . . . . . . . . . 69
4.8 Níveis de capacidade do CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.8.1 Nível de capacidade 0: Incomplete (Incompleto). . . . . . . . . . . . . . . 71
4.8.2 Nível de capacidade 1: Performed (Executado) . . . . . . . . . . . . . . . 71
4.8.3 Nível de capacidade 2: Managed (Gerenciado). . . . . . . . . . . . . . . . 71
4.8.4 Nível de capacidade 3: Defined (Definido) . . . . . . . . . . . . . . . . . . 71
5 . Modelo de Processo de Software Brasileiro (MPS .BR) . . . . . . . . . . . . . . . . . . . . . . 72
5.1 Visão geral do MPS.BR e do MR-MPS-SW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Capacidade de Processo e Níveis de Maturidade do MR-MPS-SW . . . . . . . . . . . . .74
5.3. Atributos de processos do MR-MPS-SW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
5.3.1 AP 1.1 O processo é executado. . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.2 AP 2.1 A execução do processo é gerenciada . . . . . . . . . . . . . . . . 76
5.3.3 AP 2.2 Os produtos de trabalho do processo são gerenciados . . . . . . 77
5.3.4 AP 3.1 O processo é definido . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3.5 AP 3.2 O processo está implementado . . . . . . . . . . . . . . . . . . . . 77
5.3.6 AP 4.1 O processo é objeto de análise quantitativa . . . . . . . . . . . . . 78
5.3.7 AP 4.2 O processo é controlado quantitativamente . . . . . . . . . . . . . 79
5.3.8 AP 5.1 O processo é objeto de melhorias incrementais e inovações . . . 79
5.3.9 AP 5.2 O processo é objeto de implementação de melhorias inovadoras e 
incrementais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Processos por níveis de maturidade do MR-MPS-SW. . . . . . . . . . . . . . . . . . . . . . . .81
5.4.1 Nível G – Parcialmente gerenciado . . . . . . . . . . . . . . . . . . . . . . 81
5.4.2 Nível F – Gerenciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.3 Nível E – Parcialmente definido . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.4 Nível D – Largamente definido . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.5 Nível C – Definido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.6 Nível B – Gerenciado quantitativamente . . . . . . . . . . . . . . . . . . . 85
5.4.7 Nível A – Em otimização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5 Comparativo entre MPS.BR e CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Glossário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Pág. 5 de 97
INTRODUÇÃO
As organizações vêm buscando realizar a sua gestão por processos, embora muitos departamentos 
desenvolvam projetos. Administrar projetos e processos transfuncionais não é uma tarefa fácil. 
Entender como funcionam os processos e quais são os tipos existentes é importante para determinar 
como eles devem ser gerenciados e obter o máximo resultado. As organizações têm percebido 
cada vez mais que gerenciar seus processos de negócio oferece vantagens competitivas. Diante 
dessa tendência, vem crescendo no meio empresarial a prática do gerenciamento de processos de 
negócio ou BPM (business process management) como uma forma de gerenciamento e controle 
das organizações. A implementação efetiva de uma solução de BPM requer elementos estratégicos 
e de tecnologia, mas pode resultar em importantes benefícios, como o alinhamento da estratégia 
empresarial e da infraestrutura de tecnologia na qual são construídos os negócios.
Por outro lado, a adoção de processos de qualidade por equipes de desenvolvimento de software 
pode ser considerada peça fundamental no andamento dos projetos, auxiliando na redução de riscos, 
buscando garantias de qualidade e permitindo que a empresa se torne cada vez mais competitiva. A 
aplicação de processos de qualidade possibilita a construção de produtos com maior qualidade, pois 
padrões são seguidos durante todo o ciclo de vida do software. Estes processos são chamados de 
ciclo de vida da qualidade de software, pois iniciam-se na concepção do software e seguem até a sua 
descontinuidade visando o controle do desenvolvimento, auxiliam na definição de prazos e tendem 
a evitar imprevistos. Os modelos de qualidade propõem a utilização de práticas e normatização de 
processos de desenvolvimento objetivando a construção de um produto com qualidade.
Diante disso, nós lhe convidamos a conhecer o mundo da TI através dos olhos da qualidade de 
software e do BPM. Os aspectos teóricos e os conceitos da qualidade de software são mesclados 
com a definição, modelagem e implementação de processos interconectados e transformados em 
ações do dia-a-dia. Você terá, além dos fundamentos teóricos, a possibilidade de ver casos práticos 
nos quais os processos de qualidade são implantados. Então, prepare-se e venha junto conosco 
conhecer este interessante tema!
Pág. 6 de 97
1. BUSINESS PROCESS MANAGEMENT (BPM)
FIGURA 1 – BPM
Fonte: Urupong Phunkoed / shutterstock.com
Neste capítulo vamos conhecer o que são processos de negócios e sua gestão. Vamos entender 
o porquê da necessidade de mapear os processos e o porquê de usar a modelagem de processo para 
materializar todos os fluxos que o processo contempla. Estudaremos a metodologia do workflow, que 
fornece uma maneira de visualizar melhor as atividades de negócios, como uma cadeia de tarefas 
e intervenções que irão determinar melhor qualidade e produtividade nos processos de negócios.
1.1 Gestão por funções x Gestão por processos nas organizações
Vamos iniciar nossos estudos caracterizando dois tipos mais comuns de gestão organizacional: 
gestão por função e gestão por processos. Acredito que você poderá concluir que a primeira nos 
remete ao passado, e a segunda aos tempos atuais...
Empresas que fazem a gestão por função tratam os processos, dentro de áreas ou departamentos 
nas quais as funções são exercidas. É possível que os processos confundam-se ou sejam mesmo 
Pág. 7 de 97
tratados como funções. Um problema evidente é que cada área trabalha apenas com as atividades 
relacionadas à sua função e perde a noção da organização como um todo. Neste cenário, as decisões 
acontecem de forma verticalizada e o poder fica centralizado na figura do chefe daquela área. Isso 
pode levar a empresa a ter problemas de qualidade em seus produtos e serviços.
Por outro lado, empresas que fazem a gestão utilizando processos de negócios organizam-
se de forma mais horizontal, valorizam os clientes, o trabalho e a colaboração em equipe e a 
responsabilidade de cada colaborador. Nestas empresas os níveis hierárquicos são reduzidos, as 
interferências entre áreas funcionais são reduzidas e a responsabilidade recai mais para os que 
atuam diretamente nos processos, que detêm mais autonomia de ação.
Stadler (2013, p. 21) reforça este conceito afirmando que, na gestão funcional, observa-se um 
modelo de gestão fortemente hierárquico com base em departamentos, resultando em uma estrutura 
vertical, e, na abordagem por processos, o modelo de gestão está fundamentado na formação de 
equipes multifuncionais, resultando em uma estrutura horizontal.
Observando a estrutura organizacional das empresas ilustrada na Figura 2, pode-se perceber 
que a organização que se baseia em gestão funcional tem uma estrutura funcional verticalizada, 
enquanto as que utilizam gestão por processos possuem uma estrutura horizontal.
FIGURA 2 – Gestão funcional x por processos
Vertical
funcional
Funcional com
processos
em segundo plano
Processos com
funcional em 
segundo plano
Processos horizontais
Gestão funcional
tradicional
Estrutura orientada
por processo
Fonte: Fonseca (2009)
Pág. 8 de 97
Ainda reforçando a diferença entre os tipos de organização, Davenport (1994, p. 10) argumenta:
[...] como a perspectiva de um processo implica uma visão horizontal do negócio, que 
envolve toda a organização, começando pelos insumos do produto e terminando com 
os produtos finais e os clientes, a adoção de uma estrutura baseada no processo 
significa, em geral, uma não enfatização da estrutura funcional do negócio.
De acordo com o guia ABPMP-CBOK (ABPMP, 2013 p. 37), empresas que se organizam de forma 
orientada aos processos com robustez conseguem responder mais rapidamente a desvios com 
base no acompanhamento dos processos interfuncionais.
Gerenciamento por processos
 “Gerenciar por processos compreende uma visão mais ampla, posicionando processos como pedra 
angular da estruturação organizacional. Embora a estruturação funcional continue válida, pois a 
especialização leva à produtividade, a geração de valor passa a ser gerenciada horizontalmente em 
uma visão notadamente interfuncional ponta a ponta. As funções se tornam ‘centros de serviço’ 
regulados por Acordos de Nível de Serviço (ANS) e orquestrados por processos de negócios.”
Fonte: ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). ABPMP 
BPM CBOK 3 .0: Guia para o gerenciamento de processos de negócio-corpo comum de conhecimento. 
ABPMP Brazil, 2013. p. 39. Disponível em: <http://c.ymcdn.com/sites/www.abpmp.org/resource/resmgr/Docs/
ABPMP_CBOK_Guide__Portuguese.pdf>. Acesso em: 15 mar. 2017.
A gestão por processos permite que os gestores entendam como as atividades são realizadas 
na prática diária da organização, deixando os problemas mais evidentes e, com isso, abrindo 
possibilidades de correção de gargalos e ineficiências que poderiam se manter encobertos dentro de 
uma aparente normalidade. Além disso, tempos gastos nas atividades e custos podem ser reduzidos, 
mais eficiência pode ser aplicada nos processos, os produtos e serviços podem ter sua qualidade 
mais apurada e a satisfação de todos os envolvidos é aumentada, notadamente os clientes.
Mas a gestão por processos não é uma tarefa simples. Quando um processo envolve diferentes 
áreas, é comum que gestores criem uma rivalidade entre si na busca por receber os louros de 
atividadesbem sucedidas, uma vez que isso pode implicar em compensações por eficiência e 
produtividade.
Pág. 9 de 97
CURIOSIDADE
“Apenas 11 .8% das empresas de TI brasileiras têm certificação de qualidade
[...]
De acordo com um censo promovido pela Federação das Associações das Empresas Brasileiras de 
Tecnologia da Informação (Assespro Nacional), divulgado em julho de 2014, uma pequena parcela das 
empresas de TI brasileiras busca certificações de qualidade sobre produtos, serviços e processos. 
Em 2014 apenas 11,8% das organizações receberam certificados específicos de tecnologia. Em 2013, 
o índice foi de 15,3%. O levantamento aponta que a certificação mais comum é da série ISO 900x, que 
envolve padrões técnicos de gestão da qualidade. No Brasil, 3,9% das companhias possuem esse 
reconhecimento.
Em seguida aparece a MPS.BR (melhoria de processos do software brasileiro), que visa assegurar que 
a qualidade dos serviços prestados pela empresa é garantida pelas melhores práticas e pelo controle 
de qualidade. Hoje, 3,2% das organizações possuem MPS.br.
Por fim, 3% têm CMMI (Capability Maturity Model Integration) nos níveis 2 e 3. Essa certificação avalia 
melhores práticas para desenvolvimento e manutenção de produtos, com ênfase em engenharia de 
sistemas e em engenharia de software.
CERTIFICAÇÃO STEFANINI
[...]
A multinacional conta com a ISO 9001, norma referência em gestão da qualidade; CMMI Nível 5, sendo 
a primeira empresa brasileira a conseguir o mais alto nível da CMMI, e MPS.BR – Nível A.
A Stefanini também foi a primeira brasileira avaliada e aprovada no modelo MoProSoft (modelo 
de qualidade do México) e ainda conquistou, no ano passado [2014], a ISO 27.001, a norma mais 
respeitada em segurança da informação.
Já em 2015, [...] conseguiu a ISO 20.000, a norma mais respeitada mundialmente em gestão de 
serviços.”
Fonte: STEFANINI. Apenas 11,8% das empresas de TI brasileiras têm certificação de qualidade. 17 
set. 2015. Disponível em: <https://stefanini.com/br/2015/09/apenas-118-das-empresas-de-ti-brasileiras-tem-
certificacao-de-qualidade/>. Acesso em 7 jun. 2017.
1.2 Processos orquestrando as atividades de negócios
Um processo pode ser definido de diferentes formas. Segundo Marcondes (2015, s/p) um 
processo organizacional
[...] é um conjunto de atividades inter-relacionadas, que envolve pessoas, equipamentos, 
procedimentos e informações e, quando executadas, transformam entradas (insumos) 
em saídas (produtos ou serviços), que atendem a necessidade de um cliente interno 
ou externo e que agregam valor e produzem resultados para a organização.
Pág. 10 de 97
O guia ABPMP (2013 p. 47) define processo como “uma agregação de atividades e comportamentos 
executados por humanos ou máquinas para alcançar um ou mais resultados”. Já um processo de 
negócio “é um trabalho que entrega valor para um cliente ou apoia outros processos”.
De acordo com o guia citado e o Manual do MPF (2013), os processos organizacionais podem 
ser classificados em três categorias:
• Processos primários: representam as atividades essenciais que a organização realiza para 
cumprir sua missão, por isso também são chamados de finalísticos ou essenciais. Caracterizam 
a atuação da organização, recebem apoio de outros processos internos e constroem a percepção 
de valor pelo cliente, pois geram um produto ou serviço para ele. Exemplos de processos 
primários estão associados à cadeia de valor, a um modelo de serviço orientado ao cliente 
etc. Podemos citar: logística de entrada e saída, marketing e vendas, serviços pós-venda, 
satisfação das expectativas do cliente e prestação de serviços ao cliente.
• Processos de suporte: são processos importantes para a gestão efetiva da organização, 
garantindo o suporte adequado aos processos primários (ou finalísticos), embora possam 
também dar suporte a outros processos de suporte e de gerenciamento. Sua diferença em 
relação aos primários é que entregam valor a outros processos, e não diretamente ao cliente. 
Exemplos: contratação de pessoas, aquisição de bens e materiais, execução orçamentário-
financeira, montagem de um veículo etc.
• Processos de gerenciamento: são aqueles ligados à estratégia da organização, pois estabelecem 
de indicadores de desempenho e as formas de avaliação dos resultados alcançados interna 
e externamente pela organização. Estão diretamente relacionados à formulação de políticas 
e diretrizes para se estabelecer e concretizar metas. Exemplos: planejamento estratégico, 
gestão por processos e gestão do conhecimento.
Os processos são compostos por atividades inter-relacionadas que são governadas por regras 
de negócio. Um subprocesso é uma porção de um processo que desempenha um objetivo específico 
dentro do processo principal. Atividades são ações executadas dentro dos processos, necessárias 
para produzir resultados específicos. Cada atividade é constituída por um determinado número 
de tarefas, que normalmente indicam como um determinado trabalho é executado. O guia ABPMP 
(2013 p. 38) ainda define mais dois conceitos ligados a processos: instância de processo, que é cada 
execução de um processo e função de negócio, que se refere a grupos de atividades e competências 
especializadas relacionadas a objetivos ou tarefas particulares. A Figura 3 ilustra estes conceitos.
Pág. 11 de 97
De acordo com a Figura 3, o processo de negócio inicia-se em um nível mais alto do que o 
nível que realmente executa o trabalho e então subdivide-se em subprocessos que devem ser 
realizados através de uma ou mais atividades (fluxos de trabalho) dentro de funções de negócio 
(áreas funcionais). As atividades podem ser decompostas em tarefas e, posteriormente, em cenários 
para a realização das tarefas, com seus respectivos passos.
Figura 3 - Processos orquestrando as atividades de negócio
Visão lógica
(Processo)
Visão física
(Função)
Processo de negócio
Subprocesso
Função de negócio
Atividade
Tarefa
Cenário
Passo
Representa processo de negócio primário, de
suporte ou de gerenciamento
Decomposição do processo de negócio por
afinidade, objetivo ou resultado desejado
Decomposição de atividades em conjunto de 
passos ou alçoes para realizar o trabalho em um
determinado cenário
Grupo de atividades e competências
especializadas
Conjunto de tarefas necessárias para
entregar uma parte específica e definível de
um produto ou serviço
Modalidade de execução de tarefa
Ação em nível atômico
∞
∞
Fonte: ABPMP (2013, p. 33)
Pág. 12 de 97
1.3. Gerenciamento de processos de negócio/Business process management (BPM)
FIGURA 4 – Gerenciamento de processos de negócio
Fonte : Alexander Supertramp / shutterstock.com
BPM é uma abordagem sistematizada de gestão que trata os processos de negócios como ativos 
que afetam diretamente o desempenho da organização, já que possuem como meta a excelência 
organizacional e a agilidade nos negócios. Para alcançar essa meta é necessário determinar os 
recursos necessários, realizar o monitoramento de desempenho, a manutenção e a gestão do ciclo 
de vida do processo.
Pág. 13 de 97
Gerenciamento de processos de negócios
“Gerenciamento de processos de negócios ou BUSINESS PROCESS MANAGEMENT - BPM é uma 
disciplina gerencial que integra estratégias e objetivos de uma organização com expectativas e 
necessidades de clientes, por meio do foco em processos de ponta a ponta. BPM engloba estratégias, 
objetivos, cultura, estruturas organizacionais, papéis, políticas, métodos e tecnologias para analisar, 
desenhar, implementar e gerenciar o desempenho, transformar e estabelecer a governança de 
processos.”
Fonte: ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). ABPMP 
BPM CBOK 3 .0: Guia para o gerenciamento de processos de negócio-corpo comum deconhecimento. 
ABPMP Brazil, 2013. Disponível em: <http://c.ymcdn.com/sites/www.abpmp.org/resource/resmgr/Docs/ABPMP_
CBOK_Guide__Portuguese.pdf>. Acesso em: 15 mar. 2017.
Ainda de acordo com a Figura 3, BPM pode ser visto como uma nova forma de visualizar as 
operações de negócios que vai além das formas tradicionais funcionais. Esta visão abrange todo 
o trabalho necessário para entregar o produto ou serviço de um processo, independentemente de 
quais áreas funcionais estejam envolvidas. Enquanto as atividades representam a composição 
física do trabalho efetivamente realizado, os processos representam a composição lógica 
destas atividades.
Fatores críticos de sucesso na implantação do BPM incluem a mudança de atitude das pessoas 
e também as mudanças de perspectiva de processos para avaliar o desempenho dos processos 
das organizações. Mas, de forma mais ampla, dentre os fatores críticos de sucesso, podemos citar:
• A empresa deve estar preparada para mudanças, tanto no nível organizacional quanto na 
cultura vigente até então.
• É necessário que a empresa se organize para que haja uma estrutura adequada para a 
implantação do BPM.
• A estrutura para a implantação do BPM e as metas e estratégias da empresa devem estar 
alinhadas.
• A empresa deve manter o foco no cliente, respeitando suas necessidades e exigências.
• Deve haver uma abordagem específica para que sejam realizadas medições dos processos e 
consequente acompanhamento das melhorias.
• A alta administração da empresa deve estar fortemente comprometida com a implantação 
do BPM.
• A empresa deve prover sistemas de informação capazes de suportar adequadamente os 
processos.
Pág. 14 de 97
• A empresa também deve prover infraestrutura adequada e garantir o realinhamento das 
práticas organizacionais.
FIGURA 5 – As práticas de BPM
Fonte: garagestock / shutterstock.com
As práticas de BPM incluem a análise, definição, execução, monitoramento e administração de 
processos, bem como o apoio na interação entre pessoas e aplicações suportadas pela TI. Mas 
o BPM, principalmente, possibilita que as regras de negócio da organização, transformadas em 
processos, sejam criadas pelas áreas de gestão, sem interferência das áreas técnicas.
A TI oferece suporte a essas práticas através de sistemas automatizados que visam padronizar os 
processos corporativos, contribuindo para o aumento da produtividade e da eficiência. As soluções 
de BPM são aplicações cujo principal objetivo é medir, analisar e otimizar a gestão do negócio e os 
processos de análise financeira da corporação.
Pág. 15 de 97
Para que os resultados do BPM possam ser maximizados, é importante que se conheçam os 
diferentes tipos de processos e o seu funcionamento, além de se determinar a maneira pela qual 
serão gerenciados. Desta forma, para que uma estrutura organizacional por processos possa ser 
implantada, é essencial que seja feito um amplo mapeamento das atividades da organização para 
que os processos sejam identificados e que regras e relacionamentos sejam estabelecidas. Além 
disso, a organização deve providenciar suporte de tecnologia adequado e realizar um realinhamento 
estratégico para que a implantação do BPM possa ocorrer de forma mais efetiva.
Tão importante quanto dizer o que é BPM, é dizer o que não é BPM, ou seja, evitar o uso incorreto 
do termo. De acordo com Palmer (2014), BPM não é um produto ou um segmento de mercado. Uma 
aplicação não faz BPM, uma unidade organizacional inteira não faz BPM, BPM não é o conjunto 
de atividades de um BPMS e fazer algo baseado em BPMS não significa implementar BPM. BPMS 
(Business Process Management Suite/System) é um sistema computacional ou um conjunto de 
ferramentas que oferecem suporte às atividades de BPM, como automação, execução, controle e 
monitoração das etapas das atividades e tarefas realizadas em uma organização.
SAIBA MAIS
3 motivos do porquê o BPM não deu certo na sua empresa
 [...]
1- Pensar que o modelo de negócio é igual de TI
Desista. O profissional de negócio não pensa igual ao profissional de TI. Por conta disso, não adianta 
achar que o uso de BPMN irá resolver o problema dessa divergência.
[...] A área de negócios tenta explicar suas necessidades para a área de TI, que tenta resolver 
encontrando a melhor solução, baseando-se em uma realidade muitas vezes irreal.
Afinal, como resolver isso?
A área de negócios precisa estar presente e o BPMS permite isso. Com uma solução prática e 
intuitiva, a própria área de negócio desenha e prototipa a solução para o seu problema. A área de TI 
fica com os assuntos realmente relacionados ao que sua área é demandada, como as integrações e 
especificações mais técnicas que possam a vir serem necessárias. Muito mais eficiente, não é?
Assim, o que antes eram: especificações técnicas, diagramas técnicos, codificação pura, protótipos 
“fakes”, passam a ser: modelos e fluxos, regras e campos automáticos, telas automáticas e reais. [...]
Pág. 16 de 97
2- Pensar que o BPM pode correr uma maratona
Sabemos da TI bimodal: maratona e sprints.
Os projetos de TI maratonistas visam enormes entregas, com grandes períodos e equipes totalmente 
focadas. Funcionam muito bem para diversos projetos. Porém, será que essa não foi a causa do 
fracasso do BPM na sua empresa?
Lembre-se que um projeto de BPM visa a solução. [...]
Quando trabalhamos por sprints com ciclos de entrega, as soluções são melhor conduzidas e 
seus resultados aparecem de maneira mais palpável e rápida. Além disso, o risco de entrega de 
algo que não resolve o problema é mitigado. Outro ponto melhorado com o trabalho por ciclos é a 
cultura organizacional, que pouco a pouco se entrelaça com a cultura do BPM. Nada de assustar os 
colaboradores com uma reviravolta repentina em suas rotinas.
Com esses pontos, a curva de aprendizado do projeto sobe rapidamente, já que ele acontece a cada 
ciclo e não apenas ao final do projeto.
3- Achar que o BPM vai salvar o mundo
Quando pensamos que o BPM pode solucionar todos os problemas da organização, estamos 
enganados. Há muitas outras soluções no mercado que podem ser muito mais eficientes para alguns 
cenários. Precisamos ter a maturidade para utilizar a melhor tecnologia existente para atender as 
demandas organizacionais de software.
Além do BPM, temos no mercado produtos standard e o desenvolvimento de aplicações especialistas. 
Cada um resolve perfeitamente uma necessidade.
[...] automação de processos é, sem dúvida, a melhor solução para controle de fluxo de trabalho em 
aplicações restritas. Não adianta achar que ele será o melhor para solucionar necessidades que 
demandam funcionalidades especialistas que seu projeto afundará.
[...] Assim, use o BPM para o que ele realmente é bom e saiba escolher outros produtos quando a 
demanda da organização solicitar isso.”
Fonte: BARRADEL, Ana E. 3 motivos do porquê o BPM não deu certo na sua empresa. Disponível em: 
<http://blog.lecom.com.br/blog/2015/08/04/3-motivos-que-o-bpm-nao-deu-certo/>. BlogLecom, 4 ago. 2015. 
Acesso em: 27 mai. 2017.
Pág. 17 de 97
FIGURA 6 – Quadrinho TI
Fonte: <http://blog.lecom.com.br/wp-content/uploads/2015/08/como-uma-plataforma-bpms-
pode-transformar-uma-organizao-caf-com-bpm-so-paulo-e-rio-de-janeiro-3-638.jpg>
1.4 Áreas de conhecimento em BPM
O guia ABPMP-CBOK divide o BPM em nove áreas de conhecimento que refletem as capacidades 
que devem ser consideradas por uma organização que visa a implantação do BPM. O Quadro 1 
apresenta essas áreas, que são segmentadas na perspectiva organizacional e na perspectiva de 
processos e explicadas em seguida, de acordo com o guia.
Pág. 18 de 97
Quadro 1 - As nove Áreas de Conhecimento do BPM CBOK
Perspectiva de processo
Gerenciamento de processos de negócio
Modelagem deprocessos
Análise de processos
Desenho de processos
Gerenciamento de desempenho de processos
Transformação de processos
Tecnologias de BPM
Perspectiva organizacional
Gerenciamento corporativo de processos
Organização do gerenciamento de processos
Fonte: ABPMP (2013, p. 20)
1. Gerenciamento de processos de negócio: Esta área se concentra nos conceitos fundamentais 
de BPM, tais como definições principais, processos ponta a ponta, valor ao cliente e a 
natureza do trabalho interfuncional. Os tipos e componentes de processos, o ciclo de 
vida BPM, com as habilidades essenciais e fatores de sucesso são abordados, de forma 
que estes fundamentos básicos sirvam de insumo para a exploração das outras áreas de 
conhecimento.
2. Modelagem de processos: Esta área inclui um conjunto fundamental de habilidades e técnicas 
que permitem às pessoas compreenderem, comunicarem e formalizarem os principais 
componentes dos processos de negócio, incluindo uma discussão dos tipos e utilização 
dos modelos de processos, técnicas, ferramentas e padrões de modelagem.
3. Análise de processos: Esta área envolve uma compreensão dos processos de negócio, 
incluindo a eficiência e eficácia dos processos. São exploradas a finalidade e as atividades 
de análise de processos. Uma decomposição dos componentes e atributos do processo, 
técnicas analíticas e padrões dos processos também são abrangidos. O uso de modelos 
de processos e de outra documentação de processos para validar e entender processos 
Pág. 19 de 97
atuais e futuros também é explorado. Vários tipos de análises, técnicas e ferramentas estão 
incluídos nessa área de conhecimento.
4. Desenho de processos: Envolve a criação de especificações de processos de negócio dentro 
do contexto das metas de negócio e dos objetivos de desempenho dos processos. Fornecem 
planos e diretrizes sobre a aplicação de fluxos e regras e sobre como as aplicações do negócio, 
plataformas de tecnologia, recursos de dados, controles financeiros e operacionais interagem 
com outros processos internos e externos. O desenho de processos é o planejamento 
intencional e pensado sobre como os processos de negócio funcionam e são medidos, 
regulados e gerenciados. Essa área de conhecimento explora os papéis, técnicas de desenho 
de processos e princípios de um bom projeto, juntamente com a exploração de padrões 
comuns de desenho e considerações sobre a conformidade, liderança executiva e alinhamento 
estratégico.
5. Gerenciamento de desempenho de processos: É o monitoramento formal e planejado 
da execução do processo e o rastreamento dos resultados para determinar a eficácia e 
eficiência. Essas informações são utilizadas para tomar decisões sobre a melhoria ou 
eliminação de processos existentes e/ou sobre a introdução de novos processos para 
atender aos objetivos estratégicos da organização. Tópicos abrangidos incluem as principais 
definições sobre o desempenho dos processos, a importância e benefícios da medição 
do desempenho, operações de monitoramento e controle, alinhamento dos processos de 
negócio e desempenho organizacional, sobre o que medir, métodos de medição, modelagem 
e simulação, e suporte a decisões de donos e gestores de processos e considerações sobre 
o sucesso.
6. Transformação de processos: Aborda mudanças em processos. As mudanças em processos 
são discutidas no contexto de um ciclo de vida do processo de negócio. Várias metodologias 
de melhoria, redesenho e reengenharia de processos são exploradas, juntamente com 
tarefas associadas à implementação da mudança. O tópico de gerenciamento de mudanças 
organizacionais, elemento fundamental para a transformação bem sucedida do processo, é 
discutido incluindo várias metodologias de gerenciamento de mudanças organizacionais, 
de técnicas e melhores práticas.
7. Tecnologias de gerenciamento de processos: Discute uma ampla gama de tecnologias 
disponíveis para prover suporte ao planejamento, desenho, a análise, operação e monitoramento 
dos processos de negócio. Tecnologias incluem o conjunto de pacotes de aplicações, 
ferramentas de desenvolvimento, tecnologias de infraestrutura e de armazenagem de dados 
e informações que fornecem suporte aos profissionais de BPM e a colaboradores envolvidos 
em atividades de BPM. São discutidos o sistema de gerenciamento de processos de negócio 
Pág. 20 de 97
(BPMS), repositórios de processos e ferramentas independentes para modelagem, análise, 
desenho, execução e monitoramento. Padrões, metodologias e tendências emergentes de 
BPM também são abordados.
8. Gerenciamento corporativo de processos: O gerenciamento de processos corporativos 
é conduzido pela necessidade de maximizar os resultados dos processos de negócio 
consistentes com estratégias organizacionais bem definidas e com as metas funcionais 
baseadas em tais estratégias. O gerenciamento do portfólio de processos garante alinhamento 
com as estratégias da unidade corporativa ou de negócios e fornece um método para 
gerenciar e avaliar as iniciativas. Identifica métodos e ferramentas para avaliar os níveis de 
maturidade de gerenciamento de processos, juntamente com as áreas requeridas de prática 
de BPM que podem melhorar as condições da organização. Várias estruturas de processos 
de negócio são discutidas, juntamente com a noção de integração de processos, ou seja, a 
interação de vários processos entre si e os modelos que vinculam o desempenho, as metas, 
tecnologias, pessoas e controles (financeiros e operacionais) às estratégias corporativas 
e aos objetivos de desempenho. Tópicos de arquitetura de processos e melhores práticas 
de gerenciamento de processos corporativos também são explorados.
9. Organização do gerenciamento de processos: Trata de papéis, responsabilidades e a estrutura 
de reportes para prover suporte a organizações orientadas a processos. É discutido o que 
define uma organização orientada a processos, juntamente com considerações culturais 
e de desempenho da equipe. A importância da governança do processo de negócio é 
explorada, juntamente com várias estruturas de governança e o conceito de um centro de 
especialização/excelência em BPM.
As medições de desempenho são cruciais para o sucesso do BPM. Essas medições são colocadas 
em prática com o objetivo de monitorar o desempenho do processo em relação a fatores como 
tempo, custo, qualidade e capacidade. A Figura 7 ilustra essas medições.
Pág. 21 de 97
Figura 7 - Medições de desempenho por camada organizacional
Nível de
processo
Nível de
função
Área funcional
Área funcional
Processo de
negócio
Medição de eficácia
(fazendo as coisas certas)
Processo de
negócio
Expectativas
do cliente
Processo de
negócio
Processo de
negócio
Processo de
negócio
Processo de
negócio
Processo de
negócio
Processo de
negócio
M
ed
içã
o 
de
 e
fic
iên
cia
 (F
az
en
do
 ce
rto
 as
 co
isa
s)
Decomposto em
Decomposto em
Nível de
função
Executor
Executor
Tarefa
1
Indicador de
desempenho
operacional
Tarefa
3
Tarefa 
2
Decomposto em
Indicador de
desempenho
operacional
Indicador de
desempenho
operacional
Fonte: ABPMP (2013, p. 69).
De acordo com o Figura 7, as medições podem ser obtidas “de fora para dentro”, a partir da 
perspectiva do cliente, e “de dentro para fora”, a partir da perspectiva das operações internas.
Pág. 22 de 97
De acordo com o guia ABPMP (2013), medições de fora para dentro visam responder a pergunta 
“Estamos fazendo a coisa certa?” e são colocadas em prática com o objetivo de garantir que tanto 
as necessidades quanto as expectativas dos clientes sejam atendidas.
Já as medições de dentro para fora visam responder a pergunta“Estamos fazendo certo as 
coisas?” e são colocadas em prática com o objetivo de medir a eficiência dos processos.
Se considerarmos que um processo de negócio é um conjunto de atividades que produz um 
produto ou serviço, a medição do desempenho real do processo comparada com o esperado pode 
ser melhor aferida e monitorada a partir destas duas perspectivas: o aspecto externo (valor para o 
cliente) e o aspecto interno (conjunto de atividades).
ACONTECEU
O cenário atual e a evolução do gerenciamento 
de processos de negócio nas organizações 
brasileiras
 “[...] resultados da 1ª Edição da Pesquisa 
Nacional em Gerenciamento de Processos 
de Negócio realizada em 2013. A pesquisa 
foi realizada pela ABPMP Brasil, com o 
objetivo de identificar o status e evolução do 
Gerenciamento de Processos de Negócio (BPM) 
nas organizações brasileiras, tanto públicas 
quanto privadas. A iniciativa se destaca por 
sua importância para o mercado de BPM, pois 
permite visualizar dados importantíssimos 
como o perfil das organizações, há quantos 
anos a organização vem trabalhando com o 
Gerenciamento de Processos de Negócio, quais 
foram os motivadores para introdução do BPM, 
perfil dos profissionais que trabalham com 
BPM, histórico e status atual das organizações 
que utilizam a filosofia, resultados alcançados 
através do BPM e maturidade das iniciativas, 
bem como tecnologias e notações utilizadas.
Gráfi co 1 - Setores das organizações
ONG e OSCIP
1%
Economia
mista
5%
Pública
26%
Privada
68%
Fonte: <http://blog.lecom.com.br/wp-
content/uploads/grafi co1.jpg>.
Falaremos sobre o Perfil das Organizações que trabalham com BPM. A seguir trazemos alguns dados 
importantes, acompanhados de nossa Análise: Primeiramente, pode-se observar através do gráfico 
1 uma predominância de organizações da rede privada que trabalham com BPM (68%), seguida pela 
rede pública que também possui uma fatia considerável (26%) e pelas organizações de Economia 
Mista (5%) e ONGs e OSCIPs (1%).” (fonte: <http://blog.lecom.com.br/blog/2014/07/21/cenario-atual-evolucao-
gerenciamento-de-processos-de-negocio-nas-organizacoes-brasileiras-parte/>)
Pág. 23 de 97
2. MODELAGEM DE PROCESSOS COM BPMN
Neste capítulo vamos estudar a modelagem de processos com foco na notação BPMN. A 
modelagem de processos é um recurso extraordinário para o planejamento e controle de processos 
de negócios. Processos complexos e longos, principalmente, são difíceis de se visualizar como um 
todo e o seu mapeamento usando a notação BPMN facilita muito a visão geral sobre eles.
FIGURA 8 – Modelagem de processos
Fonte: Tashatuvango / shutterstock.com
2.1 Modelagem de processos de negócios
Em função da natureza abstrata dos processos, ter uma compreensão exata deles torna-se uma 
tarefa difícil sem o uso de um método de modelagem padronizado. A modelagem de processos de 
negócio é uma técnica para compreensão dos processos de uma organização e pode ser considerada 
um mapa que simula o mundo real através da representação de pessoas, materiais de trabalho e 
distribuição de tarefas.
Pág. 24 de 97
Ao fazer a representação dos processos de negócio, busca-se entender a estrutura de uma 
organização e melhorar suas atividades. Usando uma representação gráfica, é possível identificar 
todos os processos realizados, os integrantes da equipe que a executam, os recursos utilizados, 
os resultados produzidos e as informações relacionadas. Desta forma, a modelagem de processos 
de negócio realiza a representação dos processos na forma de um modelo através de métodos e 
notações gráficas específicas.
A modelagem de processos é uma poderosa ferramenta gerencial para identificação de 
oportunidades de melhorias e visualização de restrições e gargalos. A modelagem de processos 
permite que a organização vislumbre tanto oportunidades de melhorias quanto possibilidades de 
aumento do ROI (return on investment), além de tornar possível a identificação de pontos fortes e 
fracos. Isso contribui sobremaneira para que a empresa faça uma gestão mais eficiente, tanto nos 
aspectos estratégicos quanto operacionais.
“A modelagem de processos se baseia em diagramas (Diagramas de Processos) que mostram 
as atividades da empresa, ou de uma área de negócios, e a sequência na qual são executadas. 
A modelagem de um processo pode envolver diversas áreas funcionais, requerendo um trabalho 
conjunto de pessoas nos respectivos setores. Este trabalho de modelagem permite, ainda, que os 
participantes interajam e obtenham um maior entendimento global do negócio.
O modelo do processo é o ponto central para que os participantes definam mudanças para 
melhoramento do processo ou mesmo um desenho completamente novo. Pode ser identificado 
se um processo é eficiente e eficaz, ou mesmo antecipar sua complexidade, redundâncias e não 
conformidades (problemas).
A comunicação do processo, de forma eficiente, para outras pessoas é fundamental. Por melhor que 
seja um processo, se a comunicação para outros for deficiente, principalmente para aqueles que 
vão implementar o processo, o esforço desenvolvido pela equipe terá sido em vão. Bons modelos de 
processos devem ser claros e sucintos (o mais simples possível).”
Fonte: TRENTIM, Mário H. Modelagem de processos de negócio. Techoje, 5 mar. 2010. Disponível em: 
<http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1142>. Acesso em 18 mar. 2017.
Uma abordagem para a modelagem de processos de negócio bem sucedida depende da escolha 
adequada de métodos de modelagem, bem como da aplicação de técnicas e análises de fluxos de 
processos. Isso certamente levará a organização a utilizar um conjunto de ferramentas de forma 
que técnicas diferentes possam ser aplicadas em função das particularidades e dos objetivos da 
modelagem.
Existem diversos padrões de notação para a modelagem de processos. De acordo com o 
guia ABPMP (2013, p. 77), uma notação “[...] é um conjunto padronizado de símbolos e regras 
Pág. 25 de 97
que determinam o significado destes símbolos”. A escolha de uma notação oferece diversas 
vantagens, como:
• Fornece um conjunto de técnicas, símbolos e uma linguagem que funcionam como um meio 
de comunicação padronizado entre as pessoas;
• Oferece consistência de formas e significado nos modelos de processos utilizados;
• Permite a importação e exportação dos modelos entre diferentes ferramentas de software;
• Possibilita a geração de aplicações a partir dos modelos de processos.
O Quadro 2 ilustra diferentes notações de modelagem utilizadas nas organizações.
Quadro 2 - Notações para modelagem de processos de negócio
Notação Descrição
BPMN (Business 
Process Model and 
Notation)
Padrão criado pelo Object Management Group, útil para apresentar um 
modelo para públicos-alvo diferentes.
Fluxograma Originalmente aprovado como um padrão ANSI (American National 
Standards Institute), inclui um conjunto simples e limitado de símbolos 
não padronizados; facilita entendimento rápido do fluxo de um processo.
EPC (Event-driven 
Process Chain)
Desenvolvido como parte da estrutura de trabalho ARIS, considera eventos 
como “gatilhos para” ou “resultados de” uma etapa do processo; útil para 
modelar conjuntos complexos de processos.
UML (Unified Modeling 
Language)
Mantido pelo Object Management Group, consiste em um conjunto-padrão 
de notações técnicas de diagramação orientado à descrição de requisitos 
de sistemas de informação.
IDEF (Integrated 
Definitiono Language)
Padrão da Federal Information Processing Standard dos EUA que destaca 
entradas, saídas, mecanismos, controles de processo e relação dos níveis 
de detalhe do processo superior e inferior; ponto de partida para uma 
visão corporativa da organização.
Value Stream Mapping Do Lean Manufacturing, consiste em um conjuntointuitivo de símbolos 
usado para mostrar a eficiência de processos por meio do mapeamento de 
uso de recursos e elementos de tempo.
Fonte: ABPMP (2013, p. 79)
Pág. 26 de 97
2.2 A notação BPMN
FIGURA 9 – Business process model and notation
Fonte: Profit_Image / shutterstock.com
BPMN (business process model and notation) é uma notação que define um business process 
diagram (BPD) ou diagrama de processos de trabalho utilizando uma técnica baseada em flowchart 
ou diagrama de fluxo. Um BPD é um diagrama utilizado para representar graficamente a sequência 
de todas as atividades que ocorrem durante um processo, mas pode conter vários processos. Ele 
é utilizado pelos analistas que modelam, desenham, controlam e gerenciam os processos. BPMN 
está formatado para dar cobertura a diferentes tipos de mapeamento de processos e permitir a 
criação de um processo de trabalho end to end.
O objetivo do BPMN é dar suporte ao gerenciamento de processo de negócio, não apenas para 
os usuários técnicos, mas também aos usuários da área de negócio, fornecendo uma notação 
intuitiva e de fácil compreensão, tornando-os capazes de representarem processos complexos que 
possam ser entendidos por todos e representar de forma inequívoca os processos organizacionais.
Pág. 27 de 97
De acordo com o guia ABPMP (2013, p. 80), as principais características de um diagrama baseado 
em BPMN são:
• Os ícones são organizados em conjuntos descritivos e analíticos para atender diferentes perfis 
e necessidades.
• A notação permite a indicação de eventos de início, fim e intermediários, fluxos de mensagens 
e atividades, colaboração internegócio e comunicação intranegócio.
Saiba mais
“O Business Process Model and Notation (BPMN), anteriormente conhecido como Business Process 
Modeling Notation, [...] é uma notação da metodologia de gerenciamento de processos de negócio e 
trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento 
do usuário. A modelagem é uma etapa importante da automação pois é nela que os processos são 
descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do 
processo visando a sua otimização. A notação também pode ser utilizada para a modelagem de 
Arquitetura de Processos.
Foi desenvolvido pela Business Process Management Initiative (BPMI) e mantida pelo Object 
Management Group, já que as duas organizações se fundiram em 2005. Em março de 2011, foi 
lançada a versão 2.0 do BPMN.
A BPMN, desde o início, foi apoiada por várias empresas de renome mundial no segmento de 
modelagem de processos, sendo uma resposta independente de fornecedor de solução à demanda 
de modelagem de processos.
A Notação de Modelagem de Processos de Negócio é um padrão para modelagem de processos 
de negócios e fornece uma notação gráfica para a especificação de processos de negócios em 
um Business Process Diagram (BPD), baseado em uma técnica muito semelhante ao de diagramas 
de atividades da Unified Modeling Language (UML). O objetivo do BPMN é de apoiar a gestão de 
processos de negócios tanto para usuários técnicos e usuários de negócios, fornecendo uma notação 
que é intuitiva para os usuários corporativos ainda capaz de representar a semântica complexa do 
processo. A especificação BPMN também fornece um mapeamento entre os gráficos da notação 
para as construções subjacentes de linguagens de execução, particularmente a Business Process 
Execution Language.”
Fonte: BUSINESS Process Model and Notation. Wikipedia, 15 abr. 2017. Disponível em: <https://
pt.wikipedia.org/wiki/Business_Process_Model_and_Notation>. Acesso em 8 jun. 2017.
2.3 Principais elementos do BPMN
De acordo com o guia OMG – BPMN (2013, p. 55), há cinco categorias básicas de elementos, cada 
um dos quais com suas subcategorias, sendo que cada subcategoria ainda possui especificidades:
1. Flow objects (objetos de fluxo)
I. Events (eventos)
Pág. 28 de 97
II. Activities (atividades)
III. Gateways
2. Data (Dados)
I. Data objects (objetos de dados)
II. Data inputs (dados de entrada)
III. Data outputs (dados de saída)
IV. Data stores (armazém de dados)
3. Connecting objects (objetos de conexão)
I. Sequence flows (fluxo sequencial)
II. Message flows (fluxo de mensagem)
III. Associations (associações)
IV. Data associations (associações de dados)
4. Swimlanes
I. Pools
II. Lanes
5. Artifacts (artefatos)
I. Group (grupo)
II. Text annotation (anotação de texto)
No que se segue, caro aluno, vamos detalhar e exemplificar alunos destes elementos considerados 
os mais importantes. Recomendamos que você prossiga seus estudos caso eseje se aprofundar 
mais na utilização do BPMN.
2.4 Pools, lanes, objetos de conexão e artefatos
As swimlanes são formadas por pools (piscinas) e lanes (raias). Um pool assume a forma de 
um retângulo com uma identificação vertical em sua porção esquerda, e é a representação de um 
participante ou entidade em uma colaboração. Embora um pool possa assumir a forma de uma 
“caixa preta” ocultando o que o processo realiza, geralmente apresenta detalhes da maneira que 
um processo será executado. As lanes são subdivisões de um processo, geralmente dentro de um 
pool, e são utilizadas para organizar e categorizar as atividades.
Os objetos de conexão permitem a ligação entre elementos de um diagrama. Um sequence 
flow (fluxo sequencial) é representado por uma seta contínua e é usado para mostrar a ordem em 
que as atividades serão executadas em um processo. Um message flow (fluxo de mensagem) é 
representando por uma seta tracejada e é usado para mostrar o fluxo de mensagens entre participantes 
Pág. 29 de 97
que estejam preparados para enviá-las ou recebê-las. Uma association (associação) é usada para 
ligar informações e artefatos com elementos do diagrama BPMN, sendo representadas por linhas 
pontilhadas com ou sem direção.
Um text annotation (anotação) é um artefato usado para acrescentar informações textuais em 
um diagrama BPMN, sendo simbolizado por uma folha de papel. Um group (grupo) é um artefato que 
serve para agrupar elementos de uma mesma categoria, não influenciando no fluxo das atividades; 
seu símbolo é um retângulo com bordas arredondadas cuja linha é formada por traço e ponto. A 
Figura 10 ilustra estes elementos.
Figura 10 – Pool, lane e objetos de conexão
Pool ou piscina: Representa um processo ou uma entidade
Lane ou raia: É uma subpartição da pool. São usadas para organizar e
categorizar a pool.
Fluxo de sequência: É usado para mostrar a 
ordem em que as atividades serão
executadas. Cada fluxo tem só uma
origem e só um destino.
Fluxo de mensagem: É usado para mostrar o
fluxo de mensagem entre dois participantes,
ou seja, entre duas pools.
Associação: Usada para associar
informações com objetos de fluxos
Pr
oc
es
so
 1
Ad
m
in
ist
ra
çã
o
Re
cu
rs
os
hu
m
an
os
Tarefa 1
Tarefa 1
Tarefa 1
La
ne
 1
La
ne
 2
Pr
oc
es
so
 1
Fonte: DPO/UnB (2015)
Pág. 30 de 97
2.5 Objetos de fluxo: eventos, atividades e gateways
Um evento é algo que acontece durante o curso de um processo. Os eventos afetam o fluxo 
do modelo e geralmente possuem uma causa ou um impacto. São simbolizados por círculos sem 
preenchimento e podem ser de três tipos: start (início), intermediate (intermediário) e end (fim), 
conforme ilustra a Figura 11.
Figura 11 – Eventos: início, intermediário e fim
Evento de início
(Start events)
Evento de intermediário
(intermedate events)
Evento de fim
(end events)
Inicía um
processo
Acontece durante
o curso de um
processo
Finaliza o fluxo
do processo
Fonte: baseado em OMG (2013, p. 59)
Uma atividade indica um trabalho que a organização executa em um processo.A atividade pode 
ser atômica ou composta. São simbolizados como retângulos com bordas arredondadas e podem 
ser sub-process (subprocesso) e task (tarefa), conforme ilustram as figuras 12 e 13.
Figura 12 - Tarefas
Tarefa abstrata: É o tipo de atividade mais frequentemente usado durante os 
estágios iniciais do desenvolvimento do processo.
Tarefa de serviço: É uma atividade que ocorre automaticamente, sem 
necessidade de intervenção humana.
Tarefa de recebimento: É uma atividade de recebimento de mensagem. Tem 
característica similar ao evento intermediário de recebimento de mensagem.
Tarefa de envio: É uma atividade de envio de mensagem. Tem característica 
similar ao evento intermediário de envio de mensagem.
Tarefa de usuário: É utilizada quando a atividade é executada por uma pessoa 
com o auxílio/por intermédio de um sistema.
Tarefa de execução de script: É utilizado quando na execução da atividade 
existe um roteiro a ser seguido (ckeck list).
Tarefa manual: É uma atividade que é executada por uma pessoa, sem 
qualquer intervenção de sistema
Tarefa de regra de negócio: Propicia um mecanismo para o processo enviar 
informações a um Business Rules Engine (motor de regras de negócio) e obter 
o resultado do cálculo que o motor de regras pode prover.
Subprocesso incorporado: Herda todas as características do processo em que 
está inserido. Não pode conter pscinas (pools) ou raias (lanes).
Subprocesso reutilizável: É uma referência ao diagrama de outro processo, 
indicando que está sendo reutilizado no fluxo em que está inserido.
Subprocesso eventual: Representa um conjunto lógico de atividades que pode 
ou não acontecer durante a execução de um processo e cujo início não está 
vinculado à sequência de atividades do fluxo, mas à ocorrência de um evento
Subprocesso transacional: Conjunto de atividades logicamente relacionadas 
que devem ser realizadas em uma única transação (por exemplo, uma operação 
bancária).
Fonte: iProcess Education (2014)
Pág. 31 de 97
Figura 13 – Subprocessos
Tarefa abstrata: É o tipo de atividade mais frequentemente usado durante os 
estágios iniciais do desenvolvimento do processo.
Tarefa de serviço: É uma atividade que ocorre automaticamente, sem 
necessidade de intervenção humana.
Tarefa de recebimento: É uma atividade de recebimento de mensagem. Tem 
característica similar ao evento intermediário de recebimento de mensagem.
Tarefa de envio: É uma atividade de envio de mensagem. Tem característica 
similar ao evento intermediário de envio de mensagem.
Tarefa de usuário: É utilizada quando a atividade é executada por uma pessoa 
com o auxílio/por intermédio de um sistema.
Tarefa de execução de script: É utilizado quando na execução da atividade 
existe um roteiro a ser seguido (ckeck list).
Tarefa manual: É uma atividade que é executada por uma pessoa, sem 
qualquer intervenção de sistema
Tarefa de regra de negócio: Propicia um mecanismo para o processo enviar 
informações a um Business Rules Engine (motor de regras de negócio) e obter 
o resultado do cálculo que o motor de regras pode prover.
Subprocesso incorporado: Herda todas as características do processo em que 
está inserido. Não pode conter pscinas (pools) ou raias (lanes).
Subprocesso reutilizável: É uma referência ao diagrama de outro processo, 
indicando que está sendo reutilizado no fluxo em que está inserido.
Subprocesso eventual: Representa um conjunto lógico de atividades que pode 
ou não acontecer durante a execução de um processo e cujo início não está 
vinculado à sequência de atividades do fluxo, mas à ocorrência de um evento
Subprocesso transacional: Conjunto de atividades logicamente relacionadas 
que devem ser realizadas em uma única transação (por exemplo, uma operação 
bancária).
Fonte: iProcess Education (2014)
Um gateway é usado para controlar 
divergências e convergências de fluxos 
sequenciais de um processo. Dessa forma, 
ele determina ramificação, intercalação, 
bifurcação e união de caminhos. Os 
gateways são representados como 
losangos, dentro dos quais os sinais 
indicam que tipo de comportamento é 
controlado. A Figura 14 ilustra os tipos 
de gateways: exclusive (exclusivo), event 
based (baseado em evento), paralell 
(paralelo), inclusive (inclusivo), exclusive 
event based (exclusivo baseado em evento), 
complex (complexo) e parallel event based 
(paralelo baseado em evento).
Figura 14 – Gateways
Exclusive Event based Parallel
Inclusive Exclusive
event based
Parallel event
based
Complex
Fonte: baseado em OMG (2013, p. 61)
Pág. 32 de 97
A Figura 15 reúne diversos exemplos de elementos BPMN utilizando eventos, atividades, gateways 
e setas que representam fluxos sequenciais.
Figura 15 – Exemplos de elementos BPMN
Avaliar
artigo
Enviar proposta
de crédito
Cancelar
artigo
Comunicar
partes
interessadas
Realizar
revisão final
Publicar
artigo
Ajustar
artigo
Enviar contrato
ao cliente
Notificar
gerência sobre
cancelamento
Contatar
novamente o
cliente
Identificar
documentação
necessária
Anexar negativa
criminal
Analisar 
validade
dos documentos
Anexar
negativa civil
Anexar negativa
de débitos
Definir tema
do artigo
Realizar
diagramação
Escrever
artigo
Tratar
imagens
Selecionar
imagens
Não 
Não 
5 dias
Negativa civil
Negativa
criminal
Negativa de
débitos
Fonte: DPO/UnB (2015)
Pág. 33 de 97
2.6 Exemplos de diagramas BPMN
Em um diagrama usando BPMN, cada participante é representado em um pool, e as raias dividem-
no em linhas paralelas, sendo cada raia associada a um participante que realiza as atividades. O 
fluxo de trabalho se move de atividade para atividade seguindo o fluxo, podendo envolver diversos 
participantes. A Figura 16 ilustra diferentes tipos de processos que podem ser representados por 
diagramas BPMN, e a Figura 17 apresenta um diagrama completo.
Figura 16 – Exemplos de processos representados por diagramas BPMN
Tarefa 1
Tarefa 2
Tarefa 3
5 dias
Pr
oc
es
so
 1
Tarefa 1
Tarefa 2
Tarefa 3P
ro
ce
ss
o 
1
Pr
oc
es
so
 1
Privativo: São utilizados quando não há interesse em verificar a interação entre esse processo e outros
Abstrato: Representam a interação entre um processo principal e outro processo participante. Em relação ao 
processo participante, não há preocupação com o contéudo do fluxo em si, mas sim como ele colabora com os 
outros fluxos.
Colaborativo: Descreve a interação entre duas ou mais entidades do negócio, sendo que o conteúdo do fluxo 
é especificado em todas as entidades
5 dias
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 1 Tarefa 1 Tarefa 1
Pr
oc
es
so
 1
Pr
oc
es
so
 1
Fonte: DPO/UnB (2015)
Pág. 34 de 97
Figura 17 – Diagrama BPMN
Cl
ie
nt
e
Ed
ito
ra
Registrar
pedido
Emitir
cobrança
Emitir
nota fiscal
Emitir
nota fiscal
Emitir
nota fiscal
Emitir
nota fiscal
Pedido de livros Título decobrança
Confirmação
de pagamento
Livros
vendidos
Confirmação de
recebimento
Receber
pedido do
cliente
Um ou 
mais itens 
indisponíveis
Cobrança
enviada
Recebimento
confirmado
Fim
Entrega da
encomenda
Entrega da
encomenda
Encomendar obra
Pr
oc
es
so
 v
en
de
r l
iv
ro
s v
ia
 W
eb
Ex
pe
di
çã
o
Co
br
an
ça
At
en
di
m
en
to
Fonte: <http://blog.iprocess.com.br/wp-content/uploads/2014/05/blog-da-
iprocess-processo-vender-livros-via-web-guia-bpmn-21.png>
Pág. 35 de 97
SAIBA MAIS
Modelo e notação de decisões – DMN
“Devido ao crescimento das discussões sobre a necessidade das organizações dominarem a 
gestão de decisões de negócio, a Object Management Group (OMG) criou uma subcomissãocom 
o objetivo de desenvolver esse campo de estudo e dessa iniciativa surgiu a especificação DMN 
(Decision Modeland Notation). A especificação tem por objetivo fornecer uma notação para decisões 
compreensível para todos os públicos, incluindo o pessoal de negócios e técnicos, e é composta de 
cinco componentes principais:
• uma notação no nível dos requisitos, que permite aos analistas de negócio identificarem 
requisitos iniciais de decisão;
• uma notação no nível da lógica das decisões, que permite detalhar como as decisões serão 
tomadas;
• uma linguagem de expressões chamada FEEL (Friendly Enough Expression Language – 
Linguagem de Expressões Suficientemente Amigável), que permite a expressão das diferentes 
lógicas de decisão de negócios;
• níveis específicos de conformidade, que permitem a validação automática de modelos de 
decisão; e
• um metamodelo de suporte, que permite a automatização de modelos de decisão e o intercâmbio 
desses modelos entre diferentes sistemas.
[...]
Na figura abaixo, baseada do exemplo da própria especificação da DMN, a imagem da esquerda 
representa um diagrama de processo (modelado na notação BPMN) enquanto que na direita há 
diagramas de um modelo DMN relacionado.”
Fonte: GOMES, Luciano. DMN: uma notação para modelagem de decisões de negócios. iPROCESS, 
23 dez. 2014. Disponível em: <http://blog.iprocess.com.br/2014/12/dmn-uma-notacao-para-modelagem-de-
decisoes-de-negocios/>. Acesso em: 8 jun. 2017.
Pág. 36 de 97
Figura 18 - Modelo e notação de decisões – DMN
Modelo de processo de negócio
Modelo de decisão
(DMN)
Nível de lógica
de decisão
Nível de Requisitos
de decisão
Operação
Risco da
operação Elegibilidade
Regras de
elegibilidade
Roteamento
Situação de
emprego País Idade Elegível
Inelegível
Inelegível
Inelegível
Inelegível<18
not(Brasil)
Desempregado
Elegível
Elegibilidade
-
-
- -
-
-
-
-
-
P
1
2
3
4
Regras de elegibilidade
Tabela de
roteamento
Modelo de
pontuação de riscos
das coerações
Recusar
cliente
Recusar
cliente
Decidir
roteamento
Coletar dados
da aplicação
Fonte: <http://blog.iprocess.com.br/wp-content/uploads/2014/12/Compara%C3%A7%C3%A3o1.png>
Pág. 37 de 97
3. NORMAS DE QUALIDADE ISO
Neste capítulo apresentaremos as principais normas ISO que avaliam a qualidade de produto 
de software.
3.1 Modelos e normas de qualidade de software
FIGURA 19 – Modelos e normas de qualidade de software
Fonte: Ohmega1982 / shutterstock.com
A qualidade de software é um aspecto da engenharia de software que vem evoluindo, tanto em 
relação à qualidade do processo (da concepção à construção e manutenção) quanto em relação à 
qualidade do produto (o software em si).
Qualidade de software, de acordo com Pressman (2011, p. 360) se refere a “[...] uma gestão 
de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para 
aqueles que o produzem e para aqueles que o utilizam”.
Qualidade não é uma fase do ciclo de desenvolvimento de software, mas um integrante fundamental 
de todas as fases. Portanto, é necessário um planejamento adequado para que metas de qualidade 
de software sejam atingidas. Para isso são necessários modelos, padrões, procedimentos e 
técnicas para atingir as metas de qualidade propostas. Assim, todas as etapas do ciclo de vida de 
engenharia de software devem ser contempladas com atividades que visam garantir a qualidade 
tanto do processo quanto do produto.
Um dos primeiros modelos de qualidade de software é o que James A. McCall (2002) propõe 
como métricas para qualidade de software. Conhecidos como fatores da qualidade, eles avaliam o 
Pág. 38 de 97
software em três pontos distintos: operação do produto, transição do produto e revisão do produto, 
conforme ilustra a figura 20.
• Operação: refere-se às características relativas ao uso do produto. Envolve os critérios de 
qualidade correção, confiabilidade, eficiência, integridade e usabilidade.
• Revisão: refere-se à capacidade do produto ser modificado e evoluído. Envolve os critérios de 
qualidade manutenibilidade, flexibilidade e testabilidade.
• Transição: refere-se à adaptabilidade a novos e diferentes ambientes. Envolve os critérios 
portabilidade, reusabilidade e interoperabilidade.
Figura 20 – Fatores de qualidade do software de McCall
Manutenibilidade: posso consertá-lo?
Flexibilidade: posso mudá-lo?
Testabilidade: posso restá-lo?
Corretitude: ele faz o que foi especificado?
Confiabilidade: ele tem precisão o tempo todo?
Eficiência: ele rodará neste Hw em tempo 
adequado?
Integridade: ele oferece segurança?
Usabilidade: ele foi construído para o usuário?
Adaptabilidade: ele se adapta ao usuário?
Portabilidade: posso usá-lo em outro SO?
Reusabilidade: posso reutilizar parte do Sw?
Interoperabilidade: posso compor uma interface 
com outro sistema?
Revisão Transição
Operação
Fonte: baseado em Pressman (2011, p. 362)
Naturalmente surgiram outros modelos e normas para avaliação da qualidade do produto de 
software, notadamente as homologadas pela ISO (International Organization for Standardization) 
juntamente à IEC (International Electro-Technical Commission). A abordagem das normas da série 
ISO fundamenta-se na documentação do sistema de qualidade, estabelecendo a visão da empresa 
com relação aos interesses e necessidades dos clientes e, por isso, resulta na percepção deles. A 
abordagem da ISO para qualidade é considerada uma das mais antigas e bem estabelecidas para 
a indústria em geral e tem ampliado seu espaço nas empresas de software.
Pág. 39 de 97
Além do objetivo principal de alcançar a qualidade, as organizações podem almejar a obtenção 
de certificações de qualidade que são adquiridas por meio da utilização destas normas e modelos.
CURIOSIDADE
A ISO (International Organization for Standardization ou, em português, Organização Internacional 
de Normalização) é formada por representantes de diversos países, cada um representado por um 
organismo de normas, testes e certificação. O ANSI (American National Standards Institute) é o 
representante ISO dos Estados Unidos e no Brasil a ISO é representada pela ABNT (Associação 
Brasileira de Normas Técnicas). A ABNT é uma organização que apoia o desenvolvimento de normas 
consensuais e providencia estrutura e mecanismos a fim de que grupos industriais ou de produtos se 
juntem para estabelecer um consenso e desenvolver diretivas de qualidade.
Fonte: KOSCIANSKI, André; SOARES, Michel S. Qualidade de software. São Paulo: Novatec, 2009.
De acordo com Koscianski e Soares (2009, p. 156), 
as normas da família ISO 9000 foram desenvolvidas 
para aplicação em qualquer organização em qualquer 
ramo de atividade, notadamente do setor produtivo, que 
deseja realizar o controle de qualidade dos produtos ou 
serviços oferecidos.
FIGURA 21 – ISO (International 
Organization for Standardization)
Fonte: <https://www.iso.org/modules/
isoorg-template/img/iso/iso-logo-print.gif>
CURIOSIDADE
“A família das normas ISO 9000 nasceu em 1987 e evoluiu nos anos de 1994, 2000, 2005 e 2008 
incorporando as melhores práticas, lições aprendidas, inovações e evolução requeridas pelas 
empresas e mercado.
A NBR ISO 9001:2008 Sistemas de Gestão da Qualidade faz parte da família de normas ISO 9000 
e estabelece requisitos que auxiliam a melhoria dos processos internos, a maior capacitação dos 
colaboradores, o monitoramento do ambiente de trabalho, a verificação da satisfação dos clientes, 
colaboradores e fornecedores, em um processo contínuo de melhoria do sistema de gestão da 
qualidade. Aplica-se a campos distintos dentre eles: materiais, de produtos, de processos e serviços.”
Fonte: ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO(SOFTEX). MPS .
BR - Melhoria de Processo do Software Brasileiro. Brasília: Softex, 2016. p. 15. Disponível em: <http://
www.softex.br/wp-content/uploads/2016/04/MPS.BR_Guia_Geral_Software_2016-com-ISBN.pdf?x15632>. Acesso 
em: 8 jun. 2017.
Pág. 40 de 97
 3.2 Norma ISO 14598 - Avaliação 
de produtos de software
Desenvolver software com qualidade tem sido um grande 
desafio, pois estabelecer prazos, especificar requisitos, estimar 
custos e recursos e cumprir todos esses quesitos não são 
atividades simples. É necessário um controle muito grande dos 
processos que envolvem a fabricação do software, desde a sua 
criação até a sua completa instalação no cliente. Um desafio 
ainda maior é conseguir identificar, ao final do desenvolvimento, 
se o produto de software atende aos requisitos previamente 
estabelecidos. Com a finalidade de auxiliar nestas complexas 
tarefas, processos de avaliação de produtos de software foram 
desenvolvidos e consolidados na Norma ISO 14598.
FIGURA 22 - Importante
A avaliação de produtos de 
software é defi nida como uma 
operação técnica que consiste 
em elaborar um julgamento de 
uma ou mais características de 
um produto de software de acordo 
com um procedimento defi nido. 
Fonte: Norma ISO 14598
A norma ISO 14598 traz macroprocessos de avaliação de qualidade de produtos de software 
que podem ser instanciados para avaliação do produto por desenvolvedores ou agentes externos, 
dependendo dos objetivos e da infraestrutura da organização. A Figura 23 mostra o processo 
proposto na ISO 14598-5 para avaliação por agentes externos.
Figura 23 – Processo de avaliação de software - ISO 14598-5
Requisitos do
requisitante Estabelecimento
dos requisitos da
avaliação
Requisitos de
avaliação
Especificação da
avaliação
Descrição do
produto
Entradas fornecidadas
pelo avaliador
Métodos de
avaliação
Plano de
avaliação
Ferramentas de
avaliaçãoComponentes 
do produto
Entradas fornecidas
pelo requisitado
Especificação
da avaliação
predefinida
Projeto da
avaliação
Execução de
avaliação
Síntese dos resultados
de avaliação
Relatório
de avaliação
preliminar
Relatório
de avaliação
revisado
Conclusão da
avaliação
Registros de ações
de revisão
Registros de
avaliação
Especificação da
avaliação
Fonte: <https://www.goconqr.com/p/4613970-2--qualidade-de-produto-de-software-slide_sets>.
Pág. 41 de 97
Cada fase descrita na Figura 23 possui uma série de recomendações, porém, como toda norma, 
ela recomenda o que fazer mas não explica como deve ser feito. As principais etapas são:
• Estabelecimento dos requisitos da avaliação, em que os requisitos do software são recebidos 
e os requisitos da avaliação são definidos.
• Especificação da avaliação, no qual utiliza-se a descrição do produto e os requisitos da avaliação 
para definir o que será contemplado na avaliação.
• Projeto da avaliação, no qual os dados utilizados na etapa anterior são agregados ao conhecimento 
de métodos de avaliação e projeta-se o plano de avaliação.
• Execução da avaliação, em que são utilizadas ferramentas específicas para se colocar o plano 
de avaliação em prática.
• Conclusão da avaliação, quando o relatório de avaliação é gerado, todos os resultados obtidos 
são sintetizados e um parecer é emitido para o requisitante da avaliação.
As etapas “estabelecimento dos requisitos da avaliação” e “especificação da avaliação” são 
cruciais da avaliação, pois representam o momento em que é definido o que se medirá no software 
e os níveis aceitáveis dessas medidas.
3.3 Norma ISO 9126 – Modelo de qualidade de software
FIGURA 24 – Qualidade de software
Fonte: Tashatuvango / shutterstock.com
Pág. 42 de 97
A norma ISO 9126 define um conjunto de quesitos que visam padronizar a avaliação da qualidade 
de software. A norma divide-se em quatro partes (conforme ilustra a Figura 25), sendo a primeira 
uma visão geral do modelo de qualidade e as outras três os grupos de métricas definidas para 
este modelo:
• Parte 1: Modelo de qualidade
• Parte 2: Métricas externas
• Parte 3: Métricas internas
• Parte 4: Métricas de qualidade em uso
Qualidade externa se refere ao produto final como observado pelo usuário, e qualidade interna se 
relaciona com a estrutura e as características do produto relativas ao seu projeto e à sua construção.
Figura 25 – Visão geral do modelo de qualidade ISO 9126
Qualidade do 
processo
Atributos de 
qualidade interna
Atributos de 
qualidade externa
Atributos de 
qualidade em uso
Processo Produto de software Efeitos de produto
de software
Medidas de
processo
Medidas
internas
Medidas
externas
Medidas de
qualidades de
uso
Influência
Depende de
Influência
Depende de
Influência
Depende de
Fonte: <https://cdn.goconqr.com/uploads/slide_property/image/303752/desktop_45e4f79c-8bf6-4dc4-9148-90240f41f05b.jpg>
A norma ISO 14598 recomenda a utilização do modelo de qualidade proposto na norma ISO 9126, 
que é o mais difundido na indústria. A norma 9126 tem foco na qualidade do produto de software 
e propõe atributos de qualidade distribuídos em seis características principais, cada qual, por sua 
vez, divididas em subcaracterísticas, conforme ilustra a Figura 26.
Conforme podemos observar na Figura 26, todas as características de qualidade apresentam 
uma subcaracterística em comum: a conformidade. De acordo Koscianski e Soares (2009, p. 
210), com a conformidade pode-se abranger atributos como padrões internos da organização ou 
exigências de legislação aplicáveis. É utilizada para avaliar o quanto o software respeita requisitos 
legais, padronizações ou normalizações aplicáveis.
Pág. 43 de 97
Figura 26- Modelo de Qualidade - ISO 9126 (parte 1)
Qualidade 
externa e 
interna
Funcionalidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade
Adequação
Acurácia
Interoperabilidade
Segurança de 
acesso
Conformidade 
relacionada à 
funcionalidade
Maturidade
Tolerância a falhas
Recuperabilidade
Conformidade 
relacionada à 
confiabilidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Atratividade
Conformidade 
relacionada à 
usabilidade
Comportamento 
em relação ao 
tempo
Utilização de 
recursos
Conformidade 
relacionada à 
eficiência
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Conformidade 
relacionada à 
manutenibilidade
Adaptabilidade
Capacidade para 
ser instalado
Coexistência
Capacidade para 
substituir
Conformidade 
relacionada à 
portabilidade
Fonte: NBR ISO/IEC 9126-1:2003 (p. 7)
A Norma NBR ISO/IEC 9126-1:2003 (p. 8-11), na parte 1, que trata do modelo de qualidade, define 
assim as seis características de qualidade:
1. “Funcionalidade: Capacidade do produto de software de prover funções que atendam às 
necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições 
especificadas. Suas subcaracterísticas são:
• Adequação: capacidade do produto de software de prover um conjunto apropriado de 
funções para tarefas e objetivos do usuário especificados;
• Acurácia: capacidade do produto de software de prover, com o grau de precisão necessário, 
resultados ou efeitos corretos ou conforme acordados;
• Interoperabilidade: capacidade do produto de software de interagir com um ou mais 
sistemas especificados;
• Segurança de acesso: capacidade do produto de software de proteger informações 
e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem 
modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados;
• Conformidade relacionada à funcionalidade: capacidade do produto de software de estar 
de acordo com normas, convençõesou regulamentações previstas em leis e prescrições 
similares relacionadas à funcionalidade.
Pág. 44 de 97
2. Confiabilidade:capacidade do produto de software de manter um nível de desempenho 
especificado, quando usado em condições especificadas. Suas subcaracterísticas são:
• Maturidade: capacidade do produto de software de evitar falhas decorrentes de defeitos 
no software;
• Tolerância a Falhas: capacidade do produto de software de manter um nível de desempenho 
especificado em casos de defeitos no software ou de violação de sua interface especificada;
• Recuperabilidade: capacidade do produto de software de restabelecer seu nível de 
desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha;
• Conformidade relacionada à confiabilidade: capacidade do produto de software de estar 
de acordo com normas, convenções ou regulamentações relacionadas à confiabilidade.
3. Usabilidade: Capacidade do produto de software de ser compreendido, aprendido, operado e 
atraente ao usuário, quando usado sob condições especificadas. Suas subcaracterísticas são:
• Inteligibilidade: capacidade do produto de software de possibilitar ao usuário compreender 
se o software é apropriado e como ele pode ser usado para tarefas e condições de uso 
específicas;
• Apreensibilidade: capacidade do produto de software de possibilitar ao usuário aprender 
sua aplicação;
• Operacionalidade: capacidade do produto de software de possibilitar ao usuário operá-lo 
e controlá-lo;
• Atratividade: capacidade do produto de software de ser atraente ao usuário;
• Conformidade relacionada à usabilidade: capacidade do produto de software de estar 
de acordo com normas, convenções, guias de estilo ou regulamentações relacionadas 
à usabilidade.
4. Eficiência: capacidade do produto de software de apresentar desempenho apropriado, relativo 
à quantidade de recursos usados, sob condições especificadas. Suas subcaracterísticas são:
• Comportamento em relação ao tempo: capacidade do produto de software de fornecer 
tempos de resposta e de processamento, além de taxas de transferência, apropriados, 
quando o software executa suas funções, sob condições estabelecidas;
• Utilização de Recursos: capacidade do produto de software de usar tipos e quantidades 
apropriados de recursos, quando o software executa suas funções sob condições 
estabelecidas;
• Conformidade relacionada à eficiência: capacidade do produto de software de estar de 
acordo com normas e convenções relacionadas à eficiência.
Pág. 45 de 97
5. Manutenibilidade: Capacidade do produto de software de ser modificado. As modificações 
podem incluir correções, melhorias ou adaptações do software devido a mudanças no 
ambiente e nos seus requisitos ou especificações funcionais. Suas subcaracterísticas são:
• Analisabilidade: capacidade do produto de software de permitir o diagnóstico de deficiências 
ou causas de falhas no software, ou a identificação de partes a serem modificadas;
• Modificabilidade: capacidade do produto de software de permitir que uma modificação 
especificada seja implementada;
• Estabilidade: capacidade do produto de software de evitar efeitos inesperados decorrentes 
de modificações no software;
• Testabilidade: capacidade do produto de software de permitir que o software, quando 
modificado, seja validado;
• Conformidade relacionada à manutenibilidade: capacidade do produto de software de 
estar de acordo com normas ou convenções relacionadas à manutenibilidade.
6. Portabilidade: capacidade do produto de software de ser transferido de um ambiente para 
outro. Suas subcaracterísticas são:
• Adaptabilidade: capacidade do produto de software de ser adaptado para diferentes 
ambientes especificados, sem necessidade de aplicação de outras ações ou meios além 
daqueles fornecidos para essa finalidade pelo software considerado;
• Capacidade para ser instalado: capacidade do produto de software para ser instalado 
em um ambiente especificado;
• Coexistência: capacidade do produto de 
software de coexistir com outros produtos 
de software independentes, em um ambiente 
comum, compartilhando recursos comuns;
• Capacidade para Substituir: capacidade 
do produto de software de ser usado em 
substituição a outro produto de software 
especificado, com o mesmo propósito e 
no mesmo ambiente;
• Conformidade relacionada à portabilidade: capacidade do produto de software de estar 
de acordo com normas ou convenções relacionadas à portabilidade.”
FIGURA 27 – Certificação ISO
Fonte: Aquir / shutterstock.com
Pág. 46 de 97
3.4 Normas ISO 25000
As normas ISO/IEC 9126, que tratam da qualidade do produto e ISO/IEC 14598, que tratam de 
avaliação de produto de software, estão integradas na série de normas ISO/IEC 25000, conhecida 
como SQuaRE (Software product Quality Requirements and Evaluation).
O projeto SQuaRE reorganizou o material existente nas duas séries de normas, mas não realizou 
mudanças significativas no material preexistente. Segundo Koscianski e Soares (2009, p. 206),
• a norma abrange amplamente aspectos relativos à qualidade de produto de software e define 
uma base para se definir tanto o modelo quanto a avaliação;
• os documentos oferecem um cunho didático, elencando exemplos;
• os documentos resultaram de um esforço e consenso de centenas de pesquisadores, 
representando uma soma de experiências;
• outros modelos de qualidade podem ser mapeados para o modelo SQuaRE.
 As normas ISO/IEC 25000 têm seu núcleo principal composto por cinco divisões:
• ISO/IEC 2500n – Divisão Gestão da Qualidade
• ISO/IEC 2501n – Divisão Modelo de Qualidade
• ISO/IEC 2502n – Divisão Medição da Qualidade
• ISO/IEC 2503n – Divisão Requisitos de Qualidade
• ISO/IEC 2504n – Divisão Avaliação da Qualidade
Figura 28 – SquaRE – Série de normas
Série de 
normas 9126
Série de 
normas 14698
SQuaRE: Série 
de normas 
25000
Fonte: <https://pt.slideshare.net/andradejeff/jefferson-andrade-norma-abnt-nbr-isoiec-25000-square>.
3.5 A norma ISO/IEC 12207
O objetivo da norma ISO/IEC 12207 é estabelecer uma estrutura comum para os processos 
de ciclo de vida de software, com uma terminologia bem definida, que pode ser referenciada pela 
Pág. 47 de 97
indústria de software. Koscianski e Soares (2009, p. 164) afirmam que a norma não define um ciclo 
de vida, pois foi concebida como um modelo que aponta uma meta de ciclo de vida, a partir do qual 
cada organização define seus próprios processos.
O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software, desde sua concepção até 
a sua descontinuidade, incluindo todos os envolvidos com produção, manutenção e operação do 
software. Os processos da ISO/IEC 12207 são agrupados de acordo com o seu objetivo principal 
no ciclo de vida de software, resultando em três classes de processos: processos fundamentais ou 
primários, processos de apoio e processos organizacionais. A Figura 29 apresenta os processos 
de cada classe, que são explicados sucintamente.
Figura 29 - Processos da norma ISO/IEC 12207
Aquisição
Processos fundamentais
Aquisição
Operação
Manutenção
Desenvolvimento
Documentação
Processos de apoio
Gerência de configuração
Resolução de problemas
Garantia da qualidade
Verificação
Validação
Revisão conjunta
Auditoria
Gerência Infraestrutura Melhoria Treinamento
Processos organizacionais
Fonte: <http://slideplayer.com.br/slide/290277/>
3.5.1 Processos fundamentais (primários)
1. Os processos fundamentais (ou primários) da norma são os seguintes:
2. Processo de aquisição - define as atividades de aquisição da organização (a organização 
que adquire um sistema, produto de software ou serviço).
3. Processo de fornecimento - define as atividadesdo fornecedor da organização (a organização 
que fornece o sistema, o produto de software ou o serviço do software ao cliente).
4. Processo de desenvolvimento - define as atividades da equipe de desenvolvimento da 
organização (a organização que define e desenvolve o produto de software).
Pág. 48 de 97
5. Processo de operação - define as atividades de operação 
da organização (a organização que fornece o serviço de 
operar um sistema).
6. Processo de manutenção - define as atividades de 
manutenção do software da organização (a organização 
que fornece o serviço de manter o produto de software; 
isto é, gerir as modificações do produto de software para 
mantê-lo atualizado e operacional).
3.5.2 Processos de apoio
Os processos de suporte da norma são:
1. Processo de documentação - define as atividades para registrar a informação produzida 
por um processo do ciclo de vida.
2. Processo de gestão de configurações - define as atividades de gestão de configuração.
3. Processo de garantia da qualidade - define as atividades para assegurar de forma objetiva 
que os produtos e os processos de software estão em conformidade com os requisitos 
especificados e conforme o planejado. As revisões conjuntas, as auditorias, a verificação 
e a validação podem ser usadas como técnicas da garantia de qualidade.
4. Processo de verificação - define as atividades (para o cliente, o fornecedor ou outro 
stakeholder) para verificar os produtos de software.
5. Processo de validação - define as atividades (para o cliente, o fornecedor ou outro stakeholder) 
para validar os produtos de software.
6. Processo de revisão - define as atividades para avaliar o estado e os produtos de uma atividade.
7. Processo de auditoria - define as atividades para determinar a conformidade com os 
requisitos, planejamento e contrato.
8. Processo de resolução de problemas - define um processo para analisar e resolver problemas 
(incluindo não conformidades), qualquer que seja a sua natureza ou fonte detectadas no 
decorrer do desenvolvimento, operação, manutenção ou outro processo.
3.5.3 Processos organizacionais
São quatro os processos organizacionais da norma:
FIGURA 30 – Processos de apoio
Fonte: Flat Design / 
shutterstock.com
Pág. 49 de 97
1. Processo de gestão - define as atividades básicas de gestão, incluindo a gestão de projeto, 
durante o ciclo de vida.
2. Processo de infraestrutura - define as atividades básicas para estabelecer a infraestrutura.
3. Processo de melhoria - define as atividades básicas ligadas ao desempenho da organização 
(quer seja cliente, fornecedor, equipes de desenvolvimento e manutenção ou gestor de outro 
processo) para estabelecer a medição, controle e melhoria do ciclo de vida.
4. Processo de formação - define as atividades para proporcionar a formação adequada aos 
colaboradores.
A implementação da norma consiste na definição ou seleção de um modelo de ciclo de vida de 
software apropriado ao escopo, magnitude e complexidade do projeto e nas seguintes atividades:
a) execução de documentação dos resultados, de acordo com o processo de documentação;
b) colocação dos resultados sob o processo de gerência de configuração;
c) execução do controle de alterações;
d) documentação e resolução de não-conformidades e problemas encontrados nos produtos 
de software e tarefas, de acordo com o processo de resolução de problema;
e) execução dos processos de apoio, conforme especificado no contrato;
f) seleção, adaptação e utilização de padrões, métodos, ferramentas e linguagens de 
programação de computador;
g) desenvolvimento dos planos para conduzir as atividades do processo de desenvolvimento.
3.6 A norma ISO/IEC 15504
O início da norma 15504 remonta ao início da década de 1990, quando a ISO iniciou o projeto 
Spice (Software Process Improvement and Capability Determination) como resultado de um estudo 
chamado “Necessidades e exigências para uma norma de avaliação de processos de software”. 
Esse estudo concluiu que era necessária a elaboração de uma norma que fosse aplicável à melhoria 
de processos e à determinação da capacidade, que culminou com a norma 15504.
A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois 
objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade 
organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar 
uma avaliação com o objetivo de gerar um perfil dos processos que serão usados para a elaboração 
de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e 
os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um 
fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao 
Pág. 50 de 97
contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar 
na tomada de decisão de contratá-lo ou não (SOFTEX, 2016).
Uma das vantagens desta norma é que ela integra padrões existentes de forma muito flexível. 
Mas sua aplicação na prática requer muito esforço, tempo e experiência consideráveis, o que 
complica sua aplicação em micro e pequenas empresas de software.
Os principais benefícios de uma organização com a adoção da norma são:
• Determinação da capacidade dos processos: esta norma é uma ferramenta que permite às 
empresas avaliar o estado dos seus processos em comparação com as melhores práticas, 
através da identificação das suas forças, fraquezas e riscos. Com base nesta avaliação, poderão 
decidir se têm a capacidade para empreender um determinado projeto.
• Melhoria dos processos: as empresas poderão identificar quais os processos que devem 
melhorar, o que deverá ser feito para este fim e deduzir onde devem investir em primeiro lugar, 
com vista à obtenção de retornos rápidos e significativos. De uma forma simplificada, podemos 
afirmar que com o resultado desta avaliação uma organização saberá onde se encontra, para 
onde se deve dirigir e como deve fazer.
Pág. 51 de 97
4. CMMI
Neste capítulo trataremos do modelo CMMI (Capability Maturity Model Integration), apresentando o 
modelos CMM, seus antecedentes históricos, e detalhando seu modelo de maturidade e representações.
4.1 Antecedentes históricos: modelos CMM para 
qualidade de processo de software
FIGURA 31 – Modelos CMM para qualidade de processo de software
Fonte: Profit_Image / shutterstock.com
Os modelos CMM (Capability Maturity Model) são construídos a partir do conceito de processo 
e focam na melhoria dos processos de uma organização. Eles contêm os elementos essenciais de 
processos efetivos para uma ou mais disciplinas e descrevem uma abordagem evolucionária a partir 
de processos ad hoc, imaturos, até processos disciplinados e maduros, com melhoria na qualidade 
e efetividade. Assim, na medida em que a maturidade dos processos evolui em uma empresa, estes 
passam a ser mais definidos e efetivos.
O CMM é uma marca registrada do SEI (Software Engineering Institute), sediado na Universidade 
Carnegie Mellon, em Pittsburgh, EUA. O SEI é um centro de pesquisa e desenvolvimento patrocinado 
pelo Departamento de Defesa dos Estados Unidos. O SEI realiza pesquisas em software e problemas 
ligados à cybersecurity, cria e realiza testes com base em tecnologias inovativas e focaliza a transição 
para soluções maduras para uso global. De acordo com SEI (2010, p. 17), o instituto criou o primeiro 
modelo CMM destinado para organizações de software em 1995 e o publicou no livro “The Capability 
Maturity Model: guidelines for improving the software process”.
Pág. 52 de 97
FIGURA 32 – SEI – Software Enginnering Institute
Fonte: <http://cmu-sei.github.io/assets/img/sei-logo.png>.De acordo com Royce (2002), o modelo inicial CMM desenvolvido pela SEI era especificamente 
destinado à maturação de processo de software. No entanto, com sua bem sucedida adoção e 
uso em diferentes domínios, outros modelos CMM foram desenvolvidos para disciplinas e funções 
mais específicas como engenharia de sistemas, pessoas, desenvolvimento de produto integrado, 
aquisição de software, dentre outras. Apesar de muitas organizações considerarem estes modelos 
úteis, eles também apresentavam problemas como sobreposições, inconsistências e dificuldades 
de integração. Muitas organizações também encontraram conflitos em processos de auditoria e 
programas de melhoria de software entre os modelos CMM e as normas ISO 9001.
Além destes problemas, alguns casos de práticas CMM apresentaram semelhanças com o 
modelo tradicional em cascata, com processos excessivamente baseados em gerenciamento. Isto 
acabou associando organizações que adotavam modelos CMM aos princípios da mentalidade do 
modelo cascata, dando-lhes uma conotação negativa.
Em função destes problemas, das implicações econômicas a eles associados e com a disseminação 
de técnicas de desenvolvimento iterativo e de melhores práticas utilizadas na indústria de software, 
as organizações foram motivadas a adotar uma abordagem baseada em resultados. Todo este 
cenário impulsionou o início do projeto CMMI.
O projeto CMMI foi formado para solucionar todos estes problemas, notadamente os resultantes 
do uso de múltiplos modelos CMM. O CMMI buscou integrar muitas das melhores práticas da 
indústria, desencorajando padrões de alinhamento com a mentalidade do modelo cascata, fazendo 
deste um melhor padrão a ser seguido. Mas o projeto não se limitou a reunir diferentes modelos em 
um único. O time que trabalhou no projeto CMMI construiu um framework que acomodou diversas 
constelações. A Figura 33 ilustra os modelos que foram criados até se chegar à versão 1.3.
A versão 1.3 iniciou-se em 2008 e em 2010 foram lançados: CMMI for Acquisition, CMMI for 
Development e CMMI for Services.
Pág. 53 de 97
O CMMI (Capability Maturity Model Integration), como 
outros modelos CMM, fornece um guia a ser usado para o 
desenvolvimento de processos. Os processos usados em uma 
organização dependem de muitos fatores, incluindo domínios 
de aplicação e estrutura e tamanho da organização. O CMMI 
está organizado em três modelos chamados de constelação, 
cada um contendo práticas para áreas de desenvolvimento 
(CMMI-DEV), serviços (CMMI-SVC) e de aquisição (CMMI-ACQ):
• CMMI for development (CMMI-DEV): voltado ao processo de desenvolvimento de produtos e 
serviços.
• CMMI for acquisition (CMMI-ACQ): voltado aos processos de aquisição e terceirização de 
bens e serviços.
• CMMI for services (CMMI-SVC): voltado aos processos de empresas prestadoras de serviços.
A organização pode usar os modelos CMMI para ajudar a estabelecer objetivos e prioridades do 
melhoramento de processos, obtendo um guia para garantir estabilidade, processos estáveis e maduros.
Figura 33 – História dos modelos CMM
CMM for Software
V1.1 (1993)
INCOSE SECAM
(1996)
Systems Engineering
CMM V1.1 (1995)
Software CMM
V2, draft C (1997)
Software Acquisition
CMM V1.03 (2002)
EIA 731 SECM
(1998)
Integrated Product
Development CMM (1997)
V1.02 (2000)
V1.1 (2002)
CMMI for Development
V1.2 (2006)
CMMI for Development
V1.3 (2010)
CMMI for Services
V1.2 (2009)
CMMI for Services
V1.3 (2010)
CMMI for Acquisition
V1.2 (2007)
CMMI for Acquisition
V1.3 (2010)
Fonte: SEI (2010, p. 18).
 4.2 Visão geral do modelo CMMI
FIGURA 34 – CMMI - Capability 
Maturity Model Integration
Fonte: <http://cmmiinstitute.com/
sites/all/themes/cmmi/images/
header_CMMI_institute_logo_full.png>
Pág. 54 de 97
O CMMI trabalha com process areas (PAs), por isso é importante fazermos uma distinção entre 
processos e PAs. Um processo individual é realizado através de atividades distintas e instruções 
que especificam como o produto de uma atividade é obtido. Um PA especifica metas e práticas 
comprovadas para que atividades profissionais possam ser executadas, sem especificar como isso 
deva ser feito. Além disso, o produto da atividade é especificado apenas pelas suas características 
(PLAYS-IN-BUSINESS.COM, 2010).
Todos os modelos do CMMI 1.3 definem um conjunto de PAs. Um PA especifica metas e práticas 
comprovadas para que uma atividade profissional possa ser realizada.
Como mostra a figura 35, o modelo CMMI 1.3 contém 35 PAs, das quais dezesseis são core 
process areas, comuns a todas as constelações. O modelo CMMI-SVC possui sete PAs específicas 
e tanto o CMMI-ACQ quanto o CMMI-DEV possuem seis PAs específicas cada.
Pág. 55 de 97
Figura 35 – Constelações CMMI e as PAs
Supplier/Provider Customer
De
ve
lo
pm
en
t
Se
rv
ice
s
RSKM
REQM
SAM QPM/QWM
CAR
DAR OPP
MA
CM
OPM/IPM
OPF
OT
OPD
PMC/WMC
PPQA PP/WP
IPM/IWM
CMMI-DEV
VER
TS
RD
VAL
ATM
ARD
SSAD
AVER
AVAL
AM
CAM
SSD
SSM
SCON
SST
IRP
SD
CMMI-ACQ
CMMI-SVC
CMMI-SVC: 7 service specific PAs
1 shared PA with CMMI-DEV
CMMI-DEV: 6 development specific Pas
1 shared PA with CMMI-SVC
CMMI-ACQ: 6 acquisition specific PAs
+
16 common 
Process Areas
to all v1.3 
constellations
Fonte: Plays-in-business.com (2010).
Pág. 56 de 97
SAIBA MAIS
Implantação integrada do CMMI-DEV com o CMMI-SVC: desenvolvendo software como serviço
“Os modelos CMMI dividem as práticas em áreas de processo organizadas em 5 níveis. Os níveis 
servem como um roadmap para melhoria contínua. São 22 áreas de processo no CMMI-DEV, 24 
áreas de processo no CMMI-SVC e 22 áreas de processo no CMMI-ACQ.O CMMI-DEV e CMMI-
SVC podem ser usados por empresas prestadoras de serviços de desenvolvimento de software e 
sistemas. O CMMI-ACQ pode ser usado por empresas que contratam serviços de desenvolvimento 
de software e sistemas.”
Quadro 3 – Benefícios com a implantação integrada
Nível 2 Nível 3 Nível 4 Nível 5
Visibilidade da situação dos 
projetos, demandas e 
solicitações de serviços
Cumprimento dos 
processos
Coleta automatizada de 
indicadores
Controle de mudanças em 
requisitos e documentos
Padronização dos processos
Maior capacitação das 
equipes
Implantação de metologia 
de desenvolvimento de 
software
Maior eficácia na detecção e 
remoção de defeitos
Gerenciamento da 
capacidade das equipes
Controle na resolução e 
prevenção de incidentes
Controle do desempenho 
das equipes (produtividade, 
tempo médio de resolução 
de incidentes e solicitações 
de serviços etc)
Controle da qualidade dos 
processos, produtos e 
serviços (quantidade de 
erros econtrados pelo 
cliente, quantidade de 
interrupções de serviço etc)
Implantação de inovações 
nos processos, produtos e 
serviços
Melhora no desempenho 
das equipes
Melhora na qualidade dos 
processos, produtos e 
serviços
Benefícios com a implantação integrada do CMMI-DEV e CMMI-SVC
Fonte: Promove (2016).
“No Brasil, existem 86 empresas avaliadas no CMMI-DEV e 18 no CMMI-SVC (consulta feita em 
janeiro/2016).”
Fonte: PROMOVE. O que é CMMI? 7 fev. 2016. Disponível em: <http://www.promovesolucoes.com/cmmi>. 
Acesso em 8 jun. 2017.
Pág. 57 de 97
4.3 Componentes do modelo CMMI
O modelo (ou constelação) CMMI apresenta 
conceitos e práticas do CMMI e outros serviços com 
foco em padrões e modelos consagrados como:
• ITIL - Information Technology Infrastructure 
Library
• ISO/IEC 20000: Information Technology 
Service Management
• CobiT - Control Objectives for Information 
and related Technology
• ITSCMM - Information Technology Services Capability Maturity Model
De acordo com SEI (2010, p. 20), o CMMI-SVCcobre as atividades para estabelecer, entregar e 
gerenciar serviços. Neste contexto, serviço é um produto intangível e que não pode ser armazenado. 
As práticas e metas do modelo são relevantes para organizações que atuam na entrega de serviços, 
incluindo a área de TI, defesa, saúde, finanças e transportes.
“Embora as PAs e os processos do modelo descrevam comportamentos considerados como 
melhores práticas para a maior parte dos provedores de serviços, estes devem ser interpretados e 
adaptados às restrições e ao ambiente da organização que os utilizam.”
Fonte: SEI (2010, p. 20, tradução nossa)
Conforme ilustra a Figura 37, o CMMI-SVC, da mesma maneira que os outros modelos CMMI, 
reúne os componentes:
• Áreas de processos (process areas – PAs): é um cluster de práticas relacionadas de uma área 
que, quando implementadas coletivamente, satisfazem um conjunto de metas consideradas 
importantes para a melhoria desta área.
◊ Objetivo da PA (purpose statement): descreve o propósito da PA, sendo um componente 
informativo.
◊ Notas introdutórias (introductory notes): seção da PA que descreve os principais conceitos 
cobertos pela PA, sendo um componente informativo.
◊ Áreas de processos relacionadas (related process areas): seção da PA que lista referências 
às PAs relacionadas e reflete os relacionamentos entre as PAs, sendo um componente 
informativo.
FIGURA 36 – Componentes do modelo CMMI
Fonte: Profit_Image / shutterstock.com
Pág. 58 de 97
• Metas genéricas (generic goals - GG): são chamadas genéricas porque a mesma meta pode 
ser aplicada a múltiplas PAs. Descrevem as características que devem estar presentes nos 
processos institucionalizados que implementam uma PA.
◊ Prática genérica (generic practice - GP): é chamada genérica porque a mesma prática pode 
ser aplicada a múltiplas PAs. É associada com uma meta genérica e descreve as atividades 
que são consideradas importantes para que se possa atingir uma meta genérica de uma 
PA, contribuindo para a institucionalização dos processos associados à PA.
• Metas específicas (specific goals - SG): ou objetivos específicos, descrevem as características 
únicas que devem estar presentes para satisfazer a PA.
◊ Prática específica (specific practice - SP): é a descrição de uma atividade que é considerada 
importante para que se possa atingir uma meta específica de uma PA.
 » Subprática (subpractice): é uma descrição detalhada que provê diretrizes para que 
se possa interpretar e implementar uma prática específica ou genérica, sendo um 
componente informativo.
Figura 37 – Componentes do modelo CMMI
Área de processos
(PA)
Objetivo da 
área de 
processo
Notas 
introdutórias
Áreas de 
processos 
relacionadas
Metas 
específicas 
(SG)
Metas 
específicas 
(GG)
Práticas 
genéricas
(GP)
Práticas 
específicas
(SP)
Produto 
típico de 
trabalho
Subprática Subprática Orientação deaplicação
Legenda: Requerido Esperado Informativo
Fonte: baseado em SEI (2010, p. 22)
Pág. 59 de 97
4.4 Representações do CMMI
O CMMI possui duas representações: contínua ou por estágios. Estas representações permitem 
à organização utilizar diferentes caminhos para a melhoria de seus processos de acordo com 
seu interesse. O CMMI divide cada estágio em áreas de processo e para cada uma delas são 
definidos dois conjuntos de metas: as específicas (specific goals) e as genéricas (generic goals). 
A essas metas, a definição do modelo recomenda práticas genéricas divididas em um conjunto 
de características comuns.
As metas específicas na maioria das vezes estão focadas no negócio da empresa e buscam 
alinhar o método CMMI às necessidades próprias. As metas genéricas focam em aspectos inerentes 
a qualquer empresa e devem ser consideradas para uma melhor implementação da metodologia, 
de forma a garantir a maximização dos resultados.
O método CMMI não é um processo simples de ser realizado. Exige uma mudança de cultura 
voltada para o planejamento, a qualidade e o controle dos processos de desenvolvimento de software.
4.4.1 Seleção de uma representação do modelo CMMI
O propósito do CMMI é fornecer um guia para melhorar processos de organizações e sua habilidade 
de gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços de software. 
O CMMI, através de sua estrutura, ajuda a organização a avaliar sua maturidade organizacional 
ou sua capacidade na área de processos, estabelecendo prioridades para melhoramentos e sua 
implementação.
Como vimos, o modelo CMMI apresenta dois caminhos a serem seguidos:
• Contínuo: permite que a organização evolua de forma incremental os processos correspondentes 
a uma PA (individual) ou a um grupo de área de processos selecionado pela empresa.
• Por estágios (estagiado): a evolução é feita em um grupo de processos relacionados que são 
endereçados ao se implementar grupos de áreas de processo pré-determinados sucessivos.
As representações são importantes, pois são elas que vão determinar o tipo de nível que será 
usado na organização.
Pág. 60 de 97
“As duas representações estão associadas com dois tipos de níveis de melhoria: níveis de capacidade 
e níveis de maturidade. A representação contínua habilita a organização a alcançar níveis de 
capacidade. A representação por estágios habilita a organização a alcançar níveis de maturidade.”
Fonte: SEI (2010, p. 34, tradução nossa)
Para alcançar um nível em particular, a organização deve satisfazer todas as metas da PA ou 
todas as metas do conjunto de PAs que estão definidas para serem aprimoradas, independentemente 
do nível ser de capacidade ou de maturidade. Ambas as representações fornecem maneiras de 
aprimorar os processos para se alcançar os objetivos corporativos e ambas proveem o mesmo 
conteúdo em sua essência e usam o mesmo modelo de componentes.
Assim, caro aluno, é importante frisar que são duas formas de se chegar aos mesmos objetivos. 
Independentemente da representação adotada, os níveis caracterizam a melhoria e a evolução 
de um estado desorganizado ou imaturo até um estado que usa informações quantitativas para 
determinar e gerenciar as melhorias a serem implementadas e que irão satisfazer as necessidades 
de negócios da organização.
Há muitas razões para se selecionar uma representação ou outra. Talvez a organização escolha 
usar a representação com a qual é mais familiarizada. Se usadas para melhoria de processos ou 
avaliações, ambas as representações são projetadas para oferecer resultados equivalentes. Vamos listar 
os critérios de escolha com algumas das possíveis vantagens e desvantagens de como selecionar a 
adoção de uma entre as duas representações. Para este comparativo, a Tabela 1 deve ser consultada.
Tabela 1 - Níveis de capacidade x Níveis de maturidade do CMMI
Level
Continuous Representation 
Capability Levels
Staged Representation 
Maturity Levels
Level 0 Incomplete
Level 1 Performed Initial
Level 2 Managed Managed
Level 3 Defined Defined
Level 4 Quantitatively Managed
Level 5 Optimizing
Fonte: adaptado de SEI (2010, p. 35).
Pág. 61 de 97
4.5 Representação contínua
Ao escolher a representação contínua para a organização, o modelo CMMI:
• Permite selecionar a ordem e melhoria que mais se adéqua aos objetivos de negócios da 
organização e diminui as áreas de risco.
• Habilita que haja comparações em uma empresa e entre empresas por área de processo ou 
pela comparação de resultados em estágio equivalentes.
Há quatro níveis de capacidade, numerados de 0 até 3 (veja a Tabela 1). Cada nível de capacidade 
corresponde a metas genéricas e a um conjunto de práticas genéricas e específicas, conforme 
ilustra a Figura 38.
Figura 38 – Representação contínua do CMMI
Áreas de processos
Metas
específicasPráticas
específicas
Metas
genéricas
Práticas
genéricas
Níveis de
capacidade
Representação contínua
Fonte: adaptado de SEI (2010, p. 34)
4.6 Representação por estágio
Ao escolher a representação por estágio para a organização, o modelo CMMI:
• fornece uma sequência de melhorias, começando com práticas básicas de gerenciamento, 
progredindo através de um caminho de níveis sucessivos, cada um servindo como um 
fundamento para o seguinte.
• permite comparações entre organizações pelo uso de níveis de maturidade.
• fornece um valor simples que sumariza resultados avaliados e permite comparações entre 
organizações.
Há cinco níveis de maturidade, numerados de 1 a 5 (ver Tabela 1). A obtenção de um nível de 
maturidade permite assegurar que os fundamentos adequados de melhoria foram estabelecidos para 
o próximo nível de maturidade, permitindo a melhoria incremental dos processos na organização. 
Pág. 62 de 97
Esta representação indica a ordem de implementação de cada área de processo, de acordo 
com o nível de maturidade, que define o caminho associado à melhoria dos processos de uma 
organização (desde o nível de maturidade inicial até ao nível de maturidade em otimização), 
conforme ilustra a Figura 39.
Figura 39 – Representação contínua do CMMI
Áreas de processos
Metas
específicas
Práticas
específicas
Metas
genéricas
Práticas
genéricas
Níveis de
maturidade
Representação contínua
Fonte: baseado em SEI (2010, p. 34)
Pág. 63 de 97
4.7 Níveis de maturidade do CMMI
FIGURA 40 – Níveis de maturidade do CMMI
Fonte: Keepsmiling4u / shutterstock.com
No modelo CMMI, os níveis de maturidade suportam a representação por estágio e representam 
um caminho evolucionário para que uma organização possa aprimorar os processos correspondentes 
a um dado conjunto de PAs. Há cinco níveis de maturidade numerados de 1 a 5:
1. Initial – Inicial ou ad hoc
2. Managed – Gerenciado
3. Defined – Definido
4. Quantitatively managed – Quantitativamente gerenciado
5. Optimizing – Em otimização
De acordo com SEI (2010, p. 38) um nível de maturidade é uma escala evolucionária definida para 
a melhoria dos processos organizacionais. Cada nível de maturidade representa um subconjunto de 
processos da organização que foram alcançados, preparando-a para o próximo nível de maturidade. 
Os níveis de maturidade são medidos pelo atingimento de metas específicas e genéricas associadas 
em cada conjunto de áreas de processo predefinido.
Pág. 64 de 97
Os cinco níveis indicam uma sequência lógica para que os processos evoluam na medida em que 
estes satisfaçam as exigências do modelo (veja o Gráfico 2). Do ponto de vista de quem compra o 
serviço de organizações certificadas, os níveis permitem que possa ser realizada uma comparação 
entre fornecedores distintos visando avaliar em qual nível as empresas operam. Uma avaliação 
externa realizada por um avaliador credenciado permite que as organizações determinem estes 
níveis e divulguem para o mercado a maturidade em que seus processos se encontram.
Gráfico 2 – Níveis de maturidade do CMMI
Nível 5
Em otimização
Nível 4
Gerenciamento quantitativamente
Nível 3
Definido
Nível 2
Gerenciado
Nível 1
Inicial. Não tem práticas, nem áreas de processo
Fonte: baseado em SEI (2010)
Modelos CMMI são projetados para descrever níveis discretos de melhorias de processos. Na 
representação por estágios, os níveis de maturidade fornecem uma ordem recomendada para acessar 
melhorias de processos em estágios. Os níveis de maturidade organizam as áreas de processo.
A representação por estágios provê um caminho de melhorias do nível de maturidade 1 até 
o 5 que envolve o alcance de metas das PAs de cada nível de maturidade. A Tabela 2 mostra o 
agrupamento de PAs de cada nível de maturidade no modelo CMMI-SVC. No nível 1 não há PAs, e 
a PA denominada SSD (service system development) é adicional.
Pág. 65 de 97
Tabela 2 - Áreas de processos por nível de maturidade no CMMI-SVC
Configuration Management CM 2
Measurement and Analysis MA 2
Process and Product Quality Assurance PPQA 2
Requirements Management REQM 2
Supplier Agreement Management SAM 2
Service Delivery SD 2
Work Monitoring and Control WMC 2
Work Planning WP 2
Capacity and Availability Management CAM 3
Decision Analysis and Resolution DAR 3
Incident Resolution and Prevention IRP 3
Integrated Work Management IWM 3
Organizational Process Definition OPD 3
Organizational Process Focus OPF 3
Organizational Training OT 3
Risk Management RSKM 3
Service Continuity SCON 3
Service System Development SSD 3
Service System Transition SST 3
Strategic Service Management STSM 3
Organizational Process Performance OPP 4
Quantitative Work Management QWM 4
Causal Analysis and Resolution CAR 5
Organizational Performance Management OPM 5
Fonte: SEI (2010, p. 49)
Pág. 66 de 97
Por exemplo, no nível de maturidade 2, há um conjunto de PAs que uma organização pode 
usar para guiar seu curso de melhoria até que consiga alcançar as metas de todas essas áreas de 
processo. Uma vez que atinja o nível 2, a organização concentra seus esforços nas PAs do nível 3 
e assim por diante.
FIGURA 41 – Níveis de maturidade com base em SEI
Fonte: ESB Professional / shutterstock.com
Agora, detalharemos cada um dos níveis de maturidade com base em SEI (2010, p. 39-46).
4.7.1 Nível de maturidade 1: Inicial
No nível de maturidade 1, os processos são geralmente informais (ad hoc) e caóticos e a 
organização também não fornece um ambiente estável para suportar processos. O sucesso neste 
tipos de empresa depende mais da competência e de atos individuais de colaboradores e menos 
da utilização de processos comprovados. Embora o ambiente seja desorganizado, organizações em 
níveis de maturidade 1 podem produzir produtos e serviços que funcionam, mas raramente cumprem 
os prazos e os custos previstos nos projetos, frequentemente extrapolando-os. Em função disto, 
essas organizações tendem a não cumprir seus compromissos, costumam abandonar os processos 
em tempos de crise e ainda não conseguem repetir o sucesso alcançado em projetos anteriores.
4.7.2 Nível de maturidade 2: Gerenciado
No nível de maturidade 2, grupos de trabalho estabelecem as bases para que a organização se 
torne uma efetiva provedora de serviços. Os grupos de trabalho definem uma estratégia de serviços, 
criam planos de trabalho, monitoram e controlam o trabalho de forma a garantir que o serviço seja 
Pág. 67 de 97
entregue como planejado. Acordos com os clientes são estabelecidos e os requisitos acordados 
são gerenciados.
No nível de maturidade 2, grupos de trabalho, grupos de atividades, processos, produtos de 
trabalho e serviços são controlados e os processos são planejados de acordo com uma política. 
Para executar os processos, a organização fornece recursos adequados, atribui responsabilidades 
para a sua execução, capacita pessoas e buscar garantir que os produtos de trabalho dos processos 
estão dentro de níveis de configuração de gerenciamento adequados.
Em outras palavras, as organizações buscam garantir que requisitos de projetos sejam gerenciados 
e que processos sejam planejados, executados, medidos e controlados. No nível de maturidade 2, a 
disciplina de processos contribui para que as práticas existentes sejam mantidas durante tempos 
de crise e que os projetos sejam executados e gerenciados de acordo com o planejamento e a 
documentação.
O estágio de desenvolvimento dos produtos e o estado em que se encontra a entrega de serviços 
são passíveis de serem controlados em pontos predefinidos. Compromissos são estabelecidos 
entre os principais stakeholders e são revisados quando necessário, visando garantirque sejam 
cumpridos. Os produtos e serviços mantêm a conformidade com os requisitos, padrões e objetivos 
especificados.
4.7.3 Nível de maturidade 3: Definido
No nível de maturidade 3, a organização utiliza processos definidos para o gerenciamento do 
trabalho, os quais incorporam melhores práticas de gerenciamento de serviços, como continuidade 
de serviços, resolução e prevenção de incidentes. A organização verifica se os produtos estão de 
acordo com os requisitos e realiza sua validação de forma a garantir que atendam às necessidades 
de clientes e usuários finais.
Neste nível, a organização alcançou metas específicas e genéricas das áreas de processo 
atribuídas aos níveis 2 e 3, e os processos são bem caracterizados e entendidos, sendo descritos 
como padrões, procedimentos, ferramentas e métodos.
Uma distinção importante entre o nível de maturidade 2 e 3 está no escopo de padrões, descrições 
de processos e procedimentos. No nível de maturidade 2, os padrões, descrições de processos 
e procedimentos podem ser bastante diferentes em cada instância específica do processo. No 
Pág. 68 de 97
nível de maturidade 3, os padrões, descrições de processos e procedimentos para um projeto são 
ajustados para atender a um grupo de trabalho ou unidade organizacional em particular e são mais 
consistentes, exceto para diferenças permitidas.
Outra distinção é que, no nível de maturidade 3, processos são tipicamente descritos em 
mais detalhes e mais rigorosamente que no nível 2. No nível 3, processos são gerenciados mais 
proativamente usando um entendimento das atividades dos processos e medidas detalhadas dos 
processos, seu produto e seus serviços. Um processo definido claramente tem um objetivo, entradas, 
critérios de entrada, atividades, medidas, regras, passos de verificação, saídas e critérios de saída.
4.7.4 Nível de maturidade 4: Gerenciado
No nível de maturidade 4, a organização estabelece objetivos quantitativos para qualidade e 
desempenho de processo e os utiliza como critério para o gerenciamento de processos. Os objetivos 
quantitativos são baseados nas necessidades dos clientes, dos usuários finais, da organização e 
dos implementadores dos processos. Qualidade e desempenho de processo são definidos com 
base em termos estatísticos e gerenciados através do ciclo de vida dos processos.
Neste nível de maturidade, a organização já alcançou todas as metas específicas das áreas de 
processo determinadas para os níveis de maturidade 2, 3 e 4 e as metas genéricas dos níveis de 
maturidade 2 e 3.
Os subprocessos que contribuem de forma significativa para o desempenho dos processos são 
escolhidos para serem aplicados. Estes subprocessos são controlados usando técnicas estatísticas 
e técnicas quantitativas e são coletadas medidas detalhadas do desempenho dos processos, de 
forma que possam ser estatisticamente analisadas. Isso permite que ocorrências de variações 
indesejadas sejam identificadas e corrigidas, visando evitar que ocorram novamente. Baselines e 
modelos de desempenho podem ser utilizados para ajudar na definição dos objetivos de qualidade 
e performance, ajudando a atingir os objetivos de negócios.
As medidas de qualidade e desempenho de processos coletadas são armazenadas, de forma que 
possam ser utilizadas pelo corpo gestor da organização para dar suporte às tomadas de decisões, 
com base nos fatos e dados reais. Há uma distinção entre os níveis 3 e 4: no nível 4, o desempenho 
de processos é controlado usando técnicas estatísticas e quantitativas, sendo quantitativamente 
previsível, o que não ocorre no nível 3.
Pág. 69 de 97
4.7.5 Nível de maturidade 5: Em otimização
No nível de maturidade 5, a organização continuamente melhora seus processos com base em 
um entendimento quantitativo das necessidades e objetivos do negócio. A organização utiliza a 
abordagem quantitativa para entender a variação inerente nos processos e as causas dos efeitos 
destes processos.
No nível 5 a organização alcançou todas as metas específicas das áreas de processo determinadas 
para os níveis 2, 3, 4 e 5 e metas genéricas determinadas para os níveis 2 e 3. Os processos são 
melhorados de forma continuada com base em dados quantitativos.
O nível 5 centra esforços na melhoria contínua de desempenho dos processos através de 
melhorias incrementais que buscam a utilização de inovação tecnológica. Os objetivos quantitativos 
para a melhoria dos processos são definidos e continuamente revisados para que mudanças de 
objetivos de negócios possam ser contempladas. Esses critérios de melhoria são aplicados aos 
processos, e estes são medidos e avaliados para que se verifique se os objetivos quantitativos de 
melhoria foram atingidos.
As melhorias a serem implantadas são escolhidas com base no aspecto quantitativo, ou seja, 
no quanto contribuem para alcançar os objetivos de melhoria em comparação a quanto custarão 
e a quanto impactarão na organização. Desta forma, busca-se garantir que o desempenho dos 
processos de organização seja continuamente melhorado.
A introdução de inovações nos processos e o aumento da sua eficiência depende da participação 
da equipe de colaboradores, que deve estar alinhada aos valores e objetivos da organização. Caso 
esta equipe compartilhe conhecimento, a organização pode conseguir responder às mudanças e 
oportunidades de forma mais ágil.
A principal distinção entre o nível 4 e nível 5 é: no nível 4 há preocupação com as causas de 
variação nos processos e busca-se definir o comportamento estatístico previsível de resultados; 
já no nível 5, procura-se mudar os processos em função destas variações. Apesar de processos 
poderem produzir resultados previsíveis, os resultados podem não ser suficientes para que se 
alcancem os objetivos estabelecidos. No nível 5, os processos são modificados visando o aumento 
de seu desempenho para que alcancem os objetivos quantitativos estabelecidos para a sua melhoria.
Pág. 70 de 97
SAIBA MAIS
“De acordo com o CMMI Institute que faz parte da Carnegie Mellon University, organizações de 94 
países usam o CMMI para melhorar suas performances; 11 governos no mundo investem em CMMI 
para alavancar o desenvolvimento econômico de seus países (o Brasil não está na lista) e modelos de 
CMMI já foram traduzidos para 10 línguas diferentes (entre elas o português). Já em um report feito 
pelo mesmo instituto, há um gráfico com os maiores números de avaliações reportadas por país. Em 
2014 o qual o Brasil ocupa o sétimo lugar (com 39 avaliações) e está na lista dos dez mais. Nos três 
primeiros lugares estão China (com 722 avaliações), Estados Unidos (com 314) e Índia (com 189). 
Embraer, Serasa, Claro, Itaú, GM e IBM estão entre as empresas avaliadas que obtiveram algum nível 
de maturidade dos modelos do SEI e do CMMI Institute. Essa avaliação, oficial, foi feita pelo braço 
brasileiro da consultoria internacional ISD (Integrated System Diagnostics)”
Fonte: MENA, Isabela. Verbete Draft: o que é CMMI. Projeto Draft, 10 jun. 2015. Disponível em: <http://
projetodraft.com/verbete-draft-o-que-e-cmmi/>. Acesso em: 8 jun. 2017.
4.8 Níveis de capacidade do CMMI
FIGURA 42 - Níveis de capacidade do CMMI
Fonte: Zurainy Zain / shutterstock.com
No modelo CMMI, os níveis de capacidade suportam a representação contínua e aplicam-se a 
organizações que buscam melhorias em seus processos em uma área individual. Há quatro níveis 
de capacidade numerados de 0 a 3.
0. Incomplete - Incompleto
1. Performed - Executado
2. Managed - Gerenciado
3. Defined - Definido
De acordo com SEI (2010, p. 36-37), um nível de capacidade para uma PA é alcançado quando 
todas as metas genéricas estão satisfeitas até aquele nível. Os níveis são detalhados como se segue.
Pág. 71 de 97
4.8.1 Nível decapacidade 0: Incomplete (Incompleto)
Um processo é incompleto se ele não foi executado ou foi apenas parcialmente executado. Uma 
ou mais metas específicas da PA não foram satisfeitas e nenhuma meta genérica existe neste nível.
4.8.2 Nível de capacidade 1: Performed (Executado)
A capacidade de nível 1 é caracterizada como um processo executado, que indica que o processo 
realiza o trabalho necessário para produzir os produtos daquela atividade e que as metas específicas 
da PA estão satisfeitas.
Embora a capacidade de nível 1 representa importantes melhorias, estas podem ser perdidas 
ao longo do tempo se não forem institucionalizadas. A aplicação da institucionalização ajuda que 
estas melhorias sejam mantidas.
4.8.3 Nível de capacidade 2: Managed (Gerenciado)
A capacidade de nível 2 é caracterizada como um processo gerenciado. Um processo gerenciado 
é um processo executado que é planejado e executado de acordo com uma política, emprega pessoas 
com recursos adequados para produzir saídas controladas, envolve importantes stakeholders, é 
monitorado, controlado e revisado e, ainda, é avaliado para saber se é aderente à descrição do 
processo.
4.8.4 Nível de capacidade 3: Defined (Definido)
A capacidade de nível 3 é caracterizada como um processo definido. Um processo definido é 
um processo gerenciado que é customizado a partir do conjunto de processos padronizados da 
organização, possui uma descrição de manutenção e contribui para os ativos de processos da 
organização.
Uma diferença crítica entre os níveis de capacidade 2 e 3 reside no escopo dos padrões, nas 
descrições dos processos e nos procedimentos associados. No nível 2 estes quesitos podem ser 
bastante diferentes em cada instância específica de um processo. No nível 3 estes quesitos são 
customizados a partir dos padrões organizacionais para se ajustar a um grupo de trabalho em 
particular ou a uma unidade organizacional e, portanto, são mais consistentes. Além disso, os 
Pág. 72 de 97
processos no nível 3 são descritos com mais rigor que no nível 2. Um processo definido claramente 
define o propósito, as entradas, os critérios de entrada, as atividades, as regras, as medições, os 
passos de verificação, as saídas e os critérios de saída.
 5. MODELO DE PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR)
Caro aluno, neste capítulo descreveremos o que é o Modelo de Processo de Software Brasileiro 
(MPS.BR) e detalharemos o MR-MPS-SW, mostrando sua organização, estrutura interna e seus 
níveis de maturidade. Veremos que é um modelo que se adéqua à realidade das micro, pequenas 
e médias empresas brasileiras, principalmente por oferecer um custo de certificação bem menor, 
se comparado com modelos estrangeiros como o CMMI.
 5.1 Visão geral do MPS.BR e do MR-MPS-SW
O MPS .BR - Melhoria de Processo de Software .BRasileiro 
foi criado em dezembro de 2003 e coordenado pela Softex 
(Associação para Promoção da Excelência do Software 
Brasileiro). De acordo com a Softex (2016), o programa tem 
por objetivo a melhoria de processo para o desenvolvimento 
de software brasileiro, visando aumentar a competitividade da 
indústria brasileira de software nos mercados interno e externo 
através de programas de qualificação de profissionais nesta área 
e da melhoria e avaliação de processos e produtos de software 
brasileiros, a um custo acessível às empresas de menor porte. As iniciativas deste programa buscam 
que ele seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas 
e privadas, embora com especial atenção às micro, pequenas e médias empresas.
O modelo MPS segue os modelos e normas internacionais mais aceitos no mercado. Está em 
conformidade com as normas internacionais ISO/IEC 12207 e ISO/IEC 20000, é compatível com o 
modelo CMMI, é baseado nas melhores práticas da engenharia de software e é adequado à realidade 
das empresas brasileiras. Assim, o modelo é compatível com os padrões de qualidade aceitos 
internacionalmente e tem como pressuposto o aproveitamento de toda a competência existente 
nos padrões e modelos de melhoria de processo já disponíveis.
O Programa MPS.BR possui cinco componentes (Figura 44): Modelo de Referência MPS para 
Software (MR-MPS-SW), Modelo de Referência MPS para Serviços (MR-MPS-SV), Modelo de Referência 
FIGURA 43 - Visão geral do MPS.BR 
e do MR-MPS-SW
Fonte: <http://www.softex.br/wp-content/
uploads/2013/07/Logotipo-sem_slogan_
Cromatica-Positivo-300x152.png?x15632>.
Pág. 73 de 97
MPS para Gestão de Pessoas (MR-MPS-RH), Método de Avaliação (MA-MPS) e Modelo de Negócio 
(MN-MPS). Cada componente é descrito por meio de guias e/ou documentos do Programa MPS.BR.
Cada componente é descrito por meio de guias e/ou documentos do modelo MPS, como pode 
ser visto na Figura 44.
Figura 44 – Modelo MPS.BR
PNQ
MoProSoft
CMMI-SVC
ISO/IEC 20000
P-CMM
ISO 9001
ISO/IEC 330xx
ISO/IEC 12207
CMMI-DEV
Modelo de 
referência MPS 
para software
Modelo de 
referência MPS 
para serviço
(MR-MPS-SV)
Modelo de 
referência MPS 
para gestão de 
pessoas
Método de 
avaliação
(MA-MPS)
Modelo de 
negócio
(MN-MPS)
Guia geral MPS
de software
Guia de aquisição
Guias de 
implementação
Guias de 
implementação
Guias de 
implementação
Guia geral MPS 
de serviço
Guia geral MPS 
de gestão de 
pessoas
Guia de avaliação Documentos do programa
Modelo MPS
Fonte: Softex (2016, p. 12)
Neste capítulo, trataremos apenas do Modelo de Referência MPS para Software: MR-MPS-SW. 
Segundo a Softex (2016, p. 6), o MR-MPS-SW baseia-se nos conceitos de maturidade e capacidade de 
Pág. 74 de 97
processo para a avaliação e melhoria da qualidade e produtividade de software e serviços correlatos 
e, também, para a melhoria da qualidade e produtividade dos serviços prestados.
5.2 Capacidade de Processo e Níveis de Maturidade do MR-MPS-SW
O Modelo de Referência MPS para Software (MR-MPS-SW) define níveis de maturidade que 
são uma combinação entre processos e sua capacidade, declarando o propósito e os resultados 
esperados de sua execução.
De acordo com a Softex (2016, p. 17), a definição dos processos segue os requisitos para um 
modelo de referência de processo apresentados na ISO/IEC 15504-2, o que possibilita a avaliação e 
a atribuição de graus de efetividade na execução dos processos. No MR-MPS-SW, a capacidade do 
processo é representada por um conjunto de atributos de processo e expressa o grau de refinamento 
e institucionalização com que o processo é executado na organização/unidade organizacional. À 
medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível 
de capacidade para desempenhar o processo deve ser atingido. Os diferentes níveis de capacidade 
dos processos são descritos por atributos de processos (APs).
O nível de maturidade em que se encontra uma organização permite prever o seu desempenho 
futuro ao executar um ou mais processos. Há sete níveis de maturidade:
• [1] Nível G – Parcialmente gerenciado
• [2] Nível F – Gerenciado
• [3] Nível E – Parcialmente definido
• [4] Nível D – Largamente definido
• [5] Nível C – Definido
• [6] Nível B – Gerenciado quantitativamente
• [7] Nível A – Em otimização
Pág. 75 de 97
SAIBA MAIS
“No modelo MR-MPS-SW o atendimento aos atributos do processo (APs) é requerido para todos os 
processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro 
de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui 
o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os 
processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Istosignifica que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser 
executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para 
um nível de maturidade superior, os processos anteriormente implementados devem passar a ser 
executados no nível de capacidade exigido neste nível superior.”
Fonte: ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO (SOFTEX). MPS .
BR - Melhoria de Processo do Software Brasileiro. Brasília: Softex, 2016. Disponível em: <http://www.
softex.br/wp-content/uploads/2016/04/MPS.BR_Guia_Geral_Software_2016-com-ISBN.pdf?x15632>. Acesso em: 8 
jun. 2017.
A Tabela 3 apresenta os níveis de maturidade do MR-MPS-SW, os processos e os atributos de 
processo correspondentes a cada nível.
Tabela 3- Processos e atributos de processos por níveis de maturidade doMR-MPS-SW
Nível Processos Atributos de processos
G Gerência de Requisitos – GRE
Gerência de Projetos – GPR
AP 1.1 e AP 2.1
F Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
AP 1.1, AP 2.1 e AP 2.2
E Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2
D Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2
C Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2
Pág. 76 de 97
Nível Processos Atributos de processos
B Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2, AP 4.1 e AP 4.2
A AP 1.1, AP 2.1, AP 2.2, AP 
3.1, AP 3.2, AP 4.1, AP 4.2 , 
AP 5.1 e AP 5.2
Fonte: adaptado de Softex (2016, p. 22).
A seguir apresentamos os nove APs referenciados na Tabela 3.
5.3. Atributos de processos do MR-MPS-SW
De acordo com a Softex (2016, p. 17 a 21), os nove atributos 
de processos são os que aqui reproduziremos.
5.3.1 AP 1.1 O processo é executado
O atributo de processo AP 1.1 é a medida do quanto 
o propósito do processo é alcançado pela sua execução. 
Como resultado da implementação completa deste atributo 
de processo:
• O processo produz os resultados definidos.
5.3.2 AP 2.1 A execução do processo é gerenciada
O atributo de processo AP 2.1 é a medida do quanto a execução do processo é gerenciada. 
Como resultado da implementação completa deste atributo de processo:
(i) existe uma política organizacional estabelecida e mantida para o processo;
(ii) a execução do processo é planejada;
(iii) [...]
(iv) a execução do processo é monitorada em relação ao planejado e, quando necessário, 
ajustes são realizados;
(v) as pessoas que executam o processo estão preparadas para executar suas responsabilidades;
FIGURA 45 – Atributos de processos
Fonte: Shany Muchnik / 
shutterstock.com
Pág. 77 de 97
(vi) as atividades, o status e os resultados do processo são revistos com a gerência de nível 
superior e são tratadas questões críticas;
(vii) (a partir do Nível F) a aderência dos processos executados às descrições de processo, 
padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades.
5.3.3 AP 2.2 Os produtos de trabalho do processo são gerenciados
O atributo de processo AP 2.2 é a medida do quanto os produtos de trabalho do processo são 
gerenciados, isto é, produzidos, controlados e mantidos. Como resultado da implementação completa 
deste atributo de processo:
(i) os requisitos para documentação e controle dos produtos de trabalho do processo são 
identificados;
(ii) os produtos de trabalho do processo estão identificados, documentados e sob os níveis 
de controle especificados;
(iii) os produtos de trabalho são avaliados objetivamente com relação à aderência aos padrões, 
procedimentos e requisitos aplicáveis e são tratadas as não conformidades.
5.3.4 AP 3.1 O processo é definido
O atributo de processo AP 3.1 é a medida do quanto o processo padrão da organização é mantido 
de forma a apoiar sua adaptação para um processo definido. Como resultado da implementação 
completa deste atributo de processo:
(i) existe a definição de um processo padrão, o que inclui diretrizes para a sua adaptação a 
situações específicas, a sequência de execução, a interação deste processo com os outros 
processos, os papéis e competências, a infraestrutura e o ambiente de trabalho requeridos 
para executar o processo;
(ii) métodos adequados para monitorar a efetividade e adequação do processo são identificados.
5.3.5 AP 3.2 O processo está implementado
O atributo de processo AP 3.2 é a medida do quanto o processo padrão está implementado na 
organização. Como resultado da implementação completa deste atributo de processo:
(i) um processo definido baseado nas diretrizes para seleção e/ou adaptação do processo 
padrão está implementado;
Pág. 78 de 97
(ii) a infraestrutura e o ambiente de trabalho requeridos para executar o processo definido 
estão disponibilizados, gerenciados e mantidos;
(iii) experiências e dados apropriados são coletados, analisados e utilizados para entendimento 
do comportamento e adequação do processo, e para a identificação de oportunidades de 
melhoria no processo.
FIGURA 46 – Analise 
quantitativa
Fonte: AVIcon / 
shutterstock.com
5.3.6 AP 4.1 O processo é objeto de análise quantitativa
O atributo de processo AP 4.1 é a medida do quanto às necessidades 
de informação são definidas os relacionamentos entre os elementos de 
processo são identificados e dados são coletados.
Nota: A execução de (i), (ii), (iii) e (iv) é obrigatória e deve ser realizada 
uma única vez e ao mesmo tempo para todos os processos. Caso o processo 
ou um elemento de processo a ele relacionados não tenham sido escolhidos 
para análise de desempenho, todos os demais itens a partir de (v) não são considerados e o atributo 
de processo é considerado fora de escopo para este processo.
(i) os processos que estão alinhados a objetivos quantitativos de negócio são identificados;
(ii) foram identificadas as necessidades de informação dos processos requeridas para apoiar 
o alcance dos objetivos de negócio relevantes da organização;
(iii) os objetivos de medição do processo foram definidos a partir das necessidades de informação;
(iv) relacionamentos mensuráveis entre elementos do processo que contribuem para o 
desempenho do processo são identificados;
(v) os objetivos quantitativos para qualidade e desempenho do processo da organização foram 
definidos e estão alinhados às necessidades de informação e aos objetivos de negócio;
(vi) os processos que serão objeto de análise de desempenho são selecionados a partir do 
conjunto de processos padrão da organização e das necessidades de informação dos 
usuários dos processos;
(vii) medidas adequadas para análise de desempenho do processo, incluindo a frequência de 
realização das medições, são identificadas, definidas e incorporadas ao plano de medição 
da organização;
(viii) resultados de medições são coletados, validados e reportados para monitorar o 
quanto os objetivos quantitativos para o desempenho do processo foram alcançados; 
Nota: Necessidades de informação refletem necessidades gerenciais, técnicas, de projetos, 
do processo e do produto.
Pág. 79 de 97
5.3.7 AP 4.2 O processo é controlado quantitativamente
O atributo de processo AP 4.2 é a medida do quanto dados objetivos são utilizados para gerenciar 
o desempenho do processo que é predizível.
Nota: Caso oprocesso ou elemento de processo a ele relacionados não tenham sido escolhidos 
para análise de desempenho, AP 4.2 não é executado.
(i) técnicas para análise dos dados coletados são selecionadas;
(ii) dados de medições são analisados com relação a causas especiais (atribuíveis) de variação 
do processo;
(iii) o desempenho do processo é caracterizado;
(iv) ações corretivas foram executadas para tratar causas especiais de variação;
(v) se necessário, análises adicionais são realizadas para avaliar o processo sob o efeito de 
causas especiais de variação;
(vi) modelos de desempenho do processo são estabelecidos, melhorados e ajustados em 
função do conhecimento adquirido com o aumento de dados históricos, compreensão das 
características do processo ou mudanças no próprio negócio da organização.
5.3.8 AP 5.1 O processo é objeto de melhorias incrementais e inovações
O atributo de processo AP 5.1 é a medida do quanto mudanças no processo são identificadas 
a partir de investigação de enfoques inovadores para a definição e implantação do processo.
Nota: Caso o processo ou elementos de processo a ele relacionados não tenham sido escolhidos 
para análise de desempenho, AP 5.1 não é executado.
(i) os objetivos de negócio da organização são mantidos com base no entendimento das 
estratégias de negócio e resultados de desempenho do processo;
(ii) objetivos de melhoria do processo são definidos com base no entendimento do desempenho 
do processo, de forma a apoiar o alcance dos objetivos de negócio.
(iii) dados que influenciam o desempenho do processo foram identificados, classificados e 
selecionados para análise de causas;
(iv) dados selecionados foram analisados para identificar causas raiz e propor soluções aceitáveis 
para evitar ocorrências futuras de resultados similares ou incorporar melhores práticas no 
processo;
Pág. 80 de 97
(v) dados adequados são analisados para identificar oportunidades para aplicar melhores 
práticas e inovações com impacto no alcance dos objetivos de negócio;
(vi) oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo foram 
identificadas, avaliadas e selecionadas com base no impacto no alcance dos objetivos de 
negócio;
(vii) uma estratégia de implementação para as melhorias selecionadas foi estabelecida para 
alcançar os objetivos de melhoria e inovação no processo e para resolver problemas;
5.3.9 AP 5.2 O processo é objeto de implementação de melhorias inovadoras e incrementais
O atributo de processo AP 5.2 é a medida do quanto as mudanças na definição, gerência e 
desempenho do processo alcançou os objetivos.
Nota: Caso o processo ou elementos de processo a ele relacionados não tenham sido escolhidos 
para análise de desempenho, AP 5.2 não é executado.
(i) o impacto de todas as mudanças propostas é avaliado com relação aos objetivos do processo 
definido para o projeto e do processo padrão;
(ii) a implementação das mudanças acordadas é gerenciada para garantir o entendimento 
de qualquer variação no desempenho do processo e ações corretivas necessárias foram 
executadas;
(iii) as ações implementadas para resolução de problemas e melhoria no processo são 
acompanhadas, com uso de técnicas estatísticas e outras técnicas quantitativas, para 
verificar se as mudanças no processo corrigiram o problema e melhoraram o seu desempenho;
(iv) dados de análise e resolução de causas de problemas são armazenados para uso em 
situações similares.
Pág. 81 de 97
5.4 Processos por níveis de maturidade do MR-MPS-SW
Nesse capítulo estudaremos os processos 
ordenados pelo nível de maturidade de forma 
crescente, ou seja, do primeiro patamar que se 
inicia no nível G até o patamar mais alto, que é 
o nível A. É importante ressaltar que cada nível 
inclui os processos do nível anterior. Vamos 
apresentar apenas os propósitos dos processos. 
Recomendamos que você consulte o guia MR-MPS-
SW para conhecer os resultados esperados destes 
processos.
Esta seção reproduz o que consta no guia da 
Softex (2016, p. 24 a 46) de maneira resumida.
5.4.1 Nível G – Parcialmente gerenciado
O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de 
Requisitos. Neste nível a implementação dos processos deve satisfazer os atributos de processo 
AP 1.1 e AP 2.1.
• Processo Gerência de Projetos – GPR: Tem como propósito 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 seu desempenho. O propósito deste processo evolui à medida que a organização 
cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são 
incorporados, de forma que a gerência de projetos passe 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.
• Processo Gerência de Requisitos – GRE: Tem como propósito 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.
FIGURA 47 - Processos por níveis de maturidade 
do MR-MPS-SW
Fonte: Emanuela Carratoni / shutterstock.com
Pág. 82 de 97
FIGURA 48 – Gerência de projetos
Fonte: Rawpixel.com / shutterstock.com
5.4.2 Nível F – Gerenciado
O nível de maturidade F é composto pelos processos do nível de maturidade anterior (G) acrescidos 
dos processos Aquisição, Garantia da Qualidade, Gerência de Configuração, Gerência de Portfólio 
de Projetos e Medição. Neste nível, a implementação dos processos deve satisfazer os atributos 
de processo AP 1.1, AP 2.1 e AP 2.2.
• Processo Aquisição – AQU: Tem como propósito gerenciar a aquisição de produtos que 
satisfaçam às necessidades expressas pelo adquirente.
• Processo Gerência de Configuração – GCO: Tem como propósito estabelecer e manter a 
integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a 
todos os envolvidos.
• Processo Garantia da Qualidade – GQA: Tem como propósito assegurar que os produtos de 
trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos 
e padrões estabelecidos.
• Processo Gerência de Portfólio de Projetos – GPP: Tem como propósito iniciar e manter projetos 
que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos 
da organização. Este processo planeja o investimento e aplica os recursos organizacionais 
Pág. 83 de 97
adequados, estabelecendo a autoridade necessária para executar os projetos selecionados. 
Executa a qualificação contínua de projetos para confirmar que eles justificam a continuidade 
dos investimentos ou podem ser redirecionados para justificar.
• Processo Medição – MED: Tem como propósito 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.
5.4.3 Nível E – Parcialmente definido
O nível de maturidade E é composto pelos processos dos níveis de maturidade anteriores (G e F), 
acrescidos dos processos Avaliação e Melhoria do Processo Organizacional, Definição do Processo 
Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. O processo Gerência 
de Projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com 
base no processo definido para o projeto e nos planos integrados.Neste nível, a implementação 
dos processos deve satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.
• Processo Avaliação e Melhoria do Processo Organizacional – AMP: Tem como propósito 
determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos 
de negócio 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.
• Processo Definição do Processo Organizacional – DFP: Tem como propósito 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.
• Processo Gerência de Recursos Humanos – GRH: tem como propósito prover a organização e 
os projetos com os recursos humanos necessários e manter suas competências adequadas 
às necessidades do negócio.
• Processo Gerência de Reutilização – GRU: Tem como propósito gerenciar o ciclo de vida dos 
ativos reutilizáveis.
5.4.4 Nível D – Largamente definido
O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G, 
F e E), acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Projeto e 
Construção do Produto, Validação e Verificação. Neste nível a implementação dos processos deve 
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.
Pág. 84 de 97
• Processo Desenvolvimento de Requisitos – DRE: tem como propósito definir os requisitos do 
cliente, do produto e dos componentes do produto.
• Processo Integração do Produto – ITP: Tem como propósito 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.
• Processo Projeto e Construção do Produto – PCP: tem como propósito projetar, desenvolver 
e implementar soluções para atender aos requisitos.
• Processo Validação – VAL: Tem como propósito confirmar que um produto ou componente 
do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi 
desenvolvido.
• Processo Verificação – VER: Tem como propósito confirmar que cada serviço e/ou produto 
de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados.
5.4.5 Nível C – Definido
O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G, 
F, E e D), acrescidos dos processos Desenvolvimento para Reutilização, Gerência de Decisões e 
Gerência de Riscos. Neste nível, a implementação dos processos deve satisfazer os atributos de 
processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.
• Processo Desenvolvimento para Reutilização – DRU: Tem como propósito 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.
• Processo Gerência de Decisões – GDE: Tem como propósito analisar possíveis decisões críticas 
usando um processo formal, com critérios estabelecidos, para avaliação das alternativas 
identificadas.
• Processo Gerência de Riscos – GRI: Tem como propósito identificar, analisar, tratar, monitorar 
e reduzir continuamente os riscos em nível organizacional e de projeto.
Pág. 85 de 97
5.4.6 Nível B – Gerenciado quantitativamente
FIGURA 49 – Gerência de operação do serviço
Fonte: garagestock / shutterstock.com
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G, F, 
E, D e C). Neste nível o processo de Gerência da Operação do Serviço sofre sua segunda evolução, 
sendo acrescentados novos resultados para atender aos objetivos de gerenciamento quantitativo. 
Neste nível, a implementação dos processos deve satisfazer os atributos de processo AP 1.1, AP 2.1, 
AP 2.2, AP 3.1 e AP 3.2 e alguns resultados do AP 4.1. A implementação dos processos selecionados 
para análise de desempenho deve satisfazer integralmente os atributos de processo AP 4.1 e AP 4.2.
Este nível não possui processos específicos.
5.4.7 Nível A – Em otimização
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G, F, 
E, D, C e B). Neste nível, a implementação dos processos deve satisfazer os atributos de processo 
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2 e alguns resultados do AP 4.1. A implementação dos processos 
selecionados para análise de desempenho deve satisfazer integralmente os atributos de processo 
AP 4.1 e AP 4.2. Os atributos de processo AP 5.1 e AP 5.2 devem ser integralmente satisfeitos pela 
implementação de pelo menos um dos processos selecionados para análise de desempenho.
Este nível não possui processos específicos.
Pág. 86 de 97
5.5 Comparativo entre MPS.BR e CMMI
O modelo CMMI é proprietário, envolve um longo tempo e grande custo para a realização das 
avaliações do modelo para se obter a certificação. Essas dificuldades contrastam com a realidade 
das empresas brasileiras que não podem realizar um investimento tão alto para a obtenção da 
certificação. O alto custo da adaptação para obtenção da certificação e o longo prazo para alcançar os 
níveis mais altos de maturidade impossibilitavam as pequenas e médias empresas desenvolvedoras 
de software a aderirem ao programa do CMMI.
O MPS.BR surgiu como um movimento cujo objetivo era suprir a demanda das empresas 
nacionais, que precisavam encontrar uma forma de adaptar à sua realidade, rapidamente, modelos 
para melhoria de processos de software como o CMMI com níveis de maturidade 2 e 3, a um custo 
mais accessível.
Ambos os modelos possuem níveis de maturidade que definem a capacidade da empresa para 
trabalhar em projetos grandes e complexos. Como vimos, o CMMI varia do 1 ao 5 e o MPS.BR varia 
do G ao A, sendo que, ao contrário do CMMI, o primeiro nível do MPS.BR já exige que a empresa 
tenha determinados processos definidos. Os níveis do MPS.BR também são compostos por áreas 
de processos, que são os tópicos mais importantes para um processo de desenvolvimento de 
software. Assim, podemos criar uma equivalência dos níveis de maturidade do CMMI e do MPS.
BR. Esta equivalência pode ser vista na Tabela 4 e melhor visualizado no Gráfico 3.
Tabela 4 – Equivalência entre os níveis de maturidade CMMI x MPS.BR
Comparação dos níveis de maturidade
CMMI MPS .BR
1 Não é definido
2 G
F
3 E
D
C
4 B
5 A
Fonte: Elaborado pelo autor.
Pág. 87 de 97
Analisando a Tabela 4, podemos verificar que os níveis de maturidade do MPS.BR permitem que 
a empresa implante processos de uma forma mais gradual. Essa estratégia, aplicada ao mercado 
brasileiro de software, permite que empresas de pequeno porte, que não possuem muito dinheiro 
para investir em metodologias e processos, possam tomar a iniciativa de definir processos.
O MPS.BR e o CMMI possuem níveis equivalentes de qualidade de software, mas a norma 
brasileira tem a vantagem ter menor custo.
Gráfico 3 – Níveis de maturidade: comparativo MPS.BR e CMMI
Em otimização
Gerenciado quantitativamente
Definido
Largamente definido
Parcialmente definido
Gerenciado
Parcialmente gerenciado
5
4
3
2
Relacionamento
com o CMMI
Fonte: (FRANCISCANI; PESTILLI, 2012)
Uma experiência interessante, já bastante comum entre as empresas brasileiras, é que algumas 
delas utilizam o modelo MPS.BR como forma de melhor se prepararem para alcançar um nível do 
modelo CMMI, já que há equivalência entre os níveis do CMMI e do MPS.BR. Além disso, o custo 
de um processo de implantação do MPS.BR é menor, e esse é um dos principais incentivos para 
algumas empresas fazeremisso. Uma empresa pode alcançar o nível A do MPS.BR e depois já 
tentar o nível 5 do CMMI.
No Brasil as principais empresas certificadoras destes modelos são a FUMSOFT para o MPS.
BR e a ISD-Brasil para o CMMI.
Pág. 88 de 97
De acordo com a Fumsoft (2013, s/p),
O Modelo de Melhoria de Processos do Software Brasileiro (MPS.BR) atesta a qualidade 
do processo de desenvolvimento nas empresas de software e serviços de TI. A Fumsoft 
é certificada pela Softex, coordenadora do modelo, como instituição implementadora 
do MPS.BR, promovendo a difusão das boas práticas valorizadas pelo mercado. 
Por que obter uma certificação? A qualificação de processos tem reflexos internos 
e externos para as empresas. Adotar práticas de engenharia de software alinhadas 
aos padrões internacionais de produção gera ganhos em produtividade, com a 
redução do tempo e do investimento nos projetos. Para o mercado, a certificação 
é um diferencial competitivo, visto pelos clientes como garantia de qualidade dos 
produtos e serviços oferecidos pelas empresas.
SAIBA MAIS
Processo de implementação
“Toda empresa que desenvolve software está apta a pleitear o MPS.BR. A empresa precisa dispor 
de pelo menos dez colaboradores, tendo assim condições de alocar pessoas para a definição e 
implementação dos processos. Existem dois tipos de modelos de implementação: o Cooperado, 
definido pela Softex, e o Específico, definido segundo as necessidades da empresa.
• Modelo Cooperado: implementado conjuntamente em um grupo de empresas, que compartilham 
os custos de algumas atividades coletivas dentro de um cronograma comum com duração total 
de 15 meses, sendo 12 meses de implementação e três meses para a avaliação. O projeto inclui o 
cumprimento de marcos e alcances técnicos definidos pela Softex.
• Modelo Específico: cronograma, marcos e alcances são definidos em função dos objetivos da 
empresa, que arca com todo o custo do projeto.
O processo de implementação da Fumsoft é realizado por meio das atividades de diagnóstico inicial, 
treinamento/capacitação, consultorias executivas, análise crítica e diagnóstico Pre-Assessment. A 
quantidade de consultorias depende do nível que a empresa pretende alcançar, variando de 60 a 100 
horas, que são divididas em encontros de quatro horas.
Para iniciar a implementação, não é necessário qualquer tipo de treinamento. Durante o processo, são 
oferecidos cursos de capacitação para as empresas, já incluídos no plano. A obrigação da empresa 
consiste basicamente em designar um ou mais representantes com autonomia para delinear, 
acompanhar e participar das atividades de implementação, dando todo o suporte.”
Fonte: FUMSOFT. Modelo MPS .BR. 28 ago. 2013. Disponível em: <http://www.fumsoft.org.br/qualidade/
modelo_mpsbr>. Acesso em: 13 fev. 2017.
Pág. 89 de 97
CURIOSIDADE
De acordo com a ISD-Brasil (2010), “A ISD Brasil (Integrated System Diagnostics Brasil), subsidiária 
da empresa norte-americana Integrated System Diagnostics Incorporated - ISD Inc., tem como 
missão auxiliar as corporações na melhoria contínua de seus processos de negócios, baseando-se 
em modelos e normas reconhecidas internacionalmente, buscando sempre o compromisso com a 
excelência, os resultados reais e o alinhamento máximo dos objetivos estratégicos da organização 
aos seus processos atuais e desejados.
A ISD Brasil é a primeira consultoria internacional com atuação direta na América do Sul, 
focada exclusivamente em qualidade de processos baseada em modelos. O trabalho envolve, 
fundamentalmente, consultoria, treinamento, auditorias/avaliações/certificações, seleção de 
fornecedores, gestão de portfolio de projetos, quality assurance e e-learning.
Tornou-se a primeira no Brasil a contar com as credenciais do SEI-Software Engineering Institute para 
efetuar avaliações oficiais (aquilo que o mercado chama de ‘certificação’). Conta com os primeiros 
profissionais no mercado brasileiro autorizados a conduzir avaliações de processos com resultados 
reconhecidos internacionalmente – incluindo avaliadores para altos níveis de maturidade do CMMI, 
ou ‘high maturity lead appraisers’.
Atualmente, a ISD Brasil é a única empresa brasileira a contar em seus quadros com high maturity 
lead appraisers, ou HMLA, autorizados e credenciados pelo CMMI Institute. Esses profissionais são 
autorizados a liderar avaliações de nível 4 e 5 do CMMI, consideradas avaliações de alta maturidade.
Fonte: ISD Brasil. Empresa. 10 nov. 2010. Disponível em: <http://www.isdbrasil.com.br/empresa.php>. 
Acesso em: 13 fev. 2017.
A ISD Brasil fez a revisão técnica da tradução do CMMI (Capability Maturity Model Integration) 
para o português. É a única empresa no Brasil que participou da equipe de projeto do CMMI versão 
1.3 (Appendix C do material de referência do modelo: CMMI Version 1.3 Project Participants).”
Pág. 90 de 97
ATIVIDADE REFLEXIVA
Analise o estudo de caso abaixo e reflita: como ficaria o mapeamento de processos da notação BPMN 
do caso abaixo?
“A empresa Alfa é um consórcio entre duas grandes empresas nacionais de construção civil e foi 
constituída para realizar o projeto de construção de duas Plataformas flutuantes de produção, 
armazenamento e transferência de petróleo (Floating Production Storage and Offloading - FPSO), cuja 
cliente é a Petrobras S/A. Pertencente a um grupo econômico que possui um estaleiro de construção 
e reparo de navios há cerca de 10 anos, Alfa é hoje uma das principais representantes do Polo Naval 
de Rio Grande, responsável pela construção, integração – processo que consiste na construção, 
operacionalização e instrumentação de equipamentos – e entrega de seis FPSO’s até 2020 (SINAVAL, 
2015).
A unidade de recursos humanos da empresa é responsável pelos processos de Recrutamento 
e seleção; Admissão; Demissão; Ponto; Benefícios; Folha de pagamento; Encargos trabalhistas; 
Acesso ao canteiro por visitantes, funcionários e subcontratados; Relatórios de acompanhamento 
de escopo de obra aos outros setores da empresa; e Relações sindicais e legais. O interesse pelo 
mapeamento de processos deu-se em razão do escopo futuro da obra, que neste momento, possui 
aproximadamente 400 funcionários, divididos em quatro locais, sendo estes: Rio Grande (200); Rio 
de Janeiro (120); Dalian - China (60) e Chon Buri - Tailândia (20). Contudo, segundo a programação do 
setor de planejamento da empresa, até o mês de dezembro de 2016 o efetivo operacional da cidade de 
Rio Grande tem previsão de aumento de 2500 funcionários.”
Fonte: SILVEIRA, Leonardo da Silva et al. Proposta de Mapeamento de Processos usando a BPMN: 
Estudo de Caso em uma Indústria da Construção Naval. In: CONGRESSO INTERNACIONAL DE 
DESEMPENHO PORTUÁRIO, 3., Florianópolis, 2016. p. 14 Anais eletrônicos... http://www.cidesport.com.br/
sites/default/files/a52690.pdf). Florianópolis: Unisul/UFSC, 2016.
Pág. 91 de 97
Pág. 92 de 97
CONCLUSÃO
Concluímos que esta disciplina certamente agrega um importante conjunto de informações 
sobre como devemos administrar a qualidade nos processos de desenvolvimento de software e 
como o BPM é importante no contexto corporativo.
No âmbito do ensino profissional e mesmo no meio acadêmico estamos vendo crescer a busca 
por certificações em qualidade, uma vez que as organizações estão em constante adaptação e 
melhoria de seus processos para fazer frente a um mercado competitivo que muda suas preferências 
e apura seus parâmetros de comparação a todo momento.
A busca de soluções cada vez mais eficientes vai encontrar no estudo da qualidade um meio 
seguro de atualização de métodos e processos que, aliado às metodologias de modelagem de 
processo, permitem acompanhar a evolução da forma como a organização deve executar e controlar 
os seus processos de negócios. Na produção de software, por exemplo, a automatização das etapas 
de testes desoftware também tem estado cada vez mais presente, auxiliando o processo final de 
testes. É esperado que as organizações incluam no decurso de seu desenvolvimento o processo 
de qualidade de software, não apenas no momento que o produto foi finalizado ou desenvolvido, 
mas desde o início de sua concepção.
O conteúdo aqui apresentado traz os conhecimentos necessários para que você se atualize na 
gestão da qualidade e acompanhe, com facilidade, a evolução da terminologia e uso dos processos 
de modelagem de negócios, com o BPM.
Pág. 93 de 97
GLOSSÁRIO
Equivalente: De valor idêntico; que possui a mesma força, peso, dimensões. (fonte: <https://www.
dicio.com.br/equivalente/>).
Modelagem de negócios: Em engenharia de sistemas, é a atividade de representação de processos 
de uma empresa, de modo que o processo atual pode ser analisado e melhorado. BPMN (business 
process modeling notation) é uma notação padrão para os casos de modelagem de processos de 
negócio e tem como finalidade prover recursos para que a modelagem possa ser feita. Modelagem 
de processos de negócio é normalmente realizado por analistas de negócios e gestores que estão 
buscando melhorar a eficiência do processo e da qualidade. (fonte: <https://pt.wikipedia.org/wiki/
Modelagem_de_processos_de_neg%C3%B3cio>).
Predizível: Diz-se do que é possível predizer, antecipar. (fonte: <http://www.dicionarioinformal.com.br/
prediz%C3%ADvel/>)
Transfuncional: Aquilo que pode ser ou é realizado por meio de várias funções através de várias 
funções. (fonte: <http://www.dicionarioinformal.com.br/significado/transfuncional/8532/>)
Pág. 94 de 97
BIBLIOGRAFIA
ABNT Associação Brasileira de Normas Técnicas. NBR ISO/IEC 9126-1. Engenharia de software - 
Qualidade de Produto. Parte 1- Modelo de qualidade . Jun. 2003.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO (SOFTEX). MPS .
BR - Melhoria de Processo do Software Brasileiro. Brasília: Softex, 2016. Disponível em: <http://www.
softex.br/wp-content/uploads/2016/04/MPS.BR_Guia_Geral_Software_2016-com-ISBN.pdf?x15632>. Acesso 
em: 8 jun. 2017.
ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). ABPMP BPM 
CBOK 3 .0: Guia para o gerenciamento de processos de negócio-corpo comum de conhecimento. 
ABPMP Brazil, 2013. Disponível em: <http://c.ymcdn.com/sites/www.abpmp.org/resource/resmgr/Docs/
ABPMP_CBOK_Guide__Portuguese.pdf>. Acesso em: 15 mar. 2017.
ACADEMIA PEARSON. OSM: uma visão contemporânea. São Paulo: Pearson Prentice-Hall, 2011.
BARRADEL, Ana E. 3 motivos do porquê o BPM não deu certo na sua empresa. Disponível em: 
<http://blog.lecom.com.br/blog/2015/08/04/3-motivos-que-o-bpm-nao-deu-certo/>. BlogLecom, 4 ago. 2015. 
Acesso em: 27 mai. 2017.
CAMPOS, Fábio M. Qualidade, qualidade de software e garantia da qualidade de software são as 
mesmas coisas? Linha de Código, 12 mar. 2008. Disponível em: <http://www.linhadecodigo.com.br/
artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.
aspx>. Acesso em: 1 fev. 2017.
CENTRO DE TECNOLOGIA DA INFORMAÇÃO (CTI). Software público brasileiro: uma visão sistêmica. 
2013. Disponível em: <https://softwarepublico.gov.br/social/articles/0003/7464/Software_P_blico_Brasileiro__
Perspectiva_Sist_mica__2012_.pdf>. Acesso em: 31 jan. 2017.
CHRISSIS, Mary B.; KONRAD, Mike; SHRUM, Sandy. CMMI®: guidelines for process integration and 
product improvement. Boston: Addison Wesley, 2003.
DAVENPORT, T. H. Reengenharia de processos. Rio de Janeiro: Campos, 1994.
Pág. 95 de 97
DPO/UnB. BPMN. 2015. Disponível em: http://www.dpo.unb.br/documentos/BPMN.pdf. Acesso em: 19 
mar. 2017.
FONSECA, Wilson. Gestão por processos: diferença entre a visão departamental e visão por processos. 
Tecpro .IT, 15 jul. 2009. Disponível em: <http://www.tecproit.com.br/downloads/Artigo-BPM-AGO2009-Wilson-
TecProIT.pdf>. Acesso em: 18 mar. 2017.
FRANCISCANI, Juliana F.; PESTILLI, Ligia C. CMMI e MPS.BR: um estudo comparativo. 2012. Rumos 
da pesquisa, v. 1, p. 157-170, 2016. Disponível em: <http://www.unicerp.edu.br/images/revistascientificas/3%20
-%20CMMI%20e%20MPS.BR%20Um%20Estudo%20Comparativo1.pdf>. Acesso em: 12 fev. 2017.
FUMSOFT. Modelo MPS .BR. 28 ago. 2013. Disponível em: <http://www.fumsoft.org.br/qualidade/modelo_
mpsbr>. Acesso em: 13 fev. 2017.
GARVIN, David A. Gerenciando a qualidade. Rio de Janeiro: Qualitymark, 2002.
HERNASKI, Maurício. Qualidade do produto vs qualidade do processo. Maurício Hernaski Blog, 11 
out. 2010. Disponível em:<http://hernaski.com.br/blog/qualidade-do-produto-vs-qualidade-do-processo/1>. 
Acesso em: 31 jan. 2017.
ISD Brasil. Empresa. 10 nov. 2010. Disponível em: <http://www.isdbrasil.com.br/empresa.php>. Acesso 
em: 13 fev. 2017.
iPROCESS EDUCATION. Guia de Referência Rápida BPMN 2 .0. 30 maio 2014. Disponível em: <http://
iprocess.com.br/guia-bpmn/>. Acesso em: 19 mar. 2017.
KOSCIANSKI, André; SOARES, Michel S. Qualidade de software. São Paulo: Novatec, 2009.
LAGE JÚNIOR, Murís. Mapeamento de processos de gestão empresarial. Curitiba: Intersaberes, 2016.
MARCONDES, José Sérgio. Processo organizacional: o que é? Conceito, definição, estrutura. Blog 
Gestão de Segurança Privada, 20 jun. 2015. Disponível em: <http://www.gestaodesegurancaprivada.com.
br/processo-organizacional-conceito/>. Acesso em: 26 maio 2017.
McCALL, James A. Quality factors. In: MARCINIAK, John J. Encyclopedia of software engineering. 
New York: John Wiley, 2002. Disponível em: <http://onlinelibrary.wiley.com/doi/10.1002/0471028959.sof265/
full>. Acesso em: 13 fev. 2017.
Pág. 96 de 97
MENA, Isabela. Verbete Draft: o que é CMMI. Projeto Draft, 10 jun. 2015. Disponível em: <http://
projetodraft.com/verbete-draft-o-que-e-cmmi/>. Acesso em: 8 jun. 2017.
MINISTÉRIO PÚBLICO FEDERAL (MPF). Secretaria Jurídica e de Documentação. Escritório de 
Processos Organizacionais. Manual de gestão por processos. Brasília: MPF, 2013. Disponível em: 
<http://www.mpf.mp.br/conheca-o-mpf/gestao-estrategica-e-modernizacao-do-mpf/escritorio-de-processos/
publicacoes/livros/manualdegestaoporprocessos.pdf>. Acesso em: 15 mar. 2017.
NUNES, Lucas. O cenário atual e a evolução do gerenciamento de processos de negócio nas 
organizações brasileiras - Parte I. Blog Lecom, 7 jun. 2014. Disponível em: <http://blog.lecom.com.br/
blog/2014/07/21/cenario-atual-evolucao-gerenciamento-de-processos-de-negocio-nas-organizacoes-brasileiras-
parte/>. Acesso em: 21 abr. 2017.
OLIVEIRA, Otávio J. (Org.) et al. Gestão da qualidade: tópicos avançados. São Paulo: Thomson, 2004.
OBJECT MANAGEMENT GROUP (OMG). Business Process Model and Notation (BPMN) Version 
2 .0 .2. 2013. Disponível em: <http://www.omg.org/spec/BPMN/2.0/>. Acesso em: 19 mar. 2017.
PALMER, Nathaniel. What is BPM? BPM .com, 26 mar. 2014. Disponível em: <http://bpm.com/what-is-
bpm>. Acesso em: 18 mar. 2017.
PERIARD, Gustavo. Qualidade total: o que é e como funciona. Sobre Administração, 9 abr. 2013. 
Disponível em: <http://www.sobreadministracao.com/qualidade-total-o-que-e-e-como-funciona/>. Acesso 
em: 31 jan. 2017.
PETRY, Marcelo E. CMMI – boas práticas no desenvolvimento e implantação. Blog Cigam, 6 jul. 
2011. Disponível em: <http://blogcigam.magicsoftware.com.br/tag/cmmi/>. Acesso em: 12 fev. 2017.
PFLEEGER, S. l. Engenharia de software: teoria e prática. São Paulo: Prentice Hall, 2004.
PLAYS-IN-BUSINESS.COM. Capability Maturity Model Integration – CMMI. 2010. Disponível em: 
<http://plays-in-business.com/pibold/2010/12/cmmi-overview-1/?lang=en>. Acesso em: 4 fev. 2017.
PROJECT MANAGEMENT INSTITUTE (PMI). Um guia do conhecimento em gerenciamento de 
projetos - Guia PMBoK®. 5. ed. Newtown Square: 2013.
PRESSMAN, Roger S. Engenharia de software. 7. ed. Porto Alegre: AMGH, 2011.Pág. 97 de 97
PRESSMAN, Roger S. 6. ed. São Paulo: Pearson McGraw-Hill, 2006.
Fonte: PROMOVE. O que é CMMI? 7 fev. 2016. Disponível em: <http://www.promovesolucoes.com/cmmi>. 
Acesso em 8 jun. 2017.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo: Prentice Hall, 2004.
REID, Dan R.; SANDERS, Nada R. Total quality management. In: ______. Operations management. 
2010. Cap. 5. Disponível em: <http://www.wiley.com/college/sc/reid/chap5.pdf>. Acesso em: 1 fev. 2017.
ROYCE, Walker. CMM vs. CMMI: from conventional to modern software management. The Rational 
Edge, 2002. Disponível em <http://www.student.nada.kth.se/~karlm/CMMI.pdf>. Acesso em: 4 fev. 2017.
SEI (SOFTWARE ENGINEERING INSTITUTE). CMMI for Services - version 1.3 (CMMI-SVC 1.3). Hanscom 
AFB: SEI Administrative Agent, 2010.
STADLER, Adriano (Org.). Gestão por processos com suporte em tecnologia da informação. Curitiba: 
Intersaberes, 2013.
STEFANINI. Apenas 11,8% das empresas de TI brasileiras têm certificação de qualidade. 17 set. 2015. 
Disponível em: <https://stefanini.com/br/2015/09/apenas-118-das-empresas-de-ti-brasileiras-tem-certificacao-
de-qualidade/>. Acesso em 7 jun. 2017.
TRENTIM, Mário H. Modelagem de processos de negócio. Techoje, 5 mar. 2010. Disponível em: 
<http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1142>. Acesso em 18 mar. 2017.