Apostila-Estacio-Gestão de produção e qualidade pdf

Prévia do material em texto

Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
1
Gestão da Qualidade 
com ênfase em BPM
José do Carmo Rodrigues
Elisamara de Oliveira
João Caldas Junior
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
2
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
3
Apresentação .......................................................................5
Fundamentos da Qualidade de Software ............................5
Conceitos Fundamentais de Qualidade ........................................ 5
Qualidade de Software .............................................................. 7
Qualidade de processo .............................................................. 8
Qualidade total ......................................................................... 9
Qualidade e o ciclo de vida do produto ..................................... 11
Qualidade de Produto de Software ...................................16
Modelos de Qualidade de Software ........................................... 16
Qualidade segundo o PMBOK ................................................... 18
Avaliação de Produtos de Software ........................................... 18
Modelo de Qualidade ISO 9126 ................................................ 20
Funcionalidade ................................................................... 20
Confiabilidade .................................................................... 21
Usabilidade ........................................................................ 21
Eficiência ........................................................................... 21
Manutenibilidade ................................................................ 21
Portabilidade ...................................................................... 21
CMMi- Qualidade de Processo de Software .......................23
Modelos ISO para qualidade de processo de software ................ 23
Modelos CMM para qualidade de processo de software .............. 24
CMM versus CMMI ................................................................... 25
CMMI ..................................................................................... 25
Visão geral do modelo CMMI .................................................... 26
Representações do modelo CMMI ............................................. 28
Representação Contínua ..................................................... 28
Representação por estágio .................................................. 29
Níveis de Maturidade CMMI ...................................................... 29
Modelo de Processo de Software Brasileiro (MPS.BR) ......35
Histórico e visão geral do MPS.BR ............................................. 35
Níveis de maturidade do MPS.BR .............................................. 36
Nível G – Parcialmente Gerenciado ...................................... 37
Nível F – Gerenciado ........................................................... 38
Nível E – Parcialmente Definido ........................................... 38
Nível D – Largamente Definido ............................................ 39
Nível C – Definido ............................................................... 40
Nível B – Gerenciado Quantitativamente .............................. 40
Nível A – Em Otimização ..................................................... 40
MPS.BR versus CMMI ............................................................... 40
Modelagem de Processos de Negócio (BPM) ....................42
A crescente importância dos processos ..................................... 42
SUMÁRIO
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
4
SUMÁRIO
Definição de processos ............................................................ 43
Orientação por processos nas organizações ............................... 44
Benefícios da orientação por processos ..................................... 45
Gerenciamento de Processos de 
Negócio - BPM ........................................................................ 46
O Ciclo de Vida dos Processos de Negócio ................................. 48
Captura da Definição do Processo ........................................ 48
Reengenharia do Processo .................................................. 49
Implementação do Processo ................................................ 49
Melhoria Contínua do Processo ............................................ 49
Modelagem e Otimização de Processos ................................ 50
Automação de Processos: Workflow .................................52
Definição de Workflow ............................................................. 52
O ciclo do workflow ................................................................. 52
Tipos de workflow ................................................................... 54
Workflows Ad hoc ............................................................... 54
Workflows Administrativos .................................................. 54
Classificação de workflows ....................................................... 56
Sistemas de Gerenciamento de Workflow .................................. 56
Escolha de um Sistema de Workflow ......................................... 58
Metodologias de Modelagem de Processos .......................59
Modelagem de Processos ......................................................... 59
Metodologia de Jacka & Keller .................................................. 59
Identificação do processo .................................................... 60
Coleta de dados ................................................................. 60
Entrevistas e geração do modelo ......................................... 61
Análise dos dados............................................................... 61
Apresentação ..................................................................... 62
Considerações Finais .........................................................63
Respostas Comentadas dos Exercícios ..............................63
Capítulo 1 ............................................................................... 63
Capítulo 2 ............................................................................... 64
Capítulo 3 ............................................................................... 65
Capítulo 4 ............................................................................... 65
Capítulo 5 ............................................................................... 66
Capítulo 6 ............................................................................... 67
Capítulo 7 ............................................................................... 67
Referências ........................................................................67
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
5
APRESENTAÇÃO
Caro aluno, 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 na Engenharia de Software visa à 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. Visam 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
Por outro lado, as organizações vêm buscando realizar 
a sua gestão por processos, embora muitos departamentos 
desenvolvam projetos. Administrar projetos e processosmodelos específicos para essas disciplinas, incluindo sua 
arquitetura, conteúdo e acesso, têm limitado o sucesso 
destes esforços. Além disso, aplicar modelos que não são 
integrados torna mais caro o treinamento, a avaliação e 
as atividades de melhoramento. Um conjunto de modelos 
que, com sucesso, se destina a múltiplas disciplinas e 
tem treinamento integrado e suporte de avaliação resolve 
estes problemas.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
26
mais que 1.500 mudanças requeridas. A versão atual do 
CMMI (versão 1.3) foi publicada no final de 2010.
A suíte de produtos que CMMI contém é produzida por 
um arcabouço que fornece a habilidade para gerar múltiplos 
modelos e materiais de avaliação e treinamento associados. 
Visão geral do modelo CMMI
O CMMI atualmente está organizado em três modelos 
(veja figura 6), 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 um modelo CMMI para ajudar 
a estabelecer objetivos e prioridades do melhoramento de 
processos, obtendo um guia para garantir estabilidade, 
processos estáveis e maduros.
Como mostra a figura 6, o modelo CMMI v1.2 contém 
22 áreas de processo. Dessas áreas de processos, dezesseis 
são áreas de processo principal, uma é uma área de 
processo comum e cinco são áreas de processo específicas 
do desenvolvimento.
Assim, o projeto CMM Integration foi formado para 
resolver o problema de usar múltiplos modelos CMM. 
A missão do grupo de produto CMMI foi combinar três 
modelos dentro de um único arcabouço de melhoramento 
para uso de organizações aspirando ao melhoramento dos 
processos como um todo.
(1) Capability Maturity Model for Software (SW-CMM) 
v2.0 draft C
(2) Electronic Industries Alliance Interim Standard 
(EIA/IS) 731, 
(3) Integrated Product Development Capability Maturity 
Model (IPDCMM) v0.98
Desenvolver um conjunto de modelos integrados 
envolve mais do que uma simples união de materiais de 
modelos existentes. Usando processos que promovem 
consenso, o grupo de produto CMMI construiu um 
arcabouço que acomoda múltiplas disciplinas e é bastante 
flexível para apoiar duas representações diferentes: por 
estágio e contínuo. 
A missão do grupo incluiu o desenvolvimento de um 
arcabouço comum para apoiar a futura integração de 
outros modelos CMMI de disciplinas específicas e garantir 
a consistência e compatibilidade de produtos desenvolvidos 
com ISO/IEC 15504 para avaliação de processo de software.
O grupo de produto CMMI avaliou mais de 3.000 
requisições de mudanças para criar a versão 1.0. 
Pouco tempo depois, a versão 1.02 (2002) foi lançada 
incorporando diversos melhoramentos menores. A versão 
1.1 (2003) acomodou mais melhoramentos, incorporando 
Figura 6 – Modelos CMMI
Fonte: http://www.teclogica.com.br/blog/?p=508
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
27
O CMMI é um modelo de referência que contém práticas 
(genéricas ou específicas) necessárias à maturidade em 
disciplinas específicas. O CMMI foi construído considerando 
três dimensões principais: pessoas, ferramentas e 
procedimentos. O processo serve para unir essas 
dimensões. O processo inclui quatro disciplinas ou corpos 
de conhecimento (body of knowledges), sendo elas:
[1] SE - Systems Engineering (Engenharia de 
Sistemas)
A engenharia de sistemas aborda o desenvolvimento de 
sistemas completos, que podem ou não incluir software. 
O enfoque dessa disciplina é capturar as necessidades do 
cliente, expectativas e restrições em produtos, fornecendo 
suporte necessário durante toda a vida do produto.
[2] SW - Software Engineering (Engenharia de 
Software)
A engenharia de software aborda o desenvolvimento 
de sistemas essencialmente de software. O papel dos 
engenheiros de software é aplicar abordagens quantificáveis 
ao desenvolvimento, operação e manutenção do software, 
de forma sistemática, disciplinada.
[3] IPPD - Integrated Product and Process 
Development (Desenvolvimento Integrado de 
Produto e Processo)
A área de conhecimento IPPD aborda, de maneira 
sistemática, o relacionamento e interação dos stakeholders 
mais representativos durante o tempo de vida do produto, 
objetivando satisfazer as necessidades do cliente, 
expectativas e requisitos. Os processos que contribuem 
com esta disciplina estão integrados a outros processos 
na organização.
[4] SS - Supplier Sourcing (Fornecimento de 
Recursos)
A disciplina de Fornecimento de Recursos tem como 
objetivo abordar a aquisição de produtos que podem 
melhorar, agilizar, ou simplificar o projeto, principalmente 
quando o esforço de trabalho é muito extenso ou complexo.
A engenharia de software (SW) é similar à engenharia 
de sistemas (SE) em relação às áreas de processo, apenas 
com enfoque diferente nos processos. As áreas de processo 
requeridas para engenharia de sistemas são as mesmas 
para engenharia de software, mas o nível de maturidade 
é diferente.
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.
Em sua representação por estágios, as áreas são 
divididas em cinco níveis de maturidade. 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 
e as genéricas. A essas metas, a definição do modelo 
recomenda práticas genéricas divididas em um conjunto 
de características comuns que por sua vez se divide em 
quatro categorias. São elas:
 Comprometimento com a execução: 
agrupa práticas relacionadas à definição de políticas e 
responsabilidades, descrevendo ações para assegurar que 
o processo se estabeleça e seja duradouro.
 Habilitação	 para	 execução: agrupa práticas 
contendo pré-condições para o projeto, de forma a permitir 
a implementação adequada do processo. 
 Direcionamento à implementação: agrupa 
práticas rela cionadas ao gerenciamento do desempenho 
do processo; 
	 Verificação	 da	 implementação: agrupa 
práticas para revisão junto à alta gerência e avaliação 
objetiva da conformidade com processos, procedimentos e 
padrões. É necessário que os esforços da empresa estejam 
focados na definição das metas específicas/genéricas para 
a realização do trabalho.
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; por sua vez as metas 
comuns focam em aspectos inerentes a qualquer empresa 
e devem ser considerados para a correta implementação 
da metodologia, de forma a garantir a maximização dos 
resultados.
As categorias acima descritas buscam direcionar as ações 
de forma a garantir que o ciclo de evolução seja completado, 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
28
possibilitando a implementação de uma evolução contínua 
dos processos e do produto como um todo.
O método CMMI não é de forma alguma 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 dos softwares.
Representações 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.
Comovimos, 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 
área de processo (Process Area - 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.
De acordo com Cortada (2009), estes caminhos 
(também chamados de representações do modelo) são 
importantes porque são eles que vão determinar o tipo de 
nível que será usado na organização. 
Para a representação contínua, usa-se o termo nível 
de capacidade ou ainda capacidade da área de processo. 
Ou seja, um nível de capacidade está relacionado a apenas 
uma área de processo. Exemplo: nível de capacidade 3 na 
área de planejamento de projetos.
Para a representação por estágios, usa-se o termo nível 
de maturidade ou ainda a maturidade da organização. 
Ou seja, um nível de maturidade está relacionado a um 
grupo de áreas de processo. Exemplo: nível de maturidade 
2 significa que a empresa implementou as práticas das 
áreas de processo PP, PMC, REQM, SAM, MA, PPQA e CM 
(mais detalhes na próxima seção).
Mas, caro aluno, é importante frisar que são duas 
formas de se enxergar a mesma coisa. Independente 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 qual é mais familiarizada. Se usados 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.
Representação Contínua
A representação contínua para a organização, o modelo 
CMMI:
 Permite selecionar a ordem e melhoria que mais 
se adequa 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.
 Permite uma fácil comparação de melhoria de 
processo com as normas ISO/IEC 15504.
Há seis níveis de capacidade, numerados de 0 até 5 
(veja tabela 3). Cada nível de capacidade corresponde a 
metas genéricas e a um conjunto de práticas genéricas e 
específicas. Os níveis de capacidade são aplicados a uma 
realização de processo de melhoramento de organização 
para cada área de processo. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
29
Tabela 3- Níveis de capacidade da representação contínua
Nível de 
Capacidade
Representação Contínua 
Níveis de Capacidade
0 Incompleto
1 Executável
2 Gerenciado
3 Definido
4 Quantitativamente Gerenciado
5 Otimizado
Representação	por	estágio
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 uma migração fácil de SW-CMM para 
CMMI.
 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 
(veja figura 7). A obtenção de um nível de maturidade 
permite assegurar que os fundamentos adequados 
de melhoria foram colocados para o próximo nível de 
maturidade permitindo a melhoria incremental dos 
processos na organização. 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 otimizado).
Níveis de Maturidade CMMI
No modelo CMMI, os níveis foram criados para denotar 
a capacidade de uma organização e representam um 
caminho evolucionário para aprimorar seus processos com 
base nas melhores práticas do CMMI.
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 figura 7). Por outro lado, 
do ponto de vista de quem compra o serviço destas 
organizações, os níveis permitem que comparações sejam 
feitas entre diversos fornecedores, avaliando em qual nível 
(ou níveis) as empresas operam. Uma avaliação externa 
realizada por um avaliador credenciado permite que as 
empresas determinem estes níveis e divulguem para o 
mercado sua capacidade.
Figura 7 – Níveis de maturidade do CMMI
Fonte: http://www.isdbrasil.com.br/o-que-e-cmmi.php
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
30
Modelos CMMI são projetados para descrever níveis 
discretos de melhorias de processos. Em uma representação 
por estágios, 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.
Nesta representação, a maturidade é medida por 
um conjunto de processos, sendo necessário que todos 
os processos até o nível requerido atinjam o nível de 
maturidade necessário para que a empresa seja certificada 
naquele nível do CMMI. São acumulativos e representam 
estágios que devem ser alcançados até o nível máximo 
de maturidade, onde o foco passa a ser a manutenção e 
melhoria contínua. Na tabela 4 podemos verificar todos os 
processos de cada nível.
Tabela 4 - Processos por nível de maturidade no CMMI
Nível de Maturidade 2
Gerência de Requisitos
Planejamento do Projeto
Monitoração e Controle do Projeto
Gerência de Acordos com Fornecedores
Medição e Análise
Garantia da Qualidade do Processo e do Produto
Gerência de Configuração
Nível de Maturidade 3
Desenvolvimento de Requisitos
Solução técnica
Integração do Produto
Verificação
Validação
Foco no Processo Organizacional
Definição do processo Organizacional
Treinamento Organizacional
Gerência de Projeto Integrada (parte só IPPD)
Gerência de Riscos
Integração da Equipe (IPPD)
Gerência Integrada de Fornecedores
Análise de Decisão e Resolução
Ambiente Organizacional para Integração (IPPD)
Nível de Maturidade 4
Desempenho do Processo Organizacional
Gerência Quantitativa do Projeto
Nível de Maturidade 5
Inovação e Deploy Organizacional
Análise e Resolução de Causas
O nível de maturidade de uma organização fornece 
uma maneira de prever o desempenho futuro de 
uma organização. A experiência tem mostrado que 
organizações fazem o melhor quando focam seus esforços 
de melhoramento de processos em número gerenciável de 
áreas de processo que requerem esforço crescente com o 
aperfeiçoamento da organização.
Um nível de maturidade é um patamar evolutivo de 
processo de melhoramento. Cada nível de maturidade 
estabelece uma parte importante dos processos da 
organização.
Os níveis de maturidade são medidos pelo alcance 
de metas específicas e genéricas que aplicam para cada 
conjunto predefinido de áreas de processo.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
31
Vamos, agora, detalhar cada um dos níveis de 
maturidade e seus processos associados.
•	 Nível	de	Maturidade	1:	Inicial
No nível de maturidade 1, processos são geralmente 
informais e caóticos e a organização, geralmente, 
não fornece um ambiente estável. O sucesso nestas 
organizações depende da competência e do heroísmo 
de pessoas da organização e não do uso dos processos. 
Organizações em níveis de maturidade 1 geralmenteproduzem produtos e serviços que funcionam, entretanto, 
eles frequentemente excedem o prazo e o orçamento 
de seus projetos. Estas organizações são caracterizadas 
pela tendência de ultrapassar compromisso, abandonar 
processo em tempos de crise e não ser capaz de repetir 
seus sucessos anteriores.
•	 Nível	de	Maturidade	2:	Gerenciado
No nível de maturidade 2, uma organização alcança 
todas as metas específicas e genéricas de áreas de 
processo. Em outras palavras, os projetos das organizações 
garantem que requisitos são gerenciados e que processos 
são planejados, executados, medidos, e controlados. A 
disciplina do processo refletido pelo nível de maturidade 
2 ajuda a garantir que práticas existentes são retidas 
durante tempos de estresse e que projetos são executados 
e gerenciados de acordo com os planos documentados.
O status dos produtos e a entrega de serviços são 
visíveis para controle em pontos definidos (por exemplo, 
nos principais marcos do desenvolvimento e na conclusão 
das principais tarefas). Compromissos são estabelecidos 
entre os stakeholders relevantes e revisados quando 
necessário. Os produtos e serviços satisfazem seus 
requisitos, padrões e objetivos especificados.
Em suma, no nível 2 do CMMI, os processos 
são caracterizados por projeto e as ações são 
frequentemente reativas. Os processos deste nível são:
 Gestão de Requisitos (REQM): o propósito do 
REQM é gerenciar os requisitos dos produtos e componentes 
de produto do projeto e identificar inconsistências entre 
esses requisitos e os planos e produtos de trabalho do 
projeto. 
 Planejamento de Projeto (PP): o propósito 
do PP é estabelecer e manter planos que definam as 
atividades de projeto.
 Monitoramento e Controle de Projeto (PMC): 
o propósito do PMC é proporcionar um entendimento 
do progresso do projeto, de forma que ações corretivas 
apropriadas possam ser tomadas quando o desempenho 
do projeto desviar significativamente do plano.
 Gestão de Acordo com Fornecedores (SAM): 
o propósito da SAM é gerenciar a aquisição de produtos de 
fornecedores.
 Medição	e	Análise	(MA): o objetivo da medição 
e análise é desenvolver e sustentar a capacidade de 
medições utilizada para dar suporte às necessidades de 
gerenciamento de informações (indicadores).
 Garantia da Qualidade de Processos e 
Produto (PPQA): o propósito da PPQA é munir a equipe 
e a gerência com uma visão clara sobre os processos e 
seus produtos de trabalho associados.
 Gestão	da	Configuração	(CM): o propósito da 
CM é estabelecer e manter a integridade dos produtos de 
trabalho, utilizando identificação de configuração, controle 
de configuração, balanço de configuração e auditorias de 
configuração.
•	 Nível	de	Maturidade	3:	Definido
No nível de maturidade 3, uma organização alcançou metas 
específicas e genéricas das áreas de processo atribuídas aos 
níveis 2 e 3. Neste nível os processos são bem caracterizados 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
32
e entendidos e são descritos como padrões, procedimentos, 
ferramentas e métodos. O conjunto de padrões de processos 
da organização, que são a base para o nível de maturidade 3, 
é estabelecido e melhorado toda vez.
Uma distinção entre 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 estar diferentes de cada instância 
específica do processo. No nível de maturidade 3, os padrões, 
descrições de processos e procedimentos para um projeto 
são adaptados a partir de um conjunto de processos padrões 
para se adequar a um projeto particular. Como resultado, 
os processos que executam através da organização são 
consistentes exceto para diferenças permitidas para guias.
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. 
Em suma, no nível 3 do CMMI, os processos são 
caracterizados por organização e são proativos. Os 
processos deste nível e seus objetivos são:
 Desenvolvimento de Requisitos (RD): produzir e 
analisar os requisitos de cliente, de produto e de componente 
de produto.
 Solução Técnica (TS): projetar, desenvolver e 
implementar soluções para requisitos. Soluções, designs 
e implementações englobam produtos, componentes 
de produto e processos de ciclo de vida relacionados ao 
produto isoladamente ou a combinações de produtos 
quando apropriado.
 Integração de Produtos (PI): montar o 
produto a partir de componentes de produto, garantir 
que o produto integrado execute as funções de forma 
apropriada e entregar o produto.
  Verificação	 (VER): assegurar que os produtos 
de trabalho selecionados atendem aos seus requisitos 
especificados.
 Validação	 (VAL): demonstrar que um produto 
ou componente de produto atende ao seu uso pretendido 
quando colocado em seu ambiente alvo.
 Foco no Processo Organizacional (OPF): 
planejar, implementar e implantar melhorias do processo 
organizacional com base na compreensão dos pontos 
fortes e pontos fracos atuais dos processos e dos ativos de 
processo da organização.
 Definição	do	Processo	Organizacional	(OPD)	
+ IPPD: o propósito da OPD é estabelecer e manter 
um conjunto de ativos de processo da organização e 
padrões de ambiente de trabalho disponíveis para uso. 
Para IPPD, a Definição do Processo Organizacional + 
IPPD cobre, também, o estabelecimento de regras e guias 
organizacionais que possibilitam a condução de trabalhos 
realizados por equipes integradas.
 Treinamento Organizacional (OT): 
desenvolver as habilidades e o conhecimento das pessoas 
para que elas possam desempenhar seus papéis de forma 
eficiente e eficaz.
 Gestão Integrada de Projetos (IPM) + 
IPPD: estabelecer e gerenciar o projeto e o ambiente 
dos stackeholders relevantes de acordo com um processo 
integrado e definido que é adaptado a partir do conjunto 
de processos padrão da organização. Para IPPD, a 
Gestão Integrada de Projeto + IPPD cobre também o 
estabelecimento de uma visão compartilhada para o 
projeto e o estabelecimento de equipes integradas que 
irão cumprir os objetivos do projeto.
 Gestão de Risco (RSKM): identificar potenciais 
problemas antes que ocorram. Para isso, as atividades de 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
33
tratamento de risco podem ser planejadas e colocadas em 
prática quando necessário, durante a vida do produto ou 
do projeto, para mitigar impactos indesejáveis na obtenção 
dos objetivos.
 Análise	 de	 Decisão	 e	 Resolução	 (DAR): 
analisar decisões possíveis usando um processo de 
avaliação formal que avalia alternativas identificadas com 
relação a critérios estabelecidos.
•	 Nível	de	Maturidade	4:	Gerenciado
No nível de maturidade 4, uma organização alcançou 
todas as metas específicas das áreas de processo 
determinadas para os níveis de maturidade 2, 3 e 4 e 
metas genéricas dos níveis de maturidade 2 e 3. 
Subprocessos que significativamente contribuam para 
toda parte de desempenho de processo são selecionados. 
Estes subprocessos são controlados usando técnicas 
estatísticas e outras técnicas quantitativas.
Objetivos quantitativos para qualidade e desempenho 
de processo são estabelecidos e usados como critério 
em gerenciamento de processos e são baseados em 
necessidades de clientes, usuários finais, organização e 
implementadores de processos. Qualidade e desempenho 
de processos são entendidos em termos estatísticos 
e são gerenciados ao longo de vida de processos. Para 
estes processos, medidas detalhadas do desempenho dos 
processos são coletadas e analisadas estatisticamente. 
Casos especiais de variação são identificados e,quando 
apropriado, causas especiais são corrigidas para prevenir 
futuras ocorrências.
Medidas de qualidade e desempenho de processos são 
incorporados ao repositório de medição da organização para 
apoiar tomadas de decisões reais no futuro baseadas em 
fatos. Uma distinção entre os níveis 3 e 4 está na previsão 
de desempenho de processo. No nível 4, o desempenho de 
processos é controlado usando técnicas estatísticas e outras 
técnicas quantitativas, sendo quantitativamente previsível. 
Os processos deste nível e seus objetivos são:
 Gerenciamento quantitativo de projeto 
(QPM): tem como objetivo gerenciar quantitativamente 
os processos definidos para alcançar a qualidade, e 
performance estabelecidas e previstas.
 Desempenho do processo organizacional 
