Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

Gestão da Qualidade
com ênfase em BPM
José do Carmo Rodrigues
Elisamara de Oliveira
João Caldas Junior
1
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

2
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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
Sumário 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

3
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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
Sumário 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

4
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

Apresentação Você terá, além dos fundamentos teóricos, a possibilidade

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

desenvolvimento, auxiliam na definição de prazos e tendem de software, mostraremos a importância da aplicação destes
conceitos no cenário atual de software com qualidade e
a evitar imprevistos. Os modelos de qualidade propõem
exemplificaremos alguns dos principais problemas da qualidade
a utilização de práticas e normatização de processos de
no que se refere ao desenvolvimento de sistemas.
desenvolvimento objetivando a construção de um produto
com qualidade
Conceitos Fundamentais de Qualidade
Por outro lado, as organizações vêm buscando realizar
Caro aluno, todos nós somos influenciados por produtos
a sua gestão por processos, embora muitos departamentos
de software tanto profissionalmente como em nossa vida
desenvolvam projetos. Administrar projetos e processos
pessoal, seja de forma consciente ou não. Os produtos de
transfuncionais não é uma tarefa fácil. Entender como
software possuem um papel muito influente em nossa vida,
funcionam os processos e quais são os tipos existentes
facilitando a realização de diversas atividades e provendo
é importante para determinar como eles devem ser
inúmeros serviços. Para quem trabalha no desenvolvimento
gerenciados para a obtenção do máximo resultado. As
destes sistemas, incluindo todos os profissionais da área
organizações têm percebido cada vez mais que os
de Engenharia de Software, o maior desafio é criar um
seus processos de negócio lhes oferecem vantagens
produto de software com elevada produtividade, dentro
competitivas. Diante dessa tendência, vem crescendo no
do prazo estabelecido, sem necessitar de mais recursos do
meio empresarial a prática do Gerenciamento de Processos
que aqueles alocados, assegurando com isso um software
de Negócio ou BPM- Business Process Management como
de qualidade.
uma forma de gerenciamento e controle das organizações.
A implementação efetiva de uma solução de BPM requer
Apesar do reconhecimento em relação às facilidades que
elementos estratégicos e de tecnologia, mas pode resultar
os produtos de software nos proporcionam, notadamente
em importantes benefícios como o alinhamento da
na área financeira e de telecomunicações, ainda há muito
estratégia empresarial e da infraestrutura de tecnologia na
que melhorar na qualidade dos produtos de software
qual são construídos os negócios.
desenvolvidos.

Diante disso, caro aluno, nós lhe convidamos a

Neste contexto, a aplicação eficaz e eficiente da
conhecer o mundo da TI através dos olhos da Qualidade
Engenharia de Software é fundamental para aprimorar
de Software e do BPM. Os aspectos teóricos e os
a qualidade dos produtos desenvolvidos, diminuindo os
conceitos da Qualidade de Software são mesclados com
custos de desenvolvimento do produto e aumentando a
a definição, modelagem e implementação de processos
produtividade e o tempo de atendimento ao mercado.
interconectados e transformados em ações do dia-a-dia.

5
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
6
Fonte: http://www.desenvolvatec.com/
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
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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, 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?
7
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)
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.
Fonte:http://megafoneadm.blogspot.com.br/2011/04/conheca-seus-clientes-aprenda-ouvi-los.html
8
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?
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

Com isso, vê-se que o conceito de adequação ao

Qualidade Total é a preocupação com a
uso também se dirige para a qualidade no processo.
qualidade em todas as atividades da
A qualidade não pode ser alcançada apenas com a
empresa, buscando sistematicamente o
verificação de conformidade dos resultados parciais em
nível “zero defeito”, através da melhoria
pontos escolhidos do processo. A qualidade no processo é
contínua dos processos de produção.
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. O termo TQM - Total Quality Management ou
Gerenciamento da Qualidade Total, amplamente usado nas
Assim nasce a qualidade total. A preocupação organizações, descreve uma abordagem para a melhoria
é garantir qualidade em cada atividade realizada no da qualidade.
processo de produção e evitar erros, de modo a produzir
certo da primeira vez e até eliminar a necessidade de Os quatro elementos chave do TQM podem ser vistos
inspeções, as quais perdem sentido quando cada etapa na figura 1 e são descritos no que se segue.
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.
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.

9
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
• 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 produto e 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.
10
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 : / / w w w . s o f t w a r e p u b l i c o . g o v. b r / 5 c q u a l i b r / x o w 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)

Qualidade do produto conformidade dos insumos até suas especificações,

