Atualizado e revisado por

JOSÉ DO CARMO RODRIGUES

Professora autora/conteudista
ELISAMARA DE OLIVEIRA
É 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
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. 5 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. 6 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

Funcional com Processos com

Vertical
processos funcional em Processos horizontais
funcional
em segundo plano segundo plano

Estrutura orientada
Gestão funcional
por processo
tradicional

Fonte: Fonseca (2009)

Pág. 7 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. 8 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. 9 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. 10 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

Processo de negócio Representa processo de negócio primário, de

suporte ou de gerenciamento

Subprocesso Decomposição do processo de negócio por

Visão lógica afinidade, objetivo ou resultado desejado
(Processo) ∞

Visão física ∞
(Função)
Grupo de atividades e competências
Função de negócio
especializadas

Conjunto de tarefas necessárias para

Atividade entregar uma parte específica e definível de
um produto ou serviço

Decomposição de atividades em conjunto de

Tarefa passos ou alçoes para realizar o trabalho em um
determinado cenário

Cenário Modalidade de execução de tarefa

Passo Ação em nível atômico

Fonte: ABPMP (2013, p. 33)

Pág. 11 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. 12 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çã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. 13 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. 14 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. 15 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. 16 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. 17 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. 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. 18 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. 19 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. 20 de 97
 Figura 7 - Medições de desempenho por camada organizacional

Processo de Expectativas
negócio do cliente
Nível de
processo
Processo de Medição de eficácia
negócio (fazendo as coisas certas)

Decomposto em

Medição de eficiência (Fazendo certo as coisas)

Processo de Processo de
negócio negócio

Área funcional Processo de Processo de

negócio negócio

Nível de
função
Processo de
negócio

Área funcional Processo de

negócio

Decomposto em

Indicador de Indicador de
desempenho desempenho
operacional operacional

Executor Tarefa Tarefa

1 3

Nível de
função
Indicador de
desempenho
operacional

Executor Tarefa
2

Decomposto em

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. 21 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 Gráfico 1 - Setores das organizações

O cenário atual e a evolução do gerenciamento ONG e OSCIP Economia

de processos de negócio nas organizações 1% mista
5%
brasileiras

“[...] resultados da 1ª Edição da Pesquisa

Nacional em Gerenciamento de Processos
de Negócio realizada em 2013. A pesquisa Pública
foi realizada pela ABPMP Brasil, com o 26%
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
Privada
anos a organização vem trabalhando com o 68%
Gerenciamento de Processos de Negócio, quais
foram os motivadores para introdução do BPM, Fonte: <http://blog.lecom.com.br/wp-
perfil dos profissionais que trabalham com content/uploads/grafico1.jpg>.
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.

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. 22 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. 23 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. 24 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 Padrão criado pelo Object Management Group, útil para apresentar um
Process Model and modelo para públicos-alvo diferentes.
Notation)

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 Desenvolvido como parte da estrutura de trabalho ARIS, considera eventos
Process Chain) como “gatilhos para” ou “resultados de” uma etapa do processo; útil para
modelar conjuntos complexos de processos.

UML (Unified Modeling Mantido pelo Object Management Group, consiste em um conjunto-padrão
Language) de notações técnicas de diagramação orientado à descrição de requisitos
de sistemas de informação.

IDEF (Integrated Padrão da Federal Information Processing Standard dos EUA que destaca
Definitiono Language) 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. 25 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. 26 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. 27 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. 28 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
Processo 1

Lane ou raia: É uma subpartição da pool. São usadas para organizar e

categorizar a pool.
Lane 1
Processo 1

Lane 2

Fluxo de sequência: É usado para mostrar a

Tarefa 1
ordem em que as atividades serão
executadas. Cada fluxo tem só uma
origem e só um destino.
Administração

Fluxo de mensagem: É usado para mostrar o

fluxo de mensagem entre dois participantes,
ou seja, entre duas pools.
humanos
Recursos

Tarefa 1

Associação: Usada para associar

informações com objetos de fluxos

Tarefa 1

Fonte: DPO/UnB (2015)

Pág. 29 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 Evento de intermediário Evento de fim
(Start events) (intermedate events) (end events)

Acontece durante
Inicía um Finaliza o fluxo
o curso de um
processo do processo
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 Fonte: iProcess

incorporado: Education
Herda (2014)
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, Pág. 30 de 97

indicando que está sendo reutilizado no fluxo em que está inserido.
 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 que13
Figura o motor de regras pode prover.
– Subprocessos

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 Figura 14 – Gateways

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
Exclusive Event based Parallel
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
Inclusive Exclusive Complex
event based (exclusivo baseado em evento), event based