(OPP): tem como objetivo estabelecer e manter um 
entendimento quantitativo da performance do conjunto de 
processos da organização, bem como o atendimento dos 
mesmos. Também tem a função de estabelecer baselines 
e modelos para o gerenciamento quantitativo.
•	 Nível	de	Maturidade	5:	Otimizado
No nível 5, uma 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. Processos são continuamente melhorados 
baseados em entendimentos quantitativos de causas 
comuns de variação inerente aos processos.
O nível 5 foca na melhoria contínua de desempenho 
de processo através de melhorias incrementais e 
tecnologicamente inovadoras. Os objetivos quantitativos 
do melhoramento do processo são estabelecidos, 
continuamente revisados para refletir mudanças de objetivos 
de negócios e usados como critério em gerenciamento de 
melhoria de processo. Os efeitos de melhoria de processos 
desenvolvidos são medidos e avaliados com os objetivos 
quantitativos de melhoria de processos. Ambos, processos 
definidos e conjunto de processos padrões da organização, 
são objetivos de atividades de melhoramento.
Melhoramentos são selecionados baseados em 
entendimento quantitativo de suas contribuições 
esperadas para alcançar os objetivos de melhoramento 
de processos da empresa versus o custo e impacto na 
organização. O desempenho de processos de organização 
é continuamente melhorado.
A otimização dos processos que são ágeis e inovadores 
depende da participação da força de trabalho alinhada 
aos valores e objetivos da organização. A habilidade da 
organização para rapidamente responder a mudanças e 
oportunidades está melhorada por encontrar maneiras de 
acelerar e compartilhar aprendizado. 
Uma distinção entre nível 4 e nível 5 é o tipo de variação 
de processo com que se lida. No nível 4, processos estão 
preocupados com causas especiais de variação e fornecem 
estatística previsível de resultados. Apesar de processos 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
34
poderem produzir resultados previsíveis, os resultados 
podem ser insuficientes para alcançar os objetivos 
estabelecidos. No nível 5, processos estão preocupados 
em lidar com causas comuns de variação e mudar o 
processo (isto é, aumentando a média de desempenho do 
processo) para melhorar a performance de processo para 
alcançar os objetivos quantitativos estabelecidos para o 
melhoramento do processo.
Os processos deste nível são: 
•	 Inovação	 e	 Deployment	 Organizacional	
(OID): tem como objetivo desenvolver melhorias que 
estatisticamente com comprovem que houve melhora 
no desempenho dos processos. As melhorias devem ser 
derivadas dos objetivos de negócio da organização.
•	 Análise	 e	 Resolução	 de	 Causas	 (CAR): tem 
como objetivo identificar as causas reais dos defeitos 
e problemas bem como tomar ações para prevenir que 
estes problemas ocorram novamente no futuro. Trata-se 
de um mecanismo para comunicar lições aprendidas em 
outros projetos ou mesmo no início do projeto atual, o 
que melhora a qualidade do sistema e a produtividade 
da equipe. Esta análise permite o estabelecimento de 
tendências na produção de defeitos e problemas que são 
examinados desde suas raízes. A técnica de análise e 
resolução de causas pode ser aplicada para a melhoria de 
áreas não necessariamente problemáticas.
Agora que você conhece bem o 
modelo CMMI e já tendo estudado 
sobre ITIL, é interessante ler o 
artigo Semelhanças e Diferenças 
entre ITIL e CMMI para Serviços. 
Disponível em: http://www.teclogica.com.br/blog/?p=508
Leia artigo da ComputerWorld on line sobre empresa que 
alcançou nível de maturidade 5 do CMMI. Este processo 
é tão marcante, que se torna uma importante notícia.
http://computerworld.uol.com.br/gestao/2011/03/24/tcs-
alcanca-nivel-5-do-cmmi-para-servicos-e-desenvolvimento/
Caso queira conhecer mais empresas CMMI 
no Brasil, clique no link abaixo:
http://www.blogcmmi.com.br/avaliacao/
lista-de-empresas-cmmi-no-brasil
Aproveite a parada e assista ao vídeo que apresenta 
regras de uma entrevista para avaliação 
CMMI: http://youtu.be/4fRIeU2NCHk
Exercícios do Capítulo 3 
1)	 Cite	os	benefícios	que	uma	empresa	pode	
obter	ao	adotar	a	norma	ISO/IEC	15504.
2)	 Assinale	 V-verdadeiro	 e	 F-falso	 nas	
afirmativas:	
( ) Os processos da ISO/IEC 15504 são agrupados de 
acordo com sua natureza, ou seja, o seu objetivo principal 
no ciclo de vida de software. Este agrupamento resultou 
em 3 classes de processos: Processos Fundamentais, 
Processos de Apoio e Processos Organizacionais.
( ) A norma ISO/IEC 12207 está associada ao projeto 
SPICE - Software Process Improvement and Capability 
dEtermination.
( ) Uma distinção entre nível 4 e nível 5 do CMMI 
é o tipo de variação de processo com que se lida. No 
nível 4, processos estão preocupados com causas 
especiais de variação e fornecem estatística previsível 
de resultados. No nível 5, processos estão preocupados 
em lidar com causas comuns de variação e mudar o 
processo para melhorar a performance de processo 
para alcançar os objetivos quantitativos estabelecidos 
para o melhoramento do processo.
( ) Organizações em níveis de maturidade CMMI 
2 geralmente produzem produtos e serviços que 
funcionam, entretanto, eles frequentemente excedem 
o prazo e o orçamento de seus projetos.
( ) No nível de maturidade CMMI 3, os processos 
são bem caracterizados e entendidos e são descritos 
como padrões, procedimentos, ferramentas e métodos. 
O conjunto de padrões de processos da organização é 
estabelecido e melhorado toda vez.
3)	 Complete	 as	 	 frases	 sobre	 representação	
no modelo CMMI:
Para a representação ________________, usa-
se o termo _______________________ ou ainda 
__________________________ da área de processo. 
Ou seja, um _________________________________ 
está relacionado a apenas uma área de processo. 
Para a representação _________________, usa-
se o termo _____________________ ou ainda a 
_________________________ da organização. Ou 
seja, um ______________________________ está 
relacionado a um grupo de áreas de processo. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
35
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), mostraremos 
sua organização, estrutura interna e seus níveis de maturidade 
em detalhes. Para a realidade brasileira, uma das principais 
vantagens deste modelo é seu custo reduzido de certificação 
em relação às normas estrangeiras, sendo ideal para micro, 
pequenas, e médias empresas.
Histórico e visão geral do MPS.BR
O MPS.BR - Melhoria 
de Processo de Software.
BRasileiro foi criado 
em dezembro de 2003 
coordenado pela SOFTEX - 
Associação para Promoção 
da Excelência do Software 
Brasileiro. O programa tem por objetivo a melhoria de 
processo para o desenvolvimento de software brasileiro, 
visando aumentar a competitividade da indústria brasileira 
de software, nos mercados interno e externo, através de 
programas de qualificação de profissionais nesta área e de 
melhoria e avaliação de processos e produtos desoftware 
brasileiros, a um custo acessível às empresas de menor 
porte. O MPS.BR conta com a participação de representantes 
de universidades, instituições governamentais, centros de 
pesquisa e de organizações privadas, os quais contribuem 
com suas visões complementares que agregam qualidade 
ao empreendimento. Além disso, o MPS.BR conta com 
investimentos de empresas privadas e tem o apoio do 
Ministério da Ciência e Tecnologia (MCT), Financiadora 
de Estudos e Projetos (FINEP), Banco Interamericano de 
Desenvolvimento (BID) e PROIMPE/SEBRAE.
Segundo o SOFTEX (2009), 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. Adicionalmente, outro objetivo do projeto é 
replicar o modelo na América Latina, incluindo o Chile, 
Argentina, Costa Rica, Peru e Uruguai.
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 15504, é 
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 modelo MPS baseia-se nos conceitos de maturidade 
e capacidade de processo para a avaliação e melhoria 
da qualidade e produtividade de produtos de software e 
serviços correlatos. Dentro desse conceito, o modelo MPS 
possui três componentes: 
 Modelo de Referência (MR-MPS)
 Método de Avaliação (MA-MPS) 
 Modelo de Negócio (MN-MPS)
Cada componente é descrito por meio de guias e/ou 
documentos do modelo MPS, como pode ser visto na figura 8.
Figura 8 – Modelo MPS.BR
Fonte: http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
36
Uma breve descrição dos principais documentos do 
MPS é apresentada no que se segue.
•	 O	Modelo	de	Referência	MR-MPS contém os 
requisitos que os processos das unidades organizacionais 
devem atender para estar em conformidade com o MR-
MPS. O documento contém as definições dos níveis de 
maturidade, processos e atributos do processo. O MR-MPS 
está em conformidade com os requisitos de modelos de 
referência de processo da norma internacional ISO/IEC 
15504-2.
•	 O	 	 Guia	 de	 Aquisição é um documento 
complementar destinado às organizações que pretendem 
adquirir software e serviços correlatos. O Guia de Aquisição 
não contém requisitos do MR-MPS, mas boas práticas para 
a aquisição de software e serviços relacionados.
•	 O	Guia	de	 Implementação sugere formas de 
implementar cada um dos níveis do MR-MPS, incluindo 
instruções de como uma unidade organizacional que faz 
aquisições de produtos pode implementar o MR-MPS.
•	 O	 Modelo	 de	 Avaliação	 MA-MPS tem 
como objetivo orientar a realização de avaliações, em 
conformidade com a norma ISO/IEC 15504, em empresas 
e organizações que implementaram o MR-MPS. 
•	 O	 Guia	 de	 Avaliação contém o processo e 
o método de avaliação MA-MPS, os requisitos para os 
avaliadores líderes, avaliadores adjuntos e instituições 
avaliadoras. O processo e o método de avaliação MA-MPS 
estão em conformidade com a norma internacional ISO/
IEC 15504-2.
•	 O	 Modelo	 de	 Negócio	 MN-MPS descreve 
regras de negócio para: a) implementação do MR-MPS 
pelas instituições implementadoras; b) avaliação seguindo 
o MA-MPS pelas instituições avaliadoras; c) organização de 
grupos de empresas pelas Instituições Organizadoras de 
Grupos de Empresas (IOGE) para implementação do MR-
MPS e avaliação MA-MPS; d) certificação de Consultores 
de Aquisição (CA); e) programas anuais de treinamento do 
MSP.BR por meio de cursos, provas e workshops.
Níveis de maturidade do MPS.BR
O Modelo de Referência MR-MPS do MPS.BR 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. Os níveis de 
maturidade estabelecem patamares de evolução de 
processos. O nível de maturidade em que se encontra uma 
organização permite prever o seu desempenho futuro ao 
executar um ou mais processos. 
O MR-MPS define sete níveis de maturidade:
[7] Nível A – Em otimização
[6] Nível B – Gerenciado quantitativamente
[5] Nível C – Definido
[4] Nível D – Largamente definido
[3] Nível E – Parcialmente definido
[2] Nível F – Gerenciado
[1] Nível G – Parcialmente gerenciado
No modelo MPS.BR, um nível é 
alcançado quando os propósitos e 
todos os resultados esperados dos 
respectivos processos são atendidos. Os 
níveis são acumulativos, ou seja, se a organização se 
encontra no nível F, isso significa que a mesma já passou 
pelo nível G, e os processos do nível G estão sendo 
executados junto com os processos do nível F. O nível 
mais alto é o nível A (em otimização), logo, o nível mais 
baixo é o nível G (parcialmente gerenciado).
Os processos do MR-MPS são descritos em termos de 
propósitos e resultados: 
 O propósito descreve o objetivo geral a ser 
atendido durante a execução do processo
 Os resultados esperados do processo 
estabelecem os resultados a serem obtidos com a efetiva 
implementação do processo.
Cada nível de maturidade possui seus processos, cada 
processo possui atributos de processos (APs). A tabela 5 
exibe os processos agrupados em níveis de maturidade 
bem como o grupo de atributos de processos de cada nível.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
37
Tabela 5 - Níveis de maturidade, processos e atributos do MR-MPS.
Nível Processos Atributos de processo
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, AP 5.2
B Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 
3.2, AP 4.1, AP 4.2
C Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de decisões – GDE
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 
3.2
D Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 
3.2
E Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional - AMP
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 
3.2
F Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
AP 1.1, AP 2.1, AP 2.2
G Gerência de Requisitos – GRE
Gerência de Projetos – GPR
AP 1.1, AP 2.1
Fonte: http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf
Cada atributo de processo (AP) possui resultado(s) 
esperado(s) (RAPs). Nesse caso, para alcançar um 
atributo de processo é necessário alcançar um conjunto 
de resultados esperados, exceto para o AP 1.1, que possui 
apenas um RAP. 
No que se segue, apresentamos em detalhes o que 
é verificado em cada um dos 7 níveis de maturidade do 
modelo MPS.BR, de acordo com o SOFTEX (2009).
Nível G – Parcialmente Gerenciado
O nível de maturidade G é composto pelos processos 
Gerência de Projeto e Gerência de Requisitos. Neste nível os 
atributos de processo AP 1.1 e AP 2.1 devem ser atendidos. 
A seguir apresentamos uma descrição de cada um deles.
•	 Gerência	de	Projeto	–	GPR
O propósito do processo Gerência de Projetos – 
GPR é identificar, estabelecer, coordenar e monitorar as 
atividades, tarefas e recursos que o projeto necessita 
para produzir um produto ou serviço levando-se em 
consideração requisitos e restrições do projeto. A GPR 
deve prover informações sobre o andamento do projeto 
que permitam a realização de correções quando houver 
desvios significativos no desempenho do projeto. Para 
o PMBoK (2004), gerência de projetosé a aplicação do 
conhecimento, habilidades, e técnicas para projetar 
atividades que visem atingir os requisitos do projeto. O 
gerenciamento do projeto é acompanhado através do uso 
de processos tais como: iniciação, planejamento, execução, 
controle e encerramento. Na gerência de projetos existem 
25 resultados esperados.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
38
•	 Gerência	de	Requisitos	–	GRE
O propósito do processo Gerência de Requisitos – GRE 
é gerenciar os requisitos dos produtos e componentes do 
produto do projeto e identificar inconsistências entre esses 
requisitos e os planos e produtos de trabalho do projeto. 
Pfleeger (2004), diz que a definição dos requisitos é uma 
listagem completa de tudo o que o cliente espera que o 
sistema faça, representa um consenso entre o cliente e 
o desenvolvedor sobre o que o cliente precisa ou quer e 
geralmente é escrita em conjunto pelos dois.
Para Sommerville (2007), o gerenciamento de 
requisitos é o processo de compreender e controlar as 
mudanças nos requisitos de sistemas e é um processo que 
deve ser realizado em conjunto com outros processos da 
engenharia de requisitos. Este processo gerencia todos 
os requisitos recebidos ou gerados pelo projeto, incluindo 
requisitos funcionais e não-funcionais, bem como os 
requisitos impostos ao projeto pela organização. 
Nível F – Gerenciado
O nível F é composto pelo nível anterior (G) acrescido 
dos processos Aquisição, Gerência de Configuração, 
Garantia da Qualidade e Medição. Neste nível todos os 
processos devem atender aos atributos de processos AP 
1.1, AP 2.1 e AP 2.2. Este nível agrega processos que irão 
apoiar a gestão do projeto no que diz respeito à Garantia 
da Qualidade e Medição, bem como aqueles que irão 
organizar os artefatos de trabalho por meio da Gerência 
de Configuração, conforme descrito a seguir.
•	 Aquisição	-	AQU
Este processo concentra-se na seleção do fornecedor 
e no acompanhamento dos produtos (avaliação periódica 
dos produtos intermediários e finais) e processos (como 
o desenvolvedor está executando o desenvolvimento 
do produto), e tem como objetivo principal assegurar 
a qualidade do produto que está sendo subcontratado 
quando este for integrado ao produto que será entregue 
para o cliente. 
•	 Gerência	de	Configuração	–	GCO
O propósito do processo de Gerência de Configuração 
– GCO é estabelecer e manter a integridade de todos 
os produtos de trabalho de um processo ou projeto 
e disponibilizá-los a todos os envolvidos. Durante o 
desenvolvimento, o sistema de GCO é fundamental para 
prover controle sobre os produtos de trabalho produzidos 
e modificados por diferentes engenheiros de software. 
•	 Garantia	da	Qualidade	–	GQA
O propósito da Garantia da Qualidade – GQA é garantir 
que os produtos de trabalho e a execução dos processos estão 
em conformidade com os planos e recursos predefinidos. A 
GQA tem como objetivo fornecer dados à gerência para que 
esta se mantenha informada sobre a qualidade do produto 
e garanta que esteja satisfazendo suas metas. Caso sejam 
identificados problemas é responsabilidade da gerência 
de projetos a aplicação de recursos necessários para a 
resolução das questões de qualidade.
As atividades de Garantia da Qualidade permitem 
fornecer visibilidade do projeto para todos da organização, 
por meio de uma visão independente em relação ao 
processo e ao produto. A Garantia da Qualidade é um apoio 
para o gerente, servindo como seus “olhos e ouvidos”. 
Também agrega valor à equipe de projeto, ajudando-a a 
preparar e rever procedimentos, planos e padrões, desde 
o início do projeto até o seu encerramento. 
•	 Medição	–	MED
O propósito do processo de Medição – MED é coletar e 
analisar os dados relativos aos produtos desenvolvidos e 
aos processos implementados na organização e em seus 
projetos, de forma a apoiar os objetivos organizacionais. 
A medição focaliza-se em apoiar a tomada de decisão 
em relação aos projetos, processos e atendimento aos 
objetivos organizacionais. 
Nível	E	–	Parcialmente	Definido
O nível E é composto pelos processos dos níveis de 
maturidade anteriores (G e F), acrescido 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 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
39
projeto com base no processo definido para o projeto e 
nos planos integrados. Esta evolução se deu devido ao 
escopo do nível E do MPS.BR exigir maior consistência em 
relação aos processos-padrão da organização, pois até 
o nível F do modelo não há necessidade de os projetos 
executarem processos padronizados na organização como 
um todo. Todos os processos devem satisfazer os atributos 
de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.
•	 Avaliação	 e	 Melhoria	 do	 Processo	
Organizacional – AMP
O processo de 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 seus objetivos de negócio e apoiá-la 
no planejamento, realização e implantação de melhorias 
contínuas nos processos com base no entendimento de 
seus pontos fortes e fracos. 
•	 Definição	do	Processo	Organizacional	–	DFP
O processo Definição do Processo Organizacional tem 
por finalidade estabelecer e manter um conjunto de ativos 
de processo organizacional e padrões do ambiente de 
trabalho usáveis e aplicáveis às necessidades de negócio 
da organização. 
•	 Gerência	de	Recursos	Humanos	–	GRH
A Gerência de Recursos Humanos – GRH possui a 
finalidade de prover a organização e os projetos com os 
recursos humanos necessários e manter suas competências 
consistentes com as necessidades do negócio. A GRH não 
se limita apenas a treinar pessoas, é preciso também 
identificar os requisitos mínimos de educação, habilidades 
e experiências para que as funções sejam desempenhadas 
de forma satisfatória dentro da organização. 
•	 Gerência	de	Reutilização	–	GRU
 O propósito do processo Gerência de Reutilização – 