evitando a cada fase a má qualidade.
O certo é que a qualidade chegou para ficar, seja no
trabalho, em casa, na produção de bens ou na prestação de O ideal é que qualidade de produto seja aplicada em
serviços. Enfim, em qualquer atividade humana, a qualidade conjunto com a qualidade de processo. Para tornar isso
tornou-se consenso. Mas como chegamos a isto? viável, surgiram os sistemas formais da qualidade, como
por exemplo, a série de normas produzidas pela ISO.
A qualidade, num primeiro momento, era vista
fundamentalmente sob a ótica da inspeção, na qual,
Qualidade e o ciclo de vida do produto
através de instrumentos de medição, tentava-se alcançar
a uniformidade do produto. Posteriormente, passou-se a
Há o conceito de ciclo de vida do produto vinculado
buscar, através de instrumentos e técnicas estatísticas,
ao aspecto satisfação das necessidades do cliente. Este
conseguir um controle estatístico da qualidade. Numa etapa
conceito procura relacionar os níveis de venda com o
posterior, o movimento da qualidade foi mais na direção
tempo de maturação do produto e envolve as fases de
de se encontrar instrumentos que visassem assegurar a
lançamento, estagnação e declínio (ou criação, difusão e
sua própria garantia. Para isso, todo o processo produtivo
desuso).
passou a ser coordenado, desde o projeto do produto até
a sua chegada ao mercado consumidor.
Mas o conceito de ciclo de vida do produto utilizado em
Controle de Qualidade é o que apresentamos a seguir.
Finalmente, a ênfase voltou-se para o gerenciamento
estratégico da qualidade, no qual a preocupação maior é
A qualidade final de um produto resulta
poder concorrer num determinado mercado, buscando-
de um conjunto de características
se não só satisfazer as necessidades do consumidor,
imputadas a ele ao longo de todo o seu
mas também a do próprio mercado. A metodologia que
ciclo de vida, que envolve as fases de
vai dar sustentação a essa nova mentalidade baseia-se
concepção, projeto, produção, distribuição e consumo
no planejamento estratégico, no qual, sob a liderança da
do produto.
direção, todos na empresa passam a ter a oportunidade de
serem também agentes da qualidade.
O uso genérico do termo qualidade para diferentes
situações e etapas do ciclo de vida do produto dificulta o
A qualidade de produto é a rigorosa
entendimento da questão da qualidade, uma vez que não
definição das características relevantes do
se especifica a que tipo de qualidade, ou seja, à qualidade
produto, estabelecendo os atributos e as
de qual fase do ciclo do produto está se referindo.
variáveis que deve conter, cuja dimensão
Adaptando-se o conceito de qualidade às fases do ciclo
deve ser assegurada. A especificação é o documento
de vida do produto, podemos ter as seguintes categorias:
que formalizará essas definições.
 Qualidade de projeto
 Qualidade de serviços
Há duas formas de se alcançar a conformidade de
 Qualidade de uso
um produto à sua especificação. Uma é a inspeção
final rigorosa que segrega os produtos sem qualidade.
A qualidade de projeto refere-se ao grau em que
Essa é uma alternativa cara, já que espera o consumo
o produto, através de sua concepção e especificações,
de material, capital, mão de obra para, só ao final do
atende às características de qualidade desejadas pelo
processo produtivo, separar o bom produto. Gera imenso
consumidor. A qualidade de conformação seria o grau
desperdício. A outra possibilidade é introduzir a qualidade
em que o bem é produzido em conformidade com as
ao longo do processo produtivo, desde a verificação da
especificações estabelecidas pelo projeto.

11
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
Gráfico 1 – Ciclo de vida do produto e seus pontos importantes
Fonte: http://afcomunica.wordpress.com/
12
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.
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
Processos de software improvisados pelos
participantes durante o curso do projeto.
Mesmo que um processo de software tenha
sido especificado ele não é seguido.
Gerentes focados em resolver problemas imediatos
Cronogramas e orçamentos estourados e
não baseados em estimativas realistas.
Quando prazos não realísticos são impostos
à equipe de desenvolvimento, a qualidade e
funcionalidade do produto saem comprometidas.
Não há base para julgar a qualidade do produto ou
para resolver problemas no processo ou produto.
Qualidade do produto imprevisível.
Atividades que visam garantir a qualidade dos
produtos (revisões e testes) são eliminadas
quando o projeto está atrasado.
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
13
Organização Madura
Atividades planejadas de acordo
com o processo existente.
Processo disciplinado é consistentemente seguido
porque os participantes entendem o seu valor e
existe a infraestrutura necessária para suportá-lo.
Gerentes monitoram a qualidade
do produto e do processo.
Cronogramas e orçamentos baseados
em dados históricos e realísticos.
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.
Base quantitativa para julgar qualidade e para
analisar problemas com o produto ou processo.
Capacidade de gerenciar o desenvolvimento
e manutenção dos processos e projetos.
Papéis e responsabilidades estão
claros dentro da organização.
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)

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. e) Inspeções e garantia de que o produto de

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

14
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
15
pontos distintos: Operação do 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)
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
padronização definiram qualidade de produto como:
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
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
e distintos: Operação do Produto, Transição do Produto e
Revisão do Produto.
• 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.
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
16
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

Figura 2 – Visão geral do modelo de qualidade ISO 9126

Fonte: http://edgarddavidson.com/?p=902

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

Além deste núcleo principal, o SQuaRE contempla de uso de modelos de qualidade para
extensões, que tratam de temas específicos, como ISO/ os serviços oferecidos pelas empresas:
IEC 25051, SQuaRE COTS - Commercial Off-The-Shelf
ou Requisitos para qualidade de produtos comerciais http://youtu.be/CIuDv6Qna-M

de prateleira, e ISO/IEC 2506n, SQuaRE CIF- Common

Industry Format para usabilidade.

17
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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. Com isso 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
18
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)
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
Figura 3- Processo de Avaliação de Software - ISO 14598-5
Fonte: http://www.diegomacedo.com.br/qualidade-de-produto-de-software/
19
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.
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
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.
20
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.
Funcionalidade
A capacidade de um software prover funcionalidades
que 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)
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;
21
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)
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.
22
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.

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 melhoria da
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.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
Fo n t e : h tt p : / / w w w. s i n f i c . p t / S i n f i c We b / d i s p l ayc o n t e u d o.
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.
23
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

