Gerenciamento Quantitativo

GERENCIAMENTO QUANTITATIVO DE PROJETOS
ROSEMARY FRANCISCO
Editora Unisinos, 2017

Gerenciamento quantitativo de projetos
SUMÁ RIO
Apresentação
Capítulo 1
Introdução ao gerenciamento quantitativo de projetos de
software
Capítulo 2
Estabelecendo um processo de medição para projetos de
software
Capítulo 3
Iniciando o uso do Controle Estatístico de Processos – CEP
Capítulo 4
Introdução aos gráficos de controle do CEP
Capítulo 5
Controlando estatisticamente os processos para gerenciar
quantitativamente os projetos
Referências
A autora
Informações técnicas
A PRESENTA ÇÃ O
O contexto que envolve o desenvolvimento de produtos de

software é caracterizado por subjetividade e atividades
cognitivas, portanto um ambiente altamente qualitativo. Dessa
forma, gerenciar quantitativamente esse cenário torna-se uma
capacidade que, ao ser bem explorada, pode auxiliar as
organizações a agregar maior qualidade em seus produtos.
Para auxiliar na adoção desse tipo de gerenciamento, indica-
se o uso de métricas aliadas à aplicação de estatística para
análise dos dados mensurados. Entretanto, fazer uso de
métricas não significa que já se está fazendo uso da
estatística, visto que, a medição tradicional não exige este
tipo de análise.
Portanto, para obter a capacidade de gerenciar

quantitativamente projetos de software, pode-se adotar, em
conjunto com a medição, a aplicação do Controle Estatístico
de Processos – CEP. Este livro tem como objetivo apresentar os
principais conceitos sobre o gerenciamento quantitativo de
projetos, além de demonstrar como o CEP pode ser utilizado
na realização deste tipo de gerenciamento.
Para alcançar este objetivo, o livro foi estruturado em cinco

capítulos. O primeiro capítulo faz uma introdução aos
principais conceitos acerca do Gerenciamento Quantitativo de
Projetos. Projeto e Gerenciamento de Projeto são definidos, e
a diferença entre gerenciar projetos e gerenciar
quantitativamente os projetos é ressaltada. Além disso, os
principais conceitos e abordagens que possibilitam o
gerenciamento quantitativo de projetos são revisados. Entre
os conceitos apresentados neste primeiro capítulo, destacam-
se a definição de processos e as métricas de software. Em
relação às abordagens, apresentam-se as normas ISO/IEC
12207 e 15504, além dos modelos de maturidade CMMI e MR-
MPS.
No Capítulo 2, por sua vez, são apresentados métodos e
abordagens que auxiliam no estabelecimento de um processo
de medição para processos e projetos de software.
Apresentam-se o modelo de processo de medição proposto
pelo modelo de maturidade MR-MPS, além de passos que
podem ser seguidos para a definição deste tipo de processo
na organização. São apresentados os conceitos das
abordagens GQM e GQM Strategies e demonstrados os seus
usos como suporte para a definição dos objetivos do processo
de medição. Ainda no Capítulo 2, apresenta-se os atributos de
processo, além das sete métricas de controle de projeto que
podem apoiar na definição do que deve ser mensurado pelo
processo de medição estabelecido.
O Capítulo 3 apresenta conceitos e procedimentos que são

úteis para iniciar o uso do Controle Estatístico de Processos –
CEP. Para tanto, apresenta-se a definição do CEP, além de
suas principais características. Também se menciona a
necessidade da seleção de processos críticos para a
organização, antes de iniciar o uso do CEP. Três métodos que
podem apoiar nesta seleção de processos são apresentados.
Estes métodos são conhecidos como as ferramentas essenciais
da qualidade. Por fim, ressalta-se a necessidade da
identificação de medidas adequadas ao uso do CEP. Para
isso, indica-se alguns passos e procedimentos que podem ser
adotados para esta finalidade.
No Capítulo 4, é feita uma introdução acerca dos gráficos de

controle que podem ser utilizados para o controle estatístico
dos processos de software. É apresentado o conceito de
variação e de que forma esta variação pode impactar na
estabilidade dos processos. Considerando que a principal
característica do processo é a repetibilidade, possuir e
manter processos estáveis garante esta característica e,
consequentemente, que os produtos de software gerados
tenham sempre a mesma qualidade. Neste capítulo, também
são demonstrados os dois tipos de causas que podem ser
observados nos gráficos de controle, e são apresentadas a
definição e as principais características dos gráficos de
controle. Por fim, um resumo sobre os gráficos de controle
existentes e exemplos de sua aplicação são ilustrados.
Para finalizar, no Capítulo 5 é explanada a relação entre o CEP
e o gerenciamento quantitativo de projetos de software. Para
tanto, são reforçadas a definição básica de projeto bem como
as principais características que o aproxima do processo.
Também é apresentada a inter-relação entre o CEP e o
gerenciamento quantitativo de projetos. Por fim, é
apresentada uma abordagem que possibilita a adoção de um
programa de melhoria contínua para processos de software
com base no CEP.
CAPÍTULO 1
Introdução ao gerenciamento quantitativo
de projetos de software
–
Este capítulo faz uma introdução aos principais conceitos acerca do
Gerenciamento Quantitativo de Projetos. Projeto e Gerenciamento de
Projeto são definidos, e a diferença entre gerenciar projetos e
gerenciar quantitativamente os projetos é ressaltada. Além disso, os
principais conceitos e abordagens que possibilitam o gerenciamento
quantitativo de projetos são revisados. Entre os conceitos, destacam-
se a definição de processos e as métricas de software. Em relação às
abordagens, apresentam-se as normas ISO/IEC 12207 e 15504, além
dos modelos de maturidade CMMI e MR-MPS.
1.1 Introdução
De acordo com o PMI (2014, p.3),

Projeto é um esforço temporário empreendido para criar um produto, serviço
ou resultado único. A natureza temporária dos projetos indica que eles têm
um início e término definidos. O término é alcançado quando os objetivos do
projeto são atingidos ou quando o projeto é encerrado porque os seus
objetivos não serão ou não podem ser alcançados, ou quando a necessidade
do projeto deixar de existir.
É importante ressaltar, portanto, a característica de o projeto sempre

resultar em algo único. Por exemplo, mesmo que existam
semelhanças na forma de desenvolvimento dos produtos de software
– processos de software utilizados; ou na estrutura, arquitetura e/ou
mesmo tecnologias utilizadas para o desenvolvimento dos produtos
de software; – o resultado final do projeto será um produto de
software único, com o intuito de atender as necessidades de um
domínio de problema específico, de um público específico etc. Essa
é, inclusive, a principal característica que difere um projeto de um
processo. Enquanto um projeto resulta sempre em um produto
único, o processo tem como premissa resultar em produtos similares,
principalmente no que diz respeito à qualidade do produto gerado.
Mais detalhes sobre processos são abordados na Seção 1.2.1
Definições de Processos.
Dessa forma, para garantir que os objetivos dos projetos sejam

alcançados e que ele seja executado de forma adequada, indica-se
uso do gerenciamento de projetos. Segundo o PMI (2014, p. 5), o
“gerenciamento de projetos é a aplicação do conhecimento,
habilidades, ferramentas e técnicas às atividades do projeto para
atender aos seus requisitos”. O gerenciamento de um projeto,
consequentemente, implica em gerenciar: (i) o escopo ou os
objetivos definidos para serem alcançados; (ii) o planejamento das
atividades a serem realizadas durante o projeto; (iii) a execução por
parte da equipe de projeto; (iv) as mudanças que ocorrem durante a
execução do projeto; (v) o sucesso do projeto com base na qualidade
do produto, no cumprimento do orçamento e no grau de satisfação
do cliente (PMI, 2014).
O gerenciamento quantitativo de projetos, por sua vez, limita-se,

principalmente, às questões relacionadas ao monitoramento e
controle do projeto de maneira quantitativa. Isso significa
possibilitar o gerenciamento dos projetos por meio da análise
estatística de dados obtidos em medições. Por meio do
gerenciamento quantitativo de projetos é possível avaliar a situação
do projeto bem como controlar o seu andamento. Também é possível
identificar variações de desempenho e qualidade, além de analisar
como está o alcance dos objetivos do projeto. Por conseguinte, ao
gerenciar quantitativamente um projeto de software, será possível
utilizar recursos para monitorar o andamento de todo o projeto de
forma quantitativa. Esse monitoramento munirá os responsáveis com
dados que possibilitem examinar a variação dos projetos e processos
além de prever resultados futuros.
Antes de iniciar o gerenciamento quantitativo de projetos, no

entanto, é necessário conhecer os principais conceitos que
englobam o tema. Na seção a seguir, é feita uma revisão sobre os
principais conceitos e abordagens necessários para um adequado
gerenciamento quantitativo de projetos.
1.2 Revisando os principais conceitos e abordagens

Esta seção tem como propósito apresentar os principais conceitos e
abordagens relacionados ao gerenciamento quantitativo de projetos.
Entre os conceitos, revisa-se a definição de processos e as definições
básicas utilizadas para as métricas de processos de software. Em
relação às abordagens apresenta-se as principais normas e os
modelos de maturidade. Essas abordagens ressaltam a necessidade
do gerenciamento quantitativo de projetos, para o alcance dos
objetivos dos projetos por meio do bom desempenho dos processos
de software.
1.2.1 Definição de processos
Existem várias definições, com pequenas diferenças, sobre o conceito

de processos. Processos, segundo Humphrey (2003), é um conjunto
definido de passos para a realização de uma tarefa. De acordo com
Gonçalves (2000), é qualquer atividade ou conjunto de atividades
que recebe uma entrada, adiciona valor a ela, e fornece uma saída a
um cliente específico. Segundo Oliveira (2008), processo é um
conjunto de ações ordenadas e integradas para um fim produtivo
específico, ao final do qual serão gerados produtos e/ou serviços
e/ou informações. Ainda segundo Oliveira (2008), processos são
resultados dos sistemas em ação, representados por fluxos de
atividades ou eventos.
De acordo com Cruz (2006), processo é um conjunto de atividades

que têm por objetivo transformar insumos (entradas), adicionando-
lhes valor por meio de procedimentos, em bens ou serviços (saídas),
que serão entregues e devem atender às necessidades dos clientes.
A ABNT (2005), por sua vez, descreve que quaisquer atividades que
recebem entradas e as transformem em saídas podem ser
consideradas como um processo. As definições destes autores
convergem para uma ideia única que pode ser representada na
Figura 1.
Figura 1 – Visão macro de um processo.
Fonte: elaborada pela autora.
A Figura 1 ilustra a visão macro de um processo. Nesta visão,

destacam-se dois dos principais elementos de um processo: as
entradas e as saídas. Todo processo, obrigatoriamente, deverá ter
uma entrada, que será utilizada pelas atividades do processo para
gerar uma saída. Dessa forma, a saída do processo também é um
elemento obrigatório. Além desses dois elementos, outros elementos
fazem parte da estrutura de um processo. Estes elementos são
representados no Quadro 1.
Quadro 1 – Principais elementos de um processo
Elemento D efinição
Entradas Tudo o que é introduzido no processo e tem como
objetivo ser transformado ou fornecer dados e
informações. Pode ser do tipo lógico (dados dos
sistemas de informação) ou físico (materiais, bens).
Saídas Produto e/ou serviço resultante da execução do
processo. Pode ser do tipo lógico (dados dos
sistemas de informação) ou físico (materiais, bens).
Clientes São categorizados em Externos e Internos:
Clientes externos=são a razão da existência da
organização. Os clientes externos sempre utilizam
o produto/serviço prestado pela organização.
Clientes internos=todos os participantes de todos
os processos da organização.
Fornecedores São categorizados em Externos e Internos:
Fornecedores externos=fornecem entradas e estão
fora da organização.
Fornecedores internos=fornecem entradas e estão
dentro da organização.
Atividades Tem como objetivo processar as entradas para
produzir parte do produto do processo.
Papéis Toda atividade tem uma responsabilidade dentro do
Funcionais processo e é esta responsabilidade que o papel
funcional deve assumir.
Fonte: elaborado pela autora com base em Oliveira (2008) e Cruz (2006).
As principais características que podem ser observadas nos

processos são descritas a seguir (GONÇALVES, 2000; CRUZ, 2006;
OLIVEIRA, 2008; DE SORDI, 2008):
a. utiliza os recursos da organização para atingir os resultados;
b. pode ocorrer em qualquer tempo, bastando que um gatilho o

dispare;
c. pode produzir milhares de produtos, serviços ou resultados

similares;
d. caracteriza-se pela repetibilidade de ocorrência, podendo

coexistir várias instâncias de processo simultaneamente.
Estas características demonstram que os processos estão

intrinsecamente relacionados aos fluxos de trabalho existentes nas
organizações. Para o caso dos processos de software, os fluxos de
trabalho estão diretamente ligados às atividades de desenvolvimento
de produtos de software, propostos pela Engenharia de Software.
Esses fluxos de trabalho, quando estruturados na forma de
processos, permitem um maior controle e ações de melhoria
constantes, por meio do aprendizado sobre seu funcionamento.
Melhorar processos é uma ação básica para as organizações
responderem às mudanças que ocorrem constantemente em seu
ambiente de atuação e para manter o sistema produtivo competitivo
(PAIM et al., 2009).
Para melhorar os processos, no entanto, é preciso avaliar, de forma

quantitativa e contínua, como está o desempenho e a estabilidade
do processo. Processos instáveis podem gerar resultados negativos
na saída. Dessa forma, para evitar que isso ocorra, é aconselhado o
uso de métricas para o monitoramento e a identificação das causas
da instabilidade. A seção que segue apresenta, de forma breve, os
principais conceitos de métricas de software e de que forma estas
métricas podem auxiliar no gerenciamento dos processos e projetos
de software.
1.2.1 Métricas de software
Medir software não é uma tarefa trivial. Os motivos que

desencadeiam esta afirmação dizem respeito, principalmente, à
grande subjetividade no qual o desenvolvimento de software está
situado e à quantidade de tarefas qualitativas que devem ser
desempenhadas nesse processo. De qualquer forma, fazer uso de
métricas para medir o processo e o projeto de software auxilia a
tornar a avaliação do produto de software com caráter mais
quantitativo e menos impreciso.
Porém, antes de fazer uso de métricas de software, é imprescindível

compreender os principais conceitos que envolvem esta temática: o
que é medida, métrica, indicador e medição. Como medida pode ser
usada tanto como substantivo quanto como verbo, as definições do
termo podem ser um tanto confusas. O Quadro 2 apresenta e
exemplifica estes conceitos.
Quadro 2 – Conceitos básicos para a medição
Item D efinição Exemplo

Medida É indicação quantitativa da Qual o número de
extensão, quantidade, bugs do projeto X?
capacidade ou tamanho de Medida: Número de
algum atributo de um produto bugs
ou processo.
Métrica É o conjunto de medidas Qual o número de
toma da s a o longo de um bugs do projeto X no
período utilizando a mesma Sprint 1?
metodologia de medição. Métrica: Número de
bugs do Sprint
Indicador É uma métrica, ou combinação De acordo com a
de métricas, q ue proporciona média de bugs por
informa ções sobre o processo Sprint, indicar se em
de software, em um projeto de um determinado
software ou no próprio produto. Sprint o número de
É utilizado para analisar o bugs ultrapassou ou
alcance de objetivos. não a média
conhecida.
Indicador: Média de
bugs por Sprint
Medição Ação de medir, de atribuir um Medição do número
valor a uma medida, executando de bugs do projeto
um procedimento de medição. por meio do registro
de defeitos na etapa
de testes.
Fonte: elaborado pela autora.
De acordo com Rocha, Souza e Barcellos (2012) o uso de métricas de