GRU é gerenciar o ciclo de vida dos ativos reutilizáveis. 
Entende-se como ativo reutilizável qualquer artefato 
relacionado a software que esteja preparado, isto é, 
empacotado de maneira própria a ser reutilizado pelos 
processos da organização. 
Nível	D	–	Largamente	Definido
O nível de maturidade D é composto pelos processos 
de todos os níveis de maturidade que o antecedem (G 
ao E), acrescido dos processos Desenvolvimento de 
Requisitos, Integração do Produto, Projeto e Construção 
do Produto, Validação, e Verificação. Todos os processos 
devem satisfazer os atributos de processo AP 1.1, AP 2.1, 
AP 2.2, AP 3.1 e AP 3.2.
•	 Desenvolvimento	de	Requisitos	–	DRE
O propósito do processo Desenvolvimento de Requisitos 
é estabelecer os requisitos dos componentes do produto 
e do cliente. 
•	 Integração	do	Produto	–	ITP
O processo de integração, para Sommerville (2007), 
visa construir o sistema e testar o sistema resultante 
quanto aos problemas que surjam a partir de interações 
de componentes. 
•	 Projeto	e	Construção	do	Produto	–	PCP
Uma vez que os requisitos foram desenvolvidos, 
suas mudanças estejam controladas, e estão sob o 
nível apropriado de gerência de configuração, o objetivo 
do processo de Projeto e Construção do Produto - PCP 
é projetar uma solução, dentre as inúmeras possíveis 
soluções existentes, para satisfazer aos requisitos, 
desenvolver e implementar a solução projetada. 
•	 Validação	–	VAL
O processo de Validação – VAL visa garantir que o 
produto correto está sendo desenvolvido e seu propósito 
é confirmar que um produto ou componente do produto 
atenderá ao seu uso pretendido quando colocado no 
ambiente para o qual foi desenvolvido. 
•	 Verificação–	VER
O processo Verificação tem por objetivo confirmar 
que cada serviço ou produto de trabalho do processo 
ou do projeto atende apropriadamente os requisitos 
especificados. Já para Pressman (2006), verificação 
se refere ao conjunto de atividades que garante que o 
software implementa corretamente uma função específica. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
40
Nível	C	–	Definido
O nível de maturidade C é composto por todos os 
processos dos níveis de maturidade anteriores (G ao D), 
acrescidos dos processos Análise de Decisão e Resolução, 
Desenvolvimento para Reutilização e Gerência de Riscos. 
Todos os processos devem satisfazer os atributos de 
processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2. A seguir 
faremos uma breve descrição de cada um dos processos 
deste nível de maturidade.
•	 Análise	de	Decisão	e	Resolução	–	ADR
O processo Análise de Decisão e Resolução - ADR 
tem como propósito analisar possíveis decisões usando 
um processo formal, com critérios estabelecidos, para 
avaliação das alternativas identificadas. A partir do 
momento em que for identificada uma questão que deve 
ser objeto de um processo de avaliação formal, inicia-se 
o processo de ADR. Nesta avaliação formal são analisadas 
soluções alternativas em relação a critérios estabelecidos, 
determinando, assim, qual a melhor solução a ser utilizada 
para resolver o problema. 
•	 Desenvolvimento	para	Reutilização	–	DRU
O propósito do processo Desenvolvimento para 
Reutilização – DRU é identificar oportunidades de 
reutilização sistemática na organização e, se possível, 
estabelecer um programa de reutilização para desenvolver 
ativos a partir de engenharia de domínios de aplicação. 
•	 Gerência	de	Riscos	–	GRI
O processo Gerência de Riscos – GRI tem por 
objetivo identificar, analisar, tratar, monitorar e reduzir 
continuamente os riscos em nível organizacional e de 
projeto. 
Nível B – Gerenciado Quantitativamente
Este nível de maturidade é composto pelos processos 
dos níveis de maturidade anteriores (G ao C), sendo que 
ao processo Gerência de Projetos são acrescentados 
novos resultados. Todos os processos devem satisfazer os 
atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e 
AP 3.2 e os RAP 16 e RAP 17 do AP 4.1. Os processos 
selecionados para análise de desempenho devem satisfazer 
integralmente AP 4.1 e AP 4.2.
A partir do nível B, com a implementação dos atributos 
de processo AP 4.1 e AP 4.2, a organização/unidade 
organizacional passa a ter uma visão quantitativa do 
desempenho de seus processos no apoio ao alcance dos 
objetivos de qualidade e de desempenho dos processos. 
É importante se ter em conta que, ao se implementar os 
níveis anteriores, em especial o processo Medição, já se 
deve preparar o caminho para a implementação do nível B, 
através de uma escolha adequada das medidas.
É a partir deste nível de maturidade que a organização 
passa a gerenciar quantitativamente os projetos. Deste 
modo, o processo Gerência de Projetos passa a ser 
executado de forma quantitativa e alguns de seus 
resultados esperados são modificados para ter este 
enfoque e novos resultados são acrescentados.
Nível A – Em Otimização
O nível de maturidade A é composto pelos níveis G, F, 
E, D, C e B acrescido do processo Análise de Causas de 
Problemas e Resolução.
•	 Análise	de	Causas	de	Problemas	e	Resolução	
– ACP
O processo Análise de Causas de Problemas e 
Resolução – ACP possui o propósito de identificar causas 
de defeitos e de outros problemas e tomar ações para 
prevenir suas ocorrências no futuro. O foco dos atributos 
de processo do nível A do MR-MPS é continuamente 
melhorar o desempenho dos processos gerenciados 
quantitativamente para melhor atender aos objetivos de 
negócio atuais e projetados da organização. 
MPS.BR versus CMMI
O modelo CMMI é proprietário e envolve um grande 
custo para a realização das avaliações do modelo para se 
obter a certificação. Geralmente o custo fica entre R$300 
mil a mais de R$1 milhão, dependendo da complexidade 
do processo. Além disso, o processo é longo, geralmente 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
41
para se chegar aos níveis de maturidade mais altos leva-se 
em média de 4 a 8 anos. [OLIVEIRA, 2008]
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 níveis 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 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 6 e melhor 
visualizado na figura 9.
Tabela 6 – 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
G
2 F
E
D
3 C
4 B
5 A
Analisando a tabela 6, podemos verificar que os níveis 
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 de ser muito mais 
barata, além de existir financiamento do BID para grupos 
de empresas que desejam se certificar.
Figura 9 – Níveis de maturidade do modelo MPS.BR e CMMI
Fonte: Fonte: http://bettawork.com.br/news/pagNoticia_6.html
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
42
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 é menos custoso que o do CMMI, 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. 
Assista ao vídeo sobre implantação do 
modelo	 e	 certificação	 MPS.BR	 em	
empresas	no	Paraná
http://youtu.be/ddOqzmo0kj8
MODELAGEM DE PROCESSOS DE 
NEGÓCIO (BPM)
Caro aluno, neste capítulo vamos conhecer o que seja 
processo em 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 uma melhor qualidade e produtividade nos processos 
de negócios.
A crescente importância dos processos
Caro aluno, embora os estudos sobre processos, quer 
sejam industriais ou empresariais, já sejam feitos há mais 
de um século, conforme estudos de Taylor, Ford e outros, a 
compreensãodos processos de negócios tem se mostrado 
como uma das tendências mais fortes para a compreensão 
do funcionamento das organizações. Diferente de 
momentos em décadas anteriores, em que a montagem 
de esquemas com ênfase na redução de erros e aumento 
da qualidade era utilizada, hoje se pretende acompanhar, 
automatizar e obter ganhos efetivos com os processos. 
Isso gera interesse de ganhos reais com estes processos, 
seja na imagem da organização, nos financeiros ou no 
aumento da competitividade.
A partir da década de 1990, as organizações têm 
experimentado uma evolução em termos de modelos 
estruturais e tecnológicos, trazendo como novos paradigmas 
as mudanças e o conhecimento. Esse fato tem exigido uma 
Exercícios do Capítulo 4 
1) Complete as sentenças:
Os processos do MR-MPS são descritos em termos de ___
____________________________________: 
Os __________________________ descrevem o objetivo 
geral a ser atendido durante a execução do processo
Os __________________________ do processo 
estabelecem os resultados a serem obtidos com a efetiva 
implementação do processo.
2)	 Assinale	 V-verdadeiro	 e	 F-falso	 nas	
afirmações		sobre	o	MPS.BR:
( ) No modelo MPS.BR, um nível é alcançado quando os 
propósitos e todos os resultados esperados dos respectivos 
processos são atendidos. Os níveis são acumulativos.
( ) O nível mais baixo do MPS.BR é o nível A, logo, o nível 
mais alto é o nível G.
( ) O nível de maturidade A é composto pelos níveis G, 
F, E, D, C e B acrescido do processo Análise de Causas de 
Problemas e Resolução.
( ) Adicionalmente, outro objetivo do MPS.BR é replicar o 
modelo na América do Norte, incluindo os Estados Unidos e 
Canadá, que apoiam o projeto.
( ) 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 15504 e é 
compatível com o modelo CMMI.
( ) Apesar do MPS.BR ser compatível com os padrões de 
qualidade aceitos internacionalmente, não se compromete em 
aproveitar a competência existente nos padrões e modelos 
de melhoria de processo já disponíveis.
( ) O modelo MPS baseia-se nos conceitos de maturidade 
e capacidade de processo para a avaliação e melhoria da 
qualidade e produtividade de produtos de software e serviços 
correlatos.
3) Faça uma comparação entre os modelos 
CMMI e MPS.BR, do seu ponto de vista.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
43
específica das atividades de trabalho no tempo e no 
espaço, com um começo, um fim, e inputs e outputs 
claramente identificados: uma estrutura para a ação.”. 
Mais formalmente, Hammer e Champy (1994) definem 
processo como um grupo de atividades realizadas numa 
sequência lógica com o objetivo de produzir um bem ou 
um serviço que tem valor para um grupo específico de 
clientes. Sob a ótica do gerenciamento de processos, Ould 
(2005) define processo como um conjunto coerente de 
atividades conduzido por um grupo de colaboradores para 
atingir um objetivo. 
Das definições apresentadas, pode-se depreender que 
o conceito de processo envolve um sequenciamento de 
atividades, com entradas e saídas, executadas por pessoas 
ou sistemas, que visam atender as necessidades de um 
cliente interno ou externo. Um processo é, portanto, um 
conjunto estruturado de operações que conduzem a um 
determinado fim.
Harrington et al. (1997) estratificam hierarquicamente 
a estrutura dos processos dentro de uma organização em 
quatro níveis, do mais amplo para o mais específico, da 
seguinte forma: macroprocessos, subprocessos, atividades 
e tarefas, conforme mostrado na figura 10.
nova postura nos estilos pessoal e gerencial, voltados para 
uma realidade diferenciada e emergente. Não exatamente 
abandonando a estrutura de funções na empresa, como 
mencionam Maranhão & Macieira (2004), mas reduzindo 
a sua importância, as empresas contemporâneas estão 
gradualmente passando a se organizar de forma orientada 
aos processos que as permeiam, acompanhando a lógica 
dos mesmos, e não mais o raciocínio compartimentado da 
abordagem funcional. 
A maior vantagem da orientação por processos é que 
esta ajuda a entender como as coisas são realmente 
feitas na organização, revelando problemas, gargalos e 
ineficiências que poderiam permanecer escondidos em uma 
organização que, aparentemente, funciona normalmente. 
O gerenciamento dos processos também ajuda a reduzir 
tempos de ciclos, diminuir custos, melhorar a eficiência 
interna e a qualidade global e aumentar a satisfação do 
cliente e do empregado.
Definição de processos
Um processo pode ser definido de diferentes formas. 
Segundo Davenport (1994), processo é “uma ordenação 
Figura 10 – Processo, subprocesso, atividades e tarefas
Fonte: [HARRINGTON et al., 1997]
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
44
Os macroprocessos ou processos principais são processos 
que geralmente envolvem mais de uma função na estrutura 
organizacional e sua operação tem um impacto significativo 
no funcionamento da organização. Um subprocesso é uma 
porção de um macroprocesso que desempenha um objetivo 
específico dentro do processo principal.
Todo processo ou subprocesso é constituído de um 
determinado número de atividades. 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.
Orientação por processos nas 
organizações
A Norma ISO 9000:2000 requer que as organizações 
adotem a abordagem por processos e explicita a intenção 
da Organização Internacional para Normalização Técnica 
de encorajar a adoção desta abordagem para a gerência 
de uma organização. No entanto, é importante ressaltar 
que uma estrutura organizacional baseada em processos 
é uma estrutura alicerçada no modo em que o trabalho 
é executado, não em torno de habilitações específicas 
departamentalizadas. 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.”
Observando a estrutura organizacional das empresas, 
percebe-se que os processos possuem uma estrutura 
horizontal, enquanto a organização departamentalizada 
confere à empresa uma estrutura funcional verticalizada. 
O processo de criação de um novo produto, por exemplo, 
inclui atividades que recorrem a variados conhecimentos 
funcionais e atravessa horizontalmente todos os setores 
da organização (figura 11).
Figura 11: Processo de Desenvolvimento de um Novo Produto.
Fonte: Autoria própria 
Reduzindo gradativamente a estrutura por funções, que 
foi a forma organizacional predominante nas empresas do 
século XX, as empresas estão organizando seus recursos 
e fluxos ao longo de seus processos básicos de operação, 
adotando uma estrutura orientada para processos. 
Gonçalves (2000) explica que ao longo de décadas, 
os processos industriais sofreram aperfeiçoamentos 
contínuos que, mais recentemente, passaram a ser 
utilizados também nos processos empresariais. Isto explica 
em parte a intensa utilização do conceito de processo na 
modernização das empresas. Sob esta ótica, pensar nos 
processos em termos de coordenação de atividades em 
vez de fluxos de trabalho ou fluxos físicos de materiais 
ou produtos, como tem sido a abordagem predominante 
na reengenharia e no TQM (Total Quality Management), é 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
45
importante para identificar e tratar processos industriais 
como importantes ativos de negócio e para poder analisar 
qualquer tipo de processo. 
Em função da crescente relevância atribuída aos 
processos,cresce dentro das organizações a necessidade 
de se melhorar sua agilidade e desempenho operacional, 
através de uma gestão cada vez mais voltada a eles, ou 
seja, uma gestão por processos.
Benefícios da orientação por processos
A orientação por processos contribui para um melhor 
entendimento da meta e produto finais da organização 
e do papel desempenhado por cada indivíduo. Porém, 
mais importante é a noção de que os processos e seus 
produtos são a real interface com os clientes, não apenas 
funções individuais de uma organização. Nesse contexto, a 
modelagem e a análise dos processos de negócio permitem 
desenvolver a organização e melhorar sua efetividade e 
qualidade de trabalho.
Em empresas que adotaram uma perspectiva de 
processos, a modelagem tornou-se um elemento crucial 
no entendimento e representação desses processos, de 
modo que esta contribui de forma efetiva em projetos 
de melhoria dos procedimentos adotados na condução 
dos mesmos ou de implantação de novos processos. A 
modelagem de processos deve consistir em construir um 
modelo que apresente os relacionamentos entre atividades, 
pessoas, dados e objetos envolvidos na produção de um 
produto específico.
A construção de um modelo orientado a processos pode 
resolver muitos problemas que não aparecem quando se 
trabalha sob o ponto de vista funcional tradicional. Um 
modelo de processo é projetado para ajudar a todas as 
pessoas envolvidas a entender o cenário inteiro e a parte 
que lhes cabe dentro dele. A construção de um modelo 
requer um trabalho em equipe, de modo a assegurar que 
todo o conhecimento disponível seja usado nessa tarefa. 
Um modelo básico consiste em atividades específicas, 
passos de processo, funções organizacionais, informações 
e materiais. O modelo também pode conter notas sobre 
problemas potenciais no processo de negócio, ideias para 
melhorias e outros comentários.
Fonte:http://alissonml.blogspot.com.br/2008/01/o-que-gesto-de-
processos.html
A documentação é uma parte importante no 
gerenciamento de processos de negócio, pois ajuda no seu 
entendimento e na comunicação ao longo da organização. 
O maior desafio neste caso é manter a documentação 
atualizada e acessível a todos os envolvidos.
Para isso é essencial que se tenha uma metodologia que 
permita a análise e proposição de melhorias com facilidade 
e rapidez, a partir da documentação do processo. Para 
Damij (2007), o sucesso da modelagem de processos de 
negócio depende da seleção apropriada da metodologia 
de modelagem ou técnica de análise do fluxo de processo. 
Existe um grande número de metodologias ou técnicas de 
análise usadas neste campo, como gráficos de processos 
gerais, gráficos de atividades de processo, fluxogramas, 
diagramas de fluxo de dados, desenvolvimento da função 
qualidade (QFD), definição integrada de modelagem de 
função (IDEF), redes petri coloridas, métodos orientados a 
objeto, sete ferramentas de gerenciamento e planejamento, 
entre outras.
O entendimento do problema a ser resolvido é o fator 
mais importante na escolha da metodologia que será 
utilizada como apoio à modelagem dos processos da 
organização. A análise da metodologia mais adequada 
passa, então, por questões como: para que propósito a 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
46
empresa pretende modelar os processos, que decisões 
ela apoiará, que características são necessárias, quais os 
desdobramentos para o futuro. A partir desse entendimento 
tem-se uma visão mais clara da ferramenta de modelagem 
a ser utilizada.
Em função da metodologia adotada na modelagem do 
processo, essas informações podem estar explicitadas no 
modelo com maior ou menor nível de profundidade. No 
caso dessas informações não estarem suficientemente 
explícitas, esses gaps de informação podem tornar 
a montagem do workflow um processo árduo ou até 
impraticável. Dessa forma, o modelo do processo, obtido 
através dos métodos de modelagem, é uma ferramenta 
valiosa para a definição do modelo do fluxo de trabalho e 
deve estar voltado ao seu objetivo final que, neste caso, é 
a construção do workflow.
Gerenciamento de Processos de 
Negócio - BPM
Há muitas razões pelas quais as organizações não 
administram bem seus processos. Quando um processo 
envolve diferentes departamentos, não é incomum 
surgir uma luta de poder em torno da propriedade e 
responsabilidade sobre diferentes aspectos do processo, 
pois os gerentes são frequentemente compensados pela 
produção e eficiência dos seus próprios departamentos, 
sem levar em conta os demais departamentos. Assim, 
administrar projetos e processos transfuncionais torna-se 
uma tarefa difícil devido à existência desses silos funcionais.
Entender como funcionam os processos e quais 
são os tipos existentes é importante para determinar 
como eles devem ser gerenciados para a obtenção do 
máximo resultado Assim, para desenvolver uma estrutura 
organizacional por processos, é fundamental ter uma 
visão clara e profunda dos processos da empresa através 
do mapeamento das atividades, regras e relacionamentos 
que constituem tais processos. [GONÇALVES, 2000]
Diante dessa tendência, vem crescendo no meio 
empresarial a prática do Gerenciamento de Processos de 
Negócio (Business Process Management – BPM) como 
uma forma de gerenciamento e controle das organizações. 
Vários fatores são cruciais para o sucesso do BPM, mas que 
também podem complicar ou impedir sua implementação. 
Entre os fatores críticos de sucesso estão:
 a mudança organizacional e cultural
 a necessidade de uma abordagem estruturada 
para o BPM 
 o alinhamento da abordagem do BPM com as 
metas e estratégias corporativas
 o enfoque no cliente e suas exigências
 as medições do processo e melhorias 
 o compromisso da alta administração 
 os sistemas de informação dos processos 
 a infraestrutura e o realinhamento.
A implementação efetiva de uma solução de 
Gerenciamento de Processos de Negócios (BPM) requer 
elementos estratégicos e de tecnologia. Dois dos principais 
benefícios que as organizações ganham com um sistema 
completamente integrado e implementado são: o 
alinhamento da estratégia empresarial e a infraestrutura 
de tecnologia na qual são construídos os negócios.
De acordo com Gonçalves (2000), as organizações têm 
percebido cada vez mais que os seus processos de negócio 
lhes oferecem vantagens competitivas. Atualmente, para 
serem efetivas, as organizações devem ser capazes 
de definir, analisar, melhorar, medir e controlar os seus 
processos. Nas empresas de serviço, em especial, os 
processos tornam-se fundamentalmente importantes uma 
vez que a sequência de atividades nem sempre é visível, 
nem pelo cliente nem por quem realiza as atividades. Para 
estas empresas, a sequência de atividades é necessária 
para a realização de transações e prestação do serviço. 
Os processos de trabalho ganham mais importância à 
medida que as empresas ficam com conteúdo cada vez 
mais intelectual, afastando-se do modelo fabril.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
47
Fonte: http://www.en-sof.com.br/consultoria/bpm.php
Segundo Larson & Larson (2005), existem dois 
modos de realizar trabalho em uma organização: através 
de projetos ou de processos. Considerando que o 
gerenciamento de projeto é o planejamento e execução 
de esforços temporários para produzir algo de valor, o BPM 
emprega técnicas e sistemas para ajudar uma organização 
a supervisionar continuamente processos e aumentar 
a eficiência enquanto eles reproduzem algo de valor. 
Enquanto projetos são sempre temporários, processos 
podem ser contínuos e repetitivos.
Organizações orientadas a processos mudam seus 
objetivos para melhor apoiar os processos que as 
conduzem. Por exemplo, se reduzir o lead-time de 3 dias 
para 1 dia é um objetivo de uma companhia, ao invés de 
iniciar um projeto para cumprir o objetivo, a organização 
deveria identificarseus processos e então iniciar um projeto 
para melhorá-los. Isso diminuiria o tempo de produção e 
alcançaria o objetivo esperado. Dessa forma, projetos são 
necessários para apoiar processos, e estes aumentam a 
eficiência em alcançar metas empresariais.
Entre as estratégias que falham, 90% falham porque 
a empresa não conseguiu implementá-las corretamente, 
ou seja, não conseguiu fazer com que os processos 
espelhassem a estratégia”. No nível estratégico do BPM, 
são montadas as estratégias dos processos a fim de que 
estas estejam alinhadas com as estratégias da organização, 
pois, para administrar novas e rápidas mudanças nas áreas 
empresariais, é de importância extrema unir processos 
de negócio com estratégias corporativas. Nesse nível, 
são definidas as estratégias de melhoria ou inovação dos 
processos da empresa, indicando a arquitetura dos novos 
processos e das aplicações que lhes darão suporte. A partir 
da análise dos dados levantados é montada a especificação 
do novo processo ou da melhoria/inovação do existente.
Os fatores de sucesso em utilizar uma ferramenta 
estratégica não se resumem apenas no envolvimento da 
alta gerência, mas também na integração dos empregados, 
através de uma comunicação adequada. Um elemento 
adicional de grande influência é o amadurecimento do 
gerenciamento da mudança contínua, pois repensar 
processos empresariais e seus realinhamentos completa 
o ciclo do BPM.
Assim, após completar o gerenciamento da mudança, a 
estratégia é revisada para a nova realidade e, se necessário, 
atualizada. Na administração de empresas moderna, os 
processos empresariais são os condutores operacionais 
das organizações, exigindo uma administração proativa 
desses processos.
Há alguns anos atrás, metas estratégicas só poderiam 
ser monitoradas quando os próximos resultados trimestrais 
fossem publicados. Porém, o gerenciamento do desempenho 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
48
dos processos monitora continuamente os objetivos fixados 
e fornece alertas de divergências com o que foi planejado, 
indicando medidas a serem implementadas. Assim, as 
organizações alcançam uma qualidade de processo 
melhorada, que tem um impacto direto nos resultados 
da corporação. O monitoramento contínuo de processos 
de negócio atual diminui a distância entre a estratégia 
organizacional e sua implementação operacional.
Sabe-se que do taylorismo/fordismo aos dias de 
hoje, passando pelo modelo japonês de produção, os 
gestores industriais debruçaram-se na busca de uma 
gestão empresarial que conduzisse a organização ao nível 
competitivo face ao crescente consumo especializado da 
sociedade atual. De fato, o aumento na complexidade dos 
mercados, devido ao contexto social que dia a dia mescla-
se numa tendência de dinâmicas inovadoras, globalização 
e elevação de poder dos atores sociais, conduz a gestão 
empresarial a focar suas ações em estratégias dinâmicas. 
A empresa passa a ser modelada, via organização por 
processo, sob uma proposta de um sistema aberto, em 
que mais se preocupa com fluxos do que com operações 
isoladas de produção.
Assim, a gestão empresarial passou a reconhecer que 
o gerenciamento dos processos deve se fundamentar nas 
interações intraorganização e extraorganização de forma a 
entregar ao cliente final um produto com valor agregado 
reconhecido pelo mesmo. Desta forma, observa-se que toda 
a implantação de um sistema de gestão integrada passa 
a ter como ponto de partida a modelagem de processos, 
assim como todas as decisões estratégicas passam também 
a ser apoiadas em um bom sistema de BPM.
Para situar e destacar a importância da modelagem de 
processos dentro de um ambiente de gestão por processos 
é necessário conhecer os estágios que compõem o ciclo 
de vida de um processo de negócio, apresentado a seguir.
Assista ao vídeo sobre Gestão por 
Processos – BPM
Disponível em: http://www.youtube.com/
watch?v=wpI0Ls8Nn_c
O Ciclo de Vida dos Processos de 
Negócio
A realização de qualquer atividade de trabalho se dá 
através de um processo de negócio e este possui um ciclo 
de vida que passa necessariamente por 4 estágios: Captura, 
Reengenharia, Implementação e Melhoria Contínua 
(figura 12). Se esses estágios forem bem conhecidos 
e adequadamente conduzidos, o gerenciamento dos 
processos de negócio de uma organização pode se tornar 
efetivo em relação ao seu potencial de ganho.
Figura 12 – O ciclo de vida dos processos de negócio.
Fonte: Autoria própria
 