O CMM está organizado em cinco níveis crescentes de

Modelos CMM para qualidade de
maturidade. Cada nível de maturidade agrega áreas-chave
processo de software de um processo de software. Cada área-chave é detalhada
nas práticas-chave a serem cumpridas na implantação
O CMM é uma
do modelo. Estas práticas-chave especificam o que deve
marca registrada
ser feito, exigindo documentos, treinamentos ou políticas
do SEI- Software
Engineering definidas para atividades, mas nunca especificam o modo
Institute sediado na Universidade Carnegie Mellon, em como devem ser implementadas. Cada área possui um
Pittsburgh, EUA. conjunto de metas que, se satisfeitas rotineiramente,
tendem a aumentar a capacitação do processo em produzir
Este modelo é construído a partir do conceito de resultados previsíveis, assegurando a qualidade.
processo. Na medida em que a maturidade dos processos
de software evolui em uma empresa, os processos passam O CMM fornece e descreve um caminho de melhoria
a ser mais definidos e efetivos. evolutiva a partir de um processo ad hoc para um processo
maduro e altamente disciplinado. Na figura 5 são ilustradas
A abordagem de qualidade conhecida as 5 etapas de maturação de processo de desenvolvimento
como CMM – Capability Maturity de software segundo o CMM.
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.

Figura 5 – Níveis de maturidade do modelo CMM

Fonte: http://www.followscience.com/wiki/science/capability-maturity-model-cmm-16

24
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
25
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
modelos 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)

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

(1) Capability Maturity Model for Software (SW-CMM)

v2.0 draft C
Visão geral do modelo CMMI
(2) Electronic Industries Alliance Interim Standard
O CMMI atualmente está organizado em três modelos
(EIA/IS) 731,
(veja figura 6), chamados de constelação, cada um contendo
(3) Integrated Product Development Capability Maturity
práticas para áreas de desenvolvimento (CMMI-DEV),
Model (IPDCMM) v0.98
serviços (CMMI-SVC) e de aquisição (CMMI-ACQ):

Desenvolver um conjunto de modelos integrados

• CMMI for Development (CMMI-DEV): voltado
envolve mais do que uma simples união de materiais de
ao processo de desenvolvimento de produtos e serviços.
modelos existentes. Usando processos que promovem
• CMMI for Acquisition (CMMI-ACQ): voltado
consenso, o grupo de produto CMMI construiu um
aos processos de aquisição e terceirização de bens e
arcabouço que acomoda múltiplas disciplinas e é bastante
serviços.
flexível para apoiar duas representações diferentes: por
• CMMI for Services (CMMI-SVC): voltado aos
estágio e contínuo.
processos de empresas prestadoras de serviços.

A missão do grupo incluiu o desenvolvimento de um

A organização pode usar um modelo CMMI para ajudar
arcabouço comum para apoiar a futura integração de
a estabelecer objetivos e prioridades do melhoramento de
outros modelos CMMI de disciplinas específicas e garantir
processos, obtendo um guia para garantir estabilidade,
a consistência e compatibilidade de produtos desenvolvidos
processos estáveis e maduros.
com ISO/IEC 15504 para avaliação de processo de software.

Como mostra a figura 6, o modelo CMMI v1.2 contém

O grupo de produto CMMI avaliou mais de 3.000
22 áreas de processo. Dessas áreas de processos, dezesseis
requisições de mudanças para criar a versão 1.0.
são áreas de processo principal, uma é uma área de
Pouco tempo depois, a versão 1.02 (2002) foi lançada
processo comum e cinco são áreas de processo específicas
incorporando diversos melhoramentos menores. A versão
1.1 (2003) acomodou mais melhoramentos, incorporando do desenvolvimento.

Figura 6 – Modelos CMMI

Fonte: http://www.teclogica.com.br/blog/?p=508

26
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
27
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)
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.
Como vimos, o modelo CMMI apresenta dois caminhos
a serem seguidos:
 Contínuo: permite que a organização evolua de
forma incremental os processos correspondentes a uma
á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.
28
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)
Tabela 3- Níveis de capacidade da representação contínua
Nível de Representação Contínua
Capacidade 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
Figura 7 – Níveis de maturidade do CMMI
Fonte: http://www.isdbrasil.com.br/o-que-e-cmmi.php
29
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.
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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
Nível de Maturidade 3
Nível de Maturidade 4
Nível de Maturidade 5
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
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)
Desempenho do Processo Organizacional
Gerência Quantitativa do Projeto
Inovação e Deploy Organizacional
Análise e Resolução de Causas

O nível de maturidade de uma organização fornece Um nível de maturidade é um patamar evolutivo de

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

30
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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 geralmente
produzem 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,
31
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)
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.
32
 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)

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

• Nível de Maturidade 4: Gerenciado

No nível 5, uma organização alcançou todas as metas