software permite avaliar, quantitativamente, qualquer aspecto dos
processos, projetos e produtos de software e, dessa forma,
possibilitar o seu melhor entendimento. Além disso, as métricas
também podem auxiliar no planejamento, controle e melhoria do
resultado que está sendo produzido pelo processo e/ou projeto de
software.
Apesar das vantagens no uso de métricas de software, é importante,

no entanto, destacar algumas desvantagens. Como já mencionado,
medir software não é nada simples e, além disso, definir quais
métricas são mais adequadas para a avaliação do projeto de
software é algo complexo. Existem várias métricas na literatura,
porém, fazer uso de todas elas, ou mesmo medir por medir, não irá
trazer dados adequados para a análise e melhoria do processo e
projeto de software.
Medição exige planejamento e esforço sobre o que medir, quando

medir, onde armazenar, o que e como analisar. E como o domínio no
qual o desenvolvimento de software se encontra é altamente
subjetivo e qualitativo, o ideal é que as métricas sejam estabelecidas
com base em objetivos definidos pela organização e pela equipe do
projeto de software. No Capítulo 2 são apresentados mais detalhes
sobre como estabelecer um processo de medição para projetos de
software. A seção que segue, por sua vez, apresenta as normas e os
modelos de maturidade que recomendam o uso do gerenciamento
quantitativo para os projetos de software.
1.2.3 Normas e modelos de maturidade para processos de software
De acordo com as normas e os modelos de maturidade, para que as

organizações atinjam um nível de excelência (ou maturidade) maior
na execução dos seus processos de software, é importante o uso de
medição. Por meio da medição é possível avaliar o desempenho do
projeto e, consequentemente, do processo utilizado para a execução
do projeto. A análise dos dados da medição permitirá avaliar a
condição do projeto/processo e auxiliar na tomada de decisão no
que diz respeito a ações de melhorias. No entanto, é muito comum
as organizações adotarem a medição tradicional, que basicamente
consiste na coleta dos dados dos projetos realizados e a simples
comparação com o que foi planejado (ROCHA; SOUZA; BARCELLOS,
2012).
Portanto, para que as organizações e as equipes de projeto atinjam

uma maturidade maior e melhores resultados no desenvolvimento
dos produtos de software, indica-se a adoção de um programa de
melhorias de processos. Um programa de melhorias deve ser
adotado com base em normas que estabelecem padrões para a
qualidade de software e/ou em modelos de maturidade para os
processos de software. Neste livro, são apresentadas as normas
ISO/IEC 12207 e ISO/IEC 15504, além dos modelos CMMI (Capability
Maturity Model Integration) e MR-MPS (Modelo de Referência –
Melhoria de Processo do Software), para este fim.
1.2.3.1 Norma ISO/IEC 12207
A norma ISO/IEC 12207 tem como propósito estabelecer uma estrutura

comum para os processos de software, com base em uma
terminologia bem definida (ISO/IEC, 2008). Quando o processo de
medição é implantado com base nesta norma, os seguintes
resultados são esperados (ROCHA; SOUZA; BARCELLOS, 2012):
a. As necessidades de informação dos processos técnicos e
gerenciais são identificadas.
b. Um conjunto adequado de medidas orientado pelas

necessidades de informação é identificado ou desenvolvido.
c. As atividades de medição são identificadas e planejadas.
d. Os dados requeridos são coletados, armazenados, analisados,

e os resultados interpretados.
e. As informações produzidas são usadas para apoiar decisões e

fornecer bases objetivas para a comunicação.
f. O processo de medição também é medido e analisado.
g. Melhorias são comunicadas ao responsável pelo processo de

medição.
1.2.3.2 Norma ISO/IEC 15504
A norma ISO/IEC 15504 estabelece uma estrutura para a avaliação e

melhoria de processos de software (ISO/IEC, 2003). A estrutura de
avaliação está baseada em duas dimensões (ROCHA; SOUZA;
BARCELLOS, 2012):
1. dimensão de processo, fornecida por um modelo de referência

externo que define um conjunto de processos caracterizados
por seu propósito e resultados esperados e;
2. dimensão de capacidade, que consiste em um framework com

seis níveis de capacidade de processo.
Os seis níveis de capacidade para os processos de software,

estipulados pela norma ISO/IEC 15504, são apresentados no Quadro
3.
Quadro 3 – Níveis de capacidade da norma ISO/IEC 15504
Nível D efinição
0 – Caracterizado por processo não existente ou que falha
Incompleto em atingir os seus objetivos.
1 – Inicial O processo geralmente atinge os objetivos, porém,
sem padrão de qualidade e sem controle de prazos e
custos.
2 – O processo é planejado e acompanhado e satisfaz
Gerenciado requisitos definidos de qualidade, prazo e custos.
3 – O processo é executado e gerenciado com uma
Estabelecido adaptação de um processo padrão definido, eficaz e
eficiente.
4 – O processo é executado dentro de limites de controle
Previsível definidos e com medições detalhadas e analisadas.
5 – Em O processo é melhorado continuamente de forma
otimização disciplinada.
Fonte: elaborado pela autora com base em Rocha, Souza e Barcellos (2012).
Conforme demonstrado no Quadro 3, desde o nível 3 a medição de

software é tratada. Para implementar a medição e o controle
estatístico dos processos de software com base na norma ISO/IEC
15504, deve-se observar os seguintes critérios (ROCHA; SOUZA;
BARCELLOS, 2012):
1. Implantação do processo:
a. Dados apropriados são coletados e analisados,

constituindo uma base para o entendimento do
comportamento do processo, para demonstrar a
adequação e a eficácia do processo, e analisar onde
pode ser feita a melhoria contínua do processo.
2. Medição do processo:
a. São identificadas as necessidades de informação do

processo, com o intuito de apoiar os objetivos de negócio
relevantes da organização.
b. Os objetivos de medição do processo devem ser

derivados das necessidades de informação do processo.
c. São definidos objetivos quantitativos de desempenho

para apoiar os objetivos de negócio relevantes.
d. Medidas, bem como a frequência de realização de suas
medições, são identificadas e definidas de acordo com
os objetivos de medição e os objetivos quantitativos de
desempenho do processo.
e. Resultados das medições são coletados, analisados e

comunicados para monitorar o atendimento dos
objetivos quantitativos de desempenho do processo.
f. Resultados de medições são utilizados para caracterizar

o desempenho do processo.
3. Controle do processo:
a. Técnicas de análise e controle são identificadas e

aplicadas quando pertinente.
b. Limites de controle de variação são estabelecidos para o

desempenho normal do processo.
c. Dados de medição são analisados com relação a causas

especiais de variação.
d. Ações corretivas são realizadas para tratar causas

especiais de variação.
e. Limites de controle são redefinidos (quando necessário)

seguindo as ações corretivas.
Os níveis de capacidade propostos pela norma ISO/IEC 15504 são

equivalentes aos níveis de capacidade proposto pelo modelo de
maturidade do CMMI. Mais detalhes sobre o CMMI são apresentados
na seção a seguir.
1.2.3.3 CMMI (Capability Maturity Model Integration)
Os modelos de maturidade indicam o estágio em que os processos

de software se encontram. De acordo com estes modelos, quanto
maior a capacidade do processo melhor o seu desempenho e/ou
habilidade para alcançar os objetivos de negócio da organização.
Esses modelos são recomendados para dois propósitos (AHERN,
2008): (1) para estabelecer uma linha de base para a melhoria e (2)
para medir o progresso das atividades de melhorias realizadas.
Conforme mencionado na seção anterior, o CMMI também utiliza
níveis de capacidade para avaliar os processos de software. Estes
níveis assemelham-se aos níveis propostos pela norma ISO/IEC
15504, sendo a única diferença o CMMI utilizar somente 5 níveis ao
invés de 6. Os níveis de capacidade propostos pelo CMMI são
(AHERN, 2008): (1) Inicial, (2) Gerenciado, (3) Definido, (4) Gerenciado
Quantitativamente e (5) Em Otimização.
O CMMI recomenda o uso de medição dos processos de software a

partir do nível (2) Gerenciado (SEI, 2010). Esse nível especifica a área
Medição e Análise cuja finalidade é desenvolver e manter um
processo de medição com o intuito de prover dados para as decisões
gerenciais. Os objetivos e as práticas específicas para a área de
Medição e Análise, propostos pelo CMMI, são apresentados no
Quadro 4.
Quadro 4 – Objetivos e práticas da área de Medição e Análise do CMMI
Objetivo Específico 1: A linhar as atividades de medição e análise

Prática Específica 1.1: Estabelecer objetivos de medição
Prática Específica 1.2: Especificar medidas
Prática Específica 1.3: Especificar procedimentos de coleta de
dados e armazenamento
Prática Específica 1.4: Especificar procedimentos de análise
Objetivo Específico 2 : F ornecer resultados das medições
Prática Específica 2.1: Coletar dados de medições
Prática Específica 2.2: Analisar dados
Prática Específica 2.3: Armazenar dados e resultados
Prática Específica 2.4: Comunicar resultados
Fonte: elaborado pela autora com base SEI (2010).
O controle estatístico dos processos é recomendado a partir do nível

4 do CMMI. (SEI, 2010). A partir deste nível pode-se fazer uso dos
objetivos específicos e práticas definidos pelas áreas: Desempenho
do Processo Organizacional e Gerenciamento Quantitativo de
Projetos, propostos pelo CMMI. A área de Desempenho do Processo
Organizacional tem como finalidade estabelecer e manter um
entendimento quantitativo de determinados processos,
estrategicamente alinhados aos objetivos de negócio da organização
(ROCHA; SOUZA; BARCELLOS, 2012). A área de Gerenciamento
Quantitativo de Projetos, por sua vez, tem como propósito gerenciar
quantitativamente os projetos a fim de alcançar a qualidade
estabelecida para o projeto, levando em consideração o desempenho
dos processos (ROCHA; SOUZA; BARCELLOS, 2012).
Os objetivos e as práticas específicas para as áreas de Desempenho

do Processo Organizacional e Gerenciamento Quantitativo de Projetos
são apresentados no Quadro 5.
Quadro 5 – Objetivos e práticas das áreas do CMMI nível 4
Á rea: D esempenho do Processo Organizacional

Objetivo Específico 1: Estabelecer linhas de base e modelos de
desempenho
Prática Específica 1.1: Estabelecer objetivos de qualidade e de
desempenho do processo
Prática Específica 1.2: Selecionar processos
Prática Específica 1.3: Estabelecer medidas de desempenho do
processo
Prática Específica 1.4: Analisar o desempenho do processo e
estabelecer linhas de base
Prática Específica 1.5: Estabelecer modelos de desempenho do
processo
Á rea: Gerenciamento Quantitativo de Projetos
Objetivo Específico 1: Preparar a gerência quantitativa
Prática Específica 1.1: Estabelecer os objetivos do projeto
Prática Específica 1.2: Compor o processo definido
Prática Específica 1.3: Selecionar sub-processos e atributos
Prática Específica 1.4: Selecionar medidas e técnicas analíticas
Objetivo Específico 2 : Gerenciar quantitativamente o projeto
Prática Específica 2.1: Monitorar o desempenho dos sub-
processos selecionados
Prática Específica 2.2: Gerenciar o desempenho do projeto
Prática Específica 2.3: Realizar análise de causas
Fonte: elaborado pela autora com base SEI (2010).
1.2.3.3 MR-MPS (Modelo de Referência – Melhoria de Processo do

Software)
O MR-MPS, assim como o CMMI, também é um modelo de maturidade
para os processos de software. A principal diferença entre o MR-MPS
e o CMMI é a quantidade de níveis de maturidade, enquanto o CMMI
propõe 5 níveis, o MR-MPS propõe 7 níveis. De acordo com a SOFTEX
(2016), o MR-MPS baseia-se nas boas práticas do CMMI e normas
ISO/IEC 12207 e ISO/IEC 15504, porém, possibilita uma implantação
mais gradual para os níveis de maturidade. A Figura 2 ilustra os
níveis do MR-MPS e sua equivalência com os níveis propostos pelo
CMMI.
Figura 2 – Níveis do MR-MPS e Equivalência com o CMMI.

Fonte: elaborada pela autora com base em SOFTEX (2012, 2016).
No MR-MPS a medição é exigida a partir do nível F: Gerenciado. As

organizações que alcançam ou se mantêm neste nível possuem um
processo de medição definido, com base nos objetivos
organizacionais, a fim de auxiliar na tomada de decisão. Como já
mencionado nas seções anteriores, o processo de medição tem como
finalidade: coletar, armazenar, analisar e comunicar os dados
relativos aos projetos e produtos desenvolvidos a fim de auxiliar no
alcance dos objetivos organizacionais e promover a melhoria
contínua dos processos de software. Mais detalhes sobre o processo
de medição e como estabelecer um processo deste tipo na
organização são abordados no Capítulo 2.
Complementação dos estudos
Para aprofundar o conhecimento a respeito de Métricas de processo

de software recomenda-se a leitura de Francisco (2017). Para mais
detalhes sobre processos e gerenciamento de processos, indica-se a
leitura de Paim et al. (2009). Mais informações sobre as normas ISO
podem ser obtidas em Rocha, Souza e Barcellos (2012). Aconselha-se
a leitura de Ahern (2008) e SEI (2010) para conhecer mais sobre o
CMMI e a leitura de SOFTEX (2012, 2016) para conhecer mais sobre o
MR-MPS.
Resumo do capítulo
Um projeto de software pode ser considerado como uma instância do

processo de desenvolvimento de software utilizado pela organização.
Dessa forma, assim como o processo estabelecido, o projeto possuirá
os principais elementos de um processo como: entrada (as
necessidades para o produto de software), saída (o produto de
software entregue), clientes, fornecedores, papéis funcionais
(desempenhados pela equipe do projeto) e atividades que
possibilitarão o desenvolvimento do produto final. Portanto, para
garantir que o projeto alcance o objetivo de produzir o produto final
com a qualidade desejada, recomenda-se gerenciá-lo
quantitativamente. Gerenciar quantitativamente significa fazer uso
de medições para avaliar aspectos do projeto e do produto de
software, bem como analisar estatisticamente os dados obtidos. O
resultado da análise auxiliará na identificação do estado do projeto
e, consequentemente, na adequação do processo de software
utilizado para instanciar o projeto com os objetivos de negócio da
organização. Logo, a fim de garantir a observação e a melhoria
contínua do processo de software utilizado pela organização,
recomenda-se a avaliação e a realização de melhorias constantes no
processo com base nas normas e/ou modelos de maturidade
apresentados. Essas melhorias contínuas no processo garantirão que
novos projetos sejam executados de uma melhor forma.
CAPÍTULO 2
Estabelecendo um processo de medição
para projetos de software
–
Neste capítulo são apresentados métodos e abordagens que auxiliam
no estabelecimento de um processo de medição para processos e
projetos de software. Apresenta-se o modelo de processo de medição
proposto pelo MR-MPS, além de passos que podem ser seguidos para
a definição deste tipo de processo na organização. Demonstra-se o
uso das abordagens GQM e GQM Strategies como suporte para a
definição dos objetivos do processo de Medição. E, por fim, apresenta-
se os atributos de processo e sete métricas de controle de projeto que
podem apoiar na definição do que deve ser medido pelo processo de
medição estabelecido.
2.1 Introdução
Conforme apresentado no Capítulo 1, antes de iniciar a medição dos

processos e projetos de software, é importante planejar e definir um
processo de medição. O ideal é que o processo de medição esteja
alinhado às normas e abordagens apresentados, pois, dessa forma,
poderá fornecer dados importantes para a tomada de decisão e, por
conseguinte, auxiliar no alcance dos objetivos de negócio da
organização.
Neste livro, sugere-se que o Processo de Medição de Software seja