No que se segue estes estágios são detalhados.
Captura	da	Definição	do	Processo
Ainda que escondidos na estrutura organizacional da 
empresa, os processos sempre existirão. Para capturá-los 
necessário se torna entendê-los, e isto se dá através da 
análise da documentação existente e de entrevistas com 
os atores envolvidos. Assim, após obter uma quantidade 
suficiente de informação, o processo é capturado através 
de uma definição de processo, que pode ser conduzida a 
um nível mais conceitual ou mais profundo, dependendo 
da utilização que se deseja lhe dar.
Davenport (1994) aponta pelo menos 4 razões para 
documentar os processos existentes antes de proceder à 
inovação:
• Primeira, o entendimento a ser dado aos mesmos 
facilita a comunicação entre os participantes. 
• Segunda, na maioria das organizações complexas 
não há como passar para um novo processo sem 
compreender o existente. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
49
• Terceira, o reconhecimento dos problemas de um 
processo existente pode ajudar a evitar a sua repetição no 
novo processo.
• Finalmente, o entendimento dos processos 
existentes proporciona uma medida do valor da mudança 
proposta. A execução da definição do processo requer 
a criação de um modelo, que inclui suas atividades, as 
regras de coordenação dessas atividades e as habilidades 
necessárias à sua execução (papeis – pessoas ou sistemas 
de informação). Esses elementos são combinados através 
de uma linguagem de modelagem de processos.
Reengenharia do Processo
Existem diversas metodologias propostas para a 
reengenharia de processos de negócio. Para que um 
projeto de reengenharia de processos seja efetivo, o 
corpo executivo responsável pelo projeto deve repensar o 
negócio de forma completamente nova, desconsiderando 
a maneira tradicional de se executar cada atividade. É 
o começar de novo, trabalhar com uma folha de papel 
em branco, esquecer-se dos modelos tradicionais e criar 
algo inteiramente novo na forma de se trabalhar de uma 
empresa, uma nova abordagem de um processo existente 
na empresa. É a ferramenta do “papel em branco”.
Implementação do Processo
Após a modelagem dos processos ser concluída, o passo 
natural seguinte é a implementação do que foi modelado. A 
automatização dos processos mapeados é realizada mediante 
a utilização das ferramentas de tecnologia da informação 
mais apropriadas à situação particular. A implementação de 
processos tradicionalmente tem sido realizada embutindo 
partes do processo em softwares e confiando em ações 
humanas para prover aderência ao resto do processo. 
Deve-se tomar cuidado na implementação dos processos, 
pois frequentemente, a implementação é feita pelo pessoal 
de TI sem a discussão com o pessoal envolvido no negócio, 
o que pode gerar barreiras e resistências desnecessárias.
Durante a etapa de implementação, ferramentas de 
workflow podem ser utilizadas para apoiar a transferência 
de informações através do fluxo de atividades que 
compõem um determinado processo.
Melhoria Contínua do Processo
A maioria dos processos são estruturas dinâmicas 
e necessitam ser revistas e melhoradas ao longo do 
tempo, quer seja para se adaptarem às estratégias da 
organização, quer seja para fazer uso das novas tecnologias 
da informação. Melhorar um processo implica em fazer 
pequenas correções de curso, ao invés de se ocupar em 
uma mudança radical.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 para a obtenção do máximo resultado. As 
organizações têm percebido cada vez mais que os 
seus processos de negócio lhes oferecem 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.
Diante disso, caro aluno, 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 tema interessante nas próximas páginas 
desta apostila!
José do Carmo Rodrigues
FUNDAMENTOS DA QUALIDADE DE 
SOFTWARE
Caro aluno, neste capítulo introduziremos a importância da 
qualidade do software no ambiente da engenharia de software, 
falaremos sobre o contexto da qualidade no desenvolvimento 
de software, mostraremos a importância da aplicação destes 
conceitos no cenário atual de software com qualidade e 
exemplificaremos alguns dos principais problemas da qualidade 
no que se refere ao desenvolvimento de sistemas. 
Conceitos Fundamentais de Qualidade
Caro aluno, todos nós somos influenciados por produtos 
de software tanto profissionalmente como em nossa vida 
pessoal, seja de forma consciente ou não. Os produtos de 
software possuem um papel muito influente em nossa vida, 
facilitando a realização de diversas atividades e provendo 
inúmeros serviços. Para quem trabalha no desenvolvimento 
destes sistemas, incluindo todos os profissionais da área 
de Engenharia de Software, o maior desafio é criar um 
produto de software com elevada produtividade, dentro 
do prazo estabelecido, sem necessitar de mais recursos do 
que aqueles alocados, assegurando com isso um software 
de qualidade. 
Apesar do reconhecimento em relação às facilidades que 
os produtos de software nos proporcionam, notadamente 
na área financeira e de telecomunicações, ainda há muito 
que melhorar na qualidade dos produtos de software 
desenvolvidos. 
Neste contexto, a aplicação eficaz e eficiente da 
Engenharia de Software é fundamental para aprimorar 
a qualidade dos produtos desenvolvidos, diminuindo os 
custos de desenvolvimento do produto e aumentando a 
produtividade e o tempo de atendimento ao mercado. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
6
Alguns problemas ainda são comuns no desenvolvimento 
de software. Isto se deve principalmente pelo aspecto não 
repetitivo do desenvolvimento de produtos de software, 
o que torna a garantia da qualidade uma atividade difícil 
e, muitas vezes, imprevisível. A delimitação do escopo de 
sistemas e/ou produtos de software também não é uma 
tarefa trivial. Muitas vezes o usuário não consegue definir 
com precisão todos os requisitos necessários ao projeto. 
Além disso, ainda existe a volatilidade dos requisitos, que 
representa um aspecto muito comum no desenvolvimento 
de software. 
Todo este cenário faz com que a importância da 
área de garantia da qualidade cresça continuamente 
nas organizações de desenvolvimento de software, pois 
a gerência de alto nível utiliza os resultados produzidos 
por esta área para obter visibilidade da qualidade dos 
processos executados e dos produtos entregues aos 
clientes. Além disso, decisões estratégicas de negócio são 
tomadas com base em dados consolidados das atividades 
de garantia da qualidade. Estes e outros fatores aumentam 
a complexidade e a relatividade do conceito de qualidade 
de software devido à sua forte dependência da perspectiva 
de quem está avaliando determinado produto ou serviço.
Segundo Pressman (2006), a garantia da 
qualidade de software está diretamente 
relacionada às características de qualidade 
do processo de desenvolvimento e de 
seus produtos intermediários, bem como aos esforços 
de melhoria de processos das organizações. Além disso, 
as atividades de garantia da qualidade devem estar 
presentes ao longo de todo o ciclo de vida de 
desenvolvimento do software, a fim de assegurar que o 
projeto, o desenvolvimento e a disponibilização de uma 
aplicação aconteçam de maneira bem sucedida.
Para isso, normalmente as organizações definem 
padrões, processos e procedimentos que devem ser 
seguidos para assegurar a uniformidade e o controle com 
relação ao desenvolvimento e à manutenção de software. 
Estes padrões podem incluir especificação, 
documentação, revisões, auditorias e padrões de 
Engenharia de Software, que geralmente encontram-se 
especificados em um plano de garantia da qualidade. 
A área de garantia da qualidade é constituída por um 
conjunto de atividades sistemáticas que provêm evidência 
da capacidade do processo de software de desenvolver 
um produto que atenda aos seus propósitos. Este 
conjunto de atividades que compõe a área de garantia 
da qualidade é tratado como atividades de um processo 
de apoio na implantação de outros processos e na 
elaboração e avaliação de produtos de trabalho gerados 
por estes processos. No entanto, a execução de atividades 
para atingir graus elevados de qualidade em produtos 
e processos de software requer a aplicação de muitos 
recursos. 
Mas qualidade não pode ser considerada 
sinônimo de perfeição, pois se trata de 
algo factível, relativo, substancialmente 
dinâmico e evolutivo, adequando-se ao 
nível dos objetivos a serem atingidos. Portanto, o mais 
importante é atingir o nível de qualidade desejado pelos 
usuários e necessário para o bom funcionamento dos 
produtos desenvolvidos, utilizando o mínimo de recursos 
possíveis para não impactar nos projetos.
O principal objetivo da garantia da qualidade é assegurar 
que padrões, procedimentos e políticas utilizados durante 
o desenvolvimento do software sejam adequados para 
Fonte: http://www.desenvolvatec.com/
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
7
prover o nível de confiança requerido para o processo ou 
produto de trabalho. No entanto, este nível de confiança 
varia de acordo com os diferentes tipos de usuários dos 
produtos de software, bem como o grau esperado de 
adequação do produto aos propósitos para os quais foi 
desenvolvido. Portanto, deve-se considerar que usuários 
diferentes provavelmente terão propósitos diferentes para 
o desenvolvimento de um mesmo produto.
Qualidade de Software
Caro aluno, para definirmos Qualidade de Software 
necessitamos primeiro saber o que é qualidade. Há diversas 
definições de Qualidade de Software. Vamos considerar as 
principais delas:
• De acordo com o glossário padrão de terminologia 
em Engenharia de Software do IEEE 610.12 (1990), 
qualidade pode ser definida como o grau no qual um 
sistema, componente, ou processo atende aos requisitos 
especificados e às necessidades ou expectativas do cliente 
ou usuário. 
• A norma ISO/IEC 9126 (1991) define qualidade 
como a totalidade de funcionalidades e características de 
um produto ou serviço que atendem à sua capacidade de 
satisfazer necessidades específicas ou implícitas. Além 
disso, esta norma ainda define uma lista de características 
de qualidade que um produto de software deve atender, 
como funcionalidade, confiabilidade, usabilidade, 
eficiência,A melhoria nos processos de negócio 
procura tornar os processos mais efetivos (produzindo os 
resultados desejados), mais eficientes (minimizando os 
recursos usados) e mais adaptáveis (podendo satisfazer 
as mudanças dos clientes e as necessidades do negócio).
Um processo que era satisfatório ontem é apenas 
adequado hoje e será ineficiente amanhã. Como resultado, 
um esforço de melhoria contínuo deve ser empreendido 
pelas equipes de trabalho e indivíduos envolvidos no 
processo. Os esforços de melhoria contínua resultam em 
um acréscimo anual de 10 a 15% na eficiência do processo. 
Isto é necessário se a organização visa manter os lucros 
estratégicos obtidos como resultado da implementação de 
melhoria nos processos.
A base para as melhorias são as medidas de desempenho 
do processo. Estas podem mostrar com que frequência 
certos caminhos são utilizados, quais são os tempos 
decorridos de cada processo, quais os custos envolvidos 
e resultados semelhantes. A análise destes dados pode 
conduzir a ideias para a melhoria do processo, baseado nos 
resultados atuais. Tradicionalmente, essas medições são 
realizadas adicionando-se instrumentações nos softwares e 
criando maneiras de medir a atividade humana. Conhecidos 
os ciclos de vida dos processos, é necessário gerenciá-los, 
de modo a garantir que sejam atualizados e aprimorados 
ao longo do tempo. Essa função é exercida através do 
Gerenciamento de Processos de Negócio.
Modelagem e Otimização de Processos
Os fluxogramas e mapas de processos sempre 
foram utilizados para visualizar processos de negócio. 
Fluxogramas de todos os tipos, formas e tamanho têm 
sido utilizados no gerenciamento das organizações, na 
formulação de suas políticas, procedimentos e manuais. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
50
Atualmente, os analistas de processos empresariais 
preferem o termo “modelagem de processos” em lugar de 
fluxogramação ou mapeamento. 
A modelagem de processos implica em uma abordagem 
mais disciplinada, padronizada, consistente e, sobretudo 
mais científica e madura. Tem que atender um grupo 
cada vez mais heterogêneo de trabalhadores e, para isto, 
deve ser escalável, configurável e estabelecer uma ponte 
entre a TI e as exigências do negócio. Diversos fatores, 
como a identificação do processo, estabelecimento 
de seus objetivos e limites, identificação dos diversos 
papeis funcionais envolvidos e escolha da ferramenta 
de modelagem a ser utilizada, podem afetar o sucesso 
da melhoria de processos. Porém, o mais importante 
é a habilidade de representar e modelar o processo. O 
propósito básico de um modelo é reduzir a complexidade 
de compreensão ou interação de um fenômeno, através 
da eliminação de detalhes que não influenciam seu 
comportamento pertinente.
Notadamente, a Modelagem de Processos de 
Negócio (Business Process Modeling) é essencial para a 
reengenharia ou reestruturação de processos. Ela abrange 
dois importantes papeis:
1. capturar os processos existentes através da 
representação estruturada de suas atividades e elementos 
relacionados;
2. representar novos processos a fim de avaliar seu 
desempenho. Além das duas funções acima, um método 
de modelagem de processos de negócios também possui a 
capacidade de análise na avaliação de processos e seleção 
de alternativas. Para alcançar esse propósito, a simulação 
computadorizada pode ser aplicada, como uma função do 
progresso da TI.
Gonçalves (2000) afirma que “o sucesso do novo 
desenho para um processo depende fundamentalmente 
de sua operacionalização, e o desenho do processo é o 
mapa essencial do caminho a ser percorrido.” Dessa forma, 
um modelo de processo muito simples ou que apresente 
um nível elevado de complexidade pode dificultar o 
entendimento completo do processo real.
Existem dois condutores de complexidade para a 
criação de um modelo de processo. O primeiro é a forma 
como a modelagem é abordada, isto é, a complexidade da 
modelagem. Neste caso, pode-se questionar: Quão difícil 
é projetar um modelo dentro do ambiente de modelagem? 
(ferramenta, técnicas, diretrizes, etc.) E quão complexo é 
o modelo obtido, isto é, pode o modelo ser representado 
em uma página? O segundo condutor é a complexidade 
do próprio processo, isto é, a complexidade do processo. 
Um modelo de processo é como um espelho: reflete. Mas 
diferente de um espelho, também permite um enfoque 
mais profundo nos elementos de interesse, ou seja, a 
complexidade de um processo é tão grande quanto a 
profundidade que se esteja olhando. Assim é possível 
reduzir e administrar a complexidade da modelagem para 
uma extensão que permita se concentrar na complexidade 
do processo.
A fim de modelar um processo é necessário estabelecer 
as diferentes perspectivas em que se deseja analisá-lo. Em 
resumo existem as seguintes visões de um processo, em 
função do tipo de informação requerida:
• Visão funcional – representa qual atividade ou 
elemento do processo está sendo executada. Representa 
a ação ou atividade que está sendo executada pelos atores 
ou empregados;
• Visão comportamental – relaciona quando e 
como o processo está sendo executado. A atividade ou o 
processo como um todo poderiam estar passando por um 
ciclo de realimentação ou um processo de repetição;
• Visão informacional – representa os detalhes 
da informação ou objetos que estão sendo manipuladas 
pelo processo, estes podem ser dados ou detalhes do 
objeto produto. A visão informacional considera os dados 
envolvidos e as relações entre eles;
• Visão organizacional – representa quem está 
executando o processo. 
Dentro do conceito de ciclo de vida dos processos 
apresentado por Georgakopoulos & Tsalgatidou (1997), 
pode-se dizer que a modelagem de processos compreende 
as seguintes etapas:
• Modelagem do estado atual (“As Is”);
• Otimização e modelagem do estado futuro (“To 
Be” – quando aplicável).
A primeira etapa consiste em mapear o estado atual 
do processo, como ele existe atualmente (“As Is”). Isto 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
51
significa que, juntando dados de pessoas que executam 
de fato o processo, é possível aprender exatamente como 
as coisas acontecem dentro da organização. Uma vez 
que o “As Is” do processo esteja documentado, pode-se 
entender onde poderiam ser feitas melhorias.
Qualquer processo horizontal, que atravessa os limites 
da unidade de negócios, requer a colaboração de vários 
departamentos, inclusive as pessoas da linha-de-negócio 
cujo processo está sendo modelado. Também inclui o 
departamento de finanças que entende dos custos do 
processo e recursos relacionados, o departamento de 
recursos humanos que pode oferecer subsídios para se 
definir quais empregados deveriam ser nomeados para 
tarefas específicas e departamentos adjacentes que serão 
afetados pelo novo fluxo de trabalho. Para executar a 
modelagem do processo atual, algumas etapas são comuns:
• Preparação do projeto de modelagem;
• Entrevistas e coleta de dados com usuários;
• Documentação do processo;
• Validação do processo.
Na fase de documentação do processo, torna-se 
necessária a utilização de uma linguagem para a sua 
representação. Dentre as linguagens existentes para 
representação de modelos de processos, 3 possuem 
destaque devido ao grau de aplicabilidade, capacidade 
intuitiva de representação e simplicidade:
• IDEF 0 – Integration DEFinition for Function 
Modeling
• EPC – Event-driven Process Chain
• BPMN – Business Process Modeling Notation. 
Assista ao vídeo sobre BPM - Business Process 
Modeling
http://www.youtube.com/
watch?v=D6MYXj8YD9Q
AUTOMAÇÃO DE PROCESSOS: 
WORKFLOW
Caro aluno, este capítulo apresenta um dos recursos de 
automação de processos, conhecido como workflow. Com 
o passar do tempo as organizações sentiram a necessidade 
de mecanismos para gerenciar processos repetitivos, que 
dessem uma visão ampla dos processos e suas conexões com 
as necessidadesdos negócios. Sentiu-se a necessidade de 
ferramentas passíveis de serem adaptadas aos meios eletrônicos 
de gerenciamento e que oferecessem flexibilidade suficiente para 
serem aplicadas numa variedade significativa de negócios. Surgiu, 
então, o workflow. Particularmente no campo dos processos de 
negócios, o workflow veio somar ferramentas de mapeamento, 
Exercícios do Capítulo 5 
1) Complete as sentenças:
Os ___________________________________________
___________são processos que geralmente envolvem mais 
de uma função na estrutura organizacional e sua operação tem 
um impacto significativo no funcionamento da organização.
Dois dos principais benefícios que as organizações ganham 
com um sistema completamente integrado e implementado 
são: _____________________________________________ 
e _______________________________________________
_____________ na qual são construídos os negócios.
2)	 Assinale	 V-verdadeiro	 e	 F-falso	 nas	
afirmações:
( ) Entre as estratégias que falham, apenas 10% 
falham porque a empresa não conseguiu implementá-las 
corretamente, ou seja, não conseguiu fazer com que os 
processos espelhassem a estratégia”
( ) A realização de qualquer atividade de trabalho se dá 
através de um processo de negócio e este possui um ciclo 
de vida que passa necessariamente por quatro estágios: 
Captura, Reengenharia, Implementação e Melhoria Contínua.
( ) Para que um projeto de reengenharia de processos 
seja efetivo, o corpo executivo responsável pelo projeto 
deve repensar o negócio de forma completamente nova, 
desconsiderando a maneira tradicional de se executar cada 
atividade.
( ) Melhorar um processo implica em fazer grandes 
correções de curso, de forma a se fazer uma mudança radical.
( ) A Modelagem de Processos de Negócio (Business 
Process Modeling) é essencial para a reengenharia ou 
reestruturação de processos. Um dos papéis que ela abrange 
é capturar os processos existentes através da representação 
estruturada de suas atividades e elementos relacionados;
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
52
análise e gestão, facilitando o estudo e a melhoria contínua dos 
processos da organização.
Definição de Workflow
Ambientes empresariais modernos são caracterizados 
por um conjunto de processos de negócios que precisam 
ser acompanhados para atingir os objetivos estabelecidos. 
Até a década de 1990, o trabalho era transferido de um 
trabalhador para outro manualmente. Assim que uma tarefa 
era entregue a uma pessoa, cada participante poderia 
assumir que o trabalho estava pronto para processamento. 
O foco da TI era a automação de atividades individuais 
desenvolvidas pelos participantes, de forma que estas 
fossem completadas de um modo mais rápido e eficiente.
Nos anos mais recentes, a possibilidade de automatizar 
a coordenação dos processos tem sido explorada, 
resultando em uma área de pesquisa e tecnologia 
comumente referenciada como tecnologia de workflow. 
Georgakopoulos et al. (1995) associam-na à especificação 
de processos de negócio, reengenharia e automação, 
quando definem workflow como uma coleção de tarefas 
organizadas para realizar processos de negócio.
Workflows são processos – sucessões 
temporais e lógicas de funções que são 
necessárias para executar operações em 
objetos economicamente relevantes – com 
transições automatizadas, ou seja, processos 
cujo controle lógico está dentro de um sistema de informação.
 