complex (complexo) e parallel event based

(paralelo baseado em evento).

Parallel event
based

Fonte: baseado em OMG (2013, p. 61)

Pág. 31 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

Realizar Publicar
revisão final artigo

Comunicar
Avaliar Cancelar
partes
artigo artigo
interessadas

Ajustar
artigo

Notificar
gerência sobre
cancelamento
Não

Enviar proposta Enviar contrato

de crédito ao cliente

Não

Contatar
novamente o
cliente
5 dias

Escrever
artigo

Definir tema Realizar

do artigo diagramação

Selecionar Tratar
imagens imagens

Negativa civil Anexar

negativa civil

Identificar Negativa Analisar

criminal Anexar negativa
documentação validade
criminal
necessária dos documentos

Negativa de
débitos Anexar negativa
de débitos

Fonte: DPO/UnB (2015)

Pág. 32 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

Privativo: São utilizados quando não há interesse em verificar a interação entre esse processo e outros

Tarefa 2
Processo 1

Tarefa 1

Tarefa 3

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.

Tarefa 2
Processo 1

Tarefa 1

Tarefa 3

5 dias
Processo 1

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

Tarefa 2
Processo 1

Tarefa 1

Tarefa 3

5 dias
Processo 1

Tarefa 1 Tarefa 1 Tarefa 1

Fonte: DPO/UnB (2015)

Pág. 33 de 97
 Figura 17 – Diagrama BPMN
Cliente

Título de Confirmação Livros Confirmação de

Pedido de livros vendidos recebimento
cobrança de pagamento

Registrar
Atendimento

pedido
Receber
pedido do
cliente
Processo vender livros via Web

Um ou
mais itens
indisponíveis
Emitir Emitir
Cobrança

cobrança nota fiscal

Cobrança Recebimento
enviada confirmado
Expedição

Emitir Emitir Emitir

nota fiscal nota fiscal nota fiscal
Fim
Encomendar obra

Entrega da Entrega da
encomenda encomenda
Editora

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. 34 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. 35 de 97
 Figura 18 - Modelo e notação de decisões – DMN

Modelo de processo de negócio

Coletar dados
da aplicação

Modelo de decisão
(DMN)
Decidir Tabela de
Roteamento
roteamento roteamento

Modelo de Risco da Regras de

pontuação de riscos Elegibilidade
operação elegibilidade
das coerações

Recusar Recusar
cliente cliente

Nível de Requisitos Operação

de decisão

Regras de elegibilidade

Elegibilidade
Situação de
P País Idade Elegível
emprego
Inelegível

1 Desempregado - - Inelegível

2 - not(Brasil) - Inelegível

3 - - <18 Inelegível

4 - - - Elegível

Nível de lógica
de decisão

Fonte: <http://blog.iprocess.com.br/wp-content/uploads/2014/12/Compara%C3%A7%C3%A3o1.png>

Pág. 36 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. 37 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? Portabilidade: posso usá-lo em outro SO?

Flexibilidade: posso mudá-lo? Reusabilidade: posso reutilizar parte do Sw?
Testabilidade: posso restá-lo? Interoperabilidade: posso compor uma interface
com outro sistema?

Revisão Transição

Operação

Corretitude: ele faz o que foi especificado? Integridade: ele oferece segurança?
Confiabilidade: ele tem precisão o tempo todo? Usabilidade: ele foi construído para o usuário?
Eficiência: ele rodará neste Hw em tempo Adaptabilidade: ele se adapta ao usuário?
adequado?

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. 38 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), FIGURA 21 – ISO (International

Organization for Standardization)
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.

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. 39 de 97
3.2 Norma ISO 14598 - Avaliação FIGURA 22 - Importante
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 A avaliação de produtos de
software é definida como uma
ainda maior é conseguir identificar, ao final do desenvolvimento, operação técnica que consiste
em elaborar um julgamento de
se o produto de software atende aos requisitos previamente uma ou mais características de
um produto de software de acordo
estabelecidos. Com a finalidade de auxiliar nestas complexas com um procedimento definido.
Fonte: Norma ISO 14598
tarefas, processos de avaliação de produtos de software foram
desenvolvidos e consolidados na 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 Requisitos de
requisitante avaliação
Estabelecimento
dos requisitos da
avaliação

Especificação da
avaliação
Especificação da
avaliação

Descrição do Especificação Plano de Registros de

produto da avaliação avaliação avaliação
predefinida
Projeto da
avaliação

Registros de ações
Entradas fornecidadas Métodos de de revisão
pelo avaliador avaliação
Relatório
Execução de de avaliação
avaliação preliminar