estabelecido com base no Processo Medição proposto pelo MR-MPS
(SOFTEX, 2016). O propósito, bem como os resultados esperados para
um Processo de Medição, conforme o MR-MPS, são apresentados no
Quadro 6.
Quadro 6 – Processo de medição proposto pelo MR-MPS
Processo: Medição (MED )

Propósito: O propósito do processo Medição é coletar, armazenar,
analisar e relatar os dados relativos aos produtos desenvolvidos e
aos processos implementados na organização e em seus projetos,
de forma a apoiar os objetivos organizacionais.
Resultados esperados:
MED 1. Objetivos de medição são estabelecidos e mantidos a
partir dos objetivos de negócio da organização e das
necessidades de informação de processos técnicos e gerenciais.
MED 2. Um conjunto adequado de medidas, orientado pelos
objetivos de medição, é identificado e definido, priorizado,
documentado, revisado e, quando pertinente, atualizado.
MED 3. Os procedimentos para a coleta e o armazenamento de
medidas são especificados.
MED 4. Os procedimentos para a análise das medidas são
especificados.
MED 5. Os dados requeridos são coletados e analisados.
MED 6. Os dados e os resultados das análises são armazenados.
MED 7. Os dados e os resultados das análises são comunicados
aos interessados e são utilizados para apoiar decisões.
Fonte: elaborado pela autora com base SOFTEX (2016).
Conforme apresentado no Quadro 6, é proposto pelo MR-MPS apenas

qual deve ser o propósito e os resultados esperados para um
processo de medição. Como estabelecer, executar e gerenciar este
processo, no entanto, fica a cargo de cada organização/equipe
responsável pelo Gerenciamento Quantitativo dos Projetos. A
definição do “como deve ser executado” fica em aberto,
principalmente devido à questão de que cada organização possui
um contexto específico e processos que podem ser definidos e
desempenhados de maneira diferente. Dessa forma, são
recomendados qual deve ser o propósito do processo de medição e
os resultados esperados. Assim, cada equipe poderá estabelecer o
seu processo de medição com base em seu contexto e objetivos de
negócio e gerenciar os resultados deste processo com base nos
resultados estabelecidos pelas normas e modelos de maturidade.
O que é proposto pelas normas e modelos de maturidade já foi

avaliado por várias organizações, portanto, observar e utilizar as
recomendações propostas garantirá o sucesso do processo de
medição. Levando em consideração que o processo de medição pode
fornecer dados para que seja possível a identificação de tendências
e antecipação de problemas, é imprescindível que este processo seja
definido com base em padrões reconhecidos.
Tanto o CMMI quanto o MR-MPS auxiliam na definição dos requisitos

que o processo de medição precisa atender (ROCHA; SOUZA;
BARCELLOS, 2012). Portanto, considerando os resultados esperados
propostos pelo processo Medição do MR-MPS (ver Quadro 6), para
estabelecer um processo de medição, os seguintes passos podem ser
seguidos: (1) Definir objetivos e medidas, (2) Especificar
procedimentos de coleta, armazenamento e análise e (3) Coletar,
analisar e reportar medidas. Neste capítulo são abordados mais
detalhes sobre como definir os objetivos e as medidas para o
processo de medição. Para definir os objetivos de medição sugere-se
o uso da abordagem GQM (Goal Question Metric). Para definir as
medidas, isto é, o que deve ser medido, sugere-se a observação dos
atributos de processo (AP) propostos pelo MR-MPS, além das sete
métricas para controle de projetos (MELLO FILHO, 2002). Mais
detalhes sobre esses itens são tratados nas seções a seguir.
2.2 Definindo os objetivos da medição
Para que o processo de medição seja efetivo, é necessário que ele

esteja alinhado às necessidades e aos objetivos de negócio da
organização e equipe de desenvolvimento de software. Por isso,
definir objetivos vai auxiliar a organização a beneficiar-se dos
resultados da medição, pois os dados podem desencadear ações
para a melhoria dos processos. Ao definir objetivos para a medição,
alinhados com os objetivos de negócio, fica garantido que os dados
da medição não estão sendo apenas acumulados.
A abordagem GQM é uma técnica que foi definida por Basili, Caldiera
e Rombach (1994) e tem como principal finalidade identificar
métricas significativas para gerenciar os processos e projetos de
software. De acordo com Pressman (2016), a abordagem enfatiza a
necessidade de: (1) estabelecer um objetivo de medição explícito e
que é específico para a atividade do processo ou característica do
produto que deve ser avaliada, (2) definir um conjunto de questões
que devem ser respondidas para atingir o objetivo e (3) identificar
métricas bem formuladas que ajudam a responder a essas questões.
A Figura 3 ilustra a estrutura da abordagem GQM.
Figura 3 – Abordagem GQM.
Fonte: Rocha, Souza e Barcellos (2012).
Para auxiliar na definição do objetivo de medição, Basili, Caldiera e

Rombach (1994) sugerem o uso do seguinte modelo:
A nalisar [o nome da atividade ou atributo a ser medido] com a

finalidade de [o objetivo geral da análise] com relação a [o
aspecto da atividade ou atributo considerado] do ponto de
vista de [a pessoa que tem o interesse na medição] no
contexto de [o ambiente no qual a medição ocorre].
A fim de ilustrar o uso do modelo proposto por Basili, Caldiera e

Rombach (1994) para a definição de um objetivo de medição,
apresenta-se a seguir um exemplo para um contexto hipotético:
A nalisar o desempenho do processo de testes com a

finalidade de avaliar a qualidade do produto em
desenvolvimento com relação à quantidade de não
conformidades identificadas do ponto de vista do Gerente de
Projetos no contexto do Projeto X.
Uma ressalva, no entanto, em relação à definição dos objetivos de

medição, diz respeito ao alinhamento desses objetivos aos objetivos
de negócio da organização e aos objetivos do projeto de software.
Dessa forma, com o intuito de garantir esse alinhamento, Basili et al.
(2007) evoluíram a abordagem GQM e definiram o GQM Strategies.
Nessa nova abordagem, a definição dos objetivos de medição é feita
com base nos objetivos de negócios e objetivos do projeto de
software. Assim, os resultados da medição podem auxiliar na
verificação do alcance de todos esses objetivos. A Figura 4 ilustra a
estrutura da abordagem GQM Strategies.
Figura 4 – Abordagem GQM Strategies.
Conforme ilustra a Figura 4, para utilizar a abordagem GQM

Strategies deve-se seguir os seguintes passos (ROCHA; SOUZA;
BARCELLOS, 2012):
1. Selecionar os objetivos de negócio da organização, para tanto,

indica-se a utilização do método de análise SW OT1 a fim de
definir a estratégia da organização e o alinhamento dos
objetivos estratégicos;
2. Identificar estratégias que apoiam na identificação dos

objetivos específicos de software (projeto de software) e que
contribuem para o alcance dos objetivos de negócio;
3. Identificar os objetivos de software (projeto de software);
4. Identificar cenários, isto é, um conjunto de ações necessárias

para se alcançar o objetivo de software;
5. Identificar os objetivos de medição;

6. Derivar questões e medidas a partir dos objetivos de medição.
A Figura 5 ilustra um exemplo sobre como derivar questões e

medidas a partir dos objetivos de medição.
Figura 5 – Exemplo de objetivo de medição, questões e medidas.

Após definir os objetivos do processo de medição e as questões, a

próxima etapa é definir o que será avaliado, isto é, o que será
medido, quais as medidas. Como o processo de medição objetiva
avaliar o desempenho do processo e projeto de software, é
importante definir quais atributos do processo e projeto de software
devem ser avaliados. Recomendações para a definição desses
atributos são apresentados na próxima seção.
2.3 Definindo o que será medido
2.3.1 Atributos de processos de software
Para avaliar o desempenho e o comportamento do processo e/ou dos

subprocessos de desenvolvimento de software, de forma quantitativa,
é indicada a observação de alguns atributos desses processos. Os
atributos de processo definidos pelo MR-MPS e que são
recomendados como itens de análise para um processo de medição
em uma organização são apresentados no Quadro 7.
Quadro 7 – Atributos de Processo propostos pelo MR-MPS
A tributos de Processo (A P) que devem ser observados pela

organização
A P 1.1 O processo é executado
Resultado esperado:
O processo produz os resultados definidos
A P 2 .1 A execução do processo é gerenciada
existe uma política organizacional estabelecida e mantida para o
processo;
a execução do processo é planejada (o planejamento deve
incluir identificação e disponibilização dos recursos e
informações necessárias para a execução do processo, definição,
atribuição e comunicação das responsabilidades pela execução
do processo e planejamento da comunicação entre as partes
interessadas);
a execução do processo é monitorada em relação ao planejado e,
quando necessário, ajustes são realizados;
as pessoas que executam o processo estão preparadas para
executar suas responsabilidades;
as atividades, o status e os resultados do processo são revistos
com a gerência de nível superior e são tratadas questões críticas;
a aderência dos processos executados às descrições de processo,
padrões e procedimentos é avaliada objetivamente e são
tratadas as não conformidades.
A P 2 .2 Os produtos de trabalho do processo são gerenciados
os requisitos para documentação e controle dos produtos de
trabalho do processo são identificados;
os produtos de trabalho do processo estão identificados,
documentados e sob os níveis de controle especificados;
os produtos de trabalho são avaliados objetivamente com relação
à aderência aos padrões, procedimentos e requisitos aplicáveis e
são tratadas as não conformidades.
A P 3.1. O processo é definido
existe a definição de um processo padrão, o que inclui diretrizes
para a sua adaptação a situações específicas, a sequência de
execução, a interação deste processo com os outros processos, os
papéis e competências, a infraestrutura e o ambiente de
trabalho requeridos para executar o processo;
métodos adequados para monitorar a efetividade e adequação
do processo são identificados.
A P 3.2 O processo está implementado
um processo definido baseado nas diretrizes para seleção e/ou
adaptação do processo padrão está implementado;
a infraestrutura e o ambiente de trabalho requeridos para
executar o processo definido estão disponibilizados, gerenciados
e mantidos;
experiências e dados apropriados são coletados, analisados e
utilizados para entendimento do comportamento e adequação do
processo, e para a identificação de oportunidades de melhoria
no processo.
A P 4.1 O processo é objeto de análise quantitativa
os processos que estão alinhados aos objetivos quantitativos de
negócio são identificados;
foram identificadas as necessidades de informação dos
processos requeridas para apoiar o alcance dos objetivos de
negócio relevantes da organização. As necessidades de
informação refletem necessidades gerenciais, técnicas, de
projetos, do processo e do produto;
os objetivos de medição do processo foram definidos a partir das
necessidades de informação;
relacionamentos mensuráveis entre elementos do processo que
contribuem para o desempenho do processo são identificados;
os objetivos quantitativos para qualidade e desempenho do
processo da organização foram definidos e estão alinhados às
necessidades de informação e aos objetivos de negócio;
os processos que serão objeto de análise de desempenho são
selecionados a partir do conjunto de processos padrão da
organização e das necessidades de informação dos usuários dos
processos;
medidas adequadas para análise de desempenho do processo,
incluindo a frequência de realização das medições, são
identificadas, definidas e incorporadas ao plano de medição da
organização;
resultados de medições são coletados, validados e reportados
para monitorar o quanto os objetivos quantitativos para o
desempenho do processo foram alcançados.
A P 4.2 O processo é controlado quantitativamente
técnicas para análise dos dados coletados são selecionadas;
dados de medições são analisados com relação a causas
especiais (atribuíveis) de variação do processo;
o desempenho do processo é caracterizado;
ações corretivas foram executadas para tratar causas especiais
de variação;
se necessário, análises adicionais são realizadas para avaliar o
processo sob o efeito de causas especiais de variação;
modelos de desempenho do processo são estabelecidos,
melhorados e ajustados em função do conhecimento adquirido
com o aumento de dados históricos, compreensão das
características do processo ou mudanças no próprio negócio da
organização.
Fonte: elaborado pela autora com base SOFTEX (2016).
Para exemplificar como os atributos apresentados no Quadro 7 são

analisados, considere o subprocesso de testes de software, do
processo de desenvolvimento de software. Para que o atributo AP 1.1
– o processo é executado – seja considerado como alcançado, o
subprocesso de testes deve ser executado, para todos os projetos de
software da organização. Dessa forma, evidências de que os testes
são executados para todos os projetos devem existir na organização.
Essas evidências podem ser obtidas, por exemplo, por meio de um
software que auxilia na realização das atividades de testes e também
por meio dos registros das não conformidades identificadas. Dessa
forma, medidas que poderiam ser utilizadas pelo processo de
medição, para garantir que este atributo de processo está sendo
alcançado, são: número de não conformidades registradas por
iteração, quantidade de casos de testes que identificaram não
conformidades etc.
Para avaliar se o atributo AP 2.1 – a execução do processo é

gerenciada – está sendo alcançado, pode-se, por exemplo: (1)
verificar a existência de planos de testes, e/ou (2) verificar se o
planejamento versus o realizado para os testes foi realizado
adequadamente e, em caso negativo, se ações para melhorias foram
adotadas. No caso do atributo AP 2.2 – os produtos de trabalho do
processo são gerenciados –, para garantir que ele está sendo
alcançado, pode-se observar a existência e aplicação de métricas
para o produto de software. Quando aspectos do produto são
medidos e são utilizados para análise e tomada de decisão,
principalmente no que diz respeito à sua melhoria da qualidade,
considera-se que o produto está sendo minimamente gerenciado.
O atributo AP 3.1 – o processo é definido –, por sua vez, está

diretamente relacionado à formalidade do processo. Portanto, para
avaliar seu atingimento, para o caso do subprocesso de testes, deve-
se avaliar se existe uma documentação formal deste subprocesso. A
documentação deve ter, no mínimo, a definição dos principais
elementos de um processo. Os principais elementos de um processo
foram abordados no Capítulo 1. Para o atributo AP 3.2 – o processo
está implementado – deve-se avaliar se o processo definido e
documentado formalmente pela organização está sendo realmente
executado. Muitas vezes, na prática, o processo que está sendo
executado não condiz com o que foi definido formalmente pela
organização. Avaliar esse atributo é importante pois, caso o processo
em execução seja diferente do processo formal padrão, há indícios
de que o processo formal não está adequado ao contexto e/ou
domínio dos projetos de software em desenvolvimento. Para suportar
a análise deste atributo AP 3.2, indica-se também o uso de
ferramentas que permitam a execução do fluxo de trabalho e
gerenciamento dos processos 2.
Por fim, para avaliar o alcance dos atributos: AP 4.1 – o processo é

objeto de análise quantitativa – e AP 4.2 – o processo é controlado
quantitativamente – deve-se observar se os dados de medição
coletados estão sendo analisados e controlados com base em
estatística. Para tanto, pode-se avaliar se o CEP – Controle Estatístico
de Processos – está sendo utilizado para a análise dos dados. Mais
detalhes sobre o CEP são abordados no Capítulo 3.
2.3.2 Métricas para controle de projetos
Para monitorar e controlar os projetos Mello Filho (2002) apresenta

uma lista com sete métricas para controle de projetos. As métricas de
controle têm como objetivo supervisionar a execução de um projeto,
portanto o seu uso típico é para informar periodicamente ao gerente
de projeto como está o andamento do trabalho. A fim de agilizar o
processo de medição que monitora os dados do projeto, sempre que
possível é conveniente que a coleta, computação e apresentação das
informações estejam automatizadas. Dessa forma, o gerente de
projeto pode tomar decisões baseado em alarmes acionados ou na
tendência dos indicadores.
Mello Filho (2002) sugere os seguintes indicadores e medidas para