Fonte: [GEORGAKOPOULOS et al., 1995]
A WFMC - Workfow Management Coalition (1999) define 
workflow como “a automação de processos de negócio, 
total ou em parte, na qual documentos, informações e 
tarefas são passadas de um participante para outro através 
de uma ação, de acordo com um conjunto de regras de 
procedimento”.
Ainda segundo a WFMC, os sistemas de gerenciamento 
de Workflow são “sistemas para definição, criação e 
gerência da execução de fluxos de trabalho através do uso 
de software, capaz de interpretar a definição de processos, 
interagir com seus participantes e, quando necessário, 
invocar ferramentas e aplicações.”
Um workflow normalmente é baseado em um modelo 
de processo que foi aprimorado com tipos de objetos 
adicionais, como estruturas de dados, e atributos, como 
condições iniciais, que permitem sua automatização, 
passando a ser chamado de Modelo de Workflow. 
Modelos de Workflow são normalmente descritos usando 
gráficos dirigidos cujos elementos representam funções 
elementares ou compostas. A figura 13 representa os 
relacionamentos existentes entre os conceitos de workflow 
dentro de um processo de negócio.
Pode-se observar na figura 13 a estreita relação 
existente entre a modelagem do processo, representada 
pela definição do negócio, sub processos e atividades, 
e a gestão do mesmo, realizada através de Sistemas de 
Gerenciamento de Workflow. Por estarem diretamente 
relacionados à área de negócios das organizações, os 
sistemas de workflow têm sido indicados como ferramenta 
para o apoio computacional aos processos de negócio.
O ciclo do workflow
Quando comparado ao ciclo de vida de um processo, o 
ciclo do workflow apresenta singular semelhança. E não é 
por acaso, já que o objetivo principal deste é automatizar 
processos de negócio. A implantação de um sistema de 
workflow obedece a um ciclo composto por cinco etapas:
1. Revisão do fluxo de trabalho atual;
2. Projeto do modelo do fluxo de informação do fluxo 
que se quer;
3. Programação do modelo de informação, com 
definição e detalhamento de cada um dos elementos nele 
contidos;
4. Implantação do workflow;
5. Atualização do modelo implantado.
O projeto de um novo modelo de informação deve 
partir de alguma realidade. Assim, é preciso primeiro 
analisar como o processo atual é executado a fim de que 
se tenham os elementos necessários para projetar o novo 
fluxo de trabalho. Nesse ponto a modelagem de processos 
constitui-se como uma ferramenta de grande valia, 
principalmente quando o modelo do processo é gerado 
visando à montagem do workflow.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
53
A segunda etapa consiste em montar o modelo do 
fluxo de trabalho, definindo as tarefas e procedimentos 
existentes, as regras para roteamento dos documentos e 
informações e os atores (ou papeis) que executarão as 
tarefas necessárias. Nesta etapa, o modelo do processo, 
obtido através dos métodos de modelagem de processos 
é uma ferramenta valiosa para a definição do modelo do 
fluxo de trabalho.
A próxima etapa envolve a programação/configuração 
do modelo dentro do software escolhido para suportar o 
sistema de workflow. Os softwares de workflow de última 
geração têm procurado cada vez mais diminuir o trabalho 
de programação, fornecendo interfaces mais amigáveis 
e padronizadas, em que o usuário monta o workflow 
utilizando estruturas e funções pré-definidas, aumentando 
o trabalho de configuração e diminuindo o de programação. 
Interfaces que permitem a montagem gráfica do workflow 
auxiliam nesta etapa.
A etapa de implantação do workflow exige cuidados 
quanto ao tamanho do sistema que está sendo implantado. 
Não se deve querer implantar todos os processos de uma 
única vez, é sempre aconselhável fazer um piloto do projeto. 
Além disso, deve-se estar atento ao gerenciamento da 
mudança imposta pela introdução dessa tecnologia, pois 
conforme destaca Cruz (2000) “A mudança de uma forma 
de trabalhar, como a que encontramos na maioria das 
empresas ainda hoje, para uma totalmente diferente, por 
meio da implantação do fluxo de trabalho automatizado 
não é pequena, e reconhecer isso com antecedência é 
garantir melhores condições para que o projeto tenha 
sucesso.”
A quinta e última etapa consiste em revisar e atualizar o 
sistema implantado e tem por objetivo a melhoria contínua 
do processo. Durante a implantação e principalmente no 
início da utilização do sistema é comum serem detectadas 
várias deficiências que precisam sertratadas e saneadas, 
a fim de que não se acentuem ao longo do tempo.
Figura 13 – Relacionamentos entre a terminologia básica de Workflow
Fonte: http://sistemasdeworkflow.blogspot.com.br/
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
54
Em função dos objetivos a serem alcançados, das 
características dos processos e área de atividade em que 
estes são utilizados existem diversos tipos de workflow.
Tipos de workflow
Para Cruz (2000), ainda não existe um consenso 
entre os especialistas sobre a forma de caracterizar ou 
categorizar sistemas de workflow. No entanto, para tornar 
a modelagem de processos de negócios mais efetiva, é 
importante que se identifique em qual categoria o processo 
se enquadra, visto que alguns modelos podem não ser 
adequados para uma representação de determinadas 
estruturas de fluxo e decisão. A identificação dos tipos de 
workflow permite maior segurança na escolha de modelos 
e de ferramentas de modelagem para representação dos 
processos de negócios.
Uma classificação que possui boa aceitação é a 
proposta por McCready (1992), que classifica os sistemas 
de workflow em três tipos básicos:
• Ad hoc
• Administrativo
• Produção
As dimensões básicas ao longo das quais são 
caracterizados estes tipos de processos incluem:
• repetibilidade e previsibilidade do processo e suas 
atividades;
• criticidade da missão; 
• valor para a organização.
Workflows	Ad	hoc
Os workflows ad hoc executam processos de negócios 
nos quais não há um padrão pré-determinado de 
movimentação de informação entre pessoas, tais como 
documentação de produtos ou propostas para venda de 
produtos. A ordenação e a coordenação de tarefas em um 
workflow Ad hoc não são automatizadas, mas controladas 
por humanos. 
Esta classe de workflow envolve tipicamente pequenos 
grupos de profissionais que têm o objetivo de apoiar pequenas 
atividades que requerem uma solução rápida. A figura 14 
representa um workflow Ad hoc simplificado envolvendo o 
processo de admissão de um sócio em um clube.
Figura 14 – representação de um workflow Ad hoc 
simplificado envolvendo o processo de seleção de candidatas 
em um concurso de misses. Fonte: Autoria própria
O processo mostrado consiste na avaliação individual das 
candidatas por parte dos juízes, que selecionam algumas 
poucas de um conjunto maior e escolhem aquela que, na 
somatória dos pontos atribuídos deva ser a vencedora. 
Percebe-se, neste caso, a colaboração de alguns agentes 
(juízes) para o desenvolvimento do processo e o caráter 
de certa forma improvisado de cumprir as tarefas.
Sistemas de e-mail, também são exemplos de workflow 
Ad hoc, em que os usuários podem rotear formulários de 
negócios eletrônicos como mensagens de correio eletrônico 
com documentos anexados (attachments).
Workflows	Administrativos
Os workflows administrativos envolvem processos 
repetitivos com regras de coordenação de tarefas 
simples, tal como roteamento de um relatório de despesa 
ou requisição de viagem através de um processo de 
autorização. Não são utilizados para processos com grande 
complexidade de informação e não requerem acesso a 
múltiplos sistemas de informação externos. Workflows 
administrativos geralmente não são usados em sistemas 
críticos. [GEORGAKOPOULOS et al., 1995]
Consideremos, agora, um processo de filiação de 
um sócio a um clube, para exemplificar um workflow 
administrativo. Supõe-se que os agentes cumpridores das 
rotinas são previamente conhecidos, ou seja, fazem parte 
de uma estrutura já organizada. Veja a figura 15.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
55
Figura 15 – Workflow Ad hoc para admissão de sócios.
Fonte: Autoria própria 
Workflows	de	Produção
Os workflows de produção reúnem processos de 
negócios repetitivos e previsíveis, em que a ordenação 
e coordenação de tarefas podem ser automatizadas, 
tais como aprovação de empréstimos e seguros. 
Diferentemente dos administrativos, os workflows de 
produção englobam um processamento de informações 
complexas envolvendo acesso a múltiplos sistemas 
de informação. Esse tipo de workflow é utilizado para 
processos mais críticos, em que o nível de controle 
na execução das tarefas deve ser alto, com baixa ou 
nenhuma intervenção humana. Veja figura 16.
Pode-se observar nesse workflow a presença de 
sistemas especialistas e bancos de dados auxiliares 
que são acessados ao longo do processo, de forma a 
automatizar determinadas tarefas. Dessa forma, elimina-
se a necessidade da intervenção humana nas decisões e 
encaminhamentos.
Classificação de workflows
Geogakopoulos et al. (1995) classificam os sistemas 
de workflow em um escala contínua, que possui num 
extremo os workflows orientados a humanos e no outro os 
workflows orientados a sistemas (figura 17). No primeiro 
tipo a execução e coordenação das tarefas envolvem a 
colaboração humana. Ambientes desse tipo são utilizados 
para possibilitar a coordenação e a colaboração entre 
Figura 16 – Workflow para Requisição de Seguro Saúde.
Fonte: http://www.oocities.org/wallstreet/market/4702/textos/workflow.htm
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
56
pessoas, aumentando-lhes o desempenho. Sistemas desse 
tipo são conhecidos como CSCW (Computer Supported 
Cooperative Work) ou Trabalho Cooperativo Suportado por 
Computador, ou simplesmente “workflow colaborativo”.
Figura 17 – Caracterizando workflow
Fonte: http://www.oocities.org/wallstreet/
market/4702/textos/workflow.htm
O segundo tipo de workflow envolve sistemas de 
computadores que executam operações computacionais 
intensas e softwares especializados na execução de tarefas 
com pequena ou nenhuma intervenção humana (workflow 
do tipo produção). Esses sistemas precisam incluir um 
software para controle de concorrência e técnicas de 
recuperação para assegurar consistência e segurança. A 
metodologia de modelagem de processos apresentada 
nesse trabalho pode ser aplicada como etapa inicial de 
qualquer um dos tipos de workflow apresentados, porém 
esta se torna relevante para os workflows administrativos 
e de produção, onde a possibilidade de automatização é 
maior e, consequentemente, os ganhos também podem 
ser maiores. O exemplo de validação estudado trata-se 
de um workflow de produção, já que faz acesso a outros 
sistemas da organização para atualização de dados e 
tomadas de decisão.
Sistemas de Gerenciamento de Workflow
Sistemas de Gerenciamento de Workflow (Workflow 
Management Systems – WFMS) representam uma 
infraestrutura tecnológica chave por gerenciar efetivamente 
processos de negócios em vários setores, incluindo bancos 
e financeiras, serviços de saúde, telecomunicações, 
manufatura e produção. 
As áreas tradicionais de modelagem de processos 
de negócio, coordenação de processos de negócio e 
gerenciamento de documentos e imagens, junto com 
áreas emergentes como interações business-to-business 
e business-to-consumer, impulsionaram uma grande 
diversidade de diferentes sistemas de gerenciamento de 
workflow a estarem disponíveis como produtos comerciais 
ou protótipos de pesquisa. Apesar de uma contínua 
padronização, estes produtos estão frequentemente 
baseados em diferentes paradigmas e apoiam uma grande 
variedade de linguagens de modelagem de processos.
Muitas pesquisas têm trabalhado com a fase de 
modelar esquemas de workflow e vários formalismos já 
foram propostos para apoiar o projetista na execução 
desta tarefa. Para dar uma descrição simples e intuitiva da 
estrutura de um workflow, tais formalismos estão baseados 
em representações gráficas, como o gráfico de fluxo de 
controle. Nele, o workflow é representado por um gráfico 
etiquetado dirigido, cujos nós, representam as tarefas a 
ser executadas, e dos quais partem setas que descrevem a 
precedência entre eles (figura 18). Além disso, a Workflow 
Management Coalition também identificou controles 
adicionais,como loops (laços) e subworkflows.
Figura 18 – Exemplo de gráfico de fluxo de controle.
Fonte: Autoria própria
As especificações de workflow podem ser entendidas 
sob diferentes perspectivas. A perspectiva de controle 
de fluxo (ou processo) descreve atividades e sua ordem 
de execução através dos diferentes participantes, o que 
permite o controle de execução do fluxo, por exemplo, 
sequência, escolha, paralelismo e sincronização. Atividades 
na forma elementar são unidades atômicas de trabalho que, em forma de combinação, regula uma ordem de execução 
de um conjunto de atividades.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
57
A perspectiva de dados classifica dados do negócio e 
do processamento na perspectiva de controle de fluxo. 
Documentos empresariais e outros objetos que trafegam 
entre atividades, assim como variáveis locais do workflow, 
são classificados em efeito de pré e pós-condições de 
execução da atividade. 
A perspectiva de recursos proporciona um suporte 
de estrutura organizacional para o workflow na forma 
de papeis (roles) de recursos humanos e dispositivos 
responsáveis por executar atividades. 
A perspectiva operacional descreve as ações elementares 
executadas por atividade, onde as ações são mapeadas 
dentro das aplicações subjacentes. Tipicamente, dados 
empresariais e de workflow são passados para dentro e para 
fora das aplicações através de interfaces atividade-aplicação, 
permitindo manipulação dos dados dentro das aplicações. 
Um workflow normalmente inclui vários passos lógicos 
(conhecidos como tarefas), dependências entre tarefas, 
regras para roteamento e participantes. Uma tarefa 
pode requerer envolvimento humano ou ser executada 
automaticamente por aplicações de TI. 
Um sistema de workflow lê, automatiza, processa 
e administra fluxos de trabalho, coordenando o 
compartilhamento e roteando a informação. Durante o 
processamento, tarefas, informações e documentos são 
passados de um participante para outro, de acordo com 
um conjunto de regras, rotas e papeis. A automatização de 
itens de trabalho aumenta a eficiência do processo. Além 
disso, a administração e análise de instâncias de workflow 
fornecem uma oportunidade para medir parâmetros dos 
processos de negócio, a fim de que possam ser feitas 
melhorias contínuas.
Instâncias de um workflow rodam em um ou mais 
“motores” de workflow, que são capazes de interpretar 
definições de workflow, interagir com participantes do fluxo, 
e, onde for exigido, interagir com ferramentas e aplicações 
externas. A WFMC (1995) estabeleceu um Modelo de 
Referência de Workflow (Workflow Reference Model) que é 
uma representação gráfica da arquitetura de um sistema de 
workflow. Neste modelo estão evidenciadas cinco interfaces 
entre um sistema de gerenciamento de workflow e seu 
ambiente externo, apresentadas na figura 19.
Figura 19 - Modelo de Referência de Workflow.
Fonte: traduzido de http://www.sinfic.pt/SinficNewsletter/
sinfic/Newsletter28/Dossier2.html
A importância do modelo de referência de workflow 
estabelecido pela WFMC incide no fato de que ele indica os 
elementos básicos necessários para que um sistema de TI 
possa ser considerado como um sistema de gerenciamento 
de workflow. Um elemento essencial para a identificação 
de um sistema como sendo de workflow é a presença de 
um motor, que é o responsável por ativar e dar movimento ao processo. Essa informação normalmente é usada na etapa 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
58
de comparação e seleção de um sistema de workflow para 
a organização.
Escolha de um Sistema de Workflow
Há um grande número de sistemas comerciais de 
gerenciamento de workflow. Estes sistemas diferem no que 
diz respeito à eficiência, devido ao fundo histórico distinto 
entre eles. A seleção de um sistema de gerenciamento 
de workflow apropriado demanda um processo de seleção 
eficiente. Durante o processo tradicional de avaliação 
de software, o enfoque principal baseia-se em aspectos 
técnicos, como confiabilidade, operacionabilidade, 
sustentabilidade e adaptabilidade, como também em 
aspectos econômicos dos sistemas analisados.
O uso de catálogos de critérios representa a prática 
comum de avaliação de software. Porém, eles falham 
durante a avaliação dos métodos de modelar, porque não 
refletem o vasto número de alternativas de modelagem 
oferecido por um método. A complexidade destas 
alternativas pode ser reduzida pela formalização da 
descrição do método.
No caso deste estudo, cuja aplicação está voltada para 
o setor de prestação de serviços, em especial serviços 
públicos, a escolha do Sistema de Workflow deve levar em 
consideração a disponibilidade do workflow não somente 
para a realização dos serviços internos à instituição, mas 
também para o atendimento ao cidadão. A utilização 
de sistemas de workflow na administração pública está 
ligada ao conceito de governo eletrônico. Esses sistemas 
compõem, juntamente com outros sistemas, a estrutura 
tecnológica que serve de base para a disponibilização de 
serviços via Web aos cidadãos. Dessa forma, a escolha 
do sistema de workflow não pode estar desvinculada dos 
objetivos que se deseja alcançar com a implantação do 
governo eletrônico.
Assista ao vídeo sobre BPM versus workflow 
http://www.youtube.com/
watch?v=KI6x6oJHmGg
METODOLOGIAS DE MODELAGEM DE 
PROCESSOS
Caro aluno, neste capítulo vamos estudar as metodologias 
de modelagem de processos. A modelagem de processos é um 
recurso extraordinário para o planejamento e controle de rotinas 
administrativas e de produção, portanto, de negócios. Processos 
complexos e longos, principalmente, são difíceis de se visualizar 
como um todo e o seu mapeamento facilita muito a visão geral 
Exercícios do Capítulo 6 
1) Complete as sentenças:
A importância do modelo de referência de workflow 
estabelecido pela WFMC incide no fato de que ele indica os 
elementos básicos necessários para que um sistema de TI 
possa ser considerado como um _______________________
__________________________________________ .
Os workflows _________________________ reúnem 
processos de negócios repetitivos e previsíveis, em que a 
ordenação e coordenação de tarefas podem ser automatizadas, 
tais como aprovação de empréstimos e seguros.
A implantação de um sistema de workflow obedece a um 
ciclo composto por cinco etapas:
a. _________________________________________
________________________________________________;
b. Projeto do modelo do fluxo de informação do fluxo 
que se quer;
c. _________________________________________
________________________________________________;
d. Implantação do workflow;
e. _________________________________________
________________________________________________.
McCready classifica os sistemas de workflow em três 
tipos básicos: _____________________, administrativo e, 
_____________________ .
As especificações de workflow podem ser entendidas 
sob diferentes perspectivas. A perspectiva de 
_______________________________ descreve atividades e 
sua ordem de execução através dos diferentes participantes, 
o que permite o controle de execução do fluxo, por exemplo, 
sequência, escolha, paralelismo e sincronização.
Geogakopoulos et al. (1995) classificam os sistemas 
de workflow em um escala contínua, que possui num 
extremo os workflows orientados a _________________
________________ e no outro os workflows orientados a 
_______________________________ .
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
59
sobre eles. A construção de modelos representativos de processos 
incrementa o controle e a possibilidade de testes e avaliações 
que muitas vezes o processo real, não permite. A flexibilidade da 
metodologia de modelagem pode garantir economia de recursos 
e projetar previsões que reduzem as possibilidades de erros nas 
execuções dos processos. Bons estudos.
Modelagem de Processos
Em função da natureza abstrata dos processos, ter uma 
compreensãoexata deles torna-se uma tarefa difícil sem 
o uso de uma metodologia de modelagem padronizada. 
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. 
Uma Metodologia de 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 não só é uma das 
exigências da ISO 9000 para a gestão da qualidade e garantia, 
como também é uma das questões chave na implementação 
da maioria dos sistemas de informação, como sistemas de 
gerenciamento de workflow, ERP e e-business.
Os livros sobre processos de negócio fornecem 
conceitos, uma visão geral e algum estímulo, mas não 
entram em detalhes a respeito da identificação do 
processo, modelagem e análise que os profissionais estão 
buscando. A descrição encontrada na literatura a respeito 
da maioria das metodologias de modelagem existentes 
está centralizada na forma como os objetos são nelas 
representados. Existem poucos estudos relativos à forma 
de levantamento dos dados, à coleta de informações e à 
interação com a montagem de um sistema de workflow, 
utilizadas em cada metodologia para a montagem do 
modelo do processo.
O sucesso da modelagem de processos de negócio 
depende da seleção apropriada de métodos de modelagem 
disponíveis, técnicas ou análises de fluxo de processo. 
Existem muitas técnicas ou análises usadas neste campo, 
porém a literatura sugere que não existe uma única técnica 
para uso em modelagem de processos. O mais comum é 
a utilização de um conjunto de ferramentas que permite o 
uso de técnicas diferentes, baseado nos dados disponíveis 
para o desenvolvimento do modelo e relativo ao propósito 
da modelagem.
Damij (2007) divide as pesquisas e as práticas na área 
de modelagem de processos em três grupos. O primeiro 
grupo de estudos compara várias fases da modelagem de 
processo com ferramentas e técnicas usadas por algumas 
das principais companhias ao redor do mundo. O segundo 
grupo de estudos trabalha com o desenvolvimento de 
técnicas existentes para modelagem de processo de 
negócio. Após comparar várias técnicas, eles concluíram 
que os modelos possuem limitações sérias, como 
não permitir análises quantitativas, serem subjetivos, 
apresentarem dados mecanicamente e sua manutenção 
ser relativamente trabalhosa. O terceiro grupo estuda 
e compara várias ferramentas para modelagem de 
processo de negócio. Como conclusão eles identificaram 
os seguintes elementos que influenciam no uso dessas 
ferramentas: objetivo do projeto, escopo e propósito 
das mudanças, possibilidade de desenvolvimento de TI, 
cultura organizacional.
Será apresentada a seguir uma metodologia para 
modelagem de processos que possuem uma visão mais 
abrangente, que engloba desde o levantamento dos 
processos da organização até a montagem do modelo do 
processo selecionado. 
Metodologia de Jacka & Keller
Para Jacka e Keller (2002), a modelagem de processos 
não só proporciona uma administração com uma 
visão global das operações, mas também fornece aos 
colaboradores uma visão geral de como o seu trabalho 
agrega valor ao produto ou serviço e como eles fazem 
parte de uma equipe. Além disso, o sucesso da análise de 
processos deve levar em consideração os clientes, e isso 
pode ser qualquer nível de cliente.
Assim como os processos de uma organização 
passam por numerosas mudanças ao longo do tempo, a 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
60
compreensão deles também é alterada. Nesse sentido, em 
uma organização, os executivos têm uma ideia do processo, 
os gerentes e supervisores têm outra, o pessoal da linha 
de produção tem uma terceira e a pessoa que primeiro 
imaginou o processo não reconheceria o produto acabado.
O modelo de processo é uma visualização da 
compreensão variável do processo. Após tudo ter sido 
exposto e realizado, o modelo do processo deveria conciliar 
o entendimento de todos os envolvidos para espelhar o 
processo real. Segundo Jacka e Keller (2002), os passos 
que vão mudar o modelo para refletir a realidade é que o 
fazem efetivo. Estes passos são: 
• identificação do processo (saber o que compõe o 
processo sob revisão); 
• coleta de dados (saber o que existe dentro do 
processo e quem está com ele envolvido); 
• entrevistas e geração do modelo (identificar e 
registrar as ações dentro do processo); 
• análise dos dados (verificar o que pode ser feito 
para melhorar o processo); 
• apresentação (mostrar para todos o que foi feito).
Identificação	do	processo
Ao iniciar a identificação do processo é importante ter 
em mente que, durante todo o processo de modelagem, 
deve-se pensar como o cliente, não como a organização.
As etapas da identificação do processo são as seguintes:
• Identificar os eventos que disparam os processos 
(triggers);
• Identificar os processos críticos para o cliente;
• Identificar os processos de suporte;
• Nomear os processos;
• Preparar o mapa geral dos processos.
Uma vez identificados os processos, deve-se começar 
a resumir a informação que foi coletada e desenvolver um 
plano para reunir informações detalhadas adicionais sobre 
cada processo.
Coleta de dados
Qualquer análise de processos requer uma metodologia 
sistemática por reunir e documentar informações. Existem 
diversas abordagens possíveis, mas para Jacka e Keller 
(2002) esta é a que apresenta melhor resultado:
• Identificar o processo;
• Descrever o processo;
• Identificar os donos do processo ou da unidade;
• Entrevistar os donos de processo ou da unidade, 
segundo os seguintes aspectos:
 Verificar seu entendimento do processo;
 Determinar os objetivos do negócio;
 Determinar os riscos do negócio;
 Determinar os controles chaves;
 Determinar as medidas para o sucesso.
A meta desta etapa é usar as fontes de informação 
da maneira mais eficiente. À medida que a informação 
vai sendo coletada, é necessário um reservatório para 
armazená-la. Para isso, Jacka e Keller (2002) propõem o 
uso de tabelas chamadas de Folhas de Trabalho. No início 
do projeto, o revisor deve estabelecer um conjunto de 
folhas de trabalho em branco e parcialmente preenchidas 
para armazenar as informações chave coletadas. 
A técnica consiste em reunir os pedaços deste quebra-
cabeça e ordenar corretamente as formas para encontrar 
as partes que encaixam. A Folha de Trabalho mais 
importante é a do Perfil do Processo, mostrada na figura 
20. Este formulário deve ser criado e preenchido para cada 
processo sob revisão.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
61
Figura 20 – Folha de Trabalho do Perfil do Processo
Fonte: Autoria própria
Entrevistas e geração do modelo
A chave para o sucesso da modelagem de processos é 
a entrevista, e a chave para uma entrevista eficiente é a 
criação de um ambiente no qual a informação possa ser 
compartilhada abertamente. Entrevistas para modelagem 
de processos não são particularmente diferentes de 
qualquer outra entrevista para coleta de informação, pois 
todas envolvem planejamento, conversa, e, acima de 
tudo, escuta.
Nesta metodologia, os modelos devem ser construídos 
em tempo real, através do uso da técnica de “post-its”. 
Isto permite uma sessão muito interativa, que resulta em 
uma maior quantidade de informação e adicionalmente 
assegura sua precisão. O topo da página deve mostrar os 
indivíduos envolvidos e o tempo progride à medida que se 
desloca para baixo (figura 21).
Figura 21 – Processo de pagamento através de cheques
Fonte: Autoria própria
Os modelos e os símbolos utilizados devem ser simples. 
Não se trata de tentar impressionar as pessoas com a 
quantidade de informação que se pode colocar em uma 
página,mas de procurar facilitar a compreensão visual 
do processo. Se for necessário explorar o modelo mais 
detalhadamente, pode-se quebrar um processo nos vários 
elementos que o compõem. Além disso, é recomendável 
criar uma visão geral para resumir os processos sob revisão.
A geração dos modelos, quando executada 
cronologicamente, facilita a visualização das ações que 
possuem desmembramento. À medida que o modelo 
vai sendo montando, os pontos de demora e retrabalho 
encontrados no fluxo devem ser identificados para análise 
de melhoria posterior.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
62
Análise	dos	dados
Para Jacka e Keller (2002), a análise dos dados deve 
ser executada através de duas abordagens: revisão das 
Folhas de Trabalho do Perfil do Processo e busca através 
dos modelos. A primeira abordagem visa assegurar que 
a compreensão inicial do processo esteja correta e ter a 
certeza de que a análise final corresponda à maioria das 
categorias da folha de trabalho. Estas incluem gatilhos, 
entradas, saídas, propriedade do processo, objetivos do 
negócio, riscos do negócio, chaves de controle e medidas 
do sucesso.
A maioria destas revisões está baseada nas mesmas 
informações contidas nas folhas de trabalho conforme 
foram originalmente elaboradas. Porém, os produtos 
devem ser vistos sob uma ótica diferente. É importante 
pensar em produtos como resultados e reconhecer que 
existem quatro tipos de resultados diferentes:
• produtos (o que se espera que o processo 
produza); 
• desperdícios (itens produzidos que não satisfazem 
as expectativas de produção); 
• surpresas (ramificações do processo que podem 
ser favoráveis ou desfavoráveis, mas são inesperadas); 
• consequências invisíveis (efeitos de longo prazo 
que não são percebidos até que o processo esteja sendo 
executado durante algum tempo). 
Reconhecer e analisar esses resultados ajuda a 
identificar áreas que necessitam de atenção adicional. 
Durante a análise dos modelos atuais, o revisor deveria 
estar atento aos indicadores que representam áreas que 
necessitam de revisão adicional. A remoção de aprovações 
aumenta a autoridade dos trabalhadores para completar 
suas ações de uma maneira mais oportuna. Erros de 
looping são situações em que o processo tende a voltar 
pelo mesmo caminho várias vezes até que condições 
restritivas sejam atendidas. Demoras, retrabalhos e 
operações manuais devem ser amenizados ou eliminados.
Formulários e relatórios devem ser revisados de perto 
para verificar se eles podem ser eliminados ou reduzidos. 
Situações em que os modelos estão incompletos (por 
exemplo, ações duvidosas e decisões sem resposta) 
devem ser identificadas para assegurar que todos os 
caminhos tenham sido revisados corretamente. Filas de 
espera também devem ser revisadas para ver se são 
realmente necessárias e, caso o sejam, que tenham sido 
corretamente estabelecidas.
O tempo total do ciclo (lead time) também deve 
ser observado de perto. Para as ações individuais, a 
identificação daquelas que demandam maior tempo mostra 
onde uma redução do tempo de execução produzirá maior 
efeito. O tempo total de ciclo para os processos, unidades 
e tarefas também devem ser revisados, para determinar se 
medidas de sucesso baseadas no tempo podem ser de fato 
encontradas. De acordo com os tempos de ciclo, também 
devem ser revisados os caminhos críticos, para determinar 
onde podem ocorrer restrições de tempo.
Antes de finalizar o projeto, os indivíduos entrevistados 
para a montagem dos modelos devem fazer uma verificação 
final para assegurar que esses estejam corretos. O mesmo 
deve ser feito com qualquer supervisor ou gerente envolvido. 
Finalmente, deve ser obtida a validação do dono do processo. 
Esta discussão ajuda a identificar qualquer problema com o 
modelo e prepara o dono para o relatório final.
Apresentação
Exercícios do Capítulo 7 
1) Complete as sentenças:
A modelagem de processos não só é uma das exigências 
da ISO 9000 para a gestão da qualidade e garantia, como 
também é uma das questões chave na implementação da 
maioria dos sistemas de informação, como sistemas de 
gerenciamento de _______________________, ERP e _____
____________________________.
Damij (2007) divide as pesquisas e as práticas na área de 
modelagem de processos em três grupos. O segundo grupo 
de estudos trabalha com _____________________________
_________________________________________________
________________________________________________ .
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
63
Ao colocar juntas a definição do processo, a coleta de 
dados, as entrevistas, a geração do modelo e a análise, 
o resultado deve ser um relatório final. Este é o produto 
que o revisor trabalhou para construir e é o produto que 
a gerência deseja ver. Eventualmente, este relatório pode 
ser apresentado para o público interessado.
Segundo Jacka e Keller (2002), os passos que vão mudar 
o modelo para refletir a realidade é que o fazem efetivo. Estes 
passos são: 
a. _________________________________________
________________________________________________; 
b. coleta de dados (saber o que existe dentro do 
processo e quem está com ele envolvido); 
c. _________________________________________
________________________________________________; 
d. análise dos dados (verificar o que pode ser feito para 
melhorar o processo); 
e. _________________________________________
________________________________________________.
Na metodologia de entrevista, os modelos devem ser 
construídos em tempo real, através do uso da técnica de 
_____________________.
CONSIDERAÇÕES FINAIS
Caro aluno, a disciplina de Gestão da Qualidade com 
Ênfase em BPM agrega um importante conjunto de 
informações sobre como devemos administrar a qualidade 
nos processos de desenvolvimento de software. 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, 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 em seu processo 
de 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.
Assim, esperamos que você tenha aproveitado bastante 
este conteúdo e que esteja apto a começar a atuar nesta 
área, aprofundando mais e mais seus estudos! 
Parabéns por concluir esta disciplina. Continue a contar 
conosco!
Prof. José do Carmo Rodrigues
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
64
RESPOSTAS COMENTADAS DOS 
EXERCÍCIOS
Capítulo 1
1)	 Associe	 a	 definição	 de	 qualidade	 com	 a	
entidade ou pessoa que a criou:
• IEEE 610.12: qualidade pode ser definida como 
o grau no qual um sistema, componente, ou processo 
atende aos requisitos especificados e às necessidades ou 
expectativas do cliente ou usuário. 
• ISO/IEC 9126: define qualidade como a totalidade 
de funcionalidades e características de um produto ou 
serviço que atendem à sua capacidade desatisfazer 
necessidades específicas ou implícitas. 
• Roger Pressman (2006): é a conformidade com 
requerimentos e com características implícitas que são 
esperadas de software profissionalmente desenvolvido.
2)	 Qual	 o	 principal	 objetivo	 da	 garantia	 da	
qualidade?
O principal objetivo da garantia da qualidade é assegurar 
que padrões, procedimentos e políticas utilizados durante 
o desenvolvimento do software sejam adequados para 
prover o nível de confiança requerido para o processo ou 
produto de trabalho.
3) Qual destas não é uma característica para a 
qualidade de software?
c) é responsabilidade de apenas uma área da 
empresa: a área de qualidade
4) Qual a diferença entre qualidade de produto 
e qualidade de processo?
• Qualidade do produto de software refere-se ao 
software em si, que deve seguir as especificações para o 
qual foi desenvolvido. A qualidade de produto é a rigorosa 
definição das características relevantes do produto, 
estabelecendo os atributos e as variáveis que deve conter, 
cuja dimensão deve ser assegurada. A especificação é o 
documento que formalizará essas definições.
• Qualidade do processo de software diz respeito 
à qualidade das atividades e forma pelas quais se produz 
software. A qualidade de processo é a rigorosa especificação 
dos processos que serão realizados na produção de um 
bem ou serviço, incluindo as faixas de tolerância desejadas 
em relação aos resultados.
5)	 Assinale	V,	para	verdadeiro	e	F,	para	falso:
(V) Qualidade de software é a medida que um conjunto, 
definido pela indústria, de características desejáveis são 
incorporadas em um produto, de modo a aprimorar seu 
desempenho durante sua existência.
(V) Pode-se afirmar que o teste de software é uma das 
atividades de controle da qualidade, ou seja, o teste de 
software é orientado a produto e está dentro do domínio 
do controle da qualidade.
(F) Um dos modelos mais recentes (o certo é: um 
dos primeiros, ou seja, um dos mais antigos) modelos de 
qualidade de software é o de James A. McCall conhecido 
como Fatores da Qualidade, que avaliam o software em 
três pontos distintos: Operação do Produto, Transição do 
Produto e Revisão do Produto. 
(V) Qualidade Total é a preocupação com a 
qualidade em todas as atividades da empresa, buscando 
sistematicamente o nível “zero defeito”, através da 
melhoria contínua dos processos de produção.
6) Assinale QT- para qualidade total e CQ- para 
controle de qualidade.
(QT) Foco em monitoração e melhoria de processo.
(CQ) É orientado a produto e orientado à detecção. 
(QT) Garante que o processo é definido e apropriado.
(QT) É orientada a processo e orientada à prevenção.
(CQ) As atividades focam na descoberta de defeitos em 
itens específicos.
(CQ) As atividades são focadas no final das fases no 
ciclo de vida de desenvolvimento de software.
(QT) Garante que você está fazendo as coisas certas e 
da maneira correta. 
(CQ) Garante que os resultados do seu trabalho são os 
esperados conforme requisitos.
(QT) As atividades são focadas no inicio das fases no 
ciclo de vida de desenvolvimento de software.
(CQ) Inspeções e garantia de que o produto de trabalho 
atenda aos requisitos especificados.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
65
7) Adaptando-se o conceito de qualidade às 
fases do ciclo de vida do produto, podemos ter as 
seguintes categorias: 
A qualidade de projeto refere-se ao grau em que o 
produto, através de sua concepção e especificações, 
atende às características de qualidade desejadas pelo 
consumidor. A qualidade de conformação seria o grau 
em que o bem é produzido em conformidade com as 
especificações estabelecidas pelo projeto.
 A qualidade de serviços diz respeito às facilidades 