No nível de maturidade 4, uma organização alcançou
específicas das áreas de processo determinadas para os
todas as metas específicas das áreas de processo
níveis 2, 3, 4 e 5 e metas genéricas determinadas para
determinadas para os níveis de maturidade 2, 3 e 4 e
os níveis 2 e 3. Processos são continuamente melhorados
metas genéricas dos níveis de maturidade 2 e 3.
baseados em entendimentos quantitativos de causas
comuns de variação inerente aos processos.
Subprocessos que significativamente contribuam para
toda parte de desempenho de processo são selecionados.
O nível 5 foca na melhoria contínua de desempenho
Estes subprocessos são controlados usando técnicas
de processo através de melhorias incrementais e
estatísticas e outras técnicas quantitativas.
tecnologicamente inovadoras. Os objetivos quantitativos
do melhoramento do processo são estabelecidos,
Objetivos quantitativos para qualidade e desempenho
continuamente revisados para refletir mudanças de objetivos
de processo são estabelecidos e usados como critério
de negócios e usados como critério em gerenciamento de
em gerenciamento de processos e são baseados em
melhoria de processo. Os efeitos de melhoria de processos
necessidades de clientes, usuários finais, organização e
desenvolvidos são medidos e avaliados com os objetivos
implementadores de processos. Qualidade e desempenho
quantitativos de melhoria de processos. Ambos, processos
de processos são entendidos em termos estatísticos
definidos e conjunto de processos padrões da organização,
e são gerenciados ao longo de vida de processos. Para
são objetivos de atividades de melhoramento.
estes processos, medidas detalhadas do desempenho dos
processos são coletadas e analisadas estatisticamente.
Melhoramentos são selecionados baseados em
Casos especiais de variação são identificados e, quando
entendimento quantitativo de suas contribuições
apropriado, causas especiais são corrigidas para prevenir
esperadas para alcançar os objetivos de melhoramento
futuras ocorrências.
de processos da empresa versus o custo e impacto na
organização. O desempenho de processos de organização
Medidas de qualidade e desempenho de processos são
é continuamente melhorado.
incorporados ao repositório de medição da organização para
apoiar tomadas de decisões reais no futuro baseadas em
A otimização dos processos que são ágeis e inovadores
fatos. Uma distinção entre os níveis 3 e 4 está na previsão
depende da participação da força de trabalho alinhada
de desempenho de processo. No nível 4, o desempenho de
aos valores e objetivos da organização. A habilidade da
processos é controlado usando técnicas estatísticas e outras
organização para rapidamente responder a mudanças e
técnicas quantitativas, sendo quantitativamente previsível.
oportunidades está melhorada por encontrar maneiras de
acelerar e compartilhar aprendizado.
Os processos deste nível e seus objetivos são:

Uma distinção entre nível 4 e nível 5 é o tipo de variação

 Gerenciamento quantitativo de projeto
de processo com que se lida. No nível 4, processos estão
(QPM): tem como objetivo gerenciar quantitativamente
preocupados com causas especiais de variação e fornecem
estatística previsível de resultados. Apesar de processos

33
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
34
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)

de Estudos e Projetos (FINEP), Banco Interamericano de

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

Histórico e visão geral do MPS.BR mais aceitos no mercado. Está em conformidade com as
normas internacionais ISO/IEC 12207 e ISO/IEC 15504, é
O MPS.BR - Melhoria
compatível com o modelo CMMI, é baseado nas melhores
de Processo de Software.
práticas da Engenharia de Software e é adequado à realidade
BRasileiro foi criado
das empresas brasileiras. Assim, o modelo é compatível
em dezembro de 2003
com os padrões de qualidade aceitos internacionalmente
coordenado pela SOFTEX -
e tem como pressuposto o aproveitamento de toda a
Associação para Promoção
competência existente nos padrões e modelos de melhoria
da Excelência do Software
de processo já disponíveis.
Brasileiro. O programa tem por objetivo a melhoria de
processo para o desenvolvimento de software brasileiro,
O modelo MPS baseia-se nos conceitos de maturidade
visando aumentar a competitividade da indústria brasileira
e capacidade de processo para a avaliação e melhoria
de software, nos mercados interno e externo, através de
da qualidade e produtividade de produtos de software e
programas de qualificação de profissionais nesta área e de
serviços correlatos. Dentro desse conceito, o modelo MPS
melhoria e avaliação de processos e produtos de software
possui três componentes:
brasileiros, a um custo acessível às empresas de menor
porte. O MPS.BR conta com a participação de representantes
 Modelo de Referência (MR-MPS)
de universidades, instituições governamentais, centros de
 Método de Avaliação (MA-MPS)
pesquisa e de organizações privadas, os quais contribuem
 Modelo de Negócio (MN-MPS)
com suas visões complementares que agregam qualidade
ao empreendimento. Além disso, o MPS.BR conta com
Cada componente é descrito por meio de guias e/ou
investimentos de empresas privadas e tem o apoio do
documentos do modelo MPS, como pode ser visto na figura 8.
Ministério da Ciência e Tecnologia (MCT), Financiadora

Figura 8 – Modelo MPS.BR

Fonte: http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf

35

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
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.
Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
tem
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.
36
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
Tabela 5 - Níveis de maturidade, processos e atributos do MR-MPS.
Nível Processos
A AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
B Gerência de Projetos – GPR (evolução)
C Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de decisões – GDE
D Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
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
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
G Gerência de Requisitos – GRE
Gerência de Projetos – GPR
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.
37
Atributos de processo
3.2, AP 4.1, AP 4.2, AP 5.1, AP 5.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2, AP 4.1, AP 4.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2
AP 1.1, AP 2.1, AP 2.2
AP 1.1, AP 2.1
• 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)
• 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
38
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)
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.
39
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)
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
40
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)