Ferramentas de
avaliação Relatório
Componentes Síntese dos resultados de avaliação
do produto de avaliação revisado
Conclusão da
avaliação

Entradas fornecidas
pelo requisitado

Fonte: <https://www.goconqr.com/p/4613970-2--qualidade-de-produto-de-software-slide_sets>.

Pág. 40 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. 41 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

Processo Produto de software Efeitos de produto

de software
Influência Influência Influência

Qualidade do Atributos de Atributos de Atributos de

processo qualidade interna qualidade externa qualidade em uso

Depende de Depende de Depende de

Medidas de Medidas Medidas Medidas de

processo internas externas qualidades de
uso

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. 42 de 97
 Figura 26- Modelo de Qualidade - ISO 9126 (parte 1)

Qualidade
externa e
interna

Funcionalidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade

Adequação Maturidade Inteligibilidade Comportamento Analisabilidade Adaptabilidade

Acurácia Tolerância a falhas Apreensibilidade em relação ao Modificabilidade Capacidade para
Interoperabilidade Recuperabilidade Operacionalidade tempo Estabilidade ser instalado
Segurança de Atratividade Utilização de Testabilidade Coexistência
acesso Conformidade recursos Capacidade para
relacionada à Conformidade Conformidade substituir
Conformidade confiabilidade relacionada à Conformidade relacionada à
relacionada à usabilidade relacionada à manutenibilidade Conformidade
funcionalidade eficiência 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. 43 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. 44 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 FIGURA 27 – Certificação ISO
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
Fonte: Aquir / shutterstock.com
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.”

Pág. 45 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 Série de SQuaRE: Série

normas 9126 normas 14698 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. 46 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

Processos fundamentais Processos de apoio

Aquisição Documentação

Aquisição Gerência de configuração

Garantia da qualidade
Operação Verificação
Validação
Desenvolvimento Revisão conjunta
Auditoria
Manutenção

Resolução de problemas

Processos organizacionais
Gerência Infraestrutura Melhoria Treinamento

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 atividades do 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. 47 de 97
 5. Processo de operação - define as atividades de operação FIGURA 30 – Processos de apoio
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 Fonte: Flat Design /

shutterstock.com

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:

Pág. 48 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. 49 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. 50 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. 51 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. 52 de 97
 Figura 33 – História dos modelos CMM

CMM for Software INCOSE SECAM Systems Engineering

V1.1 (1993) (1996) CMM V1.1 (1995)

Software CMM EIA 731 SECM Integrated Product

V2, draft C (1997) (1998) Development CMM (1997)

Software Acquisition V1.02 (2000)

CMM V1.03 (2002)
V1.1 (2002)
CMMI for Development
V1.2 (2006)
CMMI for Acquisition CMMI for Services
V1.2 (2007) V1.2 (2009)

CMMI for Acquisition CMMI for Development CMMI for Services

V1.3 (2010) V1.3 (2010) V1.3 (2010)

Fonte: SEI (2010, p. 18).

4.2 Visão geral do modelo CMMI

O CMMI (Capability Maturity Model Integration), como FIGURA 34 – CMMI - Capability

Maturity Model Integration
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
Fonte: <http://cmmiinstitute.com/
de aplicação e estrutura e tamanho da organização. O CMMI sites/all/themes/cmmi/images/
header_CMMI_institute_logo_full.png>
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.

Pág. 53 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. 54 de 97
 Figura 35 – Constelações CMMI e as PAs

Supplier/Provider Customer

RD
Development

TS
VAL

CMMI-DEV ATM
ARD
VER SSAD
RSKM
REQM CAR
PPQA PP/WP
SAM
QPM/QWM IPM/IWM CMMI-ACQ
DAR OPP OPM/IPM
OPF MA OPD AVER
PMC/WMC
OT
CM AVAL
SD

AM
IRP
Services

SST

CMMI-SVC CAM
SSD
SCON
SSM

CMMI-SVC: 7 service specific PAs

1 shared PA with CMMI-DEV

16 common

+ Process Areas
CMMI-DEV: 6 development specific Pas
1 shared PA with CMMI-SVC to all v1.3
constellations
CMMI-ACQ: 6 acquisition specific PAs

Fonte: Plays-in-business.com (2010).

Pág. 55 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

Benefícios com a implantação integrada do CMMI-DEV e CMMI-SVC

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 do desempenho Implantação de inovações
das equipes (produtividade, nos processos, produtos e
tempo médio de resolução serviços
de incidentes e solicitações
Melhora no desempenho
de serviços etc)
das equipes
Controle da qualidade dos Melhora na qualidade dos
processos, produtos e
processos, produtos e
serviços (quantidade de serviços
erros econtrados pelo
cliente, quantidade de
interrupções de serviço etc)