disponíveis para se assegurar a continuidade do produto 
em operação durante a etapa de seu consumo. Estas 
facilidades seriam assistência técnica, manutenção, 
orientação quanto ao uso do produto, etc. 
A qualidade de uso de um produto, também chamada 
qualidade final, resulta da soma e interação destas categorias. 
Capítulo 2
1)	 Analise	as	afirmativas	e	assinale	a	resposta	
correta:
i. A avaliação de produtos de software é definida 
como uma operação técnica que consiste em elaborar um 
julgamento de uma ou mais características de um produto 
de software de acordo com um procedimento definido.
ii. As normas da ISO que abordam a qualidade de 
produto (o certo é:processo) de software mais conhecidas 
são a norma ISO/IEC 12207 e a norma ISO/IEC 15504.
iii. 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.
c) Apenas i e iii estão corretas
2) As principais etapas são (complete):
• Estabelecimento dos requisitos da avaliação, onde 
os requisitos do software são recebidos e os requisitos da 
avaliação são definidos.
• Especificação da Avaliação, onde se utiliza a 
descrição do produto e os requisitos da avaliação para 
definir o que será contemplado na avaliação.
• Projeto da Avaliação, onde se agregam os dados 
utilizados na etapa anterior ao conhecimento de métodos 
de avaliação e projeta-se o Plano de Avaliação.
• Execução da Avaliação, onde se usam as 
ferramentas específicas para colocar o Plano de Avaliação 
em prática.
• Conclusão da Avaliação, onde o Relatório de 
Avaliação é emitido e todos os resultados obtidos são 
sintetizados e emite-se um parecer ao requisitante da 
avaliação.
Capítulo 3
1)	 Cite	 os	 benefícios	 que	 uma	 empresa	 pode	
obter	ao	adotar	a	norma	ISO/IEC	15504.
• 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.
2)	Assinale	V,	para	verdadeiro	e	F,	para	falso	nas	
afirmativas:
(F) Os processos da ISO/IEC 15504 (o certo é: ISO/IEC 
12207) são agrupados de acordo com sua natureza, ou 
seja, o seu objetivo principal no ciclo de vida de software. 
Este agrupamento resultou em 3 classes de processos: 
Processos Fundamentais, Processos de Apoio e Processos 
Organizacionais.
(F) A norma ISO/IEC 12207 (certo é ISO/IEC 15504) 
está associada ao projeto SPICE - Software Process 
Improvement and Capability dEtermination.
(V) Uma distinção entre nível 4 e nível 5 do CMMI é 
o tipo de variação de processo com que se lida. No nível 
4, processos estão preocupados com causas especiais de 
variação e fornecem estatística previsível de resultados. No 
nível 5, processos estão preocupados em lidar com causas 
comuns de variação e mudar o processo para melhorar 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
66
a performance de processo para alcançar os objetivos 
quantitativos estabelecidos para o melhoramento do 
processo.
(F) Organizações em níveis de maturidade CMMI 2 (o 
certo é: 1) geralmente produzem produtos e serviços que 
funcionam, entretanto, eles frequentemente excedem o 
prazo e o orçamento de seus projetos.
(V) No nível de maturidade CMMI 3, os processos 
são bem caracterizados e entendidos e são descritos 
como padrões, procedimentos, ferramentas e métodos. 
O conjunto de padrões de processos da organização é 
estabelecido e melhorado toda vez.
3)	 Complete	 a	 frase	 sobre	 representação	 no	
modelo CMMI:
Para a representaçãocontínua, usa-se o termo nível de 
capacidade ou ainda capacidade da área de processo. Ou 
seja, um nível de capacidade está relacionado a apenas 
uma área de processo. 
Para a representação por estágios, usa-se o termo nível 
de maturidade ou ainda a maturidade da organização. Ou 
seja, um nível de maturidade está relacionado a um grupo 
de áreas de processo. 
Capítulo 4
1) Complete as sentenças:
Os processos do MR-MPS são descritos em termos de 
propósitos e resultados: 
Os propósitos descrevem o objetivo geral a ser atendido 
durante a execução do processo
Os resultados do processo estabelecem os resultados a 
serem obtidos com a efetiva implementação do processo.
2)	 Assinale	V,	para-verdadeiro	e	F,	para	 falso	
nas	afirmações	sobre	o	MPS.BR:
(V) No modelo MPS.BR, um nível é alcançado quando os 
propósitos e todos os resultados esperados dos respectivos 
processos são atendidos. Os níveis são acumulativos.
(F) O nível mais baixo (o certo é: alto) do MPS.BR é o 
nível A, logo, o nível mais alto (o certo é: baixo) é o nível G.
(V) O nível de maturidade A é composto pelos níveis G, 
F, E, D, C e B acrescido do processo Análise de Causas de 
Problemas e Resolução.
( ) Adicionalmente, outro objetivo do MPS.BR é replicar 
o modelo na América do Norte (o certo é: América Latina), 
incluindo os Estados Unidos e Canadá, que apoiam o 
projeto.
(V) 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 15504 e é compatível com o modelo 
CMMI.
(F) Apesar do MPS.BR ser compatível com os padrões de 
qualidade aceitos internacionalmente, não se compromete 
em aproveitar a competência existente nos padrões e 
modelos de melhoria de processo já disponíveis.
(V) O modelo MPS baseia-se nos conceitos de 
maturidade e capacidade de processo para a avaliação 
e melhoria da qualidade e produtividade de produtos de 
software e serviços correlatos.
3) Faça uma comparação entre os modelos 
CMMI e MPS.BR, do seu ponto de vista.
O modelo CMMI é proprietário e envolve um 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 níveis 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. 
Os níveis de maturidade do CMMI variam do 1 ao 5 
e do MPS.BR variam do G ao A, sendo que, ao contrário 
do CMMI, o primeiro nível 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 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
67
desenvolvimento de software. Assim, há uma equivalência 
dos níveis de maturidade do CMMI e do MPS.BR. 
Capítulo 5
1) Complete as sentenças:
Os macroprocessos ou processos principais são 
processos que geralmente envolvem mais de uma função 
na estrutura organizacional e sua operação tem um 
impacto significativo no funcionamento da organização.
Dois dos principais benefícios que as organizações 
ganham com um sistema completamente integrado 
e implementado são: o alinhamento da estratégia 
empresarial e a infraestrutura de tecnologia na qual são 
construídos os negócios.
2)	 Assinale	V,	 se	 verdadeiro	e	 F,	 se	 falso	nas	
afirmações	sobre	o	MPS.BR:
(F) Entre as estratégias que falham, apenas 10% 
falham porque a empresa não conseguiu implementá-las 
corretamente, ou seja, não conseguiu fazer com que os 
processos espelhassem a estratégia”
(V) A realização de qualquer atividade de trabalho 
se dá através de um processo de negócio e este possui 
um ciclo de vida que passa necessariamente por quatro 
estágios: Captura, Reengenharia, Implementação e 
Melhoria Contínua.
(V) Para que um projeto de reengenharia de processos 
seja efetivo, o corpo executivo responsável pelo projeto 
deve repensar o negócio de forma completamente nova, 
desconsiderando a maneira tradicional de se executar 
cada atividade.
(F) Melhorar um processo implica em fazer grandes 
correções de curso, de forma a se fazer uma mudança 
radical.
(V) A Modelagem de Processos de Negócio (Business 
Process Modeling) é essencial para a reengenharia ou 
reestruturação de processos. Um dos papéis que ela 
abrange é capturar os processos existentes através da 
representação estruturada de suas atividades e elementos 
relacionados;
Capítulo 6
1) Complete as sentenças:
A importância do modelo de referência de workflow 
estabelecido pela WFMC incide no fato de que ele indica os 
elementos básicos necessários para que um sistema de TI 
possa ser considerado como um sistema de gerenciamento 
de workflow.
Os workflows de produção reúnem processos de 
negócios repetitivos e previsíveis, em que a ordenação 
e coordenação de tarefas podem ser automatizadas, tais 
como aprovação de empréstimos e seguros.
A implantação de um sistema de workflow obedece a 
um ciclo composto por cinco etapas:
a) Revisão do fluxo de trabalho atual;
b) Projeto do modelo do fluxo de informação do fluxo 
que se quer;
c) Programação do modelo de informação, com 
definição e detalhamento de cada um dos elementos nele 
contidos;
d) Implantação do workflow;
e) Atualização do modelo implantado.
McCready classifica os sistemas de workflow em três 
tipos básicos: ad hoc, administrativo e, de produção.
As especificações de workflow podem ser entendidas 
sob diferentes perspectivas. A perspectiva de controle 
de fluxo (ou processo) descreve atividades e sua ordem 
de execução através dos diferentes participantes, o que 
permite o controle de execução do fluxo, por exemplo, 
sequência, escolha, paralelismo e sincronização.
Geogakopoulos classifica os sistemas de workflow em 
um escala contínua, que possui num extremo os workflows 
orientados a humanos e no outro os workflows orientados 
a sistemas.
Capítulo 7
1)	 Complete	as	frases	abaixo:
A modelagem de processos não só é uma das exigências 
da ISO 9000 para a gestão da qualidade e garantia, como 
também é uma das questões chave na implementação da 
maioria dos sistemas de informação, como sistemas de 
gerenciamento de workflow, ERP e e-business.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
68
Damij (2007) divide as pesquisas e as práticas na área 
de modelagem de processos em três grupos. O segundo 
grupo de estudos trabalha com o desenvolvimento de 
técnicas existentes para modelagem de processo de 
negócio.
Segundo Jacka e Keller (2002), os passos que vão 
mudar o modelo para refletir a realidade é que o fazem 
efetivo. Estes passos são: 
a. identificação do processo (saber o que compõe o 
processo sob revisão); 
b. coleta de dados (saber o que existe dentro do 
processo e quem está com ele envolvido); 
c. entrevistas e geração do modelo (identificar e 
registrar as ações dentro do processo); 
d. análise dos dados (verificar o que pode ser feito 
para melhorar o processo); 
e. apresentação (mostrar para todos o que foi feito).
Na metodologia de entrevista, os modelos devem ser 
construídos em tempo real, através do uso da técnica de 
“post-its”.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
69
REFERÊNCIAS
BOEGH, J; HAUSEN, H. L.; WELZEL,D. A practioeners 
guide to evaluation of software. In Software 
engineering standards symposium. Brighton, England, 
Ago/1993.
CAVANO, J.P., MCCALL, J.A. A framework for the 
measurement of software quality. Proc. of the ACM 
Software Quality Assurance Workshop. pp. 133-139, nov. 
1978.
CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI®: 
guidelines for process integration and product 
improvement. Addison Wesley, 2003.
CORTADA, Antonio. Compreendendo os níveis de 
Maturidade e Capacidade do CMMI. 2009. Disponível 
em: http://www.ahcconsult.com/cmmi/compreendendo-
os-niveis-de-maturidade-e-capacidade-do-cmmi. Acesso 
em 20 jan. 2012.
CORTES, Mário. Modelos de qualidade de software. 
Campinas: Editora da Unicamp, 2001.
CRUZ, T. Workflow:	 a	 tecnologia	 que	 vai	
revolucionar processos. São Paulo: Atlas, 2000.
DAMIJ, N. Business process modeling using 
diagrammatic	 and	 tabular. In: Techniques Business 
Process Management Journal. v. 13, n. 7, p. 70-90. 2007.
DAVENPORT, T. H. Reengenharia de processos. Rio 
de Janeiro: Campos, 1994.
FITZPATRICK, Ronan.	Software	Quality:	definitions	
and strategic issues. 1996. Disponível em http://www.
comp.dit.ie/rfitzpatrick/papers/quality01.pdf. Acesso 18 
Jan. 2012.
GEORGAKOPOULOS, D.; HORNICK, M; SHET, A. An 
overview	 of	 workflow	 management:	 from	 process	
modeling	 to	 workflow	 automation	 infrastructure. 
Distribute and parallel databases. V. 3, n. 2, p. 119-153. 1995.
GEORGAKOPOULOS, D.; TSALGATIDOU, A. 
Technology	and	tools	 for	comprehensive	business	
process: lifecycle management. In: Proceedings of NATO 
Advanced Study Institute on Workflow. V. 164, Istambul, 
Turquia. 1997.
GONÇALVES, J. E. L. As empresas são grandes 
coleções de processos. In: Revista de Administração de 
Empresas. V. 40, n. 1, Jan/Mar 2000.
HAMMER, M. CHAMPY, J. Reengineering the 
Corporation. New York: Hammer Business, 1994.
HARRINGTON, H. J.; ESSELING, E. K. C. NIMWEGEN, 
H. V. Business	 process	 improvement	 workbook:	
documentation, analysis, design and management 
of	business	process	improvement. New York: McGraw 
Hill, 1997.
IPCC. Quality assurance and quality control. In: 
National Greenhouse gas inventories. Disponível em: 
http://www.ipcc-nggip.iges.or.jp/public/gp/english/8_QA-
QC.pdf. Acesso em: 30 mar. 2013.
ISO/IEC 9126. Information Technology – software 
product evaluation – quality characteristics and 
guidelines for their use. 1991.
ISO/IEC 12119. Tradução livre da primeira edição de 
06/11/1998. Disponível em http://www.insoft.softex.br/
home/copes/geqs/index.html. Acesso em: 20 Dez. 2011.
ISO/IEC 14598-5. Information Technology 
evaluation of software product part 5: process 
for evaluators. Disponível em: http://www.cse.dcu.ie/
essiscope/sm4/14598-5.html. Acesso em: 30 mar. 2013.
JACKA, J. M.; KELLER, P. J. Business process 
mapping: improving customer. In: Gestão Industrial. 
New York: John Wiley & Sons, 2002.
LARSON, E; LARSON, R. BPM: an analytical 
perspective. Disponível em: http://www.bpm.com/
featureRO.asp?featureId=174 Acesso em: 05 Jun. 2001
MARANHÃO, M; MACIEIRA, M. E. B. O processo nosso 
de	cada	dia:	modelagem	de	processos	de	trabalho. 
Rio de Janeiro: Qualitymark, 2004.
McCREADY, S. There is more than one kind of 
workflow	software. Computerworld. v. 26, Nov/1992.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
70
McCALL, James A. Quality Factors. 2002. Disponível em: 
http://onlinelibrary.wiley.com/doi/10.1002/0471028959.
sof265/full. Acesso em: 17 Jan. 2012.
NAWAR, KHAN. Best TQM practices guardians 
satisfaction index: a case study. Pakistanis first 
national conference on quality assurance in education. 
Conference Publication. Lahore, Pakistan: 2003.
OLIVEIRA, Camila S. Comparando CMMi x MPS. 
BR: as vantagens e desvantagens dos modelos de 
qualidade no Brasil. 2008. Disponível em: http://www.
camilaoliveira.net/Arquivos/Comparando%20CMMi%20
x%20MPS.pdf. Acesso em: 21 jan. 2012.
OULD, M. A. Business process management: a 
rigorous approach. Florida, USA: Meghan-Kiffer Press, 
2005.
PMI. Um	 guia	 de	 conhecimentos	 em	
gerenciamento de projetos - guia PMBoK. 2004.
PRESSMAN, Roger S. Engenharia de software. 7.ed. 
São Paulo: Pearson McGraw-Hill, 2010.
PRESSMAN, Roger S. Engenharia de software. 
6.ed. São Paulo: Pearson McGraw-Hill, 2006.
PFLEEGER, S. l. Engenharia de software: teoria e 
prática. São Paulo: Prentice Hall, 2004.
ROCHA. Processos de software. Disponível em 
http://www.lia.ufc.br/~eti/2003/menu/modulos/engsoft/
engsoftprocessodesoftwre.pdf 
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. 
Qualidade	de	Software:	Teoria	e	Prática. São Paulo: 
Prentice Hall, 2001. 
ROYCE, Walker. CMM vs. CMMI: from conventional 
to modern software management. 2002. Disponível 
em http://www.cdainfo.com/down/1-Desarrollo/CMM2.
pdf. Acesso em 20 jan. 2012.
SOFTEX. MPS.br	 -	 Melhoria	 de	 processo	 do	
software	brasileiro. 2009. Disponível em: http://www.
softex.br/mpsbr/_guias/guias/mps.br_guia_geral_2009.
pdf. Acesso em 18 nov. 2011.
SOMMERVILLE, Ian. Engenharia de Software. São 
Paulo: Addison-Wesley, 2007.
WEBER, K.C.; ROCHA, A.R.C.; NASCIMENTO, C.J. 
Qualidade e produtividade em software. São Paulo: 
Makron, 2001.
WEBER, K. C.; ROCHA, A.R.C. Nascimento, C. J. (Org.). 
Qualidade e produtividade em software. São Paulo: 
Makron, 2001.
WFMC – Workflow Management Coalition. Terminology 
& glossary. 1999. Disponível em: http://www.wfmc.org/
standards/docs/TC-1011_term_glossary_v3.pdf. Acesso 
em: 28 Mar. 2013.
WFMC – Workflow Management Coalition. The 
workflow	 reference	 model. 1995. Disponível em: 
http://www.wfmc.org/standards/docs/tc003v11.pdf. 
Acesso em: 28 Mar. 2013.manutenibilidade e portabilidade.
• No contexto de desenvolvimento de software, 
Rocha et al (2001) definem qualidade como um conjunto 
de características a serem satisfeitas em um determinado 
grau, de modo que o produto de software atenda às 
necessidades explícitas e implícitas de seus usuários e, 
de acordo com Pressman (2006), é a conformidade com 
requerimentos e com características implícitas que são 
esperadas de software profissionalmente desenvolvido.
Como podemos perceber, qualidade é um substantivo 
que pode ter muitos significados. Isso acontece pela 
forte ligação com as percepções das pessoas, que têm 
pensamentos e gostos diferentes. Então, a definição 
de Qualidade de Software estaria, também, fadada às 
percepções do ser humano?
A qualidade de software, assim como a qualidade ligada 
a outros produtos, está relacionada diretamente com as 
opiniões das pessoas, que neste caso, são representadas 
pelos clientes, usuários e envolvidos com o projeto de 
software.
No entanto, ainda não há regras definitivas que 
indiquem claramente como desenvolver produtos de 
software de qualidade, embora a qualidade do produto 
seja considerada fortemente dependente da qualidade 
e adequação de seu processo de desenvolvimento. Mas 
podemos elencar as seguintes características para a 
qualidade de software:
 está fortemente relacionada à conformidade com 
os requisitos
 caracteriza o grau de satisfação do cliente;
 não é responsabilidade de apenas uma área da 
empresa, e sim de todos
 deve estar presente desde o planejamento do 
software.
Além disto, a qualidade deve satisfazer um conjunto de 
diferentes pontos de vista:
•	 Usuário:
 Qualidade consiste na capacidade de satisfazer 
desejos... 
	 Qualidade é a adequação ao uso... 
•	 Valor:
	 Qualidade é o grau de excelência a um preço 
aceitável e o controle da variabilidade a um custo aceitável.
•	 Entrega:
 Um produto ou serviço produzido de acordo com 
as especificações, com custo competitivo, mas entregue 
fora do prazo, pode ser considerado de qualidade?
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
8
Atualmente, qualidade de software vem ganhando 
um grande foco nas empresas de TI, pois se percebeu 
que a qualidade não é um gasto e sim um investimento. 
E com a evolução constante da tecnologia, os clientes 
estão cada vez mais exigentes, o que também exige 
dos desenvolvedores muito mais cuidado na criação dos 
produtos de software. 
Qualidade de processo 
A qualidade no processo procura identificar a má 
qualidade o quanto antes, o que é feito pelo controle 
da conformidade à especificação, e corrigir o problema, 
evitando que continue o desperdício até o fim. Para garantir 
a conformidade à especificação ao longo do processo, 
é necessário especificar como executar atividades e 
seus resultados e controlar sistematicamente todo esse 
processo que irá atingir a qualidade. 
A qualidade de processo é a rigorosa 
especificação dos processos que serão 
realizados na produção de um bem ou 
serviço, incluindo as faixas de tolerância 
desejadas em relação aos resultados.
Aqui se deve levar em consideração a definição de 
qualidade como adequação ao uso. Por exemplo, pode-
se imaginar a existência de um cliente, que vai receber 
o bem ou serviço, cujas necessidades de uso precisam 
ser satisfeitas. Com o conceito de adequação ao uso, 
explicita-se que o produto deve cumprir as funções básicas 
que resolvem os problemas do cliente e, ao mesmo 
tempo, atender às características básicas como nível de 
desempenho, durabilidade, pouca manutenção e facilidade 
de uso, entre outras.
 É preciso, ainda, identificar e eliminar as fontes da má 