para se chegar aos níveis de maturidade mais altos leva-se equivalência dos níveis de maturidade do CMMI e do MPS.
em média de 4 a 8 anos. [OLIVEIRA, 2008] BR. Esta equivalência pode ser vista na tabela 6 e melhor
visualizado na figura 9.
Essas dificuldades contrastam com a realidade
das empresas brasileiras que não podem realizar um Tabela 6 – Equivalência entre os níveis de maturidade
investimento tão alto para a obtenção da certificação. O CMMI x MPS.BR
alto custo da adaptação para obtenção da certificação Comparação dos níveis de maturidade
e o longo prazo para alcançar os níveis mais altos de CMMI MPS.BR
maturidade impossibilitavam as pequenas e médias 1 Não é Definido
empresas desenvolvedoras de software a aderirem ao G
programa do CMMI. 2 F
E

O MPS.BR surgiu como um movimento cujo objetivo D

3 C
era suprir a demanda das empresas nacionais, que
4 B
precisavam encontrar uma forma de adaptar à sua
5 A
realidade, rapidamente, modelos para melhoria de
processos de software como o CMMI níveis 2 e 3, a um
Analisando a tabela 6, podemos verificar que os níveis
custo mais accessível.
do MPS.BR permitem que a empresa implante processos
de uma forma mais gradual. Essa estratégia aplicada ao
Ambos os modelos possuem níveis de maturidade
mercado brasileiro de software permite que empresas de
que definem a capacidade da empresa para trabalhar em
pequeno porte, que não possuem muito dinheiro para
projetos grandes e complexos. Como vimos, o CMMI varia
investir em metodologias e processos, possam tomar
do 1 ao 5 e o MPS.Br varia do G ao A, sendo que, ao
a iniciativa de definir processos. O MPS.BR e o CMMI
contrário do CMMI, o primeiro nível já exige que a empresa
possuem níveis equivalentes de qualidade de software,
tenha determinados processos definidos. Os níveis do
mas a norma brasileira tem a vantagem de ser muito mais
MPS.BR também são compostos por Áreas de Processos,
barata, além de existir financiamento do BID para grupos
que são os tópicos mais importantes para um processo de
de empresas que desejam se certificar.
desenvolvimento de software. Assim, podemos criar uma

Figura 9 – Níveis de maturidade do modelo MPS.BR e CMMI

Fonte: Fonte: http://bettawork.com.br/news/pagNoticia_6.html

41
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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.
( ) 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

BR. Além disso, o custo de um processo de implantação do e capacidade de processo para a avaliação e melhoria da
qualidade e produtividade de produtos de software e serviços
MPS.BR é menos custoso que o do CMMI, e esse é um dos
correlatos.
principais incentivos para algumas empresas fazerem isso.
Uma empresa pode alcançar o nível A do MPS.BR e depois
3) Faça uma comparação entre os modelos
já tentar o nível 5 do CMMI.
CMMI e MPS.BR, do seu ponto de vista.

Assista ao vídeo sobre implantação do

modelo e certificação MPS.BR em
empresas no Paraná Modelagem de Processos de
http://youtu.be/ddOqzmo0kj8
Negócio (BPM)
Caro aluno, neste capítulo vamos conhecer o que seja
Exercícios do Capítulo 4 processo em negócios e sua gestão. Vamos entender o porquê
da necessidade de mapear os processos e o porquê de usar a
1) Complete as sentenças: modelagem de processo para materializar todos os fluxos que
Os processos do MR-MPS são descritos em termos de ___ o processo contempla. Estudaremos a metodologia do workflow
____________________________________: que fornece uma maneira de visualizar melhor as atividades de
Os __________________________ descrevem o objetivo negócios, como uma cadeia de tarefas e intervenções que irão
geral a ser atendido durante a execução do processo determinar uma melhor qualidade e produtividade nos processos
Os __________________________ do processo de negócios.
estabelecem os resultados a serem obtidos com a efetiva
implementação do processo.
A crescente importância dos processos
2) Assinale V-verdadeiro e F-falso nas
Caro aluno, embora os estudos sobre processos, quer
afirmações sobre o MPS.BR: sejam industriais ou empresariais, já sejam feitos há mais
de um século, conforme estudos de Taylor, Ford e outros, a
( ) No modelo MPS.BR, um nível é alcançado quando os
compreensão dos processos de negócios tem se mostrado
propósitos e todos os resultados esperados dos respectivos
como uma das tendências mais fortes para a compreensão
processos são atendidos. Os níveis são acumulativos.
do funcionamento das organizações. Diferente de
( ) O nível mais baixo do MPS.BR é o nível A, logo, o nível
momentos em décadas anteriores, em que a montagem
mais alto é o nível G.
de esquemas com ênfase na redução de erros e aumento
( ) 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 da qualidade era utilizada, hoje se pretende acompanhar,
Problemas e Resolução. automatizar e obter ganhos efetivos com os processos.
( ) Adicionalmente, outro objetivo do MPS.BR é replicar o Isso gera interesse de ganhos reais com estes processos,
modelo na América do Norte, incluindo os Estados Unidos e seja na imagem da organização, nos financeiros ou no
Canadá, que apoiam o projeto. aumento da competitividade.
( ) O modelo MPS segue os modelos e normas internacionais
mais aceitos no mercado. Está em conformidade com as A partir da década de 1990, as organizações têm
normas internacionais ISO/IEC 12207 e ISO/IEC 15504 e é experimentado uma evolução em termos de modelos
compatível com o modelo CMMI. estruturais e tecnológicos, trazendo como novos paradigmas
as mudanças e o conhecimento. Esse fato tem exigido uma