Controle na resolução e
prevenção de incidentes

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. 56 de 97
4.3 Componentes do modelo CMMI FIGURA 36 – 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 Fonte: Profit_Image / shutterstock.com

• CobiT - Control Objectives for Information

and related Technology
• ITSCMM - Information Technology Services Capability Maturity Model

De acordo com SEI (2010, p. 20), o CMMI-SVC cobre 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.

Pág. 57 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 Notas Áreas de

área de introdutórias processos
processo relacionadas

Metas Metas
específicas específicas
(SG) (GG)

Práticas Práticas
específicas genéricas
(SP) (GP)

Produto
Orientação de
típico de Subprática Subprática
aplicação
trabalho

Legenda: Requerido Esperado Informativo

Fonte: baseado em SEI (2010, p. 22)

Pág. 58 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. 59 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

Continuous Representation Staged Representation

Level
Capability Levels 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. 60 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.
Representação contínua
Figura 38 – Representação contínua do CMMI

Áreas de processos
Níveis de
capacidade

Metas Metas
específicas genéricas

Práticas Práticas
específicas genéricas

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. 61 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.

Representação
Figura 39 – Representação contínua
contínua do CMMI

Níveis de
maturidade
Áreas de processos

Metas Metas
específicas genéricas

Práticas Práticas
específicas genéricas

Fonte: baseado em SEI (2010, p. 34)

Pág. 62 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. 63 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. 64 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. 65 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. 66 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 garantir que 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. 67 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. 68 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. 69 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. 70 de 97
4.8.1 Nível de capacidade 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. 71 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 FIGURA 43 - Visão geral do MPS.BR
foi criado em dezembro de 2003 e coordenado pela Softex e do MR-MPS-SW

(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 Fonte: <http://www.softex.br/wp-content/
uploads/2013/07/Logotipo-sem_slogan_
através de programas de qualificação de profissionais nesta área Cromatica-Positivo-300x152.png?x15632>.
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

Pág. 72 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 Modelo MPS

P-CMM
MoProSoft
ISO 9001

CMMI-DEV CMMI-SVC
ISO/IEC 330xx
ISO/IEC 12207 ISO/IEC 20000

Modelo de Modelo de
Modelo de Método de Modelo de
referência MPS referência MPS
referência MPS avaliação negócio
para serviço para gestão de
para software (MA-MPS) (MN-MPS)
(MR-MPS-SV) pessoas

Guia geral MPS Guia geral MPS

Guia geral MPS Documentos do
de software de gestão de Guia de avaliação
de serviço programa
pessoas

Guias de Guias de Guias de

implementação implementação implementação

Guia de aquisição

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. 73 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. 74 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). Isto
significa 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 AP 1.1 e AP 2.1

Gerência de Projetos – GPR

F Medição – MED AP 1.1, AP 2.1 e AP 2.2

Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU

E Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP

Gerência de Reutilização – GRU 3.1 e AP 3.2
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP

D Verificação – VER AP 1.1, AP 2.1, AP 2.2, AP

Validação – VAL 3.1 e AP 3.2
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE

C Gerência de Riscos – GRI AP 1.1, AP 2.1, AP 2.2, AP

Desenvolvimento para Reutilização – DRU 3.1 e AP 3.2
Gerência de Decisões – GDE

Pág. 75 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 FIGURA 45 – Atributos de processos

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.
Fonte: Shany Muchnik /
Como resultado da implementação completa deste atributo shutterstock.com

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;

Pág. 76 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. 77 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.

5.3.6 AP 4.1 O processo é objeto de análise quantitativa FIGURA 46 – Analise

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
Fonte: AVIcon /
uma única vez e ao mesmo tempo para todos os processos. Caso o processo shutterstock.com
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. 78 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 o processo 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. 79 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. 80 de 97
5.4 Processos por níveis de maturidade do MR-MPS-SW
Nesse capítulo estudaremos os processos FIGURA 47 - Processos por níveis de maturidade
ordenados pelo nível de maturidade de forma do MR-MPS-SW

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.
Fonte: Emanuela Carratoni / shutterstock.com

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.

Pág. 81 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. 82 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. 83 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. 84 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. 85 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. 86 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

5
Em otimização

4
Gerenciado quantitativamente

Definido

3
Largamente definido

Parcialmente definido

Gerenciado
2

Parcialmente gerenciado

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 fazerem isso. 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. 87 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. 88 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. 89 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. 90 de 97
Pág. 91 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 de software 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. 92 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. 93 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. 94 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. 95 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. 96 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.

Pág. 97 de 97