qualidade, mediante alterações apropriadas no processo, 
ou seja, nas especificações de suas atividades. Abaixo, 
listamos algumas perguntas que realçam essa perspectiva e 
apontam as consequências para os processos de produção: 
 Quem são os clientes visados?
 O que desejam e necessitam?
 O que tais necessidades significam para os 
produtos e processos?
 Quais características devem ter um produto/
serviço para satisfazê-las?
 Como fabricar esse produto ou prestar esse serviço?
Fonte:http://megafoneadm.blogspot.com.br/2011/04/conheca-seus-clientes-aprenda-ouvi-los.html
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
9
Com isso, vê-se que o conceito de adequação ao 
uso também se dirige para a qualidade no processo. 
A qualidade não pode ser alcançada apenas com a 
verificação de conformidade dos resultados parciais em 
pontos escolhidos do processo. A qualidade no processo é 
mais que isso. Exige que os processos sejam concebidos 
de forma a maximizar a produção de bens e serviços que 
atendam às especificações. 
Assim nasce a qualidade total. A preocupação 
é garantir qualidade em cada atividade realizada no 
processo de produção e evitar erros, de modo a produzir 
certo da primeira vez e até eliminar a necessidade de 
inspeções, as quais perdem sentido quando cada etapa 
entrega seus resultados sem defeitos para a etapa 
seguinte e se implanta um processo explícito para 
melhorar sistematicamente os processos, de modo a 
sempre aumentar a qualidade no processo.
Qualidade total
Os princípios da Qualidade Total estão fundamentados 
na Administração Científica de Frederick Taylor (1856-1915), 
no Controle Estatístico de Processos de Walter A. Shewhart 
(1891-1967) e na Administração por Objetivos de Peter 
Drucker (1909-2005). Seus primeiros movimentos surgiram e 
foram consolidados no Japão após o fim da II Guerra Mundial 
com os Círculos de Controle da Qualidade, sendo difundidos 
nos países ocidentais a partir da década de 1970.
Qualidade Total é a preocupação com a 
qualidade em todas as atividades da 
empresa, buscando sistematicamente o 
nível “zero defeito”, através da melhoria 
contínua dos processos de produção.
O termo TQM - Total Quality Management ou 
Gerenciamento da Qualidade Total, amplamente usado nas 
organizações, descreve uma abordagem para a melhoria 
da qualidade.
Os quatro elementos chave do TQM podem ser vistos 
na figura 1 e são descritos no que se segue.
Figura 1 - Elementos do Gerenciamento da Qualidade Total 
Fonte: http://mauricio.hernaski.com.br/blog/qualidade-do-produto-vs-
qualidade-do-processo-2/
• Customer Focus - Foco do Cliente: o objetivo é 
atingir a satisfação total do cliente. O foco do cliente inclui 
o estudo das necessidades e vontades do cliente, coleta 
de requisitos do cliente e a medição e gerenciamento da 
satisfação do cliente.
• Process Improvement - Melhoria de 
Processo: o objetivo é reduzir as variações de processo 
e atingir a melhoria da qualidade contínua. Este elemento 
inclui ambos os processos de negócio e o processo de 
desenvolvimento do produto. Através da melhoria de 
processo, a qualidade do produto será reforçada.
• Human Side of Quality - Lado Humano da 
Qualidade: o objetivo é criar a cultura de qualidade 
por toda a empresa. As áreas de foco incluem liderança, 
apoio da alta gerência, participação total de todos os 
colaboradores da empresa e outros fatores humanos, 
como sociais e psicológicos.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
10
• Metrics, Models, Measurement and Analysis 
-	Métricas,	Modelos,	Medições	e	Análises: o objetivo é 
direcionar a melhoria contínua em todos os parâmetros da 
qualidade por um sistema de medição orientado a metas.
Na organização moderna, portanto, qualidade significa 
simultaneamente adequação ao uso, conformidade às 
especificações e qualidade total no processo. Chega-se, 
assim, ao ponto que nos interessa. 
O processo de gerar as especificações de um produto 
chama-se desenvolvimento do produto. Por meio desse 
processo, necessidades e desejos do cliente, muitas 
vezes denominados requisitos, são transformados em 
especificações do produto e do processo. 
Tais especificações devem definir com rigor as 
características do produtoe do processo que permitirá 
reproduzi-las. Isso implica adequação das especificações 
ao ambiente operacional de produção ou aos requisitos 
relacionados à manufatura. Como outro objetivo explícito, 
permite ainda alcançar baixos custos unitários.
Há muita evidência apontando o alto impacto do 
projeto do produto sobre a qualidade e os custos do 
produto. Não há uma estimativa consensual desses 
números, mas é comum entre especialistas avaliar que 
60% a 80% dos custos unitários e da qualidade final do 
produto são estabelecidos no projeto, sobrando o restante 
para o processo de melhoria contínua. Assim, na essência 
da qualidade de produto está a qualidade do processo de 
produção. E ambas dependem de uma boa qualidade de 
projeto, sem a qual se corre o risco de não alcançar nível 
suficiente de adequação às necessidades do cliente.
As organizações têm de produzir produtos e serviços de 
qualidade, não mais como uma estratégia de diferenciação 
de mercado, mas como uma condição de preexistência. As 
empresas devem ter em mente a importância de juntar 
os conceitos de qualidade de processo e de projeto com 
qualidade total, e outras, a fim de obter a qualidade total 
do produto, utilizando padrões e um bom planejamento.
Leia o artigo: 
Introdução ao Modelo de Qualidade 
no Contexto SPB por Angela Maria Alves
“A Qualidade de Produto de Software está passando 
por uma evolução, antes estava ligada à funcionalidade 
e agora está ligada à confiabilidade. A Qualidade de 
um Produto de Software pode ser percebida por várias 
visões, como: 
• Pela visão do desenvolvedor. 
• Pela visão do responsável	
pelo desenvolvimento. 
• Pela visão do usuário	final.	
Para o usuário final, o interesse está, por exemplo, 
na utilização, no desempenho, ou seja em medidas 
externas de qualidade como: 
• Funções específicas estão disponíveis? 
• Qual é a confiabilidade do software e sua 
eficiência? 
• É facil de usar? 
• É facil para transferir para outro ambiente 
operacional? 
Para o desenvolvedor, o interesse está na qualidade 
de produtos intermediários, ou seja, verificando, se 
estão coerentes com as expectativas do usuário final. 
Para o responsável	 pelo	 desenvolvimento, o 
interesse está nos objetivos da comunidade, está em 
fazer o equilíbrio de melhoria de qualidade usando 
critérios como prazo e custo. 
A definição de Qualidade de Produto de Software está 
baseada na definição de características de interesse 
em função da àrea de aplicação desse produto. De 
acordo com a área de aplicação do produto, certas 
caracteristícas são mais desejáveis como: 
• Para aplicações de missão critica, a 
confiabilidade. 
• Para aplicações em tempo real, o desempenho. 
• Para aplicações interativas com o usuário não 
especializado, a usabilidade. 
• Para aplicações que mantêm informações 
sigilosas, a segurança. 
...”
Leia mais no link:
h t t p : / /www. so f twa repub l i c o . gov.b r / 5 cqua l i b r / xow i k i /
Introdu%E7%E3o%20ao%20Modelo%20de%20Qualidade%20
no%20Contexto%20SPB
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
11
conformidade dos insumos até suas especificações, 
evitando a cada fase a má qualidade. 
O ideal é que qualidade de produto seja aplicada em 
conjunto com a qualidade de processo. Para tornar isso 
viável, surgiram os sistemas formais da qualidade, como 
por exemplo, a série de normas produzidas pela ISO.
Qualidade e o ciclo de vida do produto
Há o conceito de ciclo de vida do produto vinculado 
ao aspecto satisfação das necessidades do cliente. Este 
conceito procura relacionar os níveis de venda com o 
tempo de maturação do produto e envolve as fases de 
lançamento, estagnação e declínio (ou criação, difusão e 
desuso). 
Mas o conceito de ciclo de vida do produto utilizado em 
Controle de Qualidade é o que apresentamos a seguir.
A qualidade final de um produto resulta 
de um conjunto de características 
imputadas a ele ao longo de todo o seu 
ciclo de vida, que envolve as fases de 
concepção, projeto, produção, distribuição e consumo 
do produto.
O uso genérico do termo qualidade para diferentes 
situações e etapas do ciclo de vida do produto dificulta o 
entendimento da questão da qualidade, uma vez que não 
se especifica a que tipo de qualidade, ou seja, à qualidade 
de qual fase do ciclo do produto está se referindo. 
Adaptando-se o conceito de qualidade às fases do ciclo 
de vida do produto, podemos ter as seguintes categorias: 
 Qualidade de projeto
 Qualidade de serviços 
 Qualidade de uso
A qualidade de projeto refere-se ao grau em que 
o produto, através de sua concepção e especificações, 
atende às características de qualidade desejadas pelo 
consumidor. A qualidade de conformação seria o grau 
em que o bem é produzido em conformidade com as 
especificações estabelecidas pelo projeto. 
Qualidade do produto
O certo é que a qualidade chegou para ficar, seja no 
trabalho, em casa, na produção de bens ou na prestação de 
serviços. Enfim, em qualquer atividade humana, a qualidade 
tornou-se consenso. Mas como chegamos a isto?
A qualidade, num primeiro momento, era vista 
fundamentalmente sob a ótica da inspeção, na qual, 
através de instrumentos de medição, tentava-se alcançar 
a uniformidade do produto. Posteriormente, passou-se a 
buscar, através de instrumentos e técnicas estatísticas, 
conseguir um controle estatístico da qualidade. Numa etapa 
posterior, o movimento da qualidade foi mais na direção 
de se encontrar instrumentos que visassem assegurar a 
sua própria garantia. Para isso, todo o processo produtivo 
passou a ser coordenado, desde o projeto do produto até 
a sua chegada ao mercado consumidor. 
Finalmente, a ênfase voltou-se para o gerenciamento 
estratégico da qualidade, no qual a preocupação maior é 
poder concorrer num determinado mercado, buscando-
se não só satisfazer as necessidades do consumidor, 
mas também a do próprio mercado. A metodologia que 
vai dar sustentação a essa nova mentalidade baseia-se 
no planejamento estratégico, no qual, sob a liderança da 
direção, todos na empresa passam a ter a oportunidade de 
serem também agentes da qualidade.
A qualidade de produto é a rigorosa 
definição das características relevantes do 
produto, estabelecendo os atributos e as 
variáveis que deve conter, cuja dimensão 
deve ser assegurada. A especificação é o documento 
que formalizará essas definições.
Há duas formas de se alcançar a conformidade de 
um produto à sua especificação. Uma é a inspeção 
final rigorosa que segrega os produtos sem qualidade. 
Essa é uma alternativa cara, já que espera o consumo 
de material, capital, mão de obra para, só ao final do 
processo produtivo, separar o bom produto. Gera imenso 
desperdício. A outra possibilidade é introduzir a qualidade 
ao longo do processo produtivo, desde a verificação da 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
12
A qualidade de serviços diz respeito às facilidades 
disponíveis para se assegurar a continuidade do produto em 
operação durante a etapa de seu consumo. Estas facilidades 
seriam assistência técnica, manutenção, orientação quanto 
ao uso do produto, etc. Na prática, estas categorias muitas 
vezes são confundidas. Assim não se faz muita distinção 
entre falhas decorrentes de um projeto deficiente e aquelas 
oriundas da falta de conformidade durante a produção.
A qualidade de uso de um produto, também chamada 
qualidade final, resulta da soma e interação destas 
categorias. Pode-se dizer que a qualidade de projeto 
está associada à qualidade inerente ao próprio produto, 
enquanto a qualidade de conformação está associada aos 
níveis de qualidade obtidos na produção, ou, em sentido 
inverso, aos níveis de defeituosos.
No processo de desenvolvimento de produtos, é 
importante que se promova o trabalho em equipe de forma 
concorrente, simultânea e colaborativa, reduzindo o ciclo de 
desenvolvimento do produto.Através da disseminação de poderes e responsabilidades 
aos indivíduos e às equipes, e da visibilidade plena de cada 
passo por trás do ciclo de vida, garante-se que o propósito 
do produto/serviço seja mantido e esteja alinhado à 
estratégia organizacional.
Se olharmos o ciclo de vida de um produto ou serviço, 
pode parecer que há somente dois pontos importantes, o 
momento de sua criação e o momento de sua renovação 
ou substituição. Ambos envolvem a inovação disruptiva. 
No entanto, entre estes dois momentos há um intervalo 
de tempo que requer ações permanentes de melhorias 
na qualidade, produtividade e custos, bem como para 
resolver os problemas que vão surgindo na produção, 
comercialização e distribuição do produto. Pela inovação, 
a empresa se diferencia de seus concorrentes e pela 
melhoria contínua, ela pode prolongar e ampliar suas 
vantagens competitivas. O gráfico 1 ilustra este processo.
Gráfico 1 – Ciclo de vida do produto e seus pontos importantes 
Fonte: http://afcomunica.wordpress.com/
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
13
Todos estes conceitos podem ser aplicados às empresas e equipes envolvidas no desenvolvimento de software. A 
tabela 1 faz uma comparação entre organizações imaturas e maturas, quanto às suas tomadas de decisões em assuntos 
relacionados à qualidade de software.
Tabela 1 – Maturidade das organizações quanto à qualidade 
Organização Imatura Organização Madura
Processos de software improvisados pelos 
participantes durante o curso do projeto.
Atividades planejadas de acordo 
com o processo existente.
Mesmo que um processo de software tenha 
sido especificado ele não é seguido.
Processo disciplinado é consistentemente seguido 
porque os participantes entendem o seu valor e 
existe a infraestrutura necessária para suportá-lo.
Gerentes focados em resolver problemas imediatos
Gerentes monitoram a qualidade 
do produto e do processo.
Cronogramas e orçamentos estourados e 
não baseados em estimativas realistas.
Cronogramas e orçamentos baseados 
em dados históricos e realísticos.
Quando prazos não realísticos são impostos 
à equipe de desenvolvimento, a qualidade e 
funcionalidade do produto saem comprometidas.
Processo definido atualizado quando necessário. As 
melhorias são descobertas através de testes pilotos 
controlados e da análise da relação custo/benefício.
Não há base para julgar a qualidade do produto ou 
para resolver problemas no processo ou produto.
Base quantitativa para julgar qualidade e para 
analisar problemas com o produto ou processo.
Qualidade do produto imprevisível.
Capacidade de gerenciar o desenvolvimento 
e manutenção dos processos e projetos.
Atividades que visam garantir a qualidade dos 
produtos (revisões e testes) são eliminadas 
quando o projeto está atrasado.
Papéis e responsabilidades estão 
claros dentro da organização.
Garantia da Qualidade
Podemos definir Garantia da Qualidade (Quality 
Assurance) como o conjunto de atividades de apoio 
para fornecer confiança de que os processos estão 
estabelecidos e são continuamente melhorados para 
produzir produtos que atendam as especificações e que 
sejam adequados para o uso pretendido. 
Portanto, garantir a qualidade consiste em obter a 
qualidade tanto do processo quanto do produto. No 
processo, podemos quantificar a sua qualidade através 
de métricas para qualidade e no produto com as técnicas 
de verificação e validação. Essas atividades podem ser, 
por exemplo, avaliações como as citadas pela ISO 9000, 
auditorias, inspeções formais, testes, revisões. Ainda 
no processo podemos usar os métodos de garantia da 
qualidade no formato de auditorias e relatos para a alta 
gerência, além de avaliações constantes do processo e 
análise estatística de controle do processo. No produto 
os métodos de garantia da qualidade são revisões, 
inspeção formal e testes, além de revisão dos resultados 
do teste realizada por profissionais altamente capacitados, 
auditorias do produto e testes realizados pelo cliente. 
Não podemos confundir os conceitos e a aplicação dos 
termos Controle da Qualidade (Quality Control) e Garantia 
da Qualidade (Quality Assurance). Embora usados 
erroneamente como sinônimos em muitos lugares, ambos 
os termos têm propósitos totalmente diferentes. Vejamos 
a tabela 2 a seguir que mostra a diferença entre estas duas 
atividades [IPCC, 2009].
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
14
Tabela 2 – Garantia da Qualidade x Controle da Qualidade
Garantia da Qualidade Controle da Qualidade
a) Garante que o processo é definido e apropriado.
b) Metodologia e padrões de desenvolvimento 
são exemplos de garantia da qualidade.
c) É orientada a processo.
d) É orientada à prevenção.
a) As atividades focam na descoberta 
de defeitos em itens específicos.
b) Um exemplo de controle da qualidade poderia ser: 
“Os requisitos definidos são os requisitos certos?”.
c) É orientado a produto.
d) É orientado à detecção.
e) Foco em monitoração e melhoria de processo.
f) As atividades são focadas no inicio das fases no 
ciclo de vida de desenvolvimento de software.
g) Garante que você está fazendo as 
coisas certas e da maneira correta.
e) Inspeções e garantia de que o produto de 
trabalho atenda aos requisitos especificados.
f) As atividades são focadas no final das fases no 
ciclo de vida de desenvolvimento de software.
g) Garante que os resultados do seu trabalho 
são os esperados conforme requisitos.
Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software 
é orientado a produto e está dentro do domínio do controle da qualidade.
Leia o que é a norma ISO 9000:
“...Em sua essência, a ISO 9000 é uma norma que visa estabelecer critérios para um adequado 
gerenciamento do negócio tendo como foco principal a satisfação do cliente e consumidor, através de uma série de 
ações. ... Ter um certificado ISO 9000 significa que uma empresa tem um sistema gerencial voltado para a qualidade 
e que atende aos requisitos de uma norma internacional....”
Disponível em: http://www.iso9000.com.br/basicas.htm
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
15
Exercícios do Capítulo 1 
1)	 Associe	 a	 definição	 de	 qualidade	 com	 a	
entidade ou pessoa que a criou:
______________________: qualidade pode ser 
definida como o grau no qual um sistema, componente, 
ou processo atende aos requisitos especificados e às 
necessidades ou expectativas do cliente ou usuário. 
______________________: define qualidade como 
a totalidade de funcionalidades e características de um 
produto ou serviço que atendem à sua capacidade de 
satisfazer necessidades específicas ou implícitas.
______________________: é a conformidade com 
requerimentos e com características implícitas que são 
esperadas de software profissionalmente desenvolvido.
2)	 Qual	o	principal	objetivo	da	garantia	da	
qualidade?
3) Qual destas não é uma característica para 
a qualidade de software?
a) está fortemente relacionada à conformidade 
com os requisitos
b) caracteriza o grau de satisfação do cliente
c) é responsabilidade de apenas uma área da 
empresa: a área de qualidade
d) deve estar presente desde o planejamento do 
software.
4) Qual a diferença entre qualidade de 
produto e qualidade de processo?
5)	 Assinale	V-verdadeiro	e	F-falso:
( ) Qualidade de software é a medida em que um 
conjunto, definido pela indústria, de características 
desejáveis são incorporadas em um produto, de modo 
a aprimorar seu desempenho durante sua existência.
( ) Pode-se afirmar que o teste de software é uma 
das atividades de controle da qualidade, ou seja, o 
teste de software é orientado a produto e está dentro 
do domínio do controle da qualidade.
( ) Um dos modelos mais recentes de qualidade 
de software é o de James A. McCall conhecido como 
Fatores da Qualidade, que avaliam o software em três 
pontos distintos: Operaçãodo Produto, Transição do 
Produto e Revisão do Produto. 
( ) Qualidade Total é a preocupação com a qualidade 
em todas as atividades da empresa, buscando 
sistematicamente o nível “zero defeito”, através da 
melhoria contínua dos processos de produção.
6) Assinale QT- para qualidade total e 
CQ- para controle de qualidade, mostrando as 
diferenças entre elas.
 
( ) Foco em monitoração e melhoria de processo.
( ) É orientado a produto e orientado à detecção. 
( ) Garante que o processo é definido e apropriado.
( ) É orientada a processo e orientada à prevenção.
( ) As atividades focam na descoberta de defeitos 
em itens específicos.
( ) As atividades são focadas no final das fases no 
ciclo de vida de desenvolvimento de software.
( ) Garante que você está fazendo as coisas certas 
e da maneira correta. 
( ) Garante que os resultados do seu trabalho são 
os esperados conforme requisitos.
( ) As atividades são focadas no inicio das fases no 
ciclo de vida de desenvolvimento de software.
( ) Inspeções e garantia de que o produto de 
trabalho atenda aos requisitos especificados.
7) Adaptando-se o conceito de qualidade às 
fases do ciclo de vida do produto, podemos ter as 
seguintes categorias: 
A ________________________ refere-se ao 
grau em que o produto, através de sua concepção 
e especificações, atende às características de 
qualidade desejadas pelo consumidor. A qualidade de 
conformação seria o grau em que o bem é produzido 
em conformidade com as especificações estabelecidas 
pelo projeto.
 A _________________________ diz respeito às 
facilidades disponíveis para se assegurar a continuidade 
do produto em operação durante a etapa de seu 
consumo. Estas facilidades seriam assistência técnica, 
manutenção, orientação quanto ao uso do produto, etc. 
A ________________________ de um produto, 
também chamada qualidade final, resulta da soma e 
interação destas categorias. 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
16
• Operação: se refere à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.
QUALIDADE DE PRODUTO DE 
SOFTWARE
Caro aluno, neste capítulo descreveremos o que é a qualidade 
de produto de software, mostraremos as normas e modelos 
que ditam as regras deste tipo de aplicação da qualidade, 
descreveremos os padrões de produtos e as formas de avaliação 
que apoiam a qualidade de produto.
Modelos de Qualidade de Software
Qualidade de software é um tema que vem sendo 
abordado e vem evoluindo há muito tempo em Engenharia 
e Arquitetura de Software, 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.
Organizações internacionais de normatização e 
padronização definiram qualidade de produto como: 
a totalidade dos recursos, aspectos e características de 
um produto ou serviço que suportam a sua capacidade 
de satisfazer os requisitos dados, as expectativas e as 
necessidades explícitas e implícitas.
Em seu estudo sobre qualidade de software, Software 
Quality: Definitions and Strategic Issues , o pesquisador 
Ronan Fitzpatrick (1996) propõe uma visão mais 
moderna e ousada de qualidade do produto de software, 
propondo a seguinte definição: Qualidade de software é a 
metodologia em que um conjunto definido pela indústria 
de características desejáveis é incorporado em um 
produto, de modo a aprimorar seu desempenho durante 
sua existência.
Um dos primeiros modelos de qualidade de software 
é o que James A. McCall (2002) sugere como métricas 
para qualidade de software. Conhecido como Fatores da 
Qualidade, estes fatores avaliam o software em três pontos 
distintos: Operação do Produto, Transição do Produto e 
Revisão do Produto.
Atualmente existem outros modelos de avaliação da 
qualidade do produto de software, que serão apresentados 
nos capítulos seguintes, mas que merece aqui apenas uma 
referência inicial.
Há o padrão internacional de Engenharia de Software da 
ISO- International Organization for Standardization / IEC- 
International Electro-Technical Commission, conhecido 
como ISO/IEC 9126, que trata da Qualidade do Produto. A 
norma se divide em quatro partes, 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 (conforme 
ilustra a figura 2):
 Parte 1: Modelo de qualidade
 Parte 2: Métricas externas
 Parte 3: Métricas internas
 Parte 4: Métricas de qualidade em uso 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