controlar os projetos de software:
Indicadores de gerenciamento
Trabalho e Progresso;
Orçamento e Despesas;
Alocação e Rotatividade na Equipe.
Indicadores de qualidade
Fluxo de Mudanças e Estabilidade;
Fragmentação e Modularidade;
Retrabalho e Adaptabilidade;
Tempo médio entre falhas e Maturidade.
Ao coletar estes indicadores, ao longo do tempo, deve-se escolher a

abrangência da coleta: por semana, por iteração, por módulo do
sistema, por equipe etc. O Quadro 8 ilustra como esta escolha pode
ser realizada.
Quadro 8 – Exemplo de indicadores e abrangência da coleta
Progresso Trabalho e Progresso: trabalho por por

realizado no tempo Iteração módulo
Despesa Orçamento e Despesas: gastos no por por
tempo Iteração módulo
Rotatividade Alocação e Rotatividade na por
equipe: mudança de pessoal ao Iteração
longo do tempo
Estabilidade Fluxo de Mudanças e por por
Estabilidade: fluxo de mudanças Iteração módulo
no tempo
Modularidade Fragmentação e Modularidade: por por
fragmentação média por Iteração módulo
mudança ao longo do tempo
Adaptabilidade Retrabalho e Adaptabilidade: por por
retrabalho médio por mudança Iteração módulo
ao longo do tempo
Maturidade Tempo médio entre falhas e por por
Maturidade: taxa de defeitos ao Iteração módulo
longo do tempo
Fonte: Mello Filho (2002).
Santos (2007) e Gonçalves et al. (2010) propõem modelos para o

gerenciamento quantitativo e o processo de medição. No trabalho de
Santos (2007) é apresentado detalhadamente como o processo de
medição pode ser definido e executado. Também se recomenda a
leitura de Rocha, Souza e Barcellos (2012) para mais detalhes sobre
processo de medição. Mais informações sobre o GQM e GQM
Strategies podem ser verificados em Basili et al. (2007). Para conhecer
mais sobre a análise SW OT recomenda-se a leitura de Belmiro (2014).
Sugere-se a leitura de Mello e Filho (2002) para mais detalhes sobre
as métricas de controle para projetos de software.
Resumo do capítulo
A principal finalidade do processo de medição é fornecer dados para

fins de melhoria de processo e planejamento dos novos projetos de
software. Observar e analisar como a produtividade e a qualidade
dos produtos desenvolvidos no passado, bem como qual foi o
comportamento e desempenho dos processos e projetos, auxilia na
tomada de decisão para o que deve ser melhorado no presente e no
futuro. Porém, para garantir que o processo de medição seja
eficiente, é importante que este processo esteja alinhado às normas
e abordagens reconhecidas, como é o caso do MR-MPS. No entanto,
tanto o MR-MPS quanto as demais abordagens apresentadas apenas
indicam o propósito e resultados esperados para este processo de
medição. As atividades do processo e como ele deve ser executado
devem ser definidos pela própria organização. Dessa forma, garante-
se que o processo de medição resulte em informações úteis para a
melhoria contínua dos processos da organização. Como sugestão
para a definição dos objetivos do processo de medição, apresentou-
se as abordagens GQM e GQM Strategies. Por fim, para a definição
das medidas a serem examinadas, indicou-se a observação dos
atributos de processo recomendados pelo MR-MPS bem como as
setes métricas de controle de projetos de software.
__________
1. A análise SWOT é um método utilizado para verificar a posição estratégica de uma organização em
seu segmento. A sigla é um acrônimo de Forças (Strengths), Fraquezas (Weaknesses), Oportunidades
(Opportunities) e Ameaças (Threats).
2. Existem ferramentas específicas para o gerenciamento do fluxo de processos de software como o