42
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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

Definição de processos a estrutura dos processos dentro de uma organização em
quatro níveis, do mais amplo para o mais específico, da
Um processo pode ser definido de diferentes formas. seguinte forma: macroprocessos, subprocessos, atividades
Segundo Davenport (1994), processo é “uma ordenação e tarefas, conforme mostrado na figura 10.

Figura 10 – Processo, subprocesso, atividades e tarefas

Fonte: [HARRINGTON et al., 1997]

43
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
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
44
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).
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)

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, Fonte:http://alissonml.blogspot.com.br/2008/01/o-que-gesto-de-
mais importante é a noção de que os processos e seus processos.html

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

45
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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

Há muitas razões pelas quais as organizações não De acordo com Gonçalves (2000), as organizações têm
administram bem seus processos. Quando um processo percebido cada vez mais que os seus processos de negócio
envolve diferentes departamentos, não é incomum lhes oferecem vantagens competitivas. Atualmente, para
surgir uma luta de poder em torno da propriedade e serem efetivas, as organizações devem ser capazes
responsabilidade sobre diferentes aspectos do processo, de definir, analisar, melhorar, medir e controlar os seus
pois os gerentes são frequentemente compensados pela processos. Nas empresas de serviço, em especial, os
produção e eficiência dos seus próprios departamentos, processos tornam-se fundamentalmente importantes uma
sem levar em conta os demais departamentos. Assim, vez que a sequência de atividades nem sempre é visível,
nem pelo cliente nem por quem realiza as atividades. Para
administrar projetos e processos transfuncionais torna-se
estas empresas, a sequência de atividades é necessária
uma tarefa difícil devido à existência desses silos funcionais.
para a realização de transações e prestação do serviço.
Os processos de trabalho ganham mais importância à
Entender como funcionam os processos e quais
medida que as empresas ficam com conteúdo cada vez
são os tipos existentes é importante para determinar
mais intelectual, afastando-se do modelo fabril.
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.

46
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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 identificar seus 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,
47
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)

dos processos monitora continuamente os objetivos fixados

O Ciclo de Vida dos Processos de
e fornece alertas de divergências com o que foi planejado,
indicando medidas a serem implementadas. Assim, as
Negócio
organizações alcançam uma qualidade de processo
A realização de qualquer atividade de trabalho se dá
melhorada, que tem um impacto direto nos resultados
através de um processo de negócio e este possui um ciclo
da corporação. O monitoramento contínuo de processos
de vida que passa necessariamente por 4 estágios: Captura,
de negócio atual diminui a distância entre a estratégia
Reengenharia, Implementação e Melhoria Contínua
organizacional e sua implementação operacional.
(figura 12). Se esses estágios forem bem conhecidos
e adequadamente conduzidos, o gerenciamento dos
Sabe-se que do taylorismo/fordismo aos dias de
processos de negócio de uma organização pode se tornar
hoje, passando pelo modelo japonês de produção, os
efetivo em relação ao seu potencial de ganho.
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 Figura 12 – O ciclo de vida dos processos de negócio.
Fonte: Autoria própria
que mais se preocupa com fluxos do que com operações

isoladas de produção.
No que se segue estes estágios são detalhados.

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

Assista ao vídeo sobre Gestão por

• Primeira, o entendimento a ser dado aos mesmos
Processos – BPM
Disponível em: http://www.youtube.com/ facilita a comunicação entre os participantes.
watch?v=wpI0Ls8Nn_c • Segunda, na maioria das organizações complexas
não há como passar para um novo processo sem
compreender o existente.

48
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
• 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.
49
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. 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)
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
50
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)
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 necessidades dos negócios. Sentiu-se a necessidade de
51
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)
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.”
52
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)

Figura 13 – Relacionamentos entre a terminologia básica de Workflow

Fonte: http://sistemasdeworkflow.blogspot.com.br/

A etapa de implantação do workflow exige cuidados

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.
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 ser tratadas e saneadas,
a fim de que não se acentuem ao longo do tempo.

53
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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

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

54
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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

Figura 15 – Workflow Ad hoc para admissão de sócios.
Fonte: Autoria própria
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.

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

55
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
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.
56
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
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
um motor, que é o responsável por ativar e dar movimento ao processo. Essa informação normalmente é usada na etapa
57
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
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
58
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)

sobre eles. A construção de modelos representativos de processos para uso em modelagem de processos. O mais comum é
incrementa o controle e a possibilidade de testes e avaliações a utilização de um conjunto de ferramentas que permite o
que muitas vezes o processo real, não permite. A flexibilidade da
uso de técnicas diferentes, baseado nos dados disponíveis
metodologia de modelagem pode garantir economia de recursos
para o desenvolvimento do modelo e relativo ao propósito
e projetar previsões que reduzem as possibilidades de erros nas
da modelagem.
execuções dos processos. Bons estudos.

Damij (2007) divide as pesquisas e as práticas na área