17
Figura 2 – Visão geral do modelo de qualidade ISO 9126
Fonte: http://edgarddavidson.com/?p=902
Vale ressaltar que qualidade do software abordada aqui 
se entende por qualidade do produto de software em si, o 
que é distinto de qualidade do processo de software, que 
diz respeito à qualidade das atividades e forma pelas quais 
se produz software.
Colocando-se todos esses conceitos dentro do contexto 
apresentado, podemos dizer que qualidade não é uma 
fase do ciclo de desenvolvimento de software, mas sim 
integrante fundamental de todas as fases. Portanto, 
é necessário um planejamento adequado para que a 
qualidade de software seja atingida, conforme a definição 
de qualidade que deverá ser alcançada. Para isso são 
necessários modelos, padrões, procedimentos e técnicas 
para atingir essas 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.
Assista ao filme que mostra a necessidade 
de uso de modelos de qualidade para 
os serviços oferecidos pelas empresas:
http://youtu.be/CIuDv6Qna-M
Qualidade externa diz respeito ao produto final como 
percebido pelo usuário, enquanto qualidade interna se 
refere à estrutura e às características do produto em seu 
projeto e construção.
Mais recentemente, desde 2005, as normas ISO/IEC 
9126 e a série ISO/IEC 14598, de avaliação de produto 
de software, têm sido integradas na nova série de normas 
ISO/IEC 25000 Software Engineering – conhecida como 
SQuaRE- Software product Quality Requirements and 
Evaluation, que tem 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
Além deste núcleo principal, o SQuaRE contempla 
extensões, que tratam de temas específicos, como ISO/
IEC 25051, SQuaRE COTS - Commercial Off-The-Shelf 
ou Requisitos para qualidade de produtos comerciais 
de prateleira, e ISO/IEC 2506n, SQuaRE CIF- Common 
Industry Format para usabilidade.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
18
Qualidade segundo o PMBOK
De acordo com o PMBoK - Project Management Body 
of Knowledge do PMI - Project Management Institute, na 
versão 2004, os processos de gerenciamento da qualidade 
do projeto detêm todas as atividades da organização 
executora que determinam as responsabilidades, os 
objetivos e as políticas de qualidade, de modo que o projeto 
atenda às necessidades que motivaram sua realização. 
Estes processos de gerenciamento desenvolvem o 
sistema de gerenciamento da qualidade através da política, 
dos procedimentos e dos processos de planejamento da 
qualidade, garantia da qualidade e controle da qualidade, 
com atividades de melhoria contínua dos processos 
conduzidas do início ao fim. Comisso os três principais 
processos são:
[1] Planejamento da Qualidade: Identificação 
dos padrões de qualidade relevantes para o projeto e 
determinação de como satisfazê-los.
[2] Garantia da Qualidade: Aplicação das atividades 
de qualidade planejadas e sistemáticas para garantir que 
o projeto emprega todos os processos necessários para 
atender aos requisitos.
[3] Controle da Qualidade: Monitoramento de 
resultados específicos do projeto a fim de determinar 
se eles estão de acordo com os padrões relevantes de 
qualidade e identificação de maneiras de eliminar as 
causas de um desempenho insatisfatório.
Há diversas semelhanças entre os conceitos usados no 
PMBoK e os conceitos da própria ISO. Com isso, é possível 
ainda relacionar estes três processos do PMBoK com as 
definições de qualidade de processo, qualidade de projeto, 
controle da qualidade, garantia da qualidade e arquitetura 
de software.
Neste contexto a arquitetura de software passa a ser 
de grande importância para a qualidade de um software. 
O software, de modo genérico, é uma entidade que se 
encontra em quase constante estado de mudança. As 
mudanças ocorrem por necessidade de corrigir erros 
existentes no software ou de adicionar novos recursos e 
funcionalidades. Igualmente, os sistemas computacionais 
(isto é, aqueles que têm software como um de seus 
elementos) também sofrem mudanças frequentemente. 
Essa necessidade evolutiva do sistema de software o torna 
‘não confiável’ e predisposto a defeitos, podendo causar 
atraso na entrega e com custos acima do estimado. 
Concomitante com esses fatos, o crescimento em tamanho 
e complexidade dos sistemas de software exige que os 
profissionais da área raciocinem, projetem, codifiquem e 
se comuniquem por meio de componentes de software. 
Como resultado, qualquer concepção ou solução de 
sistema passa então para o nível arquitetural, onde o foco 
recai sobre os componentes e relacionamentos entre eles 
num sistema de software.
Avaliação de Produtos de Software
Desenvolver software com qualidade tem sido um 
grande desafio do mercado atualmente. Cumprir prazos, 
atender aos requisitos do software, estimar custos e 
recursos, não são tarefas simples. É necessário um controle 
muito grande dos processos que envolvem a fabricação 
do software, desde a sua criação até a sua completa 
instalação no cliente. Um desafio ainda maior é conseguir 
identificar, ao final do processo de desenvolvimento, se o 
software atende aos requisitos funcionais e não funcionais 
pré-estabelecidos. Para tanto, vários investimentos foram 
realizados e processos de Avaliação de Produtos de 
Software foram desenvolvidos.
A avaliação de produtos de 
software é definida como uma 
operação técnica que consiste em 
elaborar um julgamento de uma ou 
mais características de um produto de 
software de acordo com um procedimento definido.
De acordo com Weber et al (2001) o processo de 
avaliação deve possuir quatro características principais: 
Repetível, Reprodutível, Imparcial e Objetivo. Além do 
objetivo principal de alcançar a qualidade, estas avaliações 
podem almejar a obtenção de certificações de qualidade 
que são adquiridas por meio da utilização de normas 
estabelecidas. A organização mais conhecida na área 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
19
de certificações de qualidade é a ISO, que promove o 
desenvolvimento de normas, testes e certificação, com o 
intuito de encorajar o comércio de bens e serviços. O INPI 
é uma autarquia federal criada em pela Lei n° 5648, de 
11 de Dezembro de 1970, sendo o órgão responsável pela 
concessão dos registros de marcas, patentes, modelos de 
utilidade e desenho industrial no Brasil.
A ISO- International Organization 
for Standardization é formada por 
representantes de 91 países, cada um 
representado por um organismo de normas, 
testes e certificação. Por exemplo, 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 de normas 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.
 Aproveite e assista ao vídeo que apresenta o 
papel da ISO, da família 9001 e as vantagens das 
certificações.
 
http://youtu.be/6yD5ExXTSsg
A ISO definiu, através da norma ISO 14598, 
macroprocessos de avaliação de qualidade de produtos de 
software. Estes macroprocessos podem ser instanciados para 
avaliação do produto por desenvolvedores, adquirentes ou 
agentes externos dependendo dos objetivos e infraestrutura 
da organização. A figura 3 mostra o processo proposto na 
ISO 14598-5 para avaliação por agentes externos. Cada fase 
descrita na figura 3 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, onde 
os requisitos do software são recebidos e os requisitos da 
avaliação são definidos;
 Especificação da Avaliação, onde se utiliza a 
descrição do produto e os requisitos da avaliação para 
definir o que será contemplado na avaliação;
 Projeto da Avaliação, onde se agregam os dados 
utilizados na etapa anterior ao conhecimento de métodos 
de avaliação e projeta-se o Plano de Avaliação;
 Execução da Avaliação, onde se usam as 
ferramentas específicas para colocar o Plano de Avaliação 
em prática;
 Conclusão da Avaliação, onde o Relatório de 
Avaliação é emitido e todos os resultados obtidos são 
sintetizados e emite-se um parecer ao requisitante da 
avaliação.
Figura 3- Processo de Avaliação de Software - ISO 14598-5
Fonte: http://www.diegomacedo.com.br/qualidade-de-produto-de-software/
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
20
As etapas “Estabelecimento dos requisitos da avaliação” 
e “Especificação da avaliação” são etapas cruciais da 
avaliação, pois é neste momento que precisamos definir 
o que será medido no software e quais são os níveis 
aceitáveis dessas medidas.
Essa definição não é uma tarefa fácil e além dessa 
dificuldade ainda enfrentamos o problema da imaturidade 
da indústria de software que veio se consolidar como 
indústria propriamente dita há menos de 50 anos. 
Bastante diferente da Engenharia, por exemplo, que 
já possui maturidade e padrões muito bem definidos e 
quantificáveis.
Modelo de Qualidade ISO 9126
Para que a avaliação seja mais efetiva é importante que 
se utilize um modelo de qualidade que permita estabelecer 
e avaliar requisitos de qualidade e também que o processo 
de avaliação seja bem definido e estruturado. Na norma 
ISO 14598 recomenda-se a utilização do modelo de 
qualidade proposto na ISO 9126, que é o mais difundido 
na indústria. Este modelo propõe a divisão da qualidade 
do produto de software em qualidade interna, externa e 
em uso. A norma 9126 foca na qualidade do produto de 
software, propondo atributos de qualidade, distribuídos em 
seis características principais, com cada uma delas divididas 
em sub-características, conforme podemos ver na figura 4.
Figura 4 - Modelo de Qualidade - ISO 9126
Fonte: http://www.diegomacedo.com.br/qualidade-de-produto-de-software/
No nível mais alto temos as características de qualidade 
e nos quadros de baixo as suas sub-características. Cada 
característica/sub-característica compõe um atributo de 
qualidade do software. Note que em todas as características 
temos uma subcategoria com o nome de Conformidade. A 
conformidade é utilizada para avaliar o quanto o software 
obedece aos requisitos de legislação e todo o tipo de 
padronização ou normalização aplicável ao contexto.
A seguir, serão apresentadas as sete características de 
qualidade da norma, em mais detalhes.
Funcionalidade
A capacidade de um software prover funcionalidadesque satisfaçam o usuário em suas necessidades declaradas 
e implícitas, dentro de um determinado contexto de uso. 
Suas sub-características são:
 Adequação, que mede o quanto o conjunto de 
funcionalidades é adequado às necessidades do usuário;
 Acurácia	(ou precisão) representa a capacidade 
do software de fornecer resultados precisos ou com a 
precisão dentro do que foi acordado/solicitado;
 Interoperabilidade que trata da maneira como o 
software interage com outro(s) sistema(s) especificado(s);
 Segurança mede a capacidade do sistema de 
proteger as informações do usuário e fornecê-las apenas 
(e sempre) às pessoas autorizadas;
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
21
Confiabilidade
O produto se mantém no nível de desempenho nas 
condições estabelecidas. Suas sub-características são:
 Maturidade, entendida como sendo a capacidade 
do software em evitar falhas decorrentes de defeitos no 
software;
 Tolerância a Falhas representando a capacidade 
do software em manter o funcionamento adequado mesmo 
quando ocorrem defeitos nele ou nas suas interfaces 
externas;
 Recuperabilidade que foca na capacidade de 
um software se recuperar após uma falha, restabelecendo 
seus níveis de desempenho e recuperando os seus dados;
Usabilidade
A capacidade do produto de software ser compreendido, 
seu funcionamento aprendido, ser operado e ser atraente 
ao usuário. Note que este conceito é bastante abrangente 
e se aplica mesmo a programas que não possuem uma 
interface para o usuário final. Por exemplo, um programa 
batch executado por uma ferramenta de programação 
de processos também pode ser avaliado quanto a 
sua usabilidade, no que diz respeito a ser facilmente 
compreendido, aprendido, etc. Além disto, a operação de 
um sistema é uma interface Humano-Computador sujeita 
às avaliações de usabilidade. Suas sub-características são:
 Inteligibilidade que representa a facilidade com 
que o usuário pode compreender as suas funcionalidades 
e avaliar se o mesmo pode ser usado para satisfazer as 
suas necessidades específicas;
 Apreensibilidade identifica a facilidade de 
aprendizado do sistema para os seus potenciais usuários;
 Operacionalidade é como o produto facilita a 
sua operação por parte do usuário, incluindo a maneira 
como ele tolera erros de operação;
 Atratividade envolve características que possam 
atrair um potencial usuário para o sistema, o que pode 
incluir desde a adequação das informações prestadas 
para o usuário até os requintes visuais utilizados na sua 
interface gráfica;
Eficiência
O tempo de execução e os recursos envolvidos são 
compatíveis com o nível de desempenho do software. 
Suas sub-características são:
 Comportamento em Relação ao Tempo que 
avalia se os tempos de resposta (ou de processamento) 
estão dentro das especificações;
 Utilização	 de	 Recursos que mede tanto os 
recursos consumidos quanto a capacidade do sistema em 
utilizar os recursos disponíveis;
Manutenibilidade
A capacidade (ou facilidade) do produto de software 
ser modificado, incluindo tanto as melhorias ou extensões 
de funcionalidade quanto às correções de defeitos, falhas 
ou erros. Suas sub-características são:
 Analisabilidade identifica a facilidade em se 
diagnosticar eventuais problemas e identificar as causas 
das deficiências ou falhas;
 Modificabilidade caracteriza a facilidade com 
que o comportamento do software pode ser modificado;
 Estabilidade avalia a capacidade do software 
de evitar efeitos colaterais decorrentes de modificações 
introduzidas;
 Testabilidade representa a capacidade de 
se testar o sistema modificado, tanto quanto as novas 
funcionalidades quanto as não afetadas diretamente pela 
modificação;
Portabilidade
A capacidade de o sistema ser transferido de um ambiente 
para outro. Como “ambiente”, devemos considerar todos 
os fatores de adaptação, tais como diferentes condições de 
infraestrutura (sistemas operacionais, versões de bancos 
de dados, etc.), diferentes tipos e recursos de hardware 
(tal como aproveitar um número maior de processadores 
ou memória). Além destes, fatores como idioma ou a 
facilidade para se criar ambientes de testes devem ser 
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
22
considerados como características de portabilidade. Suas 
sub-características são:
 Adaptabilidade, representando a capacidade de 
o software ser a adaptar a diferentes ambientes sem a 
necessidade de ações adicionais (configurações);
 Capacidade para ser Instalado identifica a 
facilidade com que pode se instalar o sistema em um novo 
ambiente;
 Coexistência mede o quão facilmente um 
software convive com outros instalados no mesmo 
ambiente;
 Capacidade	 para	 Substituir representa 
a capacidade que o sistema tem de substituir outro 
sistema especificado, em um contexto de uso e ambiente 
específicos. Este atributo interage tanto com adaptabilidade 
quanto com a capacidade para ser instalado;
Assista ao Webcast que traz alguns 
dos aspectos de qualidade de um software, 
maneiras de alcançá-la, e apresenta em 
alto nível norma NBR ISO/IEC 9126 que 
trata de atributos de qualidade de software.
http://www.youtube.com/watch?v=n8sAGdxmsaQ&feature=related
Exercícios do Capítulo 2 
1)	 Analise	 as	 afirmativas	 e	 assinale	 a	
resposta correta:
i. A avaliação de produtos de software é definida 
como uma operação técnica que consiste em elaborar 
um julgamento de uma ou mais características de um 
produto de software de acordo com um procedimento 
definido.
ii. As normas da ISO que abordam a qualidade de 
produto de software mais conhecidas são a norma ISO/
IEC 12207 e a norma ISO/IEC 15504.
iii. 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) Apenas i e ii estão corretas
b) Apenas ii e iii estão corretas
c) Apenas i e iii estão corretas
d) Todas estão corretas
2) A norma ISO 14598-5 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 
(complete):
__________________________________, onde os 
requisitos do software são recebidos e os requisitos da 
avaliação são definidos
__________________________________, onde 
se utiliza a descrição do produto e os requisitos da 
avaliação para definir o que será contemplado na 
avaliação
__________________________________, onde 
se agregam os dados utilizados na etapa anterior ao 
conhecimento de métodos de avaliação e projeta-se o 
Plano de Avaliação
__________________________________, onde se 
usam as ferramentas específicas para colocar o Plano 
de Avaliação em prática
___________________________________, onde o 
Relatório de Avaliação é emitido e todos os resultados 
obtidos são sintetizados e emite-se um parecer ao 
requisitante da avaliação.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
23
CMMI- QUALIDADE DE PROCESSO DE 
SOFTWARE
Caro aluno, neste capítulo descreveremos a qualidade 
de processo de software e mostraremos os modelos CMM e 
CMMi que definem regras de aplicação da qualidade. Também 
descreveremos os padrões de processos e as formas de avaliação 
que apoiam a qualidade de processo.
Modelos ISO para qualidade de processo 
de software
Um processo de software bem definido é muito 
importante, pois a partir dele, pode-se estabelecer um 
plano para o desenvolvimento do projeto. A qualidade 
de processo de software tem por objetivo aumentar a 
qualidade do produto reduzindo o retrabalho, obtendo maior 
produtividade e diminuindo o tempo de desenvolvimento. 
Esta prática certamente contribui para aumentar a 
competitividade das empresas de desenvolvimento que 
obtêm maior precisão nas estimativas de planejamento. 
Outros benefícios da qualidade incluem melhoriada 
satisfação do cliente e das condições de trabalho.
Práticas de qualidade 
são aplicadas a todas as 
etapas de desenvolvimento. 
De acordo com Cortes 
(2001), as normas ISO 
9001 foram desenvolvidas 
para aplicação em qualquer 
setor produtivo. Para 
facilitar sua aplicação em qualidade de software, a ISO 
desenvolveu o guia ISO 9000-3. Outra norma da ISO para 
aplicação em desenvolvimento de software é a ISO 12207, 
que trata dos processos de ciclo de vida de software. 
A abordagem dessas normas da série ISO é 
fundamentada nos preceitos da documentação do sistema 
de qualidade que estabelece a visão da empresa com 
relação aos interesses e necessidades dos clientes e, por 
isso, resulta na percepção desses. A abordagem da ISO 
para qualidade é considerada uma das mais antigas e bem 
estabelecidas para a indústria em geral e vem ganhando 
espaço nas empresas de software.
Na norma ISO/IEC 12207, os processos que 
envolvem o ciclo de vida de software são agrupados em 
classes que representam sua natureza. Cada processo é 
definido em termos de suas próprias atividades e cada 
uma é adicionalmente definida em termos de suas tarefas. 
Esta norma é flexível do ponto de vista da Engenharia 
de Software podendo ser usada em qualquer método ou 
técnica da área, qualquer modelo de ciclo de vida (cascata, 
incremental, evolutivo, etc.) e quaisquer linguagens de 
programação. Implementa os princípios de gerência de 
qualidade executando três etapas básicas: integração 
de qualidade no ciclo de vida, processo de garantia de 
qualidade e processo de melhoria.
A norma ISO/IEC 9000-3 estabelece um guia para 
facilitar a aplicação da ISO/IEC 9001 para desenvolvimento, 
suporte e manutenção de software. A ISO/IEC 9001 é um 
padrão internacional que especifica requisitos para um 
sistema gerencial de qualidade de uma organização, o 
que dificulta adaptação da norma para software, pois é 
aplicada a qualquer organização.
Fon t e : h t t p : / /www. s i n f i c . p t / S i n f i cWeb /d i s p l a y con t eudo .
do2?numero=24340 icada a qualquer organização.
A norma ISO/IEC 15504 está sendo desenvolvida 
desde 1993, mas em outubro de 2003 foi oficialmente 
publicada como norma para a avaliação de processos de 
software. A norma é desenvolvida pela ISO em conjunto 
com a comunidade internacional através do projeto 
SPICE - Software Process Improvement and Capability 
determination com base em modelos já existentes como 
ISO 9000-3 e CMM.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
24
Modelos CMM para qualidade de 
processo de software
O CMM é uma 
marca registrada 
do SEI- Software 
E n g i n e e r i n g 
Institute sediado na Universidade Carnegie Mellon, em 
Pittsburgh, EUA.
Este modelo é construído a partir do conceito de 
processo. Na medida em que a maturidade dos processos 
de software evolui em uma empresa, os processos passam 
a ser mais definidos e efetivos. 
A abordagem de qualidade conhecida 
como CMM – Capability	 Maturity	
Model pode ser definida como um 
conjunto de melhores práticas para 
diagnóstico e avaliação de maturidade do 
desenvolvimento de software em uma empresa. 
O CMM está organizado em cinco níveis crescentes de 
maturidade. Cada nível de maturidade agrega áreas-chave 
de um processo de software. Cada área-chave é detalhada 
nas práticas-chave a serem cumpridas na implantação 
do modelo. Estas práticas-chave especificam o que deve 
ser feito, exigindo documentos, treinamentos ou políticas 
definidas para atividades, mas nunca especificam o modo 
como devem ser implementadas. Cada área possui um 
conjunto de metas que, se satisfeitas rotineiramente, 
tendem a aumentar a capacitação do processo em produzir 
resultados previsíveis, assegurando a qualidade.
O CMM fornece e descreve um caminho de melhoria 
evolutiva a partir de um processo ad hoc para um processo 
maduro e altamente disciplinado. Na figura 5 são ilustradas 
as 5 etapas de maturação de processo de desenvolvimento 
de software segundo o CMM.
Figura 5 – Níveis de maturidade do modelo CMM
Fonte: http://www.followscience.com/wiki/science/capability-maturity-model-cmm-16
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
25
O modelo CMM é comparável com a família ISO 
9001, em particular com a norma 9000-3. Uma empresa 
certificada em ISO pode satisfazer a determinadas áreas-
chave do CMM, notadamente do nível 2 e 3. Também é 
possível existir empresas que estejam no nível 1 do CMM 
que consigam certificação ISO 9001. É muito provável que 
uma empresa que obtenha e mantenha um certificado ISO 
9001 tenha maturidade medida no nível 2 da escala CMM. 
Para uma empresa nível 3 CMM conseguir certificação 
da série ISO 9001 deve atender a alguns requisitos a 
mais desta norma, mas uma empresa nível 2 não deve 
encontrar muitas dificuldades em satisfazer os requisitos 
da ISO 9001.
CMM versus CMMI
De acordo com Royce (2002), o modelo inicial CMM 
foi desenvolvido pela SEI e 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 apresentam problemas como sobreposições, 
inconsistências e dificuldades de integração. Muitas 
organizações também encontram conflitos em processos 
de auditoria e programas de melhoria de software entre 
os modelos CMM e as normas ISO 9001.
Alguns casos associados com a prática CMM mostraram 
sintomas do modelo tradicional em cascata, com processos 
excessivamente baseados em gerenciamento. Isto acabou 
por ligar organizações baseadas no CMM aos princípios 
de mentalidade de cascata, dando-lhes uma conotação 
negativa.
A disseminação das técnicas de desenvolvimento 
iterativo, das melhores práticas da indústria de software, 
e as implicações econômicas, passou a motivar as 
organizações a adotar uma abordagem baseada em 
resultados. O CMMI integra muitas das melhores práticas 
da indústria moderna, desencorajando padrões de 
alinhamento com mentalidade de cascata, fazendo deste 
um melhor padrão a ser seguido.
CMMI
O CMMI – Capability	
Maturity Model Integration 
também foi desenvolvido pelo 
SEI. O SEI é um centro de 
pesquisa e desenvolvimento 
criado em 1984 pelo 
Departamento de Defesa dos Estados Unidos e é 
patrocinado pelo OUSD- Office of the Under Secretary of 
Defense for Acquisition and Technology. O SEI tem por 
missão aprimorar a prática de Engenharia de Software e 
atua nas áreas de capacitação de gerência de software, 
tecnologia para a engenharia e aptidão para a transição. 
O SEI focaliza a transição tecnológica, ou seja, o 
desenvolvimento e a adoção das melhores práticas de 
Engenharia de Software.
Como outros modelos CMM, os modelos CMMI fornecem 
um guia a ser usado para o desenvolvimento de processos. 
Os processos usados em uma organização dependem de 
muitos fatores, incluindo domínios de aplicação e estrutura 
e tamanho da organização. No que se segue o CMMI será 
apresentado em detalhes.
O projeto CMMI foi desenvolvido para fornecer um guia 
que encoraja o melhoramento de processos em organizações 
de qualquer estrutura. Desde 1991, modelos de maturidade 
foram desenvolvidos para as mais diversas disciplinas. 
Algumas das mais notáveis incluem modelos para engenharia 
de sistemas, engenharia de software, aquisição de software, 
gerenciamento de workforce e desenvolvimento, e produto 
integrado e desenvolvimento de processo.
Apesar de esses modelos terem inquestionável utilidade 
em muitas organizações, o uso de múltiplos modelos 
tem sido problemático. Muitas organizações gostariam 
de direcionar seus esforços de melhoramento através 
de suas disciplinas. Entretanto, as diferenças entre os