GEST DA QUALI COM ÊNF EM BPM (NPG5005)

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 
atividades bem 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 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.
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çãofí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 de processos
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. Modelagemde 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
 d
e 
ef
ic
iê
nc
ia
 (F
az
en
do
 c
er
to
 a
s c
oi
sa
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 
anosa 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áfico 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/grafico1.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 conjunto intuitivo 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 processosorganizacionais.
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
A
dm
in
is
tr
aç
ã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 queestá 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 
vi
a 
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ão com 
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
dascoeraçõ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 é definida 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 definido. 
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çãoFonte: <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ções ou 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