Modelagem de Processos de modelagem de processos em três grupos. O primeiro
grupo de estudos compara várias fases da modelagem de
Em função da natureza abstrata dos processos, ter uma
processo com ferramentas e técnicas usadas por algumas
compreensão exata deles torna-se uma tarefa difícil sem
das principais companhias ao redor do mundo. O segundo
o uso de uma metodologia de modelagem padronizada.
grupo de estudos trabalha com o desenvolvimento de
A modelagem de processos de negócio é uma técnica
técnicas existentes para modelagem de processo de
para compreensão dos processos de uma organização,
negócio. Após comparar várias técnicas, eles concluíram
e pode ser considerada um mapa que simula o mundo
que os modelos possuem limitações sérias, como
real, através da representação de pessoas, materiais de
não permitir análises quantitativas, serem subjetivos,
trabalho e, distribuição de tarefas.
apresentarem dados mecanicamente e sua manutenção
ser relativamente trabalhosa. O terceiro grupo estuda
Uma Metodologia de Modelagem de Processos é uma
e compara várias ferramentas para modelagem de
poderosa ferramenta gerencial para identificação de
processo de negócio. Como conclusão eles identificaram
oportunidades de melhorias e visualização de restrições
os seguintes elementos que influenciam no uso dessas
e gargalos. A modelagem de processos não só é uma das
ferramentas: objetivo do projeto, escopo e propósito
exigências da ISO 9000 para a gestão da qualidade e garantia,
das mudanças, possibilidade de desenvolvimento de TI,
como também é uma das questões chave na implementação
cultura organizacional.
da maioria dos sistemas de informação, como sistemas de
gerenciamento de workflow, ERP e e-business.
Será apresentada a seguir uma metodologia para
modelagem de processos que possuem uma visão mais
Os livros sobre processos de negócio fornecem
abrangente, que engloba desde o levantamento dos
conceitos, uma visão geral e algum estímulo, mas não
processos da organização até a montagem do modelo do
entram em detalhes a respeito da identificação do
processo selecionado.
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
Metodologia de Jacka & Keller
está centralizada na forma como os objetos são nelas
Para Jacka e Keller (2002), a modelagem de processos
representados. Existem poucos estudos relativos à forma
não só proporciona uma administração com uma
de levantamento dos dados, à coleta de informações e à
visão global das operações, mas também fornece aos
interação com a montagem de um sistema de workflow,
colaboradores uma visão geral de como o seu trabalho
utilizadas em cada metodologia para a montagem do
agrega valor ao produto ou serviço e como eles fazem
modelo do processo.
parte de uma equipe. Além disso, o sucesso da análise de
processos deve levar em consideração os clientes, e isso
O sucesso da modelagem de processos de negócio
pode ser qualquer nível de cliente.
depende da seleção apropriada de métodos de modelagem
disponíveis, técnicas ou análises de fluxo de processo.
Assim como os processos de uma organização
Existem muitas técnicas ou análises usadas neste campo,
passam por numerosas mudanças ao longo do tempo, a
porém a literatura sugere que não existe uma única técnica

59
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

compreensão deles também é alterada. Nesse sentido, em Coleta de dados

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

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.

60
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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
61
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)
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.
62
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)
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
_____________________.
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.
63
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)

software. A qualidade de processo é a rigorosa especificação

Respostas Comentadas dos dos processos que serão realizados na produção de um
Exercícios bem ou serviço, incluindo as faixas de tolerância desejadas
em relação aos resultados.

Capítulo 1 5) Assinale V, para verdadeiro e F, para falso:

(V) Qualidade de software é a medida que um conjunto,
1) Associe a definição de qualidade com a
definido pela indústria, de características desejáveis são
entidade ou pessoa que a criou:
incorporadas em um produto, de modo a aprimorar seu
• IEEE 610.12: qualidade pode ser definida como
desempenho durante sua existência.
o grau no qual um sistema, componente, ou processo
(V) Pode-se afirmar que o teste de software é uma das
atende aos requisitos especificados e às necessidades ou
atividades de controle da qualidade, ou seja, o teste de
expectativas do cliente ou usuário.
software é orientado a produto e está dentro do domínio
• ISO/IEC 9126: define qualidade como a totalidade
do controle da qualidade.
de funcionalidades e características de um produto ou
(F) Um dos modelos mais recentes (o certo é: um
serviço que atendem à sua capacidade de satisfazer
dos primeiros, ou seja, um dos mais antigos) modelos de
necessidades específicas ou implícitas.
qualidade de software é o de James A. McCall conhecido
• Roger Pressman (2006): é a conformidade com
como Fatores da Qualidade, que avaliam o software em
requerimentos e com características implícitas que são
três pontos distintos: Operação do Produto, Transição do
esperadas de software profissionalmente desenvolvido.
Produto e Revisão do Produto.
(V) Qualidade Total é a preocupação com a
2) Qual o principal objetivo da garantia da
qualidade em todas as atividades da empresa, buscando
qualidade?
sistematicamente o nível “zero defeito”, através da
O principal objetivo da garantia da qualidade é assegurar
melhoria contínua dos processos de produção.
que padrões, procedimentos e políticas utilizados durante
o desenvolvimento do software sejam adequados para
6) Assinale QT- para qualidade total e CQ- para
prover o nível de confiança requerido para o processo ou
controle de qualidade.
produto de trabalho.
(QT) Foco em monitoração e melhoria de processo.
(CQ) É orientado a produto e orientado à detecção.
3) Qual destas não é uma característica para a
(QT) Garante que o processo é definido e apropriado.
qualidade de software?
(QT) É orientada a processo e orientada à prevenção.
c) é responsabilidade de apenas uma área da
(CQ) As atividades focam na descoberta de defeitos em
empresa: a área de qualidade
itens específicos.
(CQ) As atividades são focadas no final das fases no
4) Qual a diferença entre qualidade de produto
ciclo de vida de desenvolvimento de software.
e qualidade de processo?
(QT) Garante que você está fazendo as coisas certas e
• Qualidade do produto de software refere-se ao
da maneira correta.
software em si, que deve seguir as especificações para o
(CQ) Garante que os resultados do seu trabalho são os
qual foi desenvolvido. A qualidade de produto é a rigorosa
esperados conforme requisitos.
definição das características relevantes do produto,
(QT) As atividades são focadas no inicio das fases no
estabelecendo os atributos e as variáveis que deve conter,
ciclo de vida de desenvolvimento de software.
cuja dimensão deve ser assegurada. A especificação é o
(CQ) Inspeções e garantia de que o produto de trabalho
documento que formalizará essas definições.
atenda aos requisitos especificados.
• Qualidade do processo de software diz respeito
à qualidade das atividades e forma pelas quais se produz