Jira (https://www.atlassian.com/software/jira), que podem ser utilizadas para a avaliação e
monitoramento da execução do processo de desenvolvimento de software.
CAPÍTULO 3
Iniciando o uso do Controle Estatístico de
Processos – CEP
–
Este capítulo apresenta conceitos e procedimentos que são úteis para
iniciar o uso do Controle Estatístico de Processos – CEP. Para tanto,
apresenta-se a definição do CEP, além de suas principais
características. Também se menciona a necessidade da seleção de
processos críticos para a organização, antes de iniciar o uso do CEP.
Três métodos que podem apoiar nesta seleção de processos são
apresentados. Por fim, ressalta-se a necessidade da identificação de
medidas adequadas ao uso do CEP. Para isso, indica-se passos e
procedimentos que podem ser adotados para este fim.
3.1 Introdução
Conforme já mencionado nos capítulos anteriores, projetar e

desenvolver software não é algo simples. E devido ao contexto
subjetivo em que o processo de desenvolvimento de software se
encontra, utilizar métodos e técnicas que possibilite avaliar e
melhorar continuamente os processos pode auxiliar as organizações
desse segmento a enfrentarem melhor a competitividade além de ter
destaque com a qualidade de seus produtos de software
desenvolvidos. De acordo com Louzada et al. (2013), a qualidade está
diretamente relacionada à satisfação no uso dos produtos
produzidos por uma organização. Dessa forma, a qualidade se torna
imprescindível para qualquer empresa, pois baseado na qualidade
de seus produtos será possível atingir um nível de excelência e o
alcance dos objetivos de negócio definidos.
Para controlar e avaliar a qualidade dos processos, portanto,

recomenda-se o uso do gerenciamento quantitativo com a aplicação
do CEP. Louzada et al. (2013, p. 1) definem o CEP como “[...] um
conjunto de métodos utilizados para planejar, monitorar e aprimorar
um processo produtivo, por meio da coleta de amostras e, em
seguida, da mensuração de uma série de variáveis que refletem a
qualidade do processo produtivo.” Montoni et al. (2007) acrescentam
que o CEP tem como finalidade principal auxiliar no monitoramento
da variabilidade do processo. Conforme apresentado no Capítulo 1,
uma das principais características dos processos diz respeito à
repetibilidade. Portanto, variações no comportamento do processo
tendem a afetar negativamente essa característica e, consequente, a
qualidade do produto gerado pelo processo.
O CEP utiliza a estatística para gerenciar os processos de produção,
promover continuamente a melhoria de qualidade e dar apoio à tomada de
decisão da alta gerência. O seu objetivo principal é permitir diagnosticar se o
processo está sob influência de causas atribuíveis3 que precisam ser
investigadas e eliminadas (FONSECA, 2010, p. xiii).
Montgomery e Runger (2012) definem a estatística como uma maneira

de lidar com a coleta, apresentação, análise e uso dos dados para
tomar decisões, resolver problemas e planejar produtos e processos.
Esses autores mencionam que os métodos estatísticos podem ser
usados para avaliar a variabilidade dos processos e tirar conclusões
quando ela ocorrer. A variabilidade pode ser conceituada como
sucessivas observações de um sistema ou de um fenômeno que não
produzem exatamente o mesmo resultado.
Quando se observa a variabilidade de um processo no tempo, de

forma contínua, aumenta-se a possiblidade de controle do processo
durante todo o desenvolvimento e não somente após a entrega do
produto (MONTONI et al., 2007). Montoni et al. (2007) citam ainda que
o CEP auxilia no controle e implementação das melhorias nos
processos, com o objetivo de reduzir a variabilidade e alcançar
metas viáveis de qualidade, tempo e custo. Seguindo nessa linha,
Fonseca (2010) ressalta que o CEP ajuda no gerenciamento dos
processos e promove continuamente a melhoria de qualidade por
meio da redução da variabilidade dos parâmetros de controle. De
acordo com a autora, uma variabilidade mínima é inerente aos
processos, isto é, não é possível eliminar completamente a
variabilidade, porém, por meio do CEP, é possível reduzi-la.
No entanto, o uso do CEP requer esforço maior do que o despendido

na medição tradicional, portanto, não é aconselhável que todos os
processos e subprocessos 4 do processo de software sejam
controlados estatisticamente. Assim, como definir qual será o escopo
do CEP? De acordo com Montoni et al. (2007) e baseado nas
recomendações dos modelos de maturidade CMMI e MR-MPS, é
imprescindível que sejam selecionados processos que se relacionam
com objetivos de negócio ou que possuem dados históricos
relevantes para o uso do CEP. Mais detalhes sobre como realizar essa
seleção são discutidos na seção a seguir.
3.2 Selecionando processos para o uso do CEP
De acordo com Seleme e Stedler (2012), três questionamentos podem

auxiliar na seleção de qual processo é mais adequado para
avaliação e o uso do CEP: (1) O desejo e as necessidades do cliente
estão sendo satisfeitos? (2) O produto ou serviço atende às
especificações? (3) O processo de desenvolvimento está de acordo
com o planejamento?
Rocha, Souza e Barcellos (2012), por sua vez, acrescentam a esta

análise duas questões que estão mais ligadas aos objetivos de
negócio da organização, são elas: (1) O que é necessário para que o
objetivo da organização seja alcançado? (2) O que pode contribuir
para o fracasso no alcance do objetivo da organização?
Por exemplo, se uma organização tem como um de seus principais

objetivos diminuir o número de defeitos nos produtos entregues ao
cliente, os subprocessos relacionados à garantia da qualidade
devem ser o foco do CEP para que os defeitos sejam identificados
antes que os produtos sejam entregues. Porém, quando há dúvidas
sobre quais subprocessos são críticos para a organização, ou quando
muitos deles se encaixam nestes critérios, pode-se fazer uso de
alguns métodos para análise e priorização. Os métodos apresentados
neste livro para este fim são: Matriz GUT (Gravidade, Urgência,
Tendência), Diagrama de causa-efeito e Diagrama de Pareto.
Esses três métodos podem ser utilizados isoladamente ou em

conjunto, visto que o uso encadeado de alguns desses métodos
resulta em uma análise mais apurada, além de apresentar mais
informações para a tomada de decisão. Ferreira, Oliveira e Garcia
(2014), por exemplo, propõem em seu estudo de caso o uso de quatro
ferramentas para o mapeamento e priorização de falhas. O
mapeamento e priorização de falhas pode ser um critério adotado
para a seleção de um subprocesso; por exemplo, pode ser
selecionado aquele que possuir maior quantidade de falhas e/ou
falhas mais graves.
O procedimento utilizado por Ferreira, Oliveira e Garcia (2014) é

ilustrado na Figura 7. No procedimento adotado está incluso o
Diagrama de Causa-Efeito, também conhecido por Diagrama de
Ishikawa, e a Matriz GUT. Estes dois métodos, além do Diagrama de
Pareto, considerado por Rocha, Souza e Barcellos (2012) outro método
interessante para seleção dos subprocessos, são apresentados nas
seções que seguem.
Figura 6 – Exemplo de uso e sequenciamento das ferramentas de qualidade.

Fonte: Ferreira, Oliveira e Garcia (2014).
3.2.1 Matriz GUT (Gravidade, Urgência, Tendência)
A matriz GUT tem como objetivo ranquear problemas por ordem de

prioridade levando em consideração a Gravidade (G), Urgência (U) e
Tendência (T) dos itens a serem resolvidos. De acordo com Seleme e
Stedler (2012) estes fatores são definidos da seguinte forma:
Gravidade - Impacto do problema sobre coisas, pessoas,

resultados, processos ou organizações e efeitos que surgirão
em longo prazo, caso o problema não seja resolvido.
Urgência - Relação com o tempo disponível ou necessário para

resolver o problema.
Tendência - Potencial de crescimento do problema, avaliação

da tendência de crescimento, redução ou desaparecimento do
problema.
Seleme e Stedler (2012) comentam que a matriz também considera o

relacionamento entre estes três fatores de análise. Para cada item
(problema) é atribuída uma nota para os três fatores (gravidade,
urgência e tendência) que varia de 1 a 5, onde é 1 tem o menor grau
e 5 o maior grau. As linhas representam o problema e as colunas os
fatores a serem pontuados de 1 a 5. A Tabela 1 ilustra o modelo
conceitual da matriz GUT.
Tabela 1 – Modelo Conceitual da Matriz GUT
valor gravidade urgência tendência G.U.T

5 gravíssima ação agravar rapidamente 125
imediata
4 muito grave ação rápida agravar no curto prazo 64
3 grave ação normal agravar no médio 27
prazo
2 pouco grave ação lenta agravar no longo prazo 8
1 menor pode esperar acomodar 1
gravidade
Fonte: Seleme e Stedler (2012).
Conforme ilustrado, a matriz GUT determina pesos de acordo com o

nível de importância de cada fator. Dessa forma, é possível
identificar quais problemas podem impactar negativamente na
organização. Por exemplo, para um problema considerado
gravíssimo, o peso atribuído a ele é o 5 (o maior deles); se esse
problema necessitar de uma ação imediata, deve-se também atribuir
o peso 5 para a urgência e, se a tendência do problema for se
agravar no médio prazo, atribui-se um peso 3. Desse modo, o valor
da matriz GUT para o problema apresentado será de (G) 5 * (U) 5 * (T)
3, totalizando 75 pontos (SELEME; STEDLER, 2012). Um exemplo de
aplicação da matriz é apresentado no Quadro 9.
Quadro 9 – Exemplo de uso da Matriz GUT
Problema G U T G.U.T Priorização

Falta de motivação da equipe de 3 5 3 45 3
desenvolvimento do projeto
Informações contraditórias fornecidas 4 4 3 48 2
pelos clientes
Má qualificação dos desenvolvedores 5 5 3 75 1
Fonte: elaborado pela autora com base em Seleme e Stedler (2012).
No Quadro 9 apresentam-se alguns exemplos de problemas que

poderiam estar afetando uma equipe de desenvolvimento de
software. Com base nos fatores, observa-se que o problema a ser
tratado em um primeiro momento é o “Má qualificação dos
desenvolvedores”. Essa questão pode impactar negativamente na
qualidade do produto de software em desenvolvimento, portanto,
com base nesse problema, o processo que poderia ser selecionado
para controle via CEP seria um subprocesso do processo de testes.
Poderiam, por exemplo, ser mensurados a ocorrência dos bugs nos
testes, o retrabalho e o defeito no código. Além disso, ações de
melhorias para qualificação dos profissionais poderiam ser
adotadas, como, por exemplo, a realização de oficinas, workshops,
programação em par etc. O sucesso dessas ações na resolução do
problema seria observado no desempenho e comportamento do
processo estatisticamente.
3.2.2 Diagrama de causa-efeito
O diagrama de causa-efeito foi criado por Ishikawa em 1953 e tinha

como finalidade auxiliar na análise de causas de problemas (o
efeito) na produção das indústrias de manufatura (SELEME; STEDLER,
2012). O diagrama também é conhecido pelos nomes: diagrama de
Ishikawa, devido ao seu criador, ou espinha de peixe, devido a sua
representação gráfica lembrar uma espinha de peixe. A
representação gráfica do diagrama possibilita estabelecer, após uma
análise criteriosa, quais são as causas (problemas que dão início à
ocorrência do problema maior) que fazem o efeito (problema)
ocorrer. “É um diagrama que pretende mostrar a relação entre uma
característica da qualidade e seus diversos fatores determinantes”
(SELEME; STEDLER, 2012, p. 91).
O diagrama é comumente utilizado para representar o

relacionamento entre um problema (o efeito) e suas possíveis
causas. O modelo clássico do diagrama é apresentado na Figura 9.
De acordo com Seleme e Stedler (2012) dois critérios podem ser
utilizados para a construção do diagrama:
Para a identificação de causas: com base em um problema

existente, utiliza-se o diagrama para identificar as possíveis
causas de sua ocorrência. É importante, no entanto, que os
responsáveis pela construção do diagrama conheçam muito
bem o processo no qual o problema está envolvido. Os
responsáveis devem saber, ou ter em mãos, todos os dados do
processo, para que possa realmente identificar a(s) causa(s)
que deu(deram) origem ao efeito.
Para levantamento sistemático das causas: o diagrama é

utilizado para identificar sistematicamente as causas, ou seja,
estruturar o problema com vistas a sua possível resolução.
Figura 7 – Exemplo básico de Diagrama de Causa-Efeito.

Fonte: Seleme e Stedler (2012).
Alguns autores, como Ferreira, Oliveira e Garcia (2014) recomendam a

“personalização” das categorias do diagrama original de causa-
efeito, com o intuito de tornar a avaliação mais próxima do contexto
de análise. No estudo de Ferreira, Oliveira e Garcia (2014), as
categorias foram renomeadas para expressar melhor a realidade do
caso. As categorias foram renomeadas da seguinte forma: (1) Mão de
obra foi nomeada como Funcionário; (2) Método foi renomeado como
Procedimento; (3) Máquina como Equipamento e (4) Meio-ambiente
como Ambiente. Conforme observado, além de renomear algumas
categorias do diagrama original, duas delas foram extintas, entre
elas: Materiais e Medida. Ferreira, Oliveira e Garcia (2014) ressaltam
que essa alteração foi feita devido ao grau de complexidade do
problema. O diagrama utilizado por esses autores é apresentado na
Figura 8.
Figura 8 – Exemplo de Diagrama de Causa-Efeito adaptado.
Fonte: Ferreira, Oliveira e Garcia (2014).
3.2.3 Diagrama de Pareto
De acordo com Seleme e Stedler (2012), o diagrama de Pareto é uma

ferramenta desenvolvida por Joseph Juran a partir da análise e
estudos realizados pelo economista italiano W ilfredo Pareto e pelo
americano Max Otto Lorenz. Os estudos realizados estabeleciam uma
relação de 20/80 (lê-se “vinte para oitenta”). O princípio de Pareto
afirma que uma quantidade consideravelmente pequena de causas,
tipicamente, causará a grande maioria dos problemas. Esse princípio
é popularmente conhecido como princípio 80/20 (80% dos
problemas se devem a 20% das causas).
Com base nesse princípio, Juran propôs uma classificação para os

problemas de qualidade dividindo-os em poucos vitais (20) e muitos
triviais (80), ou seja, a maior quantidade dos defeitos (80% deles)
está relacionado à ocorrência de poucas causas (20% delas). Dessa
forma, o gráfico permite a identificação e classificação dos
problemas de maior importância e que devem ser corrigidos
primeiramente. Quando o primeiro problema é selecionado, um
segundo se torna mais importante. Assim, a organização pode
concentrar os seus esforços no uso adequado de seus recursos em
direção à melhoria da qualidade do processo e do produto (SELEME;
STEDLER, 2012).
Para construir o gráfico, constrói-se inicialmente uma tabela,

ordenando os defeitos (problemas ou causas) por uma quantidade
maior de ocorrências (SELEME; STEDLER, 2012). Com a quantidade
ordenada dos itens, estabelece-se as quantidades acumuladas de
defeitos em unidades e calcula-se os percentuais por defeitos e os
percentuais acumulados. Após a definição da tabela, constrói-se o
gráfico definindo dois eixos verticais, um pelo número de defeitos e
outro que varia percentualmente pelo número de defeitos. Utiliza-se
também os valores acumulados em percentuais, por meio de um
gráfico de linha, o que possibilita a visualização total de todos os
problemas de forma comparativa.
O gráfico possui a mesma estrutura de um histograma, mostrando

quantos resultados foram gerados por tipo ou categoria de causa
identificada. O item de mais destaque no gráfico, de acordo com o
conceito apresentado, é o causador do maior número de defeitos e
que, se for solucionado, será possível reduzir o maior número de
defeitos apresentados. “Portanto, além da análise, um dos maiores
benefícios trazidos pelo gráfico é o seu formato simplificado, que
torna possível sua transmissão aos funcionários com relativa
facilidade” (SELEME; STEDLER, 2012, p. 90). A Figura 9 ilustra um
exemplo de uso do Diagrama de Pareto.
Figura 9 – Exemplo de Diagrama de Pareto.
É possível realizar a construção do diagrama de Pareto para a

obtenção de dois tipos de resultados (SELEME; STEDLER, 2012, p. 90):
(1) diagrama de Pareto por causas: cujo objetivo é identificar a maior
causa do problema, (2) diagrama de Pareto por efeitos: cujo objetivo
é identificar o maior problema, que é obtido a partir dos efeitos
indesejados apresentados no processo.
Após a aplicação desses métodos, para a seleção dos subprocessos

que serão submetidos ao controle estatístico, as medidas que serão
utilizadas para analisar o comportamento do subprocesso devem ser
identificadas. Para tanto, é necessário verificar o repositório de
projetos bem como as medidas disponíveis para análise. Mais
detalhes sobre como identificar as medidas adequadas para o uso
do CEP são apresentados nas próximas seções.
3.3 Identificando medidas adequadas para o uso do CEP

As medidas utilizadas para o uso do CEP têm como finalidade
auxiliar na verificação do alcance dos objetivos de negócio e dos
projetos de software. Para tanto, recomenda-se identificar métricas
que já estejam sendo coletadas pela equipe de projeto de
software/organização (MONTONI et al., 2007). Isso porque estabelecer
quais são as medidas, coletá-las e armazená-las adequadamente,
requere esforço. Assim, o ideal é que o CEP faça uso de medidas que
já estão sendo coletadas pela organização e que estão sendo
corretamente armazenadas em um repositório, de acordo com os
procedimentos de medição estabelecidos no plano de medição.
Quando as métricas necessárias para o uso do CEP não estão
disponíveis então será necessário revisar o plano de medição,
seguindo os critérios indicados no Capítulo 2, a fim de adicioná-las
no plano de medição e iniciar a execução do novo plano e a coleta
dessas medidas. É importante ressaltar que essas medidas devem
constar no plano de medição, pois ele garante o alinhamento com os
objetivos de negócio da organização.
Para auxiliar na definição das métricas adequadas para o uso do CEP

pode-se adotar os passos sugeridos por Rocha, Souza e Barcellos
(2012):
1. Definir as medidas seguindo a abordagem do GQM Strategies,

além do critério das cinco métricas essenciais indicados por
Putnam e Myers (2003), sendo elas: quantidade de funções
(tamanho), produtividade, tempo, esforço e confiabilidade.
2. Após a identificação das medidas, o próximo passo é definir os

procedimentos de coleta e armazenamento dos dados destas
medidas, isto é, como será a obtenção dos dados que serão
utilizados nas medições e onde estes ficarão armazenados.
3. O passo seguinte é a especificação dos procedimentos para

análise dos dados coletados para as medidas. Esta definição
deve ser feita antes de se iniciar a execução de medições, para
garantir que a análise seja realizada de forma correta e os
resultados sejam relatados de forma a tratar os objetivos de
medição estabelecidos e as necessidades de informação.
4. Por fim, elabora-se a definição operacional da medida

sumarizando todos os detalhes de informação em relação a ela
e, na sequência, a organização está apta para iniciar a fase
operacional da medição, que envolve coleta, análise e
armazenamento de dados e resultados das análises. Um
exemplo de definição operacional para uma medida é
ilustrado no Quadro 10.
Quadro 10 – Modelo para definição operacional de medidas para o CEP
Item D efinição Exemplo de uso

Nome Nome da medida Precisão da
Estimativa de Tempo
da Fase
Especificação e
Análise de
Requisitos do
Sistema.
Definição Descrição sucinta da medida. Medida utilizada
para quantificar a
precisão da
estimativa de
duração da fase
Especificação e
Análise de
Requisitos do
Sistema.
Mnemônico Sigla utilizada para identificar PET-EAR
a medida.
Tipo de Classificação da medida Medida Derivada.
Medida quanto a sua dependência
funcional, podendo uma
medida ser uma medida base
ou uma medida derivada.
Entidade Entidade que a medida mede. Subprocesso
Medida Exemplos: organização, projeto, Planejamento do
processo, atividade, recurso Projeto.
humano, recurso de hardware,
recurso de software e artefato,
dentre outros.
Propriedade Propriedade da entidade Precisão da
Medida medida que é quantificada estimativa de tempo.
pela medida. Exemplos:
tamanho, custos, defeitos,
esforço etc.
Unidade de Unidade de medida em Tempo em Horas.
Medida relação à qual a medida é
medida. Exemplos:
pessoa/mês, pontos por
função, reais etc.
Tipo de Natureza dos valores que Absoluta.
Escala podem ser atribuídos à
medida. Exemplos: escala
nominal, escala intervalar,
escala ordinal, escala absoluta
e escala taxa.
Valores da Valores que podem ser Números reais
Escala atribuídos à medida. positivos, utilizando-
Exemplos: números reais se precisão de duas
positivos{alto, médio, baixo}etc. casas decimais.
Para medidas com escala do
tipo absoluta ou taxa, ao
determinar os valores da
escala, é preciso identificar a
precisão a ser considerada (0,
1 ou 2 casas decimais).
Intervalo Limites de valores da escala [0.8, 1.0]
Esperado dos definida de acordo com dados
Dados históricos ou com metas
estabelecidas. Exemplo: [0, 10].
Procedimento Descrição do procedimento PET-EAR=TE-EAR/TR-
de Medição que deve ser realizado para EAR
coletar uma medida. A Onde: TR-EAR=tempo
descrição do procedimento de real despendido em
medição deve ser clara, atividades da fase
objetiva, não ambígua e deve Especificação e
incluir onde os valores Análise de
medidos devem ser Requisitos do
registrados. Sistema no período
considerado; TE-
EAR=tempo estimado
para atividades da
fase Especificação e
Análise de
Requisitos do
Sistema no período
considerado.
Fórmula de Fórmula utilizada no Calcular a precisão
Cálculo de procedimento de medição de da estimativa de
Medida medidas derivadas, para tempo utilizando a
calcular o valor atribuído à fórmula de cálculo
medida considerando-se sua da medida.
relação com outras medidas
ou com outros valores.
Exemplo: aderência ao
cronograma=tempo real /
tempo estimado.
Responsável Papel desempenhado pela Analista de
pela Medição pessoa responsável pela coleta Sistemas.
da medida. É importante que o
responsável pela medição seja
fonte direta das informações a
serem fornecidas na medição.
Exemplos: analista de
sistemas, programador,
gerente do projeto etc.
Momento da Momento em que deve ser Ao final da semana,
Medição realizada a coleta e registro de na Atividade
dados para a medida. O Registrar Dados
momento da coleta deve ser para Monitoramento
uma atividade do processo do Projeto.
definido para os projetos ou
de um processo
organizacional. Exemplos: na
atividade Homologar
Especificação de Requisitos,
na atividade Realizar Testes de
Unidade etc.
Periodicidade Frequência de coleta da Semanal.
de Medição medida. Exemplos: diária,
mensal, uma vez por fase, uma
vez por projeto, uma vez em
cada ocorrência da atividade
designada como momento da
medição etc. É indispensável
que haja coerência entre a
periodicidade de medição e o
momento de medição.
Procedimento Descrição do procedimento Representar em um
de Análise que deve ser realizado para gráfico de controle
representar e analisar os os valores coletados
dados coletados para uma para a medida no
medida, incluindo, além do projeto. Analisar o
procedimento propriamente comportamento do
dito, as ferramentas analíticas processo em relação
que devem ser utilizadas (por à linha de base de
exemplo: histograma, gráfico desempenho
de controle etc.). A descrição estabelecida para o
do procedimento de análise processo:
deve ser clara, objetiva e não (i) Se os valores
ambígua. coletados para a
medida
encontrarem-se
dentro dos limites
da linha de base de
desempenho, o
processo apresenta
comportamento
adequado.
(ii) Se houver
valores fora dos
limites da linha de
base, o
comportamento do
processo não está
adequado. É
necessário
investigar as causas
da instabilidade no
comportamento do
processo e
identificar ações
corretivas, quando
pertinente.
Momento da Momento em que deve ser Atividade Analisar
Análise de realizada a análise de dados Desempenho dos
Medição coletados para a medida. O Processos do
momento da análise deve ser Projeto.
uma atividade do processo
definido para os projetos ou
de um processo organizacional
como, por exemplo, em
atividades de monitoramento
de projeto.
Periodicidade Frequência de análise de Semanal.
da Análise dados da medida. Exemplos:
diária, mensal, uma vez por
fase, uma vez por projeto, uma
vez em cada ocorrência da
atividade designada como
momento da análise etc. É
indispensável que haja
coerência entre a
periodicidade de análise de
medição e o momento da
análise de medição.
Responsável Papel desempenhado pela Gerente do Projeto.
pela Análise pessoa responsável pela
análise da medida. É
importante que o responsável
pela análise de medição seja
apto a aplicar o procedimento
de análise e tenha
conhecimento organizacional
que propicie a correta
interpretação dos dados e
fornecimento de informações
que apoiem as tomadas de
decisão. Exemplos: gerente do
projeto, gerente de qualidade
etc.
Fonte: elaborado pela autora com base em Rocha, Souza e Barcellos (2012).
Utilizar o CEP sem vislumbrar os benefícios reais da medição e sua
evolução, impacta em medidas inúteis ao pensamento estatístico.
Como consequência, será necessário despender tempo e recursos
para “arrumar a casa” antes de, efetivamente, realizar o controle
estatístico de processos. O CEP requer processos caracterizados por
medidas válidas e dados de qualidade que possam ser utilizados
para analisar o comportamento e a previsibilidade dos processos.
Quando uma organização não visa ao controle estatístico é muito
provável que precise realizar adequações nas medidas definidas e
nos dados coletados. Muitas vezes necessita também definir novas
medidas e coletar mais dados para, só então, iniciar as práticas do
controle estatístico (ROCHA; SOUZA; BARCELLOS, 2012).
Para aprofundar os conhecimentos sobre o CEP recomenda-se a

leitura de Louzada et al. (2013). Para verificar mais detalhes sobre a
aplicação do CEP na área da Engenharia de Software, indica-se a
leitura de Fonseca (2010) e de Rocha, Souza e Barcellos (2012). Mais
detalhes sobre ferramentas essenciais para a qualidade que podem
auxiliar na definição de processos a serem tratados pelo CEP, entre
elas as ferramentas apresentadas na Figura 7, sugere-se a leitura de
Seleme e Stedler (2012). Por fim, sugere-se a leitura de Montoni et al.
(2007) para avaliação de um modelo de desempenho de processos
de desenvolvimento de software com base no gerenciamento
quantitativo de projetos e uso de CEP.
Resumo do capítulo
Controlar a qualidade dos produtos gerados pelos processos de

desenvolvimento de software podem auxiliar as empresas a se
destacar em seu segmento, além de atingir os objetivos de negócio
definidos. Um método que auxilia no controle e avaliação da
qualidade, com base em estatística, é o CEP. O CEP tem como
finalidade a verificação da variabilidade de um processo e, com base
nesse resultado, permitir às organizações estabelecerem ações de
melhorias para a redução dessa variabilidade. Ao fazer uso do CEP é
possível realizar o controle do processo e a qualidade dos produtos
gerados durante toda a execução do processo. Isso permite a
avaliação das informações e adoção de medidas corretivas durante
todo o processo e não somente após a entrega do produto – na
famosa etapa de lições aprendidas proposta pelo gerenciamento de
projetos. No entanto, utilizar CEP requer um esforço maior do que a
medição tradicional. Por isso, é importante selecionar apenas os
processos críticos, além de medidas adequadas ao CEP que estejam
alinhadas aos objetivos de negócio, para que seja possível se
beneficiar dos procedimentos e resultados do controle estatístico de
processos.
__________
3. Uma causa atribuível é uma causa que poderia ter sido prevenida, não tendo sua origem em um
fenômeno natural e inerente ao processo (FLORAC; CARLETON, 1999).
4. Subprocessos são componentes de um processo maior. Por exemplo, um processo de

desenvolvimento de software típico de uma organização é composto pelos subprocessos:
desenvolvimento de requisitos, revisão por pares, teste de integração etc.
CAPÍTULO 4
Introdução aos gráficos de controle do CEP
–
Neste capítulo é feita uma introdução acerca dos gráficos de controle
que podem ser utilizados para o controle estatístico dos processos de
software. É apresentado o conceito de variação e de que forma esta
variação pode impactar na estabilidade dos processos. São
demonstrados os dois tipos de causas que podem ser observadas nos
gráficos de controle, bem como são apresentadas a definição e as
principais características dos gráficos de controle. Por fim, um resumo
sobre os gráficos de controle existentes e exemplos de sua aplicação
são ilustrados.
4.1 Introdução
Conforme apresentado no capítulo anterior, o CEP é uma ferramenta

que usa a estatística para gerenciar os processos e promover
continuamente a melhoria de qualidade através da redução da
variabilidade dos parâmetros de controle. Também foi mencionado
que alguma variabilidade é inerente aos processos, não sendo
possível eliminá-la inteiramente, mas é intenção do CEP auxiliar a
reduzi-la.
De acordo com Montgomery e Runger (2012), a qualidade é

inversamente proporcional à variabilidade, portanto, quanto menor a
variabilidade maior é a qualidade dos produtos e processos. Para
avaliar a variação total de um processo, Florac e Carleton (1999)
recomendam a seguinte análise:
Va ria çã o Tota l
=Variação devido às ca usa s a lea tória s
+ Variação devido às ca usa s a tribuíveis

De acordo com Fonseca (2010), a variação relacionada às causas
aleatórias, também conhecidas como causas comuns, é inerente ao
processo, graças às interações de seus componentes (pessoas,
equipamentos, processos, métodos, materiais) e são inevitáveis. Os
processos que têm apenas causas aleatórias são considerados
processos estáveis, onde há variações randômicas, porém, essas
causas ocorrem dentro de um intervalo previsível, uma variação
conhecida. Florac e Carleton (1999) mencionam que um processo
previsível é um processo sob controle, portanto sua variação fica
dentro dos limites conhecidos. A Figura 10 ilustra um exemplo de
variação controlada. Com base na Figura 10 observa-se que a
variação no tempo não é representativa.
Figura 10 – Variação controlada.

Fonte: Fonseca (2010).
Em relação às causas atribuíveis, ou causas especiais, segundo o

PMBOK (PMI, 2014), estas dizem respeito aos eventos que não fazem
parte do processo. Geralmente estão relacionadas a mudanças
repentinas ou anormais em um ou mais componentes do processo. O
gerenciamento quantitativo efetivo do processo pode detectar esse
tipo de causa e, em alguns casos, pode até prevenir sua ocorrência,
principalmente em situações onde se faz o uso de controle estatístico
e a análise de tendências.
De acordo com Fonseca (2010), na ocorrência de uma ou mais

medidas fora dos limites de variação estimados, o processo é
identificado como instável, ou seja, não está sob controle e as causas
devem ser investigadas. Nesse sentindo, é necessário tomar
providências para investigar as causas além de tratar futuras
ocorrências. Florac e Carleton (1999) mencionam que as causas
atribuíveis alteram a média e a distribuição dos valores medidos.
Quando isso ocorre as amostras variam sem limites conhecidos. A
Figura 11 ilustra um exemplo de variação não controlada. Observando
a Figura 11 é nítida a ocorrência de representativa variação no tempo.
Figura 11 – Variação não controlada.

De acordo com Boffoli, Baldassarre e Caivano (2010), a ocorrência das

causas atribuíveis em processos de software são devido a:
pessoas e ao processo de produção do software, que é

totalmente baseado em atividades cognitivas;
a complexidade na medição do software, pois a medição em si

pode introduzir mais variação do que o próprio processo;
as métricas de tamanho não contam unidades discretas e
idênticas.
De forma geral, a principal finalidade do CEP é monitorar a

variabilidade e verificar se ela é constante ao longo do tempo. Esse
monitoramento pode ser feito por meio dos gráficos de controle,
apresentados na seção a seguir.
4.2 Gráficos de controle
Uma das principais características do uso do CEP é o seu controle e

monitoramento de forma visual por meio do uso de gráficos de
controle aplicados sobre coletas frequentes de dados (MONTONI et
al., 2007). Conforme apresentado na seção anterior, os gráficos de
controle baseiam-se na teoria de que as variações inerentes ao
processo variam dentro de limites previsíveis. Por isso, de acordo
com W heeler (1999), o CEP é um método eficiente para detectar
mudanças e identificar causas atribuíveis que afetam a qualidade
do processo. “Um gráfico de controle é uma maneira valiosa de
examinar a variabilidade em dados orientados no tempo”
(MONTGOMERY; RUNGER, 2012, p. 7-8).
Os gráficos de controle são uma importante ferramenta estatística

que possibilita monitorar, controlar e melhorar um processo
(MONTGOMERY; RUNGER, 2012). Esses gráficos são utilizados para
monitorar a estabilidade dos processos, identificar necessidade de
ações de melhoria para a redução da variabilidade e estimar os
parâmetros do processo ou do produto. Como exemplos de
parâmetros do processo ou do produto estimados pelos gráficos de
controle pode-se citar: a capacidade, a média (μ), o desvio padrão (σ)
ou a variância (σ2), a fração de não conformidades, entre outros
(FONSECA, 2010).
É importante, no entanto, que o uso dos gráficos de controle seja

planejado, quando da definição do plano de medição e medidas
adequadas para o uso de CEP, pois, desta forma, os gráficos serão
eficientes em detectar confiavelmente condições de “fora de
controle”. Porém, um gráfico de controle indica apenas se o processo
está ou não sob controle, por meio da representação de causas
aleatórias e atribuíveis (FONSECA, 2010). Além disso, quando se
observa a ocorrência de causas atribuíveis, é necessário realizar uma
investigação para identificar e avaliar qual a origem dessas causas e
como elas podem ser eliminadas do processo. As ferramentas
essenciais da qualidade apresentadas no Capítulo 3 podem auxiliar
nesta investigação.
Para fazer uso dos gráficos de controle é necessário realizar a

definição dos limites de controle, o tamanho da amostra, a
frequência da amostragem e os testes de estabilidade. Levando em
consideração que o CEP tem como propósito identificar mudanças
que ocorrem em determinados períodos nos parâmetros do processo,
são calculados dois valores de referência para cada um desses
parâmetros. Esses valores são os denominados limites de controle.
Assim, para cada amostra disponível deve-se calcular uma estimativa
para esses parâmetros e, a seguir, verificar se tais estatísticas se
encontram entre os limites de controle (LOUZADA et al., 2013).
Um gráfico de controle possui uma linha central (LC) que representa

o valor médio da característica de qualidade, a linha superior que
representa o Limite Superior de Controle (LSC) e a linha inferior que
representa o Limite Inferior de Controle (LIC) (FONSECA, 2010). A
Figura 12 ilustra um exemplo básico de gráfico de controle. É
importante destacar que todos os gráficos de controle seguem essa
mesma estrutura.
Figura 12 – Exemplo básico de gráfico de controle.
O limite superior de controle e o limite inferior de controle

representam um par de limites derivados estatisticamente que
refletem a variabilidade inerente ou natural no processo
(MONTGOMERY; RUNGER, 2012). Esses limites estão localizados a três
desvios-padrão dos valores de concentração acima e abaixo da linha
central. Se o processo estiver operando de forma adequada, sem
quaisquer fontes externas de variabilidade presentes no sistema, as
medidas de concentração deverão flutuar aleatoriamente ao redor da
linha central e quase todos os pontos deverão estar entre os limites
de controle.
Os gráficos de controle fornecem uma regra de decisão muito

simples: pontos dispostos fora dos limites de controle indicam que o
processo está “fora de controle”. Caso contrário, se todos os pontos
dispostos estão dentro dos limites e dispostos de forma aleatória,
considera-se que “não existem evidências de que o processo esteja
fora de controle”. A Figura 13 ilustra um exemplo de dois gráficos de
controle: (1) representando um processo estável, neste caso com os
pontos flutuando entre os limites de controle e (2) um processo com
variação, com dois pontos destacando-se fora dos limites de controle
estabelecidos.
Figura 13 – Exemplo de (1) processo estável e (2) processo com variação.

Para analisar os gráficos, é importante considerar o que Louzada et

al. (2013, p.4) indicam:
ao observar uma ou mais estatísticas fora dos limites de controle, é
razoável verificar se houve alguma alteração nas condições de ocorrência do
processo que justifique uma mudança em seus parâmetros ou se
simplesmente ocorreu um alarme falso, isto é, um item foi produzido com
baixo rendimento de qualidade apenas em razão da natureza aleatória da
medida de qualidade mensurada.
Dessa forma, para processos considerados estáveis, pode-se também

realizar alguns testes para detectar a existência de variação devido a
causas atribuíveis. Sotille (2014) indica o uso da regra dos sete como
um teste para este fim. De acordo com essa regra prática (heurística),
se sete ou mais ocorrências consecutivas ocorrem do mesmo lado da
média (ou se elas seguem na mesma direção), mesmo que elas
estejam dentro dos limites de controle, devem ser investigadas como
se fossem uma causa atribuível. É muito improvável que as sete
ocorrências consecutivas estivessem no mesmo lado da média se o
processo estivesse operando normalmente. A probabilidade de se ter
7 pontos em sequência de um mesmo lado da média é de 0,5 (50%
de chance para cada lado) elevado à sétima potência, que é igual a
0,0078 (SOTILLE, 2014). A Figura 14 ilustra o teste da regra dos sete
aplicado a um gráfico de controle.
Figura 14 – Exemplo da regra dos sete aplicado ao gráfico de controle.
Fonte: Adaptado de Sottile (2014).
Além do teste da regra dos sete pode-se também fazer uso de outros
testes, como os 4 tipos de testes para detecção de situação “fora de
controle” propostos por Florac e Carleton (1999) mais os 6 tipos
acrescentados por Montgomery e Runger (2012) a esse conjunto de
testes. Esses 10 tipos de testes são apresentados no Quadro 11 a
seguir e a Figura 15 ilustra a aplicação dos 4 testes de Florac e
Carleton (1999) ao gráfico de controle.
Quadro 11 – Os 10 tipos de testes para detecção de situação “fora de controle”
Teste D efinição
Teste 1 Um ponto localizado fora dos limites de controle 3σ
Pelo menos dois pontos de três pontos consecutivos
Teste 2
localizados entre 2σ e 3σ
Pelo menos quatro pontos de cinco pontos
Teste 3
consecutivos localizados entre 1σ e 2σ
Pelo menos oito pontos consecutivos localizados de
Teste 4
um mesmo lado da linha central (LC)
Seis pontos em uma sequência crescente ou
Teste 5
decrescente
Quinze pontos em sequência entre a linha central LC
Teste 6
e 1σ (conhecido como zona C)
Quatorze pontos em sequência alternadamente para
Teste 7
cima e para baixo
Oito pontos em sequência de ambos os lados da
Teste 8 linha central com nenhum entre a linha central LC e
1σ
Teste 9 Um padrão não usual ou não aleatório de dados
Teste 10 Um ou mais pontos perto de um limite de alerta ou
de controle
Fonte: elaborado pela autora com base em Montgomery e Runger (2012).
Figura 15 – Exemplo dos 4 testes de Florac e Carleton aplicados ao gráfico de controle.

Montgomery e Runger (2012) citam algumas razões para a

popularidade dos gráficos de controle:
Técnica comprovada para a melhoria da produtividade. Um

plano de medição com medidas adequadas ao uso do CEP,
bem como a correta aplicação do CEP para análise dos
processos, reduz retrabalho causando o aumento de
produtividade, a redução dos custos e o aumento da
capacidade de produção.
Os gráficos de controle são eficazes no apoio à prevenção de

defeitos.
Por meio dos gráficos de controle é possível evitar ajustes

desnecessários no processo. Por meio do CEP é possível
verificar o tipo de variação do processo, se é uma variação
inerente ao processo ou relacionada a causas atribuíveis que
necessitam serem investigadas e, consequentemente, se ações
de melhoria devem ser adotadas.
Os gráficos de controle fornecem informação para diagnóstico,

além de informação sobre a capacidade do processo.
O primeiro passo, antes de utilizar os gráficos de controle, deve ser a

escolha do tipo de gráfico de controle a ser utilizado. Para tanto,
deve-se identificar o tipo de dados que será tratado. Os gráficos de
controle podem ser aplicados a duas classes diferentes de dados:
dados de variáveis e dados de atributos. Mais detalhes acerca desses
tipos de dados e dos tipos de gráficos para a análise desses dados
são apresentados na seção a seguir.
4.3 Tipos de gráficos de controle
De acordo com Louzada et al. (2013), quando as medidas utilizadas no

CEP são quantitativas ou numéricas, está se utilizando dados do tipo
variáveis, e, portanto, está se realizando o controle de variáveis do
processo. Dados de variáveis são medidas de fenômenos contínuos,
como: esforço, tempo e custo. Por outro lado, quando se observa uma
determinada característica do processo, projeto ou mesmo do
produto de software, portanto uma medida qualitativa, está se
utilizando dados do tipo atributo e, consequentemente, realizando o
controle de atributos do processo.
Os gráficos de controle podem ser usados tanto para dados do tipo

variáveis quanto para dados do tipo atributos. Florac e Carleton
(1999) definem as seguintes características para cada tipo de dado e
gráfico de controle:
Gráfico de controle para variáveis:
São usados para controlar características da qualidade

expressas como números em alguma escala contínua de
medida, por exemplo: tempo gasto, esforço realizado (em
horas), custo de retrabalho, utilização de memória/CPU –
isto é, são utilizadas medidas em incrementos.
Gráfico de controle para atributos:
São usados para controlar os defeitos das características

qualitativas avaliadas, podendo ser classificadas como
conforme ou não conforme.
O número de não conformidades é avaliada por

unidade, por exemplo: número de defeitos, número de
linhas de código por módulo etc.
Existem vários gráficos de controle que podem ser utilizados, tanto

para dados variáveis quanto para dados de atributos (LOUZADA et al.,
2013). Essa situação torna a seleção do gráfico de controle uma tarefa
complexa. Por isso, ressalta-se a necessidade de planejamento
adequado antes de iniciar o uso do CEP. Um resumo sobre os
principais gráficos que podem ser utilizados no contexto de projetos
de software e um breve exemplo de seu uso é apresentado no
Quadro 12 a seguir.
Quadro 12 – Tipos de gráficos de controle
Tipo
de Característica Exemplo
Gráfico
Para dados variáveis
X-bar e Adequado para analisar o Um gerente deseja
R comportamento do processo analisar a quantidade de
através de sub-agrupamentos horas semanais que são
de medidas obtidas, dedicadas em atividades
basicamente, sob as mesmas de manutenção. As horas
condições, em determinados de trabalho com
períodos de tempo. O gráfico X- manutenção são
bar (average) analisa a média registradas diariamente.
dos valores em cada sub- Para uma análise
agrupamento e o gráfico R semanal, os dados devem
(range) indica a variação ser sub-agrupados por
interna dos subgrupos. Se semana. Cada subgrupo
limita a subgrupos formados tem 5 observações (uma
por até 10 observações. para cada dia da semana).
X-bar e Aplicado nas mesmas situações Um gerente deseja
S que XbarR, mas também analisar a taxa de
considera subgrupos com mais inspeção de código das
de 10 observações. releases de um de seus
produtos. O produto tem 5
releases e em cada uma
delas foram realizadas 13
inspeções. Como a análise
desejada é por release, os
dados devem formar 5
subgrupos de 13
observações.
XmR Adequado para analisar o Um gerente deseja
comportamento de um analisar o esforço diário
processo quando uma mesma despendido com
medida é coletada manutenção no último
frequentemente. Nesse tipo de mês. Os dados do esforço
gráfico de controle o gráfico X são registrados
representa os valores diariamente. Nesse caso, o
individuais das medidas gerente deseja analisar
analisadas e o gráfico mX uma única variável
(moving range) representa a (esforço) medida
variação móvel existente entre frequentemente, sem
dois valores consecutivos. necessidade de criar
subgrupos.
XMmR Similar ao XmR, porém para Um gerente deseja
analisar as variações, é analisar o esforço diário
utilizada a mediana (XmR usa a despendido com
média), que pode ser mais manutenção no último
sensível às causas especiais, mês e observa que, entre
principalmente quando a os valores coletados, há
variação móvel (moving range) três que destoam
possui alguns valores que consideravelmente de
podem elevar ou diminuir os seus antecessores.
limites desnecessariamente.
mXmR Segue a mesma filosofia dos Um gerente de projetos de
gráficos XmR e XMmR, porém, software deseja analisar o
além de considerar a variação progresso do
móvel (moving range), desenvolvimento das
considera a média móvel unidades de um software.
(moving average). É adequado Para isso, mensalmente,
para avaliar as tendências do devem ser consideradas,
comportamento dos processos acumuladamente, as
ao longo do tempo, unidades que foram
considerando valores concluídas desde o início
acumulados. do projeto até o momento
atual.
Para dados atributos
C Chart Adequado para representar a Um gerente de projetos de
contagem de eventos em áreas software deseja analisar a
de observação constantes. quantidade de falhas de
um determinado software
registradas diariamente.
U Chart Adequado para representar a Um gerente de projetos de
contagem de eventos que software deseja analisar a
podem ser medidos em áreas quantidade de defeitos
de observação diferentes. Por encontrados por módulo
esse motivo, os limites de em um determinado
controle superior e inferior são software, sendo que cada
calculados para cada módulo tem um tamanho
observação. Antes de ser diferente.
realizada a comparação entre
os valores coletados eles
devem ser transformados em
taxas.
Z Chart Converte os valores de um U Idem U Chart.
Chart para a escala baseada
em sigma. É adequado para
visualizar tendências à
instabilidade no
comportamento do processo
por ser mais sensível quando
há grandes diferenças entre os
valores das observações.
XmR e Idem XmR e XMmR para dados variáveis, porém, aplicados

XMmR a dados atributos.
Detalhes sobre os exemplos para cada tipo de gráfico extrapolam o

contexto e escopo deste livro. Dessa forma, aconselha-se a revisão
dos exemplos apresentados em Rocha, Souza e Barcellos (2012).

Para aprofundar os conhecimentos sobre os gráficos de controle do
CEP sugere-se a leitura de Louzada et al. (2013). Recomenda-se a
leitura de Rocha, Souza e Barcellos (2012) para mais detalhes e
exemplos sobre o uso dos gráficos de controle aplicados em
processos de software. Aconselha-se a revisão de Fonseca (2010) e de
seu modelo CEP-S, um modelo de CEP aplicado a pequenas
empresas de desenvolvimento de software. Para mais detalhes sobre
os testes de detecção para situações fora de controle, sugere-se a
revisão de Montgomery e Runger (2012).
Resumo do capítulo
Conforme apresentado, o CEP é uma ferramenta que faz uso da

estatística para auxiliar no controle e monitoramento de situações
“fora de controle” nos processos. Por meio desse controle é possível
analisar o comportamento do processo e a qualidade dos produtos
gerados e, quando necessário, propor ações de melhorias com o
intuito de redução da variabilidade do processo, principalmente no
que diz respeito às causas atribuíveis identificadas. Para auxiliar no
monitoramento, faz-se, então, uso dos gráficos de controle. Por meio
dos gráficos de controle é possível verificar, de forma visual, como
está a estabilidade dos processos. Entre os tipos de gráficos de
controle que podem ser utilizados apresentam-se os gráficos para
controle de variáveis do processo e os gráficos para o controle dos
atributos do processo. Esses tipos de gráficos auxiliam na avaliação
da variabilidade do processo e detecção de situações “fora de
controle”. No entanto, ressalta-se novamente que fazer uso do CEP e
dos gráficos de controle exige esforço por parte da organização, por
isso, recomenda-se cautela e a atenção devida para os objetivos de
negócio e do projeto durante o planejamento para o seu uso efetivo.
CAPÍTULO 5
Controlando estatisticamente os
processos para gerenciar
quantitativamente os projetos
–
Este capítulo tem como objetivo esclarecer a relação entre o CEP e o
gerenciamento quantitativo de projetos de software. Para tanto, são
reforçadas a definição básica de projeto bem como as principais
características que o aproxima do processo. Também é apresentada a
inter-relação entre o CEP e o gerenciamento quantitativo de projetos.
Por fim, é apresentada uma abordagem que possibilita a adoção de
um programa de melhoria contínua para processos de software com
base no CEP.
5.1 Introdução
Nos capítulos anteriores foram apresentados e discutidos os

principais conceitos, métodos e ferramentas que possibilitam o
gerenciamento quantitativo de projetos de software. Entre os
métodos e ferramentas, abordou-se o CEP como suporte para avaliar
os processos e detectar se os objetivos dos projetos e de negócio
estão sendo alcançados. Conforme apresentado no Capítulo 1, existe
uma diferença clara entre processo e projeto. O projeto trata-se de
uma instância do processo e tem início e fim definidos. Dessa forma,
todas as características definidas para o processo como as atividades
e os papéis, por exemplo, serão refletidas durante a execução do
projeto.
Para exemplificar, considere o processo de desenvolvimento de

software com as seguintes atividades genéricas e independentes de
modelo de processo de desenvolvimento de software utilizado5:
Requisitos, Análise e Projeto, Codificação e Testes. Tomando como
base a atividade genérica: Requisitos, que pode também ser
considerada um subprocesso do processo de desenvolvimento de
software, este subprocesso pode possuir a seguinte definição de
processo, conforme ilustrado no Quadro 13.
Quadro 13 – Definição do subprocesso: requisitos
Item D efinição
Nome Requisitos
Propósito Entender o problema a ser resolvido
Entender as necessidades dos stakeholders (o que
os usuários desejam)
Definir os requisitos para a solução (o que o
sistema tem que fazer)
Definir os limites (escopo) do sistema
Identificar interfaces externas ao sistema
Identificar restrições técnicas na solução
Fornecer a base para o planejamento das
iterações
Fornecer a base inicial para a estimativa de custo
e cronograma
Para alcançar estes objetivos, é importante
compreender a definição e o escopo do problema
que se está tentando resolver. Os stakeholders são
identificados e o problema a ser resolvido é
definido.
Concordando com o problema a ser resolvido, os
Requisitos para o sistema são eliciados, organizados,
analisados, validados e especificados.
Durante todo o ciclo de vida, as mudanças nos
requisitos são gerenciadas.
Entradas Necessidades e restrições para o produto de software
Saídas Requisitos do software especificados
Clientes Stakeholders (clientes e usuários chave)
Patrocinadores
Equipe de Desenvolvimento de Software
Fornecedores Stakeholders (clientes e usuários chave)

Patrocinadores
Atividades Elicitação
Análise
Validação
Especificação
Gerenciamento dos Requisitos
Papéis Analista de Requisitos
Funcionais Usuário-Chave
Gerente de Projetos
Fonte: elaborado pela autora com base no OpenUP6.
Conforme apresentado no Quadro 13, o subprocesso de Requisitos

definido possibilita que qualquer projeto de software a ser
executado utilize essa estrutura padrão para a etapa de Requisitos.
Dessa forma, caso esse processo seja selecionado como um processo
crítico pela organização e comece a ser mensurado, será possível
avaliar com base no CEP como foi o comportamento e capacidade
desse processo nos últimos projetos executados, além de auxiliar a
verificar se o projeto em andamento está dentro dos limites de
variação estabelecidos.
A relação entre o CEP e o gerenciamento quantitativo de projetos é

constante e via de mão-dupla. No contexto da melhoria de processos
de software, o CEP pode ser utilizado nos âmbitos organizacional e
dos projetos. No nível organizacional ocorre a gerência estatística
dos processos: o desempenho dos processos é analisado para que
seja possível identificar o comportamento esperado para os
processos, quando forem executados nos projetos. Os dados
coletados ao longo dos projetos são utilizados para descrever o
comportamento dos processos da organização (ROCHA, SOUZA;
BARCELLOS, 2012).
No nível dos projetos, por sua vez, ocorre a gerência quantitativa dos
projetos, que consiste em gerenciar o desempenho dos processos
nos projetos, utilizando linhas de base e modelos de desempenho
estabelecidos no nível organizacional. Dessa forma, em cada projeto,
o desempenho dos processos no projeto é comparado com o
desempenho para ele esperado e, caso não seja condizente, ações
corretivas devem ser realizadas. O planejamento do projeto pode ser
realizado utilizando os modelos de desempenho definidos no nível
organizacional (ROCHA, SOUZA; BARCELLOS, 2012).
Portanto, a gerência estatística de processos, por meio do CEP produz

resultados que são utilizados como insumos pela gerência
quantitativa de projetos e vice-versa. Esta situação é ilustrada por
meio da Figura 18.
Figura 16 – Relação entre o CEP e o Gerenciamento Quantitativo de Projetos.

Conforme observado, o CEP é uma importante ferramenta que pode

ser utilizada no suporte para a melhoria dos processos e projetos de
software de uma organização. No entanto, é importante ressaltar que
utilizar o CEP não deve ser uma ação isolada. É imprescindível que o
uso do CEP esteja alinhado a um contexto como um programa de
melhoria de processos, por exemplo, caso contrário, sua efetividade
e benefícios podem ficar limitados a resultados pontuais (ROCHA,
SOUZA; BARCELLOS, 2012). Nesse sentido, a organização pode
estabelecer um programa de melhoria contínua na organização.
Florac e Carleton (1999) apresentam uma abordagem interessante
que pode ser utilizada com este propósito. Mais detalhes sobre essa
abordagem são apresentados na seção a seguir.
5.2 Abordagem para melhoria contínua de processos de software
Antes de instituir um programa de melhoria para processos de

software, é importante compreender quais são os critérios que
devem ser considerados para a melhoria dos processos. Florac e
Carleton (1999) apresentam cinco aspectos relacionados a esta
questão. Estes aspectos são apresentados a seguir:
D esempenho: para melhorar um processo é preciso conhecer

seu desempenho, ou seja, é preciso saber o que o processo
está produzindo no momento em relação a qualidade,
quantidade, custos e tempo.
Estabilidade: conhecido o desempenho, é preciso analisar se
ele é previsível, ou seja, se o processo é estável e, se não for, é
preciso estabilizá-lo.
Conformidade: a estabilidade de um processo é obtida

quando seu comportamento é repetível dentro de limites de
variação estabelecidos. Para isso, é preciso garantir que o
processo seja apoiado suficientemente para que sua execução
possa ser repetida por membros distintos da organização. Tal
apoio inclui, dentre outros, definição clara e completa das
atividades do processo e ferramental de suporte a sua
execução.
Capacidade: um processo estável não necessariamente é capaz

de alcançar os objetivos para ele determinados. O processo
pode estar, por exemplo, repetindo um comportamento não
conforme e inadequado para o alcance dos objetivos de
negócio e de projeto. Processos não capazes devem ser
modificados através da realização de ações de melhoria que
apoiem o alcance aos objetivos da organização.
Melhoria: processos capazes, que produzem resultados

satisfatórios, podem, ainda, ser melhorados para que
resultados ainda melhores sejam produzidos. Apenas deve-se
ter atenção e cuidado ao implementar mudanças no processo,
pois ajustes em um processo podem repercutir no aumento da
variação do processo. Segundo Montgomery e Runger (2012),
melhorias são sempre bem-vindas mas devem ser observados
os seus resultados, pois efeitos contrários (adversos) podem
ocorrer.
Considerando estes cinco aspectos, Florac e Carleton (1999)

propuseram um framework para avaliação e melhoria do
comportamento dos processos. De acordo com Rocha, Souza e
Barcellos (2012), o framework pode ser interpretado como uma
ferramenta que possibilita a execução de um ciclo para melhoria
contínua baseado no CEP. O framework é ilustrado na Figura 17 e
suas atividades são detalhadas a seguir:
Entender os objetivos de negócio: consiste em entender como

os objetivos de negócio, metas, planos e estratégias da
organização se relacionam com os processos de software. Ou
seja, consiste na identificação das relações entre processos e
objetivos organizacionais.
Identificar e priorizar questões: consiste em identificar quais

são as necessidades de informação críticas para determinar se
o processo será capaz de alcançar os objetivos de negócio
estabelecidos.
Selecionar e definir medidas: consiste em selecionar e definir

as medidas que serão utilizadas para caracterizar o
desempenho dos processos.
Coletar, verificar e armazenar dados: consiste em coletar os

dados para as medidas definidas, verificar se são corretos e
armazená-los.
A nalisar o comportamento dos processos: consiste em utilizar

os métodos estatísticos apropriados para representar em
gráficos de controle os dados coletados para as medidas,
permitindo, assim, a análise do comportamento do processo. A
análise do comportamento do processo pode levar a três
direções:
Remover causas especiais: consiste em realizar ações

para tratar as causas especiais e tornar o comportamento
do processo estável.
Mudar o processo: consiste em realizar alterações no

processo, tratando suas causas comuns, para que ele
seja capaz de produzir os resultados necessários ao
alcance dos objetivos.
Melhorar continuamente o processo: consiste em

realizar ações que levem o processo a produzir
resultados cada vez melhores.
Figura 17 – Framework para melhoria contínua de processos baseado no CEP.
É importante ressaltar também a finalidade de um programa de

melhoria contínua. Como o próprio nome diz, quando a melhoria
proposta atingir o seu objetivo, ou seja, quando uma melhoria para
um processo for realizada e este processo atingir o desempenho
desejado, novos ciclos de melhorias podem ser iniciados. E este ciclo
permanecerá desta forma continuamente.
Outra questão que deve ser abordada diz respeito aos critérios que
possibilitam o sucesso de programas de melhoria contínua em uma
organização do segmento de desenvolvimento de software. Levando
em consideração que o desenvolvimento de software é uma
atividade intensiva em mão de obra criativa, fatores adversos podem
ocorrer e serem os causadores de situações “fora de controle”. Além
disso, o contexto qualitativo também dificulta na obtenção de um
conjunto grande de dados homogêneos. Dessa forma, para que os
conceitos apresentados neste livro sejam aplicados de maneira a
resultar em benefícios para a organização, sugere-se também que
sejam observados os seguintes critérios para a obtenção de um
gerenciamento quantitativo efetivo:
Compromisso e envolvimento da Gerência;
abordagem de equipe;
treinamento dos colaboradores em todos os níveis;
ênfase na redução da variabilidade;
avaliação do sucesso em termos quantitativos;
comunicação dos resultados de sucesso por toda a empresa.
Recomenda-se a leitura de Rocha, Souza e Barcellos (2012), Ahern

(2008), SEI (2010) e SOFTEX (2012, 2016) para mais detalhes sobre os
modelos de desempenho para processos de software. Aconselha-se a
leitura de Florac e Carleton (1999) para observar todos os detalhes
sobre o framework de melhoria contínua para processos.
Resumo do capítulo
O CEP tem como principal objetivo apoiar na avaliação quantitativa

do alcance dos objetivos de negócio e projetos e, para tanto, faz-se
uso do controle estatístico dos processos da organização para este
fim. Como abordado, um projeto nada mais é que uma instância em
execução do processo definido pela organização. Por isso, avaliar
como está o desempenho do projeto vai possibilitar avaliar como
está o desempenho do processo definido. Esta situação representa a
inter-relação entre o CEP e o gerenciamento quantitativo de projetos.
Se por um lado o CEP apoia na avaliação do desempenho dos
processos da organização e no estabelecimento de linhas de base
para um comportamento esperado, nível organizacional, por outro
lado, apoia também no planejamento e gerenciamento do projeto,
com suporte nas linhas de base padrão estabelecidas pelos projetos
passados, nível do projeto. Esse gerenciamento resulta em dados
que possibilitam mobilizar ações voltadas para a melhoria contínua.
No entanto, para que as ações e o programa de melhoria contínua
sejam bem-sucedidos, é importante que o conceito de melhoria
contínua, os aspectos para a melhoria do processo e os critérios para
obtenção de um gerenciamento quantitativo efetivo sejam
observados e atentamente considerados pela organização.
__________
5. Considera-se aqui atividades genéricas para o desenvolvimento de software e que são utilizadas
tanto para os modelos chamados tradicionais bem como os que fazem uso de métodos ágeis.
6. http://epf.eclipse.org/wikis/openuppt/.
REF ERÊNCIA S
AHERN, Dennis M. CMMI Distilled: a practical introduction to

integrated process improvement. 3. ed. Boston: Pearson
Education, 2008.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO

9001: Sistema de Gestão da Qualidade - Requisitos -
Apresentação. Rio de Janeiro: 2005.
ABPMP - Association of Business Process Management

Professionals. Guia para o Gerenciamento de Processos de
Negócio Corpo Comum de Conhecimento (BPM CBOK v3.0). 1
ed. 2013.
BASILI, V.R., CALDIERA, G., ROMBACH, H.D. The Goal Question

Metric Approach. Chapter in Encyclopedia of Software
Engineering, W iley, 1994.
BASILI, V. et. al. "GQM^+ Strategies -- Aligning Business

Strategies with Software Measurement," First International
Symposium on Empirical Software Engineering and
Measurement (ESEM 2007), Madrid, 2007, pp. 488-490. doi:
10.1109/ESEM.2007.66
BELMIRO, Luiz Alberto Gravina. Administração estratégica. 3. ed.

Rio de Janeiro: LTC, 2014.
BOFFOLI, Nicola, BALDASSARRE, Maria Teresa, CAIVANO, Danilo.

Statistical process control for software: fill the gap. In:
COSKUN, Abdurrahman. Quality Management and Six Sigma.
(Org.) Disponível em:
<https://pt.scribd.com/document/44294738/Quality-
Management-and-Six-Sigma>. Acesso em: 10 jan. 2017.
BOFFOLI, N.; BRUNO, G., CAIVANO, D., MASTELLONI, G. Statistical

process control for software: a systematic approach.
Proceedings of the Second ACM-IEEE international symposium
on Empirical software engineering and measurement (pp. 327-
329). New York, NY: ACM. 2008.
CRUZ, Tadeu. O teatro organizacional: construindo e

implantando processos de negócio. Rio de Janeiro: E-papers,
2006.
DE SORDI, José Osvaldo. Gestão de processos: uma abordagem

da moderna administração. 2. ed. São Paulo: Saraiva, 2008.
FERREIRA, M. A.; OLIVEIRA, U. R.; GARCIA, P. A. A. Quatro

ferramentas administrativas integradas para o mapeamento
de falhas: um estudo de caso. Revista UNIABEU, v. 7, p. 300-315,
2014.
FONSECA, P. C. Modelo para controle estatístico de processos

de desenvolvimento de software (CEP-S). Dissertação.
Programa de Pós-Graduação em Ciência da Computação do
Instituto de Ciências Exatas da Universidade Federal de Minas
Gerais. Belo Horizonte, set, 2010.
FLORAC, W . A., CARLETON, A. D., 1999, Measuring the Software

Process, Addison-W esley.
FRANCISCO, Rosemary. Métricas de processos de software. São

Leopoldo: UNISINOS, 2017.
GARCÉS, Bibiana Y.; PINO, Francisco J. Statistical control of

software process: a systematic review. Sistemas & Telemática,
[S.l.], v. 12, n. 31, p. 55-76, dec. 2014. Disponível em:
<http://proesa.org.co/revistas/index.php/sistemas_telematica/articl
Acesso em: 03 dez. 2016.
GONÇALVES, José Ernesto Lima. As empresas são grandes

coleções de processo. RAE Revista de Administração de
Empresas, v. 40, n. 1, p. 6-19, jan./mar. 2000.
GONÇALVES, L. P. et al. Planejamento de Gerência Quantitativa

em uma Organização com Maturidade Inicial de Qualidade –
Relato de Experiência. III Workshop de Gerenciamento de
Projetos de Software, 1-737. 2010.
HUMPHREY, J. Opportunities for SME’s in developing countries

to upgrade in a global economy. Working Paper n. 43,
International Labour Office, Geneva: 2003.
ISO/IEC, 2003, ISO/IEC 15504 - Software Engineering - Process

Assessment, The International Organization for
Standardization and the International Electrotechnical
Commission.
ISO/IEC, 2008, ISO/IEC 12207 – Systems and Software

Engineering – Software Life Cycle Process, The International
Organization for Standardization and the International
Electrotechnical Commission.
LOUZADA, Francisco et al. Controle estatístico de processos:

uma abordagem prática para cursos de engenharia e
administração. Rio de Janeiro: LTC, 2013.
MELLO FILHO, Moacyr Cardoso de. Aplicando as sete métricas

de controle de projeto. Rational Software W hite Paper, 2002.
MONTGOMERY, Douglas C.; RUNGER, George C. Estatística

aplicada e probabilidade para engenheiros. 5. ed. Rio de
Janeiro: LTC, 2012.
MONTONI, M.A. et al. Uma metodologia para Desenvolvimento

de Modelos de Desempenho de Processos para Gerência
Quantitativa de Projetos de Software. VI Simpósio Brasileiro de
Qualidade de Software (SBQS), Porto de Galinhas, 2007.
OLIVEIRA, Saulo Barbará de. Gestão por processos:

fundamentos, técnicas e modelos de implementação: foco no
sistema de gestão de qualidade com base na ISO 9000:2005 e
9001:2008. Rio de Janeiro: Qualitymark, 2008.
PAIM, Rafael et al. Gestão de processos: pensar, agir e

aprender. Porto Alegre: Bookman, 2009.
PMI - Project Management Institute. Um guia do conhecimento

em gerenciamento de projetos (guia PMBOK). 5 ed. São Paulo:
Saraiva, 2014.
PRESSMAN, Roger S. Engenharia de software: uma abordagem

profissional. 8. ed. Porto Alegre : AMGH, 2016.
PSM. PSM Insight Software, Version 4.2.3. Disponível em:
<http://www.psmsc.com>. Acesso em: 03 nov. 2016.
PUTNAM, L. H.; MYERS, W . Five core metrics: the intelligence

behind successful software management. Dorset House
Publishing Company, 2003.
ROCHA, A; SOUZA, G.; BARCELLOS, M. P. Medição de software e

controle estatístico de processos. Ministério da Ciência,
Tecnologia e Inovação; Secretaria de Política de Informática,
2012.
SANTOS, R. V. M. Definição de um processo de medição de

software baseado em seis sigma e CMMI. 2007. 177 p.
Dissertação (Mestrado em Estatística e Experimentação
Agropecuária) -Universidade Federal de Lavras, Lavras, 2007.
Sargut, K. U., Demirors, O. Utilization of statistical process

control (SPC) in emergent software organizations: pitfalls and
suggestions. Software Quality Journal. v. 14, Issue 2 (June 2006)
p: 135-157, 2006.
SEI, 2010, Capability Maturity Model Integration (CMMI) for

Development, version 1.3,
Carnegie Mellon University, Software Engineering Institute,

Technical Report CMU/SEI-2010-TR-033.
SELEME, Robson, STEDLER, Humberto. Controle da qualidade:

as ferramentas essenciais. Curitiba: InterSaberes, 2012.
SOFTEX, 2012, MPS.BR – Melhoria de Processo do Software

Brasileiro – Guia Geral. Disponível em:
<http://www.softex.br/mpsbr/guias>. Acesso em: 10 jan. 2017.
SOFTEX, 2016, MPS.BR – Melhoria de Processo do Software

Brasileiro – Guia Geral. Disponível em:
<http://www.softex.br/mpsbr/guias>. Acesso em: 10 jan. 2017.
SOTTILE, Mauro. Dicas de gerenciamento da qualidade.

Disponível em:
<http://www.pmtech.com.br/PMP/Dicas%20PMP%20-
%20Qualidade%20-%20Mauro%20Sotille.pdf>. Acesso em: 03
nov. 2016.
W HEELER, Donald J. (1999). Understanding variation: the key to

managing chaos. 2nd Edition. SPC Press.
A A UTORA
Rosemary Francisco
Doutoranda em Administração (UNISINOS)
Doutoranda em Administração pela UNISINOS com estágio

doutoral na Universidade de Helsinki, Finlândia, mestre em
Engenharia da Produção e Sistemas pela Pontifícia
Universidade Católica do Paraná (PUCPR), especialista em
Engenharia da Produção e Engenharia de Software pela
mesma instituição e bacharel em Sistemas de Informação.
Atua há mais de 15 anos na área de processos de software,
onde adquiriu experiência e conhecimentos nas melhores
práticas utilizadas em todo o ciclo de vida de projetos.
Participou e geriu projetos de integração, desenvolvimento e
implantação de sistemas de informação em organizações de
médio e grande porte. Atualmente, atua como consultora de TI
e como docente nos cursos de graduação e especialização em
Informática e nos MBAs em Administração da Tecnologia da
Informação, Gestão de Negócios da Tecnologia da Informação
e Business Process Management (BPM) da UNISINOS.
UNIVERSIDADE DO VALE DO RIO DOS SINOS – UNISINOS
Reitor: Pe. Marcelo Fernandes de Aquino, SJ

Vice-reitor: Pe. José Ivo Follmann, SJ
Diretor da Editora Unisinos: Pe. Pedro Gilberto Gomes
Editora Unisinos
Avenida Unisinos, 950, 93022-000, São Leopoldo, Rio Grande do Sul,
Brasil
editora@unisinos.br
www.edunisinos.com.br
© dos autores, 2017

2017 Direitos de publicação da versão eletrônica (em e-book) deste
livro exclusivos da Editora Unisinos.
F819g Francisco, Rosemary.

Gerenciamento quantitativo de projetos [recurso
eletrônico] / Rosemary Francisco. – São Leopoldo : Ed.
UNISINOS, 2017.
1 recurso online – (EaD)
ISBN ???-??-????-???-?
1. Software – Desenvolvimento. 2. Administração de

projetos. 3. Controle de processo. I. Título. II. Série.
CDD 005.1
CDU 004.413
Dados Internacionais de Catalogação na Publicação (CIP)
(Bibliotecária: Carla Maria Goulart de Moraes – CRB 10/1252)
Coleção EAD
Editor: Carlos Alberto Gianotti
Acompanhamento editorial: Jaqueline Fagundes Freitas
Revisão: Bianca Basile Parracho
Editoração: Guilherme Hockmüller
A reprodução, ainda que parcial, por qualquer meio, das páginas

que compõem este livro, para uso não individual, mesmo para fins
didáticos, sem autorização escrita do editor, é ilícita e constitui uma
contrafação danosa à cultura. Foi feito depósito legal.

Gerenciamento Quantitativo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento Quantitativo

Enviado por

Direitos autorais:

Formatos disponíveis

GERENCIAMENTO QUANTITATIVO DE PROJETOS

Editora Unisinos, 2017

O contexto que envolve o desenvolvimento de produtos de

Portanto, para obter a capacidade de gerenciar

Para alcançar este objetivo, o livro foi estruturado em cinco

O Capítulo 3 apresenta conceitos e procedimentos que são

No Capítulo 4, é feita uma introdução acerca dos gráficos de

De acordo com o PMI (2014, p.3),

É importante ressaltar, portanto, a característica de o projeto sempre

Dessa forma, para garantir que os objetivos dos projetos sejam

O gerenciamento quantitativo de projetos, por sua vez, limita-se,

Antes de iniciar o gerenciamento quantitativo de projetos, no

1.2 Revisando os principais conceitos e abordagens

1.2.1 Definição de processos

Existem várias definições, com pequenas diferenças, sobre o conceito

De acordo com Cruz (2006), processo é um conjunto de atividades

A Figura 1 ilustra a visão macro de um processo. Nesta visão,

Quadro 1 – Principais elementos de um processo

As principais características que podem ser observadas nos

a. utiliza os recursos da organização para atingir os resultados;

b. pode ocorrer em qualquer tempo, bastando que um gatilho o

c. pode produzir milhares de produtos, serviços ou resultados

d. caracteriza-se pela repetibilidade de ocorrência, podendo

Estas características demonstram que os processos estão

Para melhorar os processos, no entanto, é preciso avaliar, de forma

1.2.1 Métricas de software

Medir software não é uma tarefa trivial. Os motivos que

Porém, antes de fazer uso de métricas de software, é imprescindível

Quadro 2 – Conceitos básicos para a medição

Item D efinição Exemplo

De acordo com Rocha, Souza e Barcellos (2012) o uso de métricas de

Apesar das vantagens no uso de métricas de software, é importante,

Medição exige planejamento e esforço sobre o que medir, quando

1.2.3 Normas e modelos de maturidade para processos de software

De acordo com as normas e os modelos de maturidade, para que as

Portanto, para que as organizações e as equipes de projeto atinjam

1.2.3.1 Norma ISO/IEC 12207

A norma ISO/IEC 12207 tem como propósito estabelecer uma estrutura

b. Um conjunto adequado de medidas orientado pelas

c. As atividades de medição são identificadas e planejadas.

d. Os dados requeridos são coletados, armazenados, analisados,

e. As informações produzidas são usadas para apoiar decisões e

f. O processo de medição também é medido e analisado.

g. Melhorias são comunicadas ao responsável pelo processo de

1.2.3.2 Norma ISO/IEC 15504

A norma ISO/IEC 15504 estabelece uma estrutura para a avaliação e

1. dimensão de processo, fornecida por um modelo de referência

2. dimensão de capacidade, que consiste em um framework com

Os seis níveis de capacidade para os processos de software,

Quadro 3 – Níveis de capacidade da norma ISO/IEC 15504

Conforme demonstrado no Quadro 3, desde o nível 3 a medição de

a. Dados apropriados são coletados e analisados,

a. São identificadas as necessidades de informação do

b. Os objetivos de medição do processo devem ser

c. São definidos objetivos quantitativos de desempenho

e. Resultados das medições são coletados, analisados e

f. Resultados de medições são utilizados para caracterizar

a. Técnicas de análise e controle são identificadas e

b. Limites de controle de variação são estabelecidos para o

c. Dados de medição são analisados com relação a causas

d. Ações corretivas são realizadas para tratar causas

e. Limites de controle são redefinidos (quando necessário)

Os níveis de capacidade propostos pela norma ISO/IEC 15504 são