64
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)
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.
65
• 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)
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çã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.
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.
66
( ) 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)
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
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.
e 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.
67
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

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

68
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

Advanced Study Institute on Workflow. V. 164, Istambul,

Referências Turquia. 1997.

BOEGH, J; HAUSEN, H. L.; WELZEL, D. A practioeners

GONÇALVES, J. E. L. As empresas são grandes
guide to evaluation of software. In Software
coleções de processos. In: Revista de Administração de
engineering standards symposium. Brighton, England,
Empresas. V. 40, n. 1, Jan/Mar 2000.
Ago/1993.

HAMMER, M. CHAMPY, J. Reengineering the

CAVANO, J.P., MCCALL, J.A. A framework for the
Corporation. New York: Hammer Business, 1994.
measurement of software quality. Proc. of the ACM
Software Quality Assurance Workshop. pp. 133-139, nov.
HARRINGTON, H. J.; ESSELING, E. K. C. NIMWEGEN,
1978.
H. V. Business process improvement workbook:
documentation, analysis, design and management
CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI®:
of business process improvement. New York: McGraw
guidelines for process integration and product
Hill, 1997.
improvement. Addison Wesley, 2003.
CORTADA, Antonio. Compreendendo os níveis de
IPCC. Quality assurance and quality control. In:
Maturidade e Capacidade do CMMI. 2009. Disponível
National Greenhouse gas inventories. Disponível em:
em: http://www.ahcconsult.com/cmmi/compreendendo-
http://www.ipcc-nggip.iges.or.jp/public/gp/english/8_QA-
os-niveis-de-maturidade-e-capacidade-do-cmmi. Acesso
QC.pdf. Acesso em: 30 mar. 2013.
em 20 jan. 2012.

ISO/IEC 9126. Information Technology – software

CORTES, Mário. Modelos de qualidade de software.
product evaluation – quality characteristics and
Campinas: Editora da Unicamp, 2001.
guidelines for their use. 1991.

CRUZ, T. Workflow: a tecnologia que vai

ISO/IEC 12119. Tradução livre da primeira edição de
revolucionar processos. São Paulo: Atlas, 2000.
06/11/1998. Disponível em http://www.insoft.softex.br/
home/copes/geqs/index.html. Acesso em: 20 Dez. 2011.
DAMIJ, N. Business process modeling using
diagrammatic and tabular. In: Techniques Business
ISO/IEC 14598-5. Information Technology
Process Management Journal. v. 13, n. 7, p. 70-90. 2007.
evaluation of software product part 5: process
for evaluators. Disponível em: http://www.cse.dcu.ie/
DAVENPORT, T. H. Reengenharia de processos. Rio
essiscope/sm4/14598-5.html. Acesso em: 30 mar. 2013.
de Janeiro: Campos, 1994.

JACKA, J. M.; KELLER, P. J. Business process

FITZPATRICK, Ronan. Software Quality: definitions
mapping: improving customer. In: Gestão Industrial.
and strategic issues. 1996. Disponível em http://www.
New York: John Wiley & Sons, 2002.
comp.dit.ie/rfitzpatrick/papers/quality01.pdf. Acesso 18
Jan. 2012.
LARSON, E; LARSON, R. BPM: an analytical
perspective. Disponível em: http://www.bpm.com/
GEORGAKOPOULOS, D.; HORNICK, M; SHET, A. An
featureRO.asp?featureId=174 Acesso em: 05 Jun. 2001
overview of workflow management: from process
modeling to workflow automation infrastructure.
MARANHÃO, M; MACIEIRA, M. E. B. O processo nosso
Distribute and parallel databases. V. 3, n. 2, p. 119-153. 1995.
de cada dia: modelagem de processos de trabalho.
Rio de Janeiro: Qualitymark, 2004.
GEORGAKOPOULOS, D.; TSALGATIDOU, A.
Technology and tools for comprehensive business
McCREADY, S. There is more than one kind of
process: lifecycle management. In: Proceedings of NATO
workflow software. Computerworld. v. 26, Nov/1992.

69
 Gestão da Qualidade com ênfase em BPM (Business Process Modeling)

SOMMERVILLE, Ian. Engenharia de Software. São

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

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.

70