1

PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM

GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO

Mestrado
DEFINIÇÃO DE UM CATÁLOGO DE MEDIDAS
PARA A ANÁLISE DE DESEMPENHO DE
PROCESSOS DE SOFTWARE

Autor: Luis Felipe Salin Monteiro

Orientador: Profª Drª Káthia Marçal de Oliveira

2008
 i

LUIS FELIPE SALIN MONTEIRO

Definição de um Catálogo de Medidas para a Análise de Desempenho de

Processos de Software

Dissertação apresentada ao Programa de Pós-Graduação

Strictu Sensu em Gestão do Conhecimento e Tecnologia
da Informação da Universidade Católica de Brasília, como
requisito para obtenção do Título de Mestre em Gestão do
Conhecimento e Tecnologia da Informação.

Orientadora: Prof.ª Dra. Káthia Marçal de Oliveira

Brasília
2008
 ii

Dedico este trabalho à minha amada esposa Suzana.

Pelo amor incondicional, compreensão e incentivo nesta nova conquista de minha vida.
 iii

Agradecimentos

A Deus por ter-me concedido saúde, paz e a oportunidade de realizar este trabalho.
À minha esposa Suzana por ter compreendido os longos momentos de ausência,
dedicados inteiramente à elaboração deste trabalho.
Aos meus pais e irmãos pela convivência acolhedora, incentivo à pesquisa e educação
exemplar transmitida durante toda a minha vida, que culmina hoje com a publicação deste
trabalho.
À minha orientadora Dra. Káthia, pela orientação e cobrança constantes, mantendo a
motivação e persistência que me fizeram concluir esta pesquisa.
Aos meus colegas Ricardo Ajax, Luiz Carlos Ribeiro e Ana Paula Fukuda, pelo apoio
e por estarem sempre disponíveis para dividir idéias sobre a pesquisa.
Aos muitos amigos e profissionais com os quais pude dividir alegrias, desafios e
projetos.
 iv

RESUMO

Projetos de desenvolvimento de software têm apresentado problemas recorrentes de

desempenho de custo, prazo e qualidade. A complexidade de gestão destes projetos requer
que medidas de desempenho e técnicas de gestão quantitativa sejam aplicadas para identificar
de forma precisa a situação do projeto e prever a sua capacidade de atender aos objetivos
futuros. Contudo, os estudos a respeito deste tema apresentam exemplos de fracassos na
implantação de programas de medições nas organizações, devido à definição de um grande
número de medidas inúteis, muito complexas, não padronizadas e desalinhadas com a
estratégia da organização. Torna-se importante, então, identificar as medidas relevantes para a
avaliação de desempenho dos processos envolvidos no desenvolvimento de software.
Considerando que as áreas de processos da categoria de engenharia do CMMI-DEV
(Capability Maturity Model Integration for Development) correspondem à maior parcela do
esforço dos projetos de software, esta pesquisa tem como objetivo identificar um catálogo de
medidas que permitam a análise de desempenho destes processos. Para tal, foram coletadas e
classificadas as medidas de desempenho de software mais referenciadas na literatura. Estas
medidas foram então consolidadas em indicadores e organizadas em um catálogo, que permite
a análise do desempenho dos processos das áreas de processos de engenharia do modelo
CMMI-DEV, a partir de diferentes perspectivas de desempenho. Esta pesquisa apresenta um
exemplo da aplicação de algumas medidas do catálogo em um projeto de software, sugerindo
os passos para a implantação do catálogo nas organizações que buscam a análise precisa do
desempenho de seus processos de desenvolvimento de software.

Palavras chave: Medidas de software, Análise de desempenho de processos, Indicadores.

 v

ABSTRACT

Software development projects have showed recurring problems of performance on costs,

schedule and quality. The high complexity of managing these projects requires that
performance measures and quantitative management techniques be applied to identify
precisely the project’s situation and its ability to meet future goals. However, studies on this
subject have show several examples of failures in the implementation of measurement
programs due to a large number of complex, not standardized and unnecessary measures, not
aligned with the organization strategy. It is important to identify relevant measures to assess
the performance of the processes involved in software development. Considering that the
engineering process areas of CMMI-DEV (Capability Maturity Model for Development)
represents the largest amount of effort involved in software projects, this research aims to
identify a catalogue of measures, which allow the performance analysis of these processes. To
this end, the software performance measures most referenced in the literature were collected
and classified. These measures were then consolidated into indicators and organized in a
catalogue, which allows the analysis from different performance perspectives of the
engineering processes areas of CMMI-DEV. This research presents an application example of
the catalog of measures, and suggests the steps for the deployment of the catalog in
organizations that aims to precisely analyze the performance of its software development
processes.

Keywords: Software measures, Process performance analysis, Indicators.

 vi

LISTA DE FIGURAS

Figura 1: As três dimensões críticas de uma organização (Chrissis, Konrad, Shrum, 2003a, p.
4). .................................................................................................................................. 7
Figura 2: Áreas de processo envolvidas na gestão quantitativa (Adaptado de SEI, 2002)...... 19
Figura 3: Estrutura do gráfico de controle (Adaptada de Florac e Carleton, 1999, p. 77). ..... 25
Figura 4: Fluxograma de decisão do gráfico de controle (Adaptado de Stapenhrust, 2005, p.
264) ............................................................................................................................. 27
Figura 5: Testes de instabilidade de processo ....................................................................... 33
Figura 6: Passos para desenvolvimento do catálogo de medidas ........................................... 38
Figura 7: Índice de desempenho de custos (XmR)................................................................ 72
Figura 8: Índice de desempenho de prazo (XmR)................................................................. 73
Figura 9: Valor agregado (Curva S) ..................................................................................... 73
Figura 10: Variação de custo ................................................................................................ 74
Figura 11: Orçamento no término ........................................................................................ 74
Figura 12: Cobertura de testes (XmR) .................................................................................. 78
Figura 13: Custo da qualidade (Barras) ................................................................................ 81
Figura 14: Percentual de custo da qualidade (XmR) ............................................................. 82
Figura 15: u Chart de Densidade de defeitos ........................................................................ 85
Figura 16: Diagrama de Pareto de Densidade de defeitos ..................................................... 85
Figura 17: Eficácia de testes (XmR)..................................................................................... 88
Figura 18: Eficácia de revisão (XmR) .................................................................................. 89
Figura 19: Taxa de mudanças (XmR) ................................................................................... 92
Figura 20: Volatilidade de requisitos (XmR) ........................................................................ 93
Figura 21: Prazo de ciclo (barras)......................................................................................... 95
Figura 22: Prazo de ciclo relativo ao tamanho (XmR) .......................................................... 96
Figura 23: Prazo médio para a falha (XmR) ......................................................................... 98
Figura 24: Produtividade (XmR) ........................................................................................ 101
Figura 25: Taxa de entrega (PF/mês) (XmR)...................................................................... 102
Figura 26: Reuso de código (XmR).................................................................................... 104
Figura 27: Taxa de remoção de defeitos (XmR) ................................................................. 107
Figura 28: Taxa de retrabalho total (XmR) ......................................................................... 110
 vii

Figura 29: Taxa de retrabalho por disciplina (Pareto) ......................................................... 110

Figura 30: Variação de esforço total (XmR) ....................................................................... 113
Figura 31: Variação de esforço por disciplina (Pareto) ....................................................... 113
Figura 32: Variação de prazo total (XmR).......................................................................... 116
Figura 33: Variação de prazo por disciplina (Pareto) .......................................................... 116
Figura 34: Variação de tamanho (XmR)............................................................................. 119
Figura 35: Cartas XmR para medida de IDC do projeto ..................................................... 128
Figura 36: Cartas XmR para a medida IDP do projeto ........................................................ 129
Figura 37: Densidade de defeitos total do projeto ............................................................... 130
Figura 38: Diagrama de Pareto da Densidade de defeitos por tipo do projeto ..................... 130
 viii

LISTA DE QUADROS

Quadro 1: Estrutura do modelo CMMI-DEV (SEI, 2006a, p. 31) ........................................... 9

Quadro 2: Áreas de processo do modelo CMMI-DEV (Adaptado de SEI, 2006a, p. 44) ....... 10
Quadro 3: Escalas de medição (FENTON; PFLEEGER, 1997, p. 45-53) (KAN, 2003, p. 59-
61) (ISO/IEC, 2002, p. 5) ............................................................................................. 13
Quadro 4: Comparação dos modelos de especificação de medida ......................................... 16
Quadro 5: Ferramentas para gestão quantitativa de projetos ................................................. 23
Quadro 6: Resumo dos tipos de cartas de controle................................................................ 28
Quadro 7: Fórmulas para o gráfico de controle XmR (Adaptado de Florac e Carleton, 1999, p.
95) ............................................................................................................................... 31
Quadro 8: Fórmulas para o gráfico de controle u Chart (Adaptado de Florac e Carleton, 1999,
p. 116) ......................................................................................................................... 32
Quadro 9: Medidas redundantes em diferentes trabalhos pesquisados .................................. 41
Quadro 10: Categorias de medição ....................................................................................... 41
Quadro 11: Exemplos de categorização de medidas ............................................................. 42
Quadro 12: Exemplos de eliminação de redundância pelo nome e descrição das medidas .... 43
Quadro 13: Exemplos de eliminação de redundâncias pela fórmula das medidas.................. 45
Quadro 14: Exemplos de medidas cuja relação com as APs do CMMI-DEV é apresentada na
literatura....................................................................................................................... 48
Quadro 15: Exemplos de medidas cuja relação com as APs do CMMI-DEV foi identificada a
partir de suas características ......................................................................................... 50
Quadro 16: Conjunto final de medidas do catálogo .............................................................. 56
Quadro 17: Distribuição das medidas do catálogo por categoria e área de processo .............. 59
Quadro 18: Exemplos de diferentes interpretações das medidas para cada área de processo . 61
Quadro 19: Definição dos indicadores e medidas a serem especificadas no catálogo ............ 66
Quadro 20: Distribuição dos indicadores do catálogo por categoria e área de processo ......... 69
Quadro 21: Linha de base para as medidas IDC e IDP (XmR)............................................ 127
Quadro 22: Linha de base para a medida de Densidade de defeitos (u Chart) ..................... 127
Quadro 23: Fórmulas para cálculo da linha central e limites do gráfico de controle (Adaptado
de Florac e Carleton, 1999, pp. 85-123 e Stapenhrust 2005, pp. 153-164)................... 183
 ix

LISTA DE TABELAS

Tabela 1: Distribuição de medidas por categoria .................................................................. 42

Tabela 2: Distribuição de medidas por área de processo ....................................................... 48
Tabela 3: Lista de medidas referenciadas por três ou mais autores ....................................... 52
Tabela 4: Medidas eliminadas pela redundância de objetivo ................................................. 54
Tabela 5: Tabela de fatores de correção e constantes (Adaptado de Florac e Carleton, 1999,
pp. 216-219)............................................................................................................... 185
 x

SUMÁRIO

1. Introdução ..................................................................................................................... 1
1.1. Motivação e contexto ........................................................................................... 1
1.2. Objetivos .............................................................................................................. 3
1.2.1. Objetivo geral .......................................................................................... 3
1.2.2. Objetivos específicos ............................................................................... 3
1.3. Metodologia ......................................................................................................... 4
1.3.1. Classificação da pesquisa ......................................................................... 4
1.3.2. Hipóteses e suposições............................................................................. 4
1.3.3. Coleta de dados........................................................................................ 5
1.3.4. Organização da dissertação ...................................................................... 6
2. Referencial teórico ........................................................................................................ 7
2.1. Processos de software ........................................................................................... 7
2.1.1. Modelos de processos de software ........................................................... 8
2.2. Medição de software........................................................................................... 11
2.2.1. Conceituação ......................................................................................... 11
2.2.2. Fatores críticos da implantação de programas de medição ...................... 13
2.2.3. Modelos de especificação de medidas .................................................... 15
2.2.4. Medidas de processos de software.......................................................... 15
2.3. Análise de desempenho de processos de software ............................................... 18
2.3.1. Análise de desempenho de processos segundo o modelo CMMI-DEV ... 18
2.3.2. Entendimento do desempenho do processo organizacional ..................... 20
2.3.3. Importância da estabilidade do processo ................................................ 21
2.3.4. Ferramentas de análise de desempenho de processos.............................. 22
2.3.5. Gráficos de controle............................................................................... 24
2.4. Gestão quantitativa de projetos de software ........................................................ 34
2.5. Considerações finais do capítulo ......................................................................... 36
3. Definição do catálogo de Medidas............................................................................... 37
3.1. Visão geral dos passos para definição do catálogo .............................................. 37
3.2. Seleção das medidas de desempenho de software ............................................... 40
3.2.1. Revisão da literatura e identificação das medidas ................................... 40
3.2.2. Categorização das medidas .................................................................... 41
3.2.3. Consolidação de medidas redundantes ................................................... 42
 xi

3.2.4. Mapeamento das medidas em relação ao CMMI-DEV ........................... 47

3.2.5. Seleção das medidas mais referenciadas na literatura ............................. 50
3.3. Consolidação do catálogo ................................................................................... 62
3.3.1. Seleção do modelo de especificação de indicador .................................. 62
3.3.2. Seleção do conjunto de indicadores a serem especificados ..................... 65
3.3.3. Seleção de técnicas para a gestão quantitativa de projetos ...................... 70
3.3.4. Especificação dos indicadores e consolidação do catálogo ..................... 70
3.4. Considerações finais do capítulo ....................................................................... 120
4. Exemplo de Uso do Catálogo de Medidas ................................................................. 122
4.1. Caracterização do estudo de caso ...................................................................... 122
4.2. Seleção dos processos e medidas de desempenho ............................................. 123
4.3. Coleta de dados de desempenho dos processos ................................................. 124
4.4. Definição da linha de base de desempenho dos processos ................................. 126
4.5. Avaliação do desempenho dos processos .......................................................... 128
4.6. Considerações finais do capítulo ....................................................................... 131
5. Conclusão ................................................................................................................. 132
Referências Bibliográficas ................................................................................................. 135
APÊNDICE A - Lista completa de medidas citadas na literatura..................................... 143
ANEXO A - Fórmulas de cálculo dos gráficos de controle ............................................ 183
 1

1. INTRODUÇÃO

1.1. Motivação e contexto

Projetos de desenvolvimento de software têm demonstrado problemas recorrentes de

desempenho, sendo que a maioria destes projetos utiliza mais recursos e tempo do que o
planejado e provê menos funcionalidades e qualidade no produto do que o esperado
(BARROS; WERNER; TRAVASSOS, 2006, p. 1).
Após diversos anos de falhas e compromissos não atingidos, torna-se necessário
encontrar uma forma mais adequada de produzir produtos e serviços de software (FLORAC;
CARLETON, 1999, p. 1). A complexidade de gestão de projetos de desenvolvimento de
software requer que, além da experiência do gerente de projetos, técnicas de gestão
quantitativa sejam aplicadas de forma a perceber objetivamente a situação do projeto e prever
a sua capacidade em atender aos seus objetivos.
O sucesso dos projetos de software depende da capacidade da organização prever o
seu desempenho e assumir compromissos atingíveis. Processos efetivos de medição auxiliam
no gerenciamento destes projetos, pois permitem à organização entender a sua capacidade de
forma a desenvolver planos atingíveis para a entrega de produtos e serviços (FLORAC;
CARLETON, 1999, p. 10).
Modelos de melhoria de processos como o CMMI-DEV (SEI, 2006a, p. 58), afirmam
que a gestão quantitativa de projetos envolve a aplicação de técnicas estatísticas para
gerenciar o desempenho do projeto e a qualidade do produto de software.
Diversos autores (HALL; FENTON, 1997) (TAKARA; BETTIN; TOLEDO, 2007)
(AGRESTI, 2006) (BERANDER; JÖNSSON, 2006) (MUKHOPADHYAY; KRISHNAN,
2005) expõem as barreiras e melhores práticas da implantação de medições no contexto de
uma organização de software. As melhores práticas buscam normalmente uniformizar e
simplificar os mecanismos de medição, tornando mais clara e menos custosa esta atividade
para o processo de desenvolvimento de software.
Os trabalhos mais antigos, publicados entre 1992 e 1999 abordam temas gerais
relacionados à aplicação de medições, técnicas e métodos de controle estatístico de processos
em ambientes de desenvolvimento e manutenção de software (GRADY, 1992) (HALL;
FENTON, 1997) (HERBSLEB; GRINTER, 1998) (FLORAC; CARLETON, 1999). Herbsleb
 2

e Grinter (1998) afirmam que a implementação de um programa efetivo de medições é uma

tarefa árdua e de alto risco.
Com o passar do tempo, os autores passaram a focar seus trabalhos na avaliação dos
programas de medições em prática nas organizações. Takara, Bettin e Toledo (2007), Agresti
(2006) e Berander e Jönsson (2006) abordam o problema da grande quantidade de medidas
inúteis e acrescentam que esta realidade tem como conseqüência a perda do foco e
credibilidade dos programas de medições. Agresti (2006) e Berander e Jönsson (2006),
propõem diferentes frameworks, apoiados na utilização do GQM (Goal Question Metric),
introduzido por Basili, Caldiera e Rombach (2002), como ferramenta de apoio à definição de
medidas efetivas.
Nesta mesma linha de trabalho, Hall e Fenton (1997) e Gopal, Mukhopadhyay e
Krishnan (2005), avaliam diferentes programas de medições em corporações de TI por meio
de pesquisas com o objetivo de obter o nível de aceitação das medições pelos profissionais
das organizações. Os resultados esclarecem os principais aspectos a considerar para a
implantação de um programa efetivo de medições.
Diversos trabalhos abordam a aplicação de medições orientada por modelos de
maturidade e capacidade, como o CMMI (Capability Maturity Model Integration). O SEI
(2006b) realizou uma pesquisa envolvendo 2.109 profissionais com o objetivo de avaliar o
estado da prática dos programas de medição de processos nas organizações de software. Os
resultados do estudo apresentam as principais abordagens e tipos de medidas em uso, bem
como as barreiras para o seu uso efetivo e concluem que ainda é precária a utilização de
medições para apoio aos projetos nas organizações de software.
O trabalho de Takara, Bettin e Toledo (2007) aborda a estratégia, desafios e lições
aprendidas no caminho do nível 3 para o nível 4 do modelo CMMI em uma organização
brasileira. Os autores ressaltam a importância das medições na gestão de processos de
desenvolvimento de software, principalmente relacionadas ao controle do cronograma, custo,
escopo e qualidade. Entre as barreiras apresentadas no artigo, destacam-se:
• A dificuldade de atingir a cobertura entre medidas e as áreas de processo do
modelo CMMI;
• O problema de definição de medidas nos níveis 2 e 3 do modelo sem a
compreensão das necessidades dos níveis de maturidade superiores;
• A instabilidade e falta de integridade da base histórica de medidas, em virtude
da necessidade de mudanças no conjunto de medidas a partir dos níveis 4 e 5.
 3

Autores como Johnson et al (2005) e Lawler e Kitchenham (2003) apresentam as

diferenças entre a teoria e prática de medições de software, e criticam a falta de padrões nas
medidas e no processo de coleta e análise. Esta realidade torna alto o custo da coleta de
medidas pelas equipes e mantém incerto o valor agregado para a gestão dos projetos.
Eickelmann e Anant (2003) criticam a aplicação indiscriminada de gráficos de
controle e a definição de seus limites argumentando que as características dos processos de
software exigem uma adaptação destas técnicas para que se tornem efetivas.
Apesar da contribuição real das medições na gestão de projetos de software, muito
trabalho ainda precisa ser realizado para que as organizações de software utilizem as medidas
de desempenho de processos de forma efetiva (SEI, 2006b). A implementação de um processo
de gestão quantitativa de projetos de software é normalmente equivocada, pois as medidas são
definidas sem a devida avaliação da sua utilidade para gestão e do seu alinhamento aos
objetivos da organização. (HALL; FENTON, 1997) (BERANDER; JÖNSSON, 2006).
Nesse contexto, uma questão importante a ser resolvida é: quais são as medidas
relevantes de serem consideradas na avaliação do desempenho dos processos de
desenvolvimento de software? De forma mais específica, quais medidas são pertinentes para a
análise de desempenho dos processos das áreas de processos da categoria de engenharia do
modelo CMMI-DEV1, considerando que esses são os processos centrais do desenvolvimento
de software?

1.2. Objetivos

1.2.1. Objetivo geral

O presente trabalho tem por objetivo estabelecer um catálogo de medidas que permita
à análise de desempenho dos processos das áreas de processos da categoria de engenharia do
CMMI-DEV.

1.2.2. Objetivos específicos

i. Selecionar medidas relacionadas às áreas de processos da categoria de

engenharia do CMMI-DEV a partir do conjunto de medidas tipicamente
utilizadas nas organizações e as propostas de medidas encontradas na literatura;
1
As áreas de processos da categoria de Engenharia do modelo CMMI-DEV são: Desenvolvimento de
Requisitos, Gerenciamento de Requisitos, Solução Técnica, Integração de Produto, Verificação e Validação.
 4

ii. Consolidar as medidas em indicadores de desempenho de processo;

iii. Especificar as medidas e seus indicadores, definindo os métodos de coleta e
análise dos dados e os critérios de decisão sobre o desempenho dos processos,
organizando todas informações em um catálogo;
iv. Realizar um exemplo de aplicação do catálogo de medidas em um projeto de
desenvolvimento de software, considerando a análise de desempenho dos
processos das áreas de processos da categoria de engenharia do CMMI-DEV.

1.3. Metodologia

1.3.1. Classificação da pesquisa

Segundo Moresi (2004, p. 11-14) uma pesquisa pode ser classificada quanto a sua
natureza, abordagem, fins e meios.
O presente trabalho tem por objetivo identificar um conjunto de medidas que permita a
análise de desempenho de processos de software . Portanto, a pesquisa caracteriza-se como
aplicada quanto à sua natureza, já que pretende gerar conhecimentos para aplicações práticas,
dirigidas à solução de um problema específico.
Quanto à abordagem utilizada, a pesquisa caracteriza-se como qualitativa, pois
buscará apresentar um exemplo prático da utilização do catálogo na definição de medidas nas
organizações e nos seus projetos.
A pesquisa irá propor instrumentos, caminhos e procedimentos para a gestão
quantitativa de projetos de software, tratando-se, portanto, de um instrumento de captação e
manipulação da realidade, configurando-se como pesquisa metodológica quanto aos fins.
Quanto aos meios de investigação, será realizada uma busca em material científico
publicado em livros, revistas e jornais, o que caracteriza a pesquisa como bibliográfica. A
partir do referencial teórico e do catálogo de medidas estabelecido, será realizada uma
aplicação prática em campo das medidas do catálogo na análise de desempenho dos
processos de um projeto de desenvolvimento de software.

1.3.2. Hipóteses e suposições

Por se tratar de uma pesquisa qualitativa, não serão feitas hipóteses e sim suposições,
descritas adiante:
 5

• As áreas de processos do modelo CMMI-DEV configuram a estrutura mínima

de processos necessária a uma organização para o fornecimento de produtos e
serviços de software.
• As áreas de processos da categoria de Engenharia do modelo CMMI-DEV
correspondem às principais atividades envolvidas em projetos de
desenvolvimento de software, por englobar as tradicionais atividades de
engenharia de software (requisitos, análise, projeto, codificação e testes). Nesta
categoria estão incluídas as seguintes áreas de processos: Desenvolvimento de
Requisitos, Gerenciamento de Requisitos, Solução Técnica, Integração de
Produto, Verificação e Validação.
• Existe um conjunto de medidas de desempenho que permite a análise de
desempenho dos processos das áreas de processos da categoria de engenharia
do CMIM-DEV;

1.3.3. Coleta de dados

A coleta de dados nesta pesquisa teve por objetivo primário obter informações sobre a
utilização do catálogo de medidas como instrumento para a análise de desempenho de
processos. Com este intuito, a coleta de dados para a aplicação do catálogo desta pesquisa foi
realizada na unidade de fábrica de uma empresa brasileira.
O catálogo de medidas estabelecido não tem por finalidade listar todas as medidas
existentes e suas variações, mas sim identificar um conjunto de medidas que permita a análise
de desempenho dos processos das áreas de processos da categoria de engenharia do CMMI-
DEV. Sendo assim, não fazem parte do escopo desta pesquisa medidas de desempenho
relacionadas à gestão organizacional, como os processos de suporte (qualidade de produtos e
processo, medição e análise, entre outros) e gestão dos processos (definição de processos,
melhoria de processos, treinamento, entre outros).
A aplicação da pesquisa irá se limitar em apresentar um exemplo da aplicação de
medidas do catálogo em um projeto real. Portanto, essa aplicação não contemplou todas as
medidas do catálogo, nem mesmo todos os processos envolvidos em um projeto típico de
desenvolvimento de software.
 6

1.3.4. Organização da dissertação

Esta dissertação é constituída de 5 capítulos, incluindo esta Introdução.

O capítulo 2 que segue, apresenta as definições e conceitos pertinentes aos tópicos
principais do tema da pesquisa, que são: processos de software, medidas de desempenho de
software, análise de desempenho de processos de software e gerenciamento quantitativo de
projetos.
No capítulo 3 é apresentada a abordagem defendida nesta pesquisa, detalhando os
passos realizados na busca pela definição do catálogo de medidas de desempenho de
processos de software.
O capítulo 4 aborda um exemplo de utilização do catálogo de medidas, realizado por
meio da aplicação de medidas na análise de desempenho dos processos envolvidos em um
projeto real de desenvolvimento de software.
Por fim, o capítulo 5 apresenta as conclusões da pesquisa, destacando as contribuições
e perspectivas de trabalhos futuros.
 7

2. REFERENCIAL TEÓRICO

Nesta seção é apresentado o referencial teórico que embasa o trabalho, envolvendo os

conceitos de processos de software, medição de software, análise de desempenho de
processos e gestão quantitativa de projetos de software.

2.1. Processos de software

Segundo Chrissis, Konrad e Shrum (2003), uma organização pode focar várias
dimensões para melhorar o desempenho de seus projetos de desenvolvimento de software.
Tipicamente, três destas dimensões são consideradas críticas: pessoas, procedimentos e
ferramentas, conforme a Figura 1.

Figura 1: As três dimensões críticas de uma organização (Chrissis, Konrad, Shrum, 2003a, p. 4).

O que mantêm as três dimensões trabalhando em conjunto é o processo da

organização, permitindo o alinhamento de como a organização realiza o negócio (CHRISSIS;
KONRAD; SHRUM, 2003).
Segundo Pall (1987, apud FLORAC; CARLETON, 1999, p. 3), o processo pode ser
definido como a organização lógica de pessoas, materiais, energia, equipamentos e
procedimentos em atividades de trabalho realizadas para produção de um resultado específico.
Para melhorar o desempenho dos projetos de desenvolvimento de software, as
organizações têm buscado investir na melhoria de seus processos (RAFFO, 2005). Entretanto,
Figueiredo (2002) relata que as organizações encontram dificuldades em gerenciar seus
processos. As dificuldades começam na definição dos processos, quando a organização
 8

precisa reconhecer suas atividades e os recursos envolvidos. O próximo desafio para a

organização é a avaliação dos processos. Muitas vezes a organização não possui mecanismos
que permitam comparar os seus processos com o desempenho do mercado para identificar
oportunidades de melhoria.
Segundo Florac e Carleton (1999, p. 4) o gerenciamento do processo de software
envolve gerenciar as atividades associadas com o desenvolvimento, manutenção e suporte aos
produtos de software. O gerenciamento é considerado eficaz quando os produtos e serviços
resultantes do processo atendem completamente aos requisitos dos clientes. A premissa
principal defendida pelo Software Engineering Institute (SEI) é de que a qualidade de um
sistema ou produto é altamente influenciada pela qualidade do processo utilizado para
desenvolvê-lo e mantê-lo (SEI, 2006a, p. 5).
O conceito de gerenciamento de processos é fundamentado nos princípios do controle
estatístico de processos. Estes princípios sustentam que, ao estabilizar e manter os níveis de
variação, os processos tendem a apresentar resultados previsíveis (FLORAC; CARLETON,
1999, p. 5).
De acordo com Florac e Carleton (1999, p. 5), o gerenciamento de processos de
software envolve as atividades de medição e controle a fim de coletar o desempenho dos
processos e analisá-los em relação aos limites de desempenho considerados normais pela
organização.

2.1.1. Modelos de processos de software

Com o objetivo de apoiar a gestão de seus processos, e conseqüentemente obter

melhoria no desempenho, as organizações têm cada vez mais recorrido a normas e modelos de
processos de software. Os diferentes modelos disponíveis provêm às organizações um guia
baseado em melhores práticas internacionais para o gerenciamento eficaz de seus processos.
Dentre as normas e modelos mais difundidos no mercado, destacam-se o CMMI (Capability
Maturity Model Integration), a ISO/IEC 12207 (Engenharia de software e sistemas -
Processos do ciclo de vida de software) e o modelo brasileiro MBS.BR (Melhoria do processo
de software brasileiro).
O propósito do CMMI, de acordo com SEI (2006a), é prover um guia para a melhoria
dos processos organizacionais e suas habilidades para gerenciar o desenvolvimento, aquisição
e manutenção de produtos ou serviços. A última versão do CMMI, denominada CMMI-DEV
(CMMI for Development) é uma continuação e atualização da versão anterior acrescentando
 9

uma solução integrada para atividades de manutenção e desenvolvimento aplicadas a produtos

e serviços.
A estrutura do modelo varia de acordo com sua a representação, conforme Quadro 1.
A representação por estágios é estruturada em cinco níveis de maturidade, enquanto a
representação contínua é estruturada em seis níveis de capacidade, numerados de 0 a 5, para
cada área de processo selecionada pela organização. Na representação em estágio cada nível é
composto de um conjunto de áreas de processo e para que a organização evolua nos níveis de
maturidade, todas as áreas de processos dos níveis anteriores devem ser implementadas. Na
representação contínua, de acordo com os objetivos da organização, é permitida a seleção
individual de uma ou várias áreas de processos para implementação e melhoria através dos
níveis de capacidade.

Quadro 1: Estrutura do modelo CMMI-DEV (SEI, 2006a, p. 31)

Representação continua Representação por estágios

Nível
Níveis de capacidade Níveis de maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Gerenciado Gerenciado
Nível 3 Definido Definido
Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente
Nível 5 Otimizado Otimizado

As áreas de processos são um conjunto de melhores práticas em determinada área, que

quando implementadas coletivamente, satisfazem um conjunto de metas consideradas
importantes para a melhoria naquela área (SEI, 2006a, p. 548). As diferentes áreas de
processo são agrupadas em quatro categorias (Engenharia, Gerenciamento de processos,
Gerenciamento de projetos e Suporte) e distribuídas de acordo com os níveis de cada
representação do modelo. O Quadro 2 lista as categorias, áreas de processos e o nível de
maturidade correspondente, de acordo com a representação por estágios do modelo CMMI-
DEV.
A norma ISO/IEC 12207 é um padrão internacional que estabelece um framework
comum de processos do ciclo de vida de software e define uma terminologia que pode ser
referenciada pela indústria de software. A norma contém processos, atividades e tarefas que
são aplicadas durante o desenvolvimento, operação, manutenção e aquisição de produtos e
serviços de software (ISO/IEC, 2008, p. 1).
 10

Quadro 2: Áreas de processo do modelo CMMI-DEV (Adaptado de SEI, 2006a, p. 44)

Categoria Área de processo Nível de maturidade

Engenharia Integração de produto 3 - Definido
Desenvolvimento de requisitos 3 - Definido
Gerenciamento de requisitos 2 - Gerenciado
Solução técnica 3 - Definido
Validação 3 - Definido
Verificação 3 - Definido
Gerenciamento de Inovação organizacional e implantação 5 - Otimizado
processos Definição do processo organizacional + IPPD 3 - Definido
(Desenvolvimento integrado de produto e processo)
Foco do processo organizacional 3 - Definido
Desempenho do processo organizacional 4 - Gerenciado
Quantitativamente
Treinamento organizacional 3 - Definido
Gerenciamento de Gerenciamento integrado do projeto + IPPD 3 - Definido
projetos Monitoramento e controle do projeto 2 - Gerenciado
Planejamento do projeto 2 - Gerenciado
Gerenciamento quantitativo do projeto 4 - Gerenciado
Quantitativamente
Gerenciamento de riscos 3 - Definido
Gerenciamento de acordos com fornecedores 2 - Gerenciado
Suporte Análise de causas e resoluções 5 - Otimizado
Gerenciamento de configuração 2 - Gerenciado
Análise de decisões e resoluções 3 - Definido
Medições e análises 2 - Gerenciado
Garantia da qualidade do processo e produto 2 - Gerenciado

A ISO/IEC 12207 agrupa as atividades associadas a um sistema de software em dois

ciclos de vida e sete grupos. Os processos do ciclo de vida de sistema estabelecem a infra-
estrutura para tratar de um produto ou serviço de software. Por sua vez, ciclo de vida de
software fornece processos específicos para a implementação de um produto ou serviço de
software como parte de um sistema mais amplo (ISO/IEC, 2008, p. 19).
O MPS.BR tem o objetivo de fornecer às organizações brasileiras um guia para
direcionar os esforços de melhoria de processos de software. O modelo, distribuído em sete
níveis de maturidade, foi desenvolvido em conformidade com os padrões internacionais de
qualidade de software e estabelece um modelo de processos baseado nas normas NBR
ISO/IEC 12207 e ISO/IEC 12207 e um método de avaliação baseado na norma ISO/IEC
15504 (SOFTEX, 2007, p. 12).
Os três modelos de processos de software apresentados compartilham o objetivo de
orientar às organizações no caminho das melhores práticas para fornecimento de produtos e
serviços de software. Além de diversas referências em comum (ISO/IEC, 2008, p. 31) (SEI,
 11

2006a, p. 517) (SOFTEX, 2007, p. 47), a relação de processos dos modelos possui
semelhanças de nomenclatura, propósitos e resultados.
A partir das semelhanças entre os processos do ciclo de vida de software, pode-se
concluir que todos os três modelos servem como referência para o gerenciamento de
processos de software, já que abrangem todos os aspectos envolvidos na produção de
produtos e serviços de software.
O uso de uma abordagem baseada em processos pela indústria de software traz
consigo a necessidade de avaliar e evoluir estes processos, a fim de executar projetos
controlados e previsíveis. As ferramentas e técnicas de medição e análise quantitativa
permitem as organizações determinar e prever o desempenho dos seus processos, detectarem
desvios e identificar oportunidades de melhoria.

2.2. Medição de software

A engenharia de software envolve a aplicação de técnicas de engenharia em conjunto

com a ciência da computação para a construção e suporte de produtos de software. Neste
processo, a abordagem da engenharia quer dizer que cada atividade é planejada e a sua
execução é objetivamente controlada. Medições realizam um papel importante no
desenvolvimento de software efetivo e eficiente, bem como fornecem a base científica que
torna a área de software uma verdadeira disciplina da engenharia. (FENTON; PFLEEGER,
1997, p. 9) (KAN, 2003).
Processos efetivos de medição do desempenho auxiliam na obtenção de sucesso, pois
permitem à organização entender a sua capacidade de forma desenvolver planos atingíveis
para a entrega de produtos e serviços. As medições auxiliam também na detecção de
tendências e na antecipação de problemas, resultando em um melhor controle de custos,
redução de riscos, melhoria da qualidade e garantindo que os objetivos de negócio sejam
atingidos (FLORAC; CARLETON, 1999, p. 10).

2.2.1. Conceituação

García et al (2006, p. 635) afirmam não haver tratamento uniforme para alguns
conceitos básicos de medição como métrica, medida básica, medida derivada e indicador.
Neste contexto, é importante definir os conceitos que serão utilizados como base para este
trabalho.
 12

Medição é um conjunto de operações com objetivo de determinar um valor a uma

medida (ISO/IEC, 2002, p. 4).
Segundo Fenton e Pfleeger (1997, p. 5), medição é o processo pelo qual números ou
símbolos são atribuídos para atributos de entidades no mundo real, como meio de descrevê-
los de acordo com regras claramente definidas. Medições, portanto capturam informação
sobre atributos de entidades. Uma entidade é um objeto ou um evento do mundo real. Um
atributo é uma característica ou propriedade de uma entidade. Quando as entidades são
descritas através de seus atributos, normalmente estes atributos são definidos por números ou
símbolos, ou seja, medidas.
Por fim, medição pode ser definida como o mapeamento do mundo empírico ou real
para o mundo formal, representado por elementos de um sistema numérico.
Conseqüentemente, uma medida é o número ou símbolo atribuído a uma entidade através
deste mapeamento de forma a caracterizar um atributo desta entidade (FENTON,
PFLEEGER, 1997, p. 28).
A partir do momento onde exista um modelo para representar as entidades e seus
atributos, podem ser definidas medidas que permitam a sua avaliação e comparação com
outras entidades (FENTON; PFLEEGER, 1997, p. 39). Medidas básicas ou diretas podem ser
definidas em termos de um atributo e o método para quantificá-lo e são independentes de
outras medidas. Medidas derivadas ou indiretas são definidas como uma função de dois ou
mais valores de medidas básicas ou diretas. (ISO/IEC, 2002, p. 3) (ABNT, 2008).
As medidas podem, ainda, ser classificadas de acordo com o método de medição como
subjetivas, quando a obtenção de um valor para a medida envolve o julgamento humano, ou
objetivas, nos casos em que, a partir de regras estabelecidas, é obtido um valor numérico para
a medida (ISO/IEC, 2002, p. 4).
O método de medição representa a seqüência lógica de operações para quantificar um
atributo em relação à determinada escala. As principais escalas de medição descritas na
literatura são apresentadas no Quadro 3.
Finalmente, outro conceito importante na área de medição é o indicador. Para autores
como ISO/IEC (2002, p. 22), Mcgarry et al (2002), SEI (2004, p. 1), um indicador é uma
medida ou uma combinação de medidas, normalmente apresentado na forma de gráfico ou
tabela, que provê entendimento a respeito de uma questão ou conceito de software. Os
indicadores são a base para a análise e tomada de decisão, portanto são eles que devem ser
apresentados aos usuários de medição.
 13

Quadro 3: Escalas de medição (FENTON; PFLEEGER, 1997, p. 45-53) (KAN, 2003, p. 59-61) (ISO/IEC,
2002, p. 5)

Escalas de
Descrição Exemplos
medição
Número de defeitos encontrados
no software, número de pessoas
A medição para uma escala absoluta é feita simplesmente pela
Absoluta da equipe, número de
contagem do número de elementos no conjunto da entidade.
ocorrências de um determinado
tipo, etc.
Cor dos olhos, classes de
Os valores das medidas são categorizados, representados por
defeitos, nomes de linguagens,
Nominal um nome ou rótulo. Não existe ordenação implícita entre as
classes de custos (custos
classes.
diretos, custos indiretos), etc.
Níveis de maturidade do CMMI
(níveis de 1 a 5), complexidade
Os valores das medidas são classificados, acrescentando a
de um sistema (baixa, média,
Ordinal noção de ordem e comparação. Porém, neste tipo de escala não
alta), classificação de
podem ser realizadas operações matemáticas entre as medidas.
severidade de um defeito em
níveis, etc.
Os valores das medidas têm distâncias iguais correspondendo a
quantidades iguais dos atributos. Preserva a importância da
ordem dos resultados da escala ordinal e ainda possui
Complexidade ciclomática,
Intervalar informações sobre o tamanho dos intervalos que separam seus
intervalo de datas, horários, etc.
pontos. Operações matemáticas de adição e subtração podem
ser aplicadas, porém não são permitidas multiplicações e
divisões entre as medidas. O valor zero não é possível.
Preserva a ordem, o tamanho dos intervalos entre entidades,
mas apresenta também as razões entre elas. Incorpora o
Tamanho, peso, altura, tempo
elemento zero absoluto (representando a total falta do
Razão entre falhas, custo, prazo,
atributo). Todas as funções aritméticas podem ser utilizadas
esforço, etc.
aplicadas em cada intervalo do mapeamento, gerando
resultados significativos.

Takara, Bettin e Toledo (2007, p. 92) complementam que um indicador é uma medida
extremamente importante para a organização, sendo acompanhada e analisada periodicamente
a partir de uma meta de desempenho pré-estabelecida.
A experiência de SEI (2001, p. 5) sugere que, em um programa de medição,
normalmente não é suficiente a definição de questões e medidas sem a visualização e reporte
de um indicador como forma de comunicação dos resultados.

2.2.2. Fatores críticos da implantação de programas de medição

As dificuldades encontradas na gestão de serviços de software tornam clara a

necessidade da implantação de programas de medições nas organizações. Porém, de acordo
com McGarry et al (2002), desenvolver um programa de medições de forma desordenada
agrega um alto nível de riscos que pode comprometer os objetivos desejados. Abaixo são
 14

listadas as principais falhas cometidas na implantação de programas de medições

(MCGARRY et al, 2002):
• A sobrecarga envolve a coleta simultânea de muitos dados, o que resulta em
esforço desperdiçado e perda da credibilidade do programa de medição.
• O uso incorreto da medição é a utilização dos resultados de medições para
avaliação dos profissionais, resultando em perda da integridade dos dados, pois
os profissionais tendem a mascarar os dados com medo de que estes sejam
utilizados contra eles.
• As falhas de medição são a obtenção de medidas erradas, ambíguas e
inconsistentes, resultando em análises não conclusivas.
• As falhas de processo são a obtenção de medidas que motivam as falhas de
processo (exemplo: o objetivo de diminuir a taxa de resolução de problemas
induz à ação indesejada de que as equipes tratem primeiramente os problemas
mais simples).
Berander e Jönsson (2006, p. 316), complementam que, devido à ausência de foco, os
modelos de gestão quantitativa aplicados nas organizações resultam em grande quantidade de
dados que nunca são analisados ou utilizados. Nestes casos, o fato dos envolvidos não
saberem claramente quais medidas são importantes, torna o esforço de medição uma perda de
tempo, causando a perda da credibilidade do processo de medição. Sendo assim, é melhor que
as organizações possuam poucas métricas úteis do que muitas sem utilidade alguma.
Segundo McGarry et al (2001, p. 7), a experiência de uma grande gama de projetos de
desenvolvimento e manutenção de software sugere que, para se obter sucesso em um
programa de medições é necessário desenvolver dois aspectos chaves: os procedimentos de
coleta, análise e reporte das medidas devem ser relacionados diretamente às necessidades de
informação dos tomadores de decisão nos projetos de software; e um processo de medição
estruturado, repetível e adaptável deve estar em prática para apoiar os processos técnicos e
gerenciais da engenharia de software.
Diferentes abordagens de medição estão disponíveis na literatura com o objetivo de
auxiliar a identificação de medidas, métodos e técnicas de medição dos processos de software,
alinhados com os objetivos da organização e de seus projetos. Dentre estas, destacam-se o
framework de medição proposto por Florac e Carleton (1999), O GQM (Goal-Question-
Metric) proposto por Basili, Caldiera e Rombach (2002), O PSM (Practical Software
Measurement) de McGarry et al (2002) e a norma ISO/IEC 15939 (ISO/IEC, 2002).
 15

2.2.3. Modelos de especificação de medidas

A fim de minimizar as dificuldades apresentadas na seção anterior, o SEI (SEI, 2004),

o PSM (DoD, 2004) e a ISO 15939 (ISO/IEC, 2002) apresentam modelos de especificação de
medidas, que podem ser utilizados como guia para a definição clara das medidas necessárias
para a avaliação dos processos da organização.
O Quadro 4 a seguir apresenta um paralelo realizado, mostrando lado a lado as
semelhanças e diferenças entre os três modelos de especificação de medidas referenciados,
identificando principalmente as informações que não são contempladas por algum dos
modelos de documento.
A partir da análise dos diferentes modelos de especificação, é possível concluir que o
modelo do PSM proposto por DoD (2004) é o mais completo, contendo a maior quantidade de
seções para especificação da medida.

2.2.4. Medidas de processos de software

O assunto de medição de processos de software tem sido tema recorrente em

publicações especializadas. Diversos autores apresentam em seus trabalhos propostas e
conclusões a respeito de programas de medições implementados em diferentes contextos e
organizações.
Publicações como as de Florac e Carleton (1999) e McGarry et al (2002) dissertam de
forma abrangente sobre o tema de medição de processos de software, apresentando as
técnicas, boas práticas e também exemplos de medidas para avaliação destes processos.
Trabalhos mais direcionados como o SEI (2006a) e Kulpa e Johnson (2008)
apresentam medidas de desempenho relacionadas com as áreas de processos do modelo
CMMI-DEV. Já autores como Becker et al (2006), Wang e Li (2005), Debou, Kuntzmann-
Combelles e Rowe (1994), Buglione e Abran (2005), Xu et al (2006), IEEE (1992), Murdoch
et al (2003), Paul et al (1999), Galin e Avrahami (2005) (2006), Chikofsty e Rubin (1999) e
García et al (2004) identificam medidas para avaliação de aspectos específicos dos processos
de desenvolvimento de software, como por exemplo: retorno do investimento, produtividade,
eficácia de testes, entre outros.
 16

Quadro 4: Comparação dos modelos de especificação de medida

SEI (SEI, 2004) PSM (DoD, 2004) ISO 15939 (ISO/IEC, 2002)
Nome/título do indicador Nome da medição Não contém a informação
Data Versão da medição Não contém a informação
Descrição da necessidade de informação
Questões Necessidade de informação Necessidade de informação
Não contém a informação Categoria de informação Não contém a informação
Objetivo Conceito mensurável Conceito mensurável
Entidade e atributos
Não contém a informação Entidades relevantes Entidades relevantes
Não contém a informação Atributos Atributos
Entradas Especificação de medida básica
Elementos de dados
Medidas básicas Medidas básicas
Definição
Não contém a informação Métodos de medição Método de medição
Não contém a informação Tipos de métodos Tipo de método de medição
Não contém a informação Escala Escala
Não contém a informação Tipos de escalas Tipo de escala
Não contém a informação Unidade de medição Unidade de medição
Especificação de medida derivada
Não contém a informação Medidas derivadas Medida derivada
Algoritmo Função de medição Função de medição
Especificação de indicador
Visualização gráfica Descrição do indicador e amostra Indicador
Análise Modelo de analise Modelo
Não contém a informação Critério de decisão Critério de decisão
Interpretação Interpretação do indicador Não contém a informação
 17
Quadro 4 (cont.): Comparação dos modelos de especificação de medida

SEI (SEI, 2004) PSM (DoD, 2004) ISO 15939 (ISO/IEC, 2002)
Coleta de dados Procedimento de coleta de dados (para cada medida básica)
Como Não contém a informação Não contém a informação
Quando/Em que freqüência Freqüência da coleta de dados Não contém a informação
Por quem Responsável Não contém a informação
Não contém a informação Fase ou atividade de coleta de dados Não contém a informação
Formulários Ferramentas utilizadas para coleta de dados Não contém a informação
Não contém a informação Verificação e Validação Não contém a informação
Armazenamento de dados
Onde Repositório de dados coletados Não contém a informação
Como Não contém a informação Não contém a informação
Segurança Não contém a informação Não contém a informação
Reporte de dados Procedimento de análise de dados (para cada indicador)
Em que freqüência Freqüência de reporte dos dados Não contém a informação
Responsável pelo reporte Responsável Não contém a informação
Não contém a informação Fase ou atividade de análise dos dados Não contém a informação
Não contém a informação Fonte de dados para análise Não contém a informação
Não contém a informação Ferramentas utilizadas para análise de dados Não contém a informação
Por quem/Para quem Não contém a informação
Revisão, reporte e usuário
Perspectiva Não contém a informação
Informação adicional
Questões de sondagem Não contém a informação
Guia de análise adicional
Referência cruzada Não contém a informação
Não contém a informação Considerações de implementação Não contém a informação
Premissas Não contém a informação Não contém a informação
Evolução Não contém a informação Não contém a informação
Guia para sugestões de melhoria no indicador Não contém a informação Não contém a informação
 18

Relatórios redigidos por SEI (2006b) e Kulik e Weber (2002), fazem uma ampla
avaliação da maturidade das organizações no que tange os processos de medição e análise do
desempenho dos seus processos. Ambos concluem que as organizações têm inúmeras
dificuldades na implantação de programas de medição.
Apesar disto, autores publicam também os resultados de pesquisas experimentais,
realizadas em organizações de reconhecida maturidade em processos de software, como a
IBM, NASA e HP (KITCHENHAM et al, 2006) (RESEMBERG; SHEPPARD; 1994)
(MCGARRY; BURKE; DECKER, 1998) (LINDSTRÖM, 2004) (GRADY, 1994)
(AGRAWAL; CHARI, 2007) (HERBSLEB; GRINTER, 1998) (GALIN; AVRAHAMI,
2007) (HALL; FENTON, 1997).
As diferentes medidas identificadas nestes trabalhos formam a base conceitual para a
definição do catálogo proposto nesta pesquisa, sendo apresentadas no capítulo 3.

2.3. Análise de desempenho de processos de software

Quando definidas e relacionadas aos processos de software, as medidas permitem a

avaliação precisa do desempenho dos processos e projetos. Esta seção apresenta o objetivo,
instrumentos e outros conceitos a respeito da análise de desempenho de processos de
software.

2.3.1. Análise de desempenho de processos segundo o modelo CMMI-DEV

O modelo CMMI-DEV (SEI, 2006a) estabelece um conjunto de áreas de processo

envolvidas na análise de desempenho dos processos e gestão quantitativa de projetos,
conforme apresentado na Figura 2. Estas áreas de processos interagem entre si através de seus
resultados, possibilitando a identificação da capacidade dos processos da organização, e a
partir daí gestão quantitativa dos seus projetos.
 19

Figura 2: Áreas de processo envolvidas na gestão quantitativa (Adaptado de SEI, 2002).

Segundo o CMMI-DEV (SEI, 2006a), a execução de todas as áreas de processos em

um projeto de desenvolvimento de software fornece informações a partir das quais é possível
avaliar o desempenho do projeto (Passo 1 da Figura 2). Estas informações de desempenho
são coletadas pela área de Medição e Análise (MA), que é focada na definição de medidas,
coleta de dados, apuração e análise dos resultados obtidos pela organização ao desenvolver
seus produtos
O histórico de medidas de desempenho coletadas pela organização nos seus diferentes
projetos (Passo 2 da Figura 2) é insumo para o estabelecimento do Desempenho do
Processo Organizacional (DPO). A área de processo de DPO proporciona um entendimento
quantitativo de desempenho dos processos da organização, provendo linhas de base de
medidas e modelos estatísticos de avaliação do desempenho dos processos a serem aplicados
na gestão quantitativa dos projetos (Passo 3 da Figura 2).
A Gestão Quantitativa de Projetos (GQP) utiliza os modelos de desempenho para
gerenciar quantitativamente o projeto, comparando o resultado das medidas de desempenho
dos processos do projeto (Passo 4 da Figura 2) com a linha de base estabelecida em DPO. O
foco desta área de processos é identificar sinais de desvios e prever o desempenho futuro do
projeto para suportar a tomada de decisões, a fim de manter o projeto alinhado com os seus
objetivos.
Durante o planejamento do projeto, o gerente beneficia-se dos valores históricos e
análises realizadas como subsídio para refinar as estimativas, tornando o planejamento mais
 20

preciso e aderente à realidade do projeto e da organização. O Monitoramento e Controle do

Projeto (MCP) envolve a avaliação da gravidade dos desvios para estabelecer ações
corretivas e preventivas, baseado nos resultados da análise quantitativa do projeto (Passo 5 da
Figura 2).
Para os desvios críticos, por exemplo, aqueles que podem comprometer
significativamente o resultado do projeto, a avaliação das alternativas de ações deve ser
realizada por um processo formal de tomada de decisões (Passo 6 da Figura 2). Através da
área de Análise de Decisão e Resolução (ADR), o gerente pode utilizar métodos formais de
avaliação de alternativas a fim de decidir as ações mais adequadas em cada caso (Passo 7 da
Figura 2).
Por fim, as ações gerenciais corretivas e preventivas para tratamento dos desvios são
então implementadas nos processos do projeto (Passo 8 da Figura 2), fechando o ciclo que
tem como objetivo melhorar continuamente o desempenho dos processos alinhado com os
objetivos do projeto.

2.3.2. Entendimento do desempenho do processo organizacional

De acordo com o SEI (2006a, p. 261), obter o entendimento do desempenho do

processo organizacional, descritos na área de processo de Desempenho do Processo
Organizacional (DPO), envolve estabelecer e manter um entendimento quantitativo do
desempenho dos processos e prover dados de desempenho, linhas de base para comparação e
modelos para gerenciar quantitativamente os projetos da organização. As seguintes práticas
são específicas para a citada área de processo do modelo CMMI-DEV:
1) Selecionar processos
2) Estabelecer medidas de desempenho dos processos
3) Estabelecer objetivos de desempenho dos processos
4) Estabelecer linhas de base de desempenho dos processos
5) Estabelecer modelos de desempenho dos processos
As medidas podem ser utilizadas para sumarizar o desempenho dos processos em um
conjunto de projetos da organização. Os dados das medições são analisados para estabelecer
metas e limites que caracterizem o desempenho esperado dos projetos ao executarem os
processos. Métodos são utilizados para comparar o desempenho dos projetos com as metas e
limites estabelecidos a fim de gerenciar quantitativamente os projetos avaliando seu resultado
e prevendo a sua capacidade de atender aos objetivos no futuro.
 21

Quando a organização possui medidas, dados e técnicas analíticas para processos

críticos, produtos e serviços, ela é capaz de (SEI, 2006a, p. 262):
• Determinar se o processo está se comportando de forma consistente ou possui
tendência estável, ou seja, se seus resultados são previsíveis.
• Identificar processos para os quais o desempenho está dentro de limites
naturais.
• Estabelecer critérios para identificar quando um processo ou subprocesso deve
ser estatisticamente gerenciado, determinando as medições e técnicas
necessárias para tal.
• Identificar processos que demonstram comportamento incomum, ou seja, que
são instáveis ou imprevisíveis.
• Identificar os aspectos nos processos que possam ser melhorados.
• Identificar qual implementação de processo que é realizada com maior
eficiência.

2.3.3. Importância da estabilidade do processo

Em toda e qualquer atividade, automatizada ou realizada manualmente, os resultados

não são uniformes, estes variam de acordo com as condições nas quais a atividade foi
realizada. Ao realizar o controle estatístico de um processo, as variações nos dados de suas
medições precisam ser avaliadas a fim de identificar se estas se tratam de ruídos ou sinais
(FLORAC; CARLETON, 1999, pp. 65-70).
Ruídos (variações randômicas ou variações por causas comuns) descrevem condições
normais de execução do processo, ou seja, condições previstas devido à instabilidade natural
de todo e qualquer processo. Sinais (variações não randômicas ou variações por causas
especiais) identificam condições de desvio, ou seja, situações onde o desempenho do processo
desviou consideravelmente e, portanto ações para tratamento das causas devem ser
implementadas. De acordo com Florac e Carleton (1999, p. 67), agir em ruídos como se
fossem sinais apenas amplifica a instabilidade e aumenta a variabilidade dos resultados do
processo. Deixar de agir em sinais avaliando-os como ruídos mascara as deficiências do
processo e limita a identificação de oportunidades de melhoria.
Quando todas as causas especiais forem removidas e sua recorrência futura for evitada
através de ações de prevenção, somente as causas comuns de variação permanecerão. Neste
 22

momento o processo pode ser considerado estável e, portanto o seu desempenho futuro torna-
se previsível. (FLORAC; CARLETON, 1999, p. 70).
A estabilidade do processo é crucial para que a organização seja capaz de produzir
seus resultados de acordo com os planos. Florac e Carleton (1999, p. 71), justificam a
importância de se obter processos estáveis:
• Sem estabilidade e o entendimento da capacidade do processo, não existe
forma de distinguir sinais de ruídos, o que pode resultar em ações
inapropriadas.
• Sem um histórico de desempenho estável, situações descontroladas podem
ocorrer a qualquer tempo. Não existe base para prever as situações futuras e,
portanto todos os planos são considerados de alto risco.
• Desconhecendo o nível de estabilidade do processo, não existe base de
comparação para reconhecer causas especiais de desvio que demandem ações
de melhoria.
• Sem estabilidade não se obtém um processo repetível para usar como linha de
base para a implementação de melhorias. De fato, não existe um único
processo, mas diversos, todos diferentes. Os efeitos das ações de melhoria
podem ser imperceptíveis em meio a todas as variações.

2.3.4. Ferramentas de análise de desempenho de processos

Conforme apresentado anteriormente, a execução de processos de software

normalmente apresenta variação de desempenho. De acordo com a linha de base do processo,
as variações são consideradas de causas comuns ou de causas especiais. Neste último caso, o
processo passa a ser considerado em estado de desvio e, portanto necessita ser tratado por
ações corretivas.
Diversos instrumentos de controle estatístico de processos são utilizados para avaliar o
desempenho dos processos de uma organização ou de um projeto de software específico.
Estas ferramentas apóiam a identificação e análise de causas especiais e, portanto são
fundamentais para a análise de desempenho de processos.
Autores como Wheeler e Chambers (1992, pp. 309-320), Florac e Carleton (1999, pp.
54-64), Kulpa e Johnson (2008, pp. 237-242), Stapenhrust (2005, pp. 337-351), PMI (2004,
pp. 192-196) e Oakland (2003, p. 44) apresentam as principais ferramentas utilizadas para a
análise de desempenho de processos, dentre as quais se destacam as listadas no Quadro 5.
 23

Quadro 5: Ferramentas para gestão quantitativa de projetos

Ferramenta Descrição Apresentação

Fluxograma A ferramenta de fluxograma é uma representação
gráfica das atividades do processo e pode ser
utilizada para analisar onde um problema ocorre.

Folha de Instrumento utilizando quando se quer coletar

Disciplina Recusas
verificação informação relacionada à freqüência de ocorrência de Requisitos √√
um determinado evento. Análise e projeto √√√√
Uma lista de verificação quando virada 90o fornece Implementação √√√√√
um bom indício de como o processo seria Testes √√
apresentado em um histograma ou diagrama de Gerenciamento de
√√√√√
Projetos
Pareto.
Diagrama de Este diagrama apresenta relacionamentos entre duas Quantidade de defeitos X
dispersão variáveis ou características de um processo. A Tamanho
observação de padrões nos pontos do digrama sugere 100,00

Quantidade de defeitos
que as variáveis analisadas são associadas, 80,00
60,00
possivelmente em uma relação de causa-e-efeito. 40,00
20,00
-
- 50,00 100,00 150,00

Tamanho

Histograma Um histograma exibe os dados coletados do processo Histograma

por freqüência. Os valores observados do processo 6

são distribuídos em determinados intervalos de 4

mesmo tamanho (colunas). A altura das barras de um 3

histograma é proporcional ao número de observações 2

dentro da do intervalo. 1

0
Os histogramas são úteis, pois permitem analisam a 0,0 0
to
0,08
to
0,16
to
0,24
to
0,32
to
0,40
to
0,48
to
0,56
to
0,64
to
0 ,72
to
0,80
to
0,8 8
to
0,96
to
1,04
to
1,12
to
0,0 8 0,16 0,24 0,32 0,40 0,48 0,56 0,64 0,72 0 ,80 0,88 0,9 6 1,04 1,12 1,20
taxa de variação de um processo.
Diagrama de O Diagrama de causa e efeito é uma representação
causa-e-efeito, gráfica de problemas e suas causas.
Espinha de peixe Esta ferramenta é muito útil em reuniões de
ou Ishikawa brainstorming, para capturar dos envolvidos na
execução do processo as causas prováveis de um
determinado problema.
Gráfico de Da mesma forma que um histograma, um gráfico de 35,00
Defeitos x Disciplinas x Builds

barras barras é utilizado para investigar o perfil de um 30,00

Build 1
Build 2

processo. Porém, os gráficos de barras podem conter 25,00

Build 3
Build 4

quaisquer valores, não somente freqüências como nos 20,00

15,00
histogramas. Neste caso, a largura das colunas e 10,00

barras é livre, e, juntamente com cores, sombras e 5,00

textos, podem ser utilizadas para diferenciar os dados -

do gráfico.
 24

Quadro 5 (cont.): Ferramentas para gestão quantitativa de projetos

Ferramenta Descrição Apresentação

Gráfico ou Um Diagrama de Pareto é simplesmente a exibição de
diagrama de freqüências de determinado dado em ordem
Densidade de defeitos (Pareto)
Pareto decrescente.
0,325
Esta ferramenta pode é utilizada para analisar as 0,350 100,00%

Densidade de defeitos
0,300 80,00%
0,250
60,00%
ocorrências mais comuns de um evento e priorizar as 0,200
0,150
0,100 0,055 0,046
40,00%
0,050 0,014 0,010 0,009 0,003 - - 20,00%
ações a serem tomadas no tratamento do processo. - 0,00%

Diagramas de Pareto são conceitualmente relacionados

com a Lei de Pareto, que defende que um número
relativamente pequeno de causas é responsável pela
produção da grande maioria dos problemas ou defeitos.
Gráfico ou Um gráfico ou carta de execução exibe observações IDC
0,600
carta de individuais de um processo no decorrer do tempo. 0,500

execução Esta ferramenta pode ser utilizada para identificar 0,400

tendências ou mudanças no desempenho do processo. 0,300

Um risco de utilizar simplesmente gráficos de 0,200

0,100
execução é a tendência de reagir às variações naturais 0,000

do processo. nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06

Gráfico ou Um gráfico de controle é basicamente um gráfico de IDC (X)

carta de execução com o acréscimo de uma linha central e 0,700
0,600

controle limites de controle inferior e superior associados. 0,500

0,400

Os limites de controle, definidos de acordo com cada 0,300

0,200
0,100
tipo de gráfico, permitem a organização acompanhar o 0,000
nov/05 dez/05 jan/06 fev/06 mar/06 abr /06 mai/06 jun/06 jul/06 ago/06 set/06

desempenho do processo e identificar as causas IDC (X) LC LCS (+3 sigmas) + 2 sigmas
+ 1 sigma LCI (- 3 sigmas) - 2 sigmas - 1 sigma
normais e especiais de variação.

Segundo Kulpa e Johnson (2008, p. 242), alguns autores não consideram o

Fluxograma e o Diagrama de causa-e-efeito ferramentas estatísticas, pois as mesmas não
necessariamente são focadas em dados quantitativos.

2.3.5. Gráficos de controle

Os gráficos de controle são uma das principais ferramentas para a análise de

desempenho de processos. Um gráfico de controle é uma ferramenta de controle estatístico de
processos que apresenta a execução de determinado processo geralmente no decorrer do
tempo, incluindo uma linha central que representa a média ou mediana do desempenho
observado no processo, e limites de controle superior e inferior para avaliação da estabilidade
do processo (STEPENHRUST, 2005, p. 447).
A estrutura clássica de um gráfico de controle é apresentada na Figura 3. Os limites de
controle superior (LCS) e inferior (LCI) em cada lado da linha central (LC) são derivados de
uma das possíveis medidas de variação do processo: amplitude, desvio padrão, amplitude
móvel, entre outras.
 25

Figura 3: Estrutura do gráfico de controle (Adaptada de Florac e Carleton, 1999, p. 77).

Os limites de controle superior e inferior são definidos a mais e menos 3 sigmas da

linha central, respectivamente. Quando um limite de controle é definido com um valor além
da variação possível do processo, este limite é normalmente omitido do gráfico, como por
exemplo, no caso de um limite de controle inferior (LCS) negativo para a medida densidade
de defeitos (FLORAC; CARLETON, 1999, p. 77).
Como descrito nas seções seguintes, existem diferentes tipos de gráficos de controle
disponíveis para uso como instrumento controle estatístico de processos. Características como
o tipo de dado sendo representado no gráfico, bem como o agrupamento destes dados em cada
observação do gráfico são fatores determinantes para a seleção do gráfico e análise correta do
desempenho do processo.

2.3.5.1. Tipos de dados

Segundo Florac e Carleton (1999, p. 78), Kulpa e Johnson (2008, p. 247), Stapenhrust
(2005, p. 265), e Oakland (2003, p. 45), os dados utilizados para análise de desempenho de
processos podem ser classificados como variáveis ou atributos. Ao exibir os dados em um
gráfico de controle, é importante ter um entendimento claro das diferenças entre os tipos de
dados, já que os tipos de gráficos de controle e seus limites são em geral diferentes para
variáveis e atributos.
Dados variáveis, também chamados de dados de medições, medem normalmente
fenômenos contínuos ou contagens que representam medição de tamanho ou situação.
Exemplos de variáveis para a área de software incluem esforço gasto, anos de experiência,
utilização de memória e custo de retrabalho.
 26

Por outro lado, os dados são classificados como atributos, ou dados discretos, nos
casos onde a informação é registrada somente quando o processo atende a determinado
critério. Atributos são normalmente medidos como contagens, como por exemplo: número de
defeitos encontrados, número de itens defeituosos, número de linhas de código de
determinado tipo, número de pessoas com determinada habilidade, entre outros.

2.3.5.2. Subgrupos de dados

Para Wheeler e Chambers (1992, pp. 40-42), dado determinado processo, medido a
partir de uma quantidade de valores numéricos, é importante determinar como estes dados
serão utilizados para análise e conclusão a respeito do fenômeno.
O conceito de subgrupo de dados trata da organização dos dados de maneira racional,
de forma que seja possível monitorar tanto o valor quanto a dispersão dos valores produzidos
pelo processo. Um subgrupo envolve um conjunto de múltiplas observações da medida
coletadas dentro de um curto espaço de tempo e, principalmente, sob as mesmas condições de
execução do processo (WHEELER; CHAMBERS, 1992, pp. 40-42) (FLORAC;
CARLETON, 1999, p. 137).
As medidas de um determinado subgrupo são apresentadas no gráfico de controle
como uma única observação do processo, representada pela média ou mediana dos dados da
amostra. Espera-se, portanto que exista uniformidade nos dados do subgrupo, e que variações
internas ao subgrupo sejam resultado de causas semelhantes de variação (FLORAC;
CARLETON, 1999, p. 137).
A homogeneidade dos subgrupos de dados é importante porque a variação das
observações dentro do subgrupo é utilizada para compor os limites de controle para o
processo. Minimizar esta variação torna os limites de controle mais ajustados ao desempenho
real do processo e, portanto torna mais fácil e precisa a identificação de causas especiais de
variação entre os subgrupos (FLORAC; CARLETON, 1999, p. 138).

2.3.5.3. Seleção do gráfico de controle

Diferentes tipos de gráficos de controle são disponíveis para uso pela organização, e a
seleção de qual tipo é o mais adequado para cada situação não é trivial (KULPA; JOHNSON,
2008, pp. 244-247).
 27

A Figura 4 apresenta de forma resumida as características envolvidas na seleção e as

questões que a organização precisa responder a respeito dos seus processos antes da decisão
de que gráfico de controle utilizar.

Figura 4: Fluxograma de decisão do gráfico de controle (Adaptado de Stapenhrust, 2005, p. 264)

O processo de seleção apresentado na Figura 4 inicia-se pela decisão de que tipo de

dado a medida representa (1), conforme explicado anteriormente na seção 2.3.5.1. Caso a
medida represente um dado variável, a segunda pergunta a ser respondida é qual o tamanho
do subgrupo de dados apresentado em cada observação da medida (1.1), conforme descrito na
seção 2.3.5.2.
Considerando o dado é variável (1), caso o gráfico contenha apenas valores
individuais, ou seja, subgrupo de tamanho igual a 1 (1.1), então o gráfico de controle mais
adequado é o de médias e amplitudes móveis (XmR). Se o subgrupo for maior do que uma
coleta da medida (1.1), então se deve perguntar se o gráfico de controle será apresentado a
partir do desvio padrão ou amplitude das medidas dentro do subgrupo (1.1.1).
Neste caso, se o gráfico de controle for representado pela amplitude das medidas do
subgrupo, alternativa normalmente adequada quando o subgrupo tiver tamanho menor ou
igual a 10 medidas, o gráfico de médias e amplitudes (X-bar e R) é o indicado. Agora, se o
gráfico for construído a partir do desvio padrão dos dados do subgrupo, normalmente
indicado para subgrupos de tamanho maior que 10 medidas, então o gráfico de médias e
desvio padrão (X-bar e S) passa a ser o selecionado.
Caso a medida seja um atributo ao invés de uma variável (1), o próximo passo é
avaliar o seu modelo de distribuição estatística (1.2). Este modelo pode ser binomial, como no
 28

caso quando a medida baseia-se na quantidade de produtos com defeito, ou Poisson, quando,
por exemplo, a medida representa a quantidade de defeitos de um ou mais produtos.
Independentemente do modelo de distribuição (1.2) selecionado, a última pergunta
(1.2.1 e 1.2.2) refere-se à configuração das amostras de dados, ou áreas de oportunidade.
Neste caso, é necessário avaliar se as amostras de dados possuem tamanhos fixos ou variáveis
dentro de cada medida.
Por exemplo, uma medida de densidade de produtos defeituosos a cada 100 produtos
avaliados, representa uma distribuição binomial de amostras de tamanho fixo (100 produtos).
Neste caso o gráfico mais adequado é o np Chart. Já uma medida de densidade de defeitos por
ponto de função em sistemas de escopo diferentes, será representada por uma distribuição
Poisson em amostras de tamanhos variáveis, sendo mais adequado o uso de gráficos do tipo u
chart.
O Quadro 6 apresenta os principais tipos de gráficos de controle, suas aplicações e
exemplos de utilização em processos de engenharia de software.

Quadro 6: Resumo dos tipos de cartas de controle

Tipo de
gráfico de Descrição e aplicação Exemplos para área de software
controle
X-bar e R Gráficos para médias (X-bar) e dispersão (R) são úteis para • Média de esforço realizado
(XbarR) determinar quando a média (X-bar) ou a dispersão do diariamente com retrabalho
subgrupo (R) são afetadas por causas especiais. por semana (neste caso o
Estes gráficos de controle respondem às perguntas: ‘Qual é a subgrupo é de 1 semana ou 5
tendência central do processo?’ e ‘Quanta variação ocorreu dias úteis)
de um subgrupo a outro no decorrer do tempo?’ • Produtividade média de
Utilizada para dados do tipo variável com subgrupos projetos Java por mês (neste
pequenos (menores ou iguais a 10 observações). caso o subgrupo é o conjunto
de projetos Java finalizados
no mês)
X-bar e S Gráficos para médias (X-bar) e desvio padrão (S) são • Taxa de revisão de código
(XbarS) semelhantes às cartas X-bar e R, porém são mais eficientes (LOC/hora) por release (neste
que a primeira para subgrupos grandes (maiores que 10 caso o subgrupo é cada
observações). release, contendo mais do
que 10 revisões de código)
X e mR Nos casos onde as medições são coletadas de forma esparsa Aplicável para a maioria das
(XmR) ou quando são utilizadas individualmente para avaliação do medidas de processos de software:
processo, somente é possível apresentar valores individuais • Produtividade de um
nos gráficos de controle. O gráfico X é utilizado para valores determinado projeto por mês
individuais (subgrupo de tamanho 1), enquanto o gráfico mR • Variação de prazo de um
apresenta a variação entre dois valores consecutivos do determinado projeto por fase
processo. • Esforço realizado
diariamente com retrabalho
Utilizada tanto para variáveis quanto para atributos, em determinado projeto
independente de modelo de distribuição e com valores
individuais (subgrupo igual a 1).
 29

Quadro 6 (cont.): Resumo dos tipos de cartas de controle

Tipo de
gráfico Exemplos para área de
Descrição e aplicação
de software
controle
c-chart Utilizada para dados do tipo atributo com distribuição Poisson e • Número de defeitos
amostras de tamanhos constantes, normalmente maiores que 5 encontrados durante
observações. inspeção ou testes
• Número de shutdowns não
planejados no servidor de
aplicação
u-chart Gráfico de controle mais utilizado em processos de software caso • Defeitos por milhares de
os dados sejam atributos e a distribuição seja Poisson. É mais linhas de código
flexível que a carta c, pois permite a normalização dos dados • Defeitos por pontos de
(conversão para taxas), já que o tamanho das amostras não é função
constante.

Utilizada para dados do tipo atributo com distribuição Poisson e

amostras de tamanhos variáveis.
np- Utilizada para dados do tipo atributo com distribuição binomial e Praticamente não é utilizado para
chart todas as amostras de tamanhos constantes, normalmente maiores processos de software. Mais
ou iguais a 50 observações. adequado para processos
industriais.
p-chart Utilizada para dados do tipo atributo com distribuição binomial e • Percentual de código fonte
amostras de tamanhos variáveis, normalmente maiores ou iguais em um módulo que possui
a 50 observações. determinada instrução (ex.:
comentário)

De acordo com Florac e Carleton (1999) e Kulpa e Johnson (2008), os gráficos de

controle do tipo XmR são quase sempre os mais adequados para a análise de desempenho de
processos de software. As razões para a sugestão de uso de gráficos do tipo XmR são:
• Os gráficos XmR são recomendados para uso tanto para variáveis quanto para
atributos.
• A utilização de valores individuais em cartas do tipo XmR evita a preocupação
quanto à homogeneidade do subgrupo.
• Os gráficos do tipo XmR não possuem como requisito nenhum modelo de
distribuição específico. Sendo assim, estes provêem um instrumento confiável
para análise do desempenho do processo, sem a preocupação em garantir que
o processo respeite uma distribuição normal, binomial ou Poisson.
• Por fim, os gráficos de controle XmR são mais fáceis de utilizar, mais fáceis de
entender e mais fáceis de implementar, além de serem os mais encontrados
em organizações de elevado nível de maturidade.
Por outro lado, apesar das vantagens apresentadas acima, o gráfico de controle do tipo
XmR não é a ferramenta mais adequada para a análise da medida de Densidade de defeitos
(FLORAC; CARLETON, 1999, p. 121). Normalmente, esta medida respeita um modelo de
 30

distribuição Poisson, onde a densidade de defeitos tende a diminuir enquanto aumenta o

tamanho do objeto de verificação. Para estes casos, as cartas de controle dos tipos c e u
aparecem como uma melhor opção em relação à XmR.

2.3.5.4. Cálculo da linha central e limites de controle

Segundo Florac e Carleton (1999, p. 76), os parâmetros utilizados para avaliação do

desempenho futuro do processo não devem ser definidos arbitrariamente, já que devem
representar o desempenho real do processo sob avaliação.
Os cálculos da linha central e limites de controle variam conforme o tipo de gráfico de
controle e a composição dos subgrupos utilizados para representar a medida. No ANEXO A
são apresentadas as tabelas de fórmulas e as constantes utilizadas para cálculo da linha central
e dos limites de controle superior e inferior do gráfico de controle. Para ilustrar este processo,
são apresentados detalhadamente a seguir o raciocínio de cálculo para os gráficos de controle
dos tipos XmR e u Chart.
Em um gráfico de controle XmR supõe-se que é possível apenas estabelecer subgrupos
de dados de tamanho igual a 1, ou seja, que os valores exibidos no gráfico correspondem a
observações individuais da execução do processo (FLORAC; CARLETON, 1999, p. 94).
Nesta situação não é possível calcular o valor do sigma a partir de uma única medida, então o
cálculo dos limites de controle dá-se a partir das mudanças ocorridas no processo entre duas
observações sucessivas (amplitude móvel - mR).
O gráfico de controle de valores individuais (X) demonstra a evolução das medidas em
relação ao tempo. Neste gráfico, conforme fórmulas apresentadas no Quadro 7, a linha

central (LC) é calculada a partir da média dos valores da medida ( X ) e os limites de controle
superior (LCS) e inferior (LCI) são calculados, respectivamente, a partir da soma e subtração

do valor constante de 2,66 vezes a média das amplitudes móveis ( mR ) em relação à linha
central (LC).
O cálculo do valor do sigma, utilizado para estabelecer limites intermediários de

controle, é realizado a partir da divisão da média das amplitudes móveis ( mR ) pelo valor
constante de 1,128.
Para o gráfico de controle de amplitudes móveis (mR) a linha central (LC) é calculada

a partir da média das variações do indicador ( mR ), o limite de controle superior (LCS) é

 31

calculado a partir de 3,268 vezes a média ( mR ). Neste gráfico o limite inferior (LCI) é
sempre igual a zero, pois os valores de amplitude são absolutos.

As constantes 3 , d 2 e D4 utilizadas nos cálculos são fatores tabulados por

d2
estatísticos para conversão das médias de amplitudes para estimativas de limites 3-sigma.
Para este gráfico de controle, estas variáveis assumem os valores únicos de 2,66, 1,128 e
3,268, respectivamente, já que a amostra utilizada para cálculo ( n ) é sempre de tamanho igual
a 2, representada pela amplitude móvel a cada dois valores consecutivos da medida. A tabela
completa de fatores de correção e constantes para este e outros tipos de gráficos de controle é
apresentada no ANEXO A.

Quadro 7: Fórmulas para o gráfico de controle XmR (Adaptado de Florac e Carleton, 1999, p. 95)

Fórmulas base Linha central e Limites de controle

X + X +K+ X =X+
3mR
= X + 2,660mR
X =
1 2 n
k
n
LCS X
d2
mR = X − X , onde 1 ≤ i ≤ k − 1
i i +1 i LC X
=X
3mR
i =k
LCI =X− = X − 2,660mR
∑ mR i
X
d2
mR = i =1
mR mR
k sigma = =
X d 2 1,128
LCS = D mR 4 mR = 3,268mR

LC = mR
mR

LCI = 0 mR

Para o caso do gráfico de controle do tipo u Chart, conforme fórmulas apresentadas no

Quadro 8, considera-se que o valor de cada observação da medida ( u i ) é calculado a partir da

taxa de ocorrência de determinado evento ( ci ) em relação ao tamanho da amostra ( a i ). Neste

gráfico, a premissa é que o tamanho das amostras não é constante, ou seja, variam para cada
coleta da medida, como nos exemplos de densidade de defeitos, onde o tamanho do produto
testado é variável. (FLORAC; CARLETON, 1999, p. 115).
A linha central (LC) para o u Chart é calculada a partir da média geral dos eventos

sobre o tamanho total das amostras ( u ). A presença do tamanho da amostra ( a i ) na

composição da fórmula dos limites de controle tem como conseqüência limites de controle
superior (LCS) e inferior (LCI) variáveis, ou seja, para cada observação da medida, os limites
 32

são re-calculados a partir da média geral ( u ) mais ou menos três vezes o valor do sigma, que
por sua vez é representado pela relação entre esta média e o tamanho a amostra para cada
observação da medida ( a i ).

Quadro 8: Fórmulas para o gráfico de controle u Chart (Adaptado de Florac e Carleton, 1999, p. 116)

Fórmulas base Linha central e Limites de

controle

= c , onde:
i
=u+3
u
u i LCS
a i
u
a i

• c é igual à quantidade de ocorrências (defeitos) =u

i LC u
• a é igual à área de oportunidade ou tamanho da
i u
amostra LCI u
= u−3

u=
∑c i
a i

∑a i
sigma =
u
u
a i

De acordo com Florac e Carleton (1999, p. 2008), mesmo com subgrupos de dados de
tamanho igual a 1 (XmR), 3 a 4 subgrupos já são suficientes para estabelecer limites de
controle temporários (trial limits) e a partir destes identificar situações de processos de fora de
controle. Porém, é prematuro concluir que um processo é estável com menos de 20 a 30
subgrupos de dados coletados, no caso de subgrupos de tamanho maior que 1 (X-bar e S), ou
pelo menos 40 a 45 dados individuais, no caso de gráficos XmR.

2.3.5.5. Regras para avaliação de processos em gráficos de controle

Os gráficos de controle são examinados a procura de padrões que mostrem

comportamentos incomuns do processo que o coloquem em situações de instabilidade ou fora
de controle.
Segundo Wheeler e Chambers (1992, p. 96), as quatro regras listadas abaixo e
exemplificadas na Figura 5Erro! Fonte de referência não encontrada. são suficientes para
detectar situações de instabilidade do processo em um gráfico de controle:
• Teste 1: Um ou mais pontos fora dos limites de controle superior (LC + 3
sigmas) e inferior (LC - 3 sigmas).
• Teste 2: Pelo menos dois de três pontos consecutivos a mais de 2 sigmas
da linha central (LC), no mesmo lado da linha central. Processos
 33

previsíveis tendem a apresentar 85% a 90% dos dados mais próximos à

linha central (LC).
• Teste 3: Pelo menos quatro de cinco pontos consecutivos a mais de 1
sigma da linha central (LC), no mesmo lado da linha central. Processos
previsíveis tendem a apresentar 85% a 90% dos dados mais próximos à
linha central (LC).
• Teste 4: Pelo menos oito pontos consecutivos localizados no mesmo lado
da linha central (LC). Demonstra que provavelmente tenha ocorrido uma
mudança no desempenho do processo que impacta a sua linha de base
(linha central e limites de controle).

Figura 5: Testes de instabilidade de processo

É importante ressaltar que os quatro testes listados acima, apesar de suficientes, não
são os únicos existentes para a detecção de instabilidade de processo. Outras regras podem ser
aplicadas para identificação de padrões de oscilação e tendências do processo. Porém, quanto
mais critérios são aplicados ao gráfico de controle, maior é a chance de obter alarmes falsos
na identificação de sinais de variação. (WHEELER; CHAMBERS, 1992, pp. 96-97).
Segundo Florac e Carleton (1999, p. 80), os testes 2, 3 e 4 são chamados testes de
execução e são baseados na premissa que a variação do processo é simétrica em volta da linha
central (LC) e que os dados são exibidos em uma seqüência temporal. Este requisito de
simetria significa que estes testes são desenhados para uso principalmente em gráficos de
controle dos tipos: X-bar e individuais (X). Sendo assim, os testes 2, 3 e 4 não se aplicam aos
gráficos de controle do tipo amplitude (R), desvio padrão (S) ou amplitude móvel (mR).
A partir da análise do desempenho do processo em um gráfico de controle e a
identificação de causas especiais de variação, o diagrama de causa-e-efeito pode ser utilizado
 34

para identificar as causas prováveis para o comportamento observado e, finalmente, o

diagrama de Pareto apóia o gerente do projeto na priorização das ações a serem aplicadas.

2.4. Gestão quantitativa de projetos de software

Após a análise de desempenho dos processos é possível realizar a gestão dos projetos
a partir de informações precisas de desempenho e limites que representam a capacidade dos
processos da organização
Segundo o PMI (2004), projeto é um empreendimento temporário realizado para criar
um produto, serviço ou resultado único. Projetos são os meios para a realização do
planejamento estratégico da organização, normalmente motivados por uma demanda de
mercado, necessidade organizacional, solicitação de usuário, avanço tecnológico ou
necessidade regulamentar.
O gerenciamento de projetos é a aplicação de conhecimento, habilidades, técnicas e
ferramentas em atividades, a fim de satisfazer os objetivos do projeto (PMI, 2004). Para tal, o
gerenciamento de projetos envolve atividades de diferentes áreas de conhecimento além de
habilidades da administração geral, conhecimentos específicos da área de aplicação do
projeto, habilidades interpessoais e entendimento do ambiente do projeto.
Segundo Wakeland, Martin e Raffo (2003, p. 2), a gestão de um projeto de
desenvolvimento de software transcende a complexidade da gestão de projetos de outras áreas
de aplicação. Inicialmente o gerente necessita fornecer estimativas de custos, prazos e
qualidade com base em informações incompletas sobre os requisitos e recursos. O gerente
acaba então tendo que decidir o escopo do trabalho, a metodologia do projeto, o cronograma e
a equipe levando em consideração o impacto de fatores ambientais como experiência da
equipe, estabilidade dos requisitos, cultura da organização e ambiente de desenvolvimento.
Para complicar o problema, os fatores citados são dinâmicos e mudam constantemente no
decorrer do projeto.
No gerenciamento de projetos tradicional, o esforço de monitoramento e controle
envolve basicamente a identificação de desvios do desempenho realizado em relação ao
planejado para o projeto. A partir destes desvios são estão identificadas e implementadas
alternativas de ação com o objetivo de convergir o projeto para os seus objetivos (PMI, 2004,
p. 41).
Além das características do gerenciamento de projeto tradicional, o gerenciamento
quantitativo de projetos envolve o uso das informações de desempenho coletadas no projeto e
 35

a capacidade dos processos da organização para avaliar a situação atual, variações em relação
ao planejamento e prever, através de modelos de desempenho, a probabilidade de o projeto
atender seus objetivos futuros. Através da avaliação correta das informações e da aplicação
adequada dos métodos de controle estatístico de processos (CEP) é possível coordenar ações
preventivas e corretivas de forma a manter o projeto alinhado com as suas metas de
desempenho (SEI, 2006a, p. 364-366).
Para o SEI (2006a, p. 364), o propósito da gestão quantitativa de projetos é gerenciar
quantitativamente o processo definido para o projeto a fim de que este atenda aos objetivos de
qualidade e de desempenho de processo estabelecidos para o projeto. A área de processo de
Gestão Quantitativa de Projetos (GQP) modelo CMMI-DEV envolve:
• Estabelecer e manter os objetivos de qualidade e de desempenho do processo
do projeto.
• Identificar os subprocessos adequados que compõem o processo definido para
o projeto, baseado no histórico de estabilidade e nos dados de capacidade
encontrados nas linhas de base ou modelos de desempenho de processos.
• Selecionar os subprocessos do processo definido do projeto que serão
gerenciados estatisticamente.
• Monitorar o projeto para determinar se os seus objetivos de qualidade e
desempenho dos processos estão sendo atendidos e identificar ações corretivas
apropriadas.
• Selecionar as medidas e técnicas analíticas que serão usadas para gerenciar
estatisticamente os subprocessos selecionados.
• Estabelecer e manter um entendimento da variação dos subprocessos
selecionados usando as medições e técnicas analíticas.
• Monitorar o desempenho dos subprocessos selecionados para determinar se
estes serão capazes de satisfazer, no futuro, os objetivos de qualidade e
desempenho de processos determinados para o projeto.
• Armazenar os dados da gestão estatística no repositório de medições da
organização.
Para o SEI (2006a, p. 313), o propósito do monitoramento e controle do projeto é
prover um entendimento do desempenho do projeto de forma que ações corretivas apropriadas
possam ser tomadas quando o desempenho do projeto desvia significativamente do
planejamento.
 36

O processo de gerenciamento das ações corretivas e preventivas envolve as seguintes

atividades: (SEI, 2006, p. 318):
1) Analisar problemas envolve coletar e analisar os sinais de problemas,
avaliando a sua criticidade e necessidade de ações para tratamento.
2) Tomar as ações corretivas envolve planejar a execução das ações a fim de
corrigir os problemas identificados.
3) Gerenciar as ações corretivas envolve acompanhar a execução das ações,
avaliando os resultados obtidos e determinar a eficiência das ações realizadas.

2.5. Considerações finais do capítulo

De posse das informações providas pelas medições do processo e de ferramentas

adequadas de controle estatístico de processos, a organização é capaz de identificar condições
de instabilidade do processo e implementar ações para prevenir e corrigir as causas de
variação, tornando-o o seu desempenho estável e previsível.
A partir dos conceitos expostos neste referencial teórico é possível perceber a
importância das medidas para a análise de desempenho dos processos e, principalmente, a
necessidade de se estabelecer medidas adequadas para os objetivos de cada organização.
 37

3. DEFINIÇÃO DO CATÁLOGO DE MEDIDAS

Neste capítulo é apresentada a abordagem proposta nesta pesquisa para a definição de

um catálogo de medidas que permita apoiar à análise de desempenho de processos de
desenvolvimento de software. Os passos descritos neste capítulo ilustram desde o processo de
seleção das medidas de desempenho até a consolidação de um catálogo de medidas,
devidamente classificadas de acordo com os seus objetivos de medição e distribuídas nas
diferentes áreas de processos do modelo CMMI-DEV.

3.1. Visão geral dos passos para definição do catálogo

Com o objetivo de melhorar o desempenho dos projetos de desenvolvimento de

software, as organizações têm buscado investir na melhoria de seus processos (RAFFO,
2005). Para tal, é necessário que a organização obtenha o entendimento do processo, que este
seja executado e monitorado através da coleta de medidas de desempenho, e que os seus
resultados sejam analisados para controlar e melhorar continuamente o processo (FLORAC;
CARLETON, 1999, p. 16).
Diversos autores como Agresti (2006), Hall e Fenton (1997) e Berander e Jönsson
(2006) afirmam que os programas de medição em prática nas organizações falham ao definir
inúmeras medidas que não são efetivamente coletadas, analisadas e utilizadas na tomada de
decisão nos projetos de software.
Os argumentos acima fundamentam a necessidade da gestão quantitativa como
instrumento para aumentar a efetividade de projetos de desenvolvimento de software. Por
outro lado, desafios como a falta de padronização e clareza na definição dos instrumentos de
medição dificultam o estabelecimento de um conjunto de medidas básicas para a organização,
capazes de prover informações confiáveis para a análise de desempenho de seus processos.
Com o objetivo de apoiar a implantação de programas de medição, esta pesquisa
oferece um catálogo detalhado de medidas de desempenho de processos de software, que
pode ser utilizado como instrumento de apoio na definição de medidas e processos de
medição, alinhados com as características da organização e de seus projetos.
Apesar da similaridade dos processos e técnicas de desenvolvimento de software em
prática nas organizações, as medidas de desempenho aplicadas para avaliação destes
 38

processos variam consideravelmente de uma organização para outra. Sendo assim, um dos
objetivos do catálogo é unificar os objetivos e características das medidas, permitindo que as
organizações comparem o desempenho dos seus processos com o desempenho geral da
indústria de software.
Para tal, torna-se necessário primeiramente identificar as medidas em prática nas
organizações, unificá-las em um conjunto mínimo e representativo de medidas para a
avaliação de desempenho de processos de software e, por fim, consolidar as medidas em um
catálogo, especificando detalhadamente as suas características. Seguindo esta linha
metodológica central, nove passos foram realizados no desenvolvimento desta pesquisa,
resumidos na Figura 6 e detalhados nas seções seguintes.

Figura 6: Passos para desenvolvimento do catálogo de medidas

 39

O desenvolvimento de catálogo de medidas envolveu duas grandes etapas: A seleção

de medidas e a consolidação do catálogo. A seleção de medidas tratou de realizar cinco passos
desde o levantamento de medidas citadas na literatura especializada até a seleção do conjunto
final de medidas para composição do catálogo.
O primeiro passo foi realizar uma ampla revisão da literatura para identificar as
medidas de desempenho em prática em organizações que executam projetos de
desenvolvimento de software. A partir do universo completo de medidas citadas na literatura,
o passo seguinte da pesquisa foi analisar todas as medidas encontradas, buscando categorizá-
las segundo o seu objetivo de medição.
As medidas categorizadas foram novamente comparadas no terceiro passo da pesquisa
com o objetivo de eliminar redundâncias. Neste momento, as medidas de mesmas
características tiveram sua nomenclatura e interpretação unificadas, reduzindo a variabilidade
do universo de medidas a ser considerado para o catálogo.
Com o objetivo de validar se as medidas selecionadas fornecem instrumentos para
gestão quantitativa de projetos de software, o modelo CMMI-DEV foi utilizado como
referência na identificação dos processos tipicamente executados em projetos desta natureza.
Sendo assim, o quarto passo da pesquisa foi realizar o mapeamento entre as medidas
consolidadas e as áreas de processos (APs) do modelo CMMI-DEV. Ao final deste passo, as
medidas foram novamente filtradas, selecionando apenas as relacionadas às áreas de
processos do grupo de Engenharia do modelo CMMI-DEV.
Por fim, sendo o foco da pesquisa estabelecer um catálogo sucinto e prático, contendo
apenas as medidas essenciais para a gestão quantitativa dos projetos, o quinto passo foi
selecionar para composição do catálogo apenas as medidas mais referenciadas entre os
autores.
Durante a realização dos passos 3, 4 e 5 da pesquisa, onde as medidas foram
individualmente analisadas, houve necessidade de revisar a lista de medidas, eventualmente
alterando as classificações realizadas nos passos anteriores.
A etapa de consolidação do catálogo envolveu desde a seleção do modelo para
documentação até a identificação dos indicadores relacionando-os com as medidas
selecionadas e sua melhor forma de análise.
O sexto passo da pesquisa teve como objetivo selecionar um modelo de especificação
de indicador e adaptá-lo de acordo com as características do catálogo.
 40

A partir da definição do conjunto de medidas, o sétimo passo envolveu a definição do

conjunto de indicadores a serem especificados, bem como a associação do conjunto de
medidas básicas e derivadas para cada indicador.
O oitavo passo da pesquisa envolveu a seleção de técnicas de controle estatístico de
processos para permitir a gestão quantitativa de projetos a partir dos indicadores selecionados.
O nono e último passo tratou de especificar a descrição e procedimentos de medição
de cada indicador e consolidá-los em um catálogo indexado a partir das áreas de processos do
modelo CMMI-DEV.
Nas seções seguintes serão apresentadas detalhadamente como as medidas foram
selecionadas (seção 3.2) e por fim os quatro últimos passos relacionados à consolidação do
catálogo (seção 3.3).

3.2. Seleção das medidas de desempenho de software

3.2.1. Revisão da literatura e identificação das medidas

O trabalho de seleção de medidas de desempenho de processos de software para

composição do catálogo iniciou-se com uma ampla revisão da literatura, com o objetivo de
identificar as medidas de desempenho referenciadas pelos autores e mais utilizadas pela
indústria de tecnologia da informação.
A revisão da literatura envolveu a leitura de trabalhos publicados que tratam do tema
de medição para processos de software. Dos trabalhos avaliados, 32 foram considerados
relevantes e, portanto serviram de referência para este trabalho, pois citam as os diferentes
conjuntos de medidas de desempenho em prática nas organizações pesquisadas.
Durante o processo de leitura e identificação das medidas, procurou-se coletar todas as
medidas citadas pelos autores, sem realizar juízo de valor em relação à sua efetividade de
medição ou redundância em relação às medidas referenciadas por outros autores. Sendo
assim, entre as medidas coletadas, existem medidas com o mesmo objetivo citadas em
diferentes trabalhos. Para ilustrar um exemplo, as medidas listadas na Quadro 9 possuem
como objetivo comum a medição do retrabalho executado pelo projeto, apesar da diferença de
nomenclatura adotada pelos autores referenciados.
 41

Quadro 9: Medidas redundantes em diferentes trabalhos pesquisados

Medida Referências
Percentual de retrabalho Galin e Avrahami (2005), Galin e Avrahami (2006), Galin e Avrahami
(2007)
Percentual de tempo de SEI (2006b)
retrabalho
Retrabalho Agrawal e Chari (2007), Chikofsty e Rubin (1999), McGarry et al (2002) e
Stutzke (2005)
Taxa de retrabalho Debou, Kuntzmann-Combelles e Rowe (1994)

Ao final da revisão da literatura, 869 medidas de desempenho de processos de

software foram identificadas a partir dos 32 trabalhos referenciados. O conjunto de medidas
foi então catalogado, sendo registradas as informações de “Nome original” e “Referências”,
conforme apresentado no quadro de medidas do APÊNDICE A.

3.2.2. Categorização das medidas

O processo de análise da lista de medidas identificadas envolveu a categorização

destas medidas de acordo com o seu objetivo de medição. Para tal, primeiramente foi
necessário identificar o grupo de categorias de medição que seriam utilizadas nesta pesquisa.
A seleção das categorias foi realizada a partir das pesquisas de Mcgarry (2002) e
Putman e Myers (2003), onde são apresentados diferentes grupos de categorias de medição. O
Quadro 10 apresenta o conjunto de seis categorias utilizadas na classificação das medidas
desta pesquisa.

Quadro 10: Categorias de medição

Categoria Objetivo de medição

Custo Medidas relacionadas à avaliação do recurso financeiro despendido nas atividades do
processo de desenvolvimento de software.
Escopo Medidas relacionadas à avaliação do tamanho ou volume do produto a ser realizado a
partir das atividades do processo de desenvolvimento de software. Esta categoria
contempla também medidas relacionadas à avaliação de mudanças no escopo do trabalho
a ser realizado pelo projeto.

O escopo é normalmente medido a partir de medidas de quantidade de linhas de código,

quantidade de pontos de função ou quantidade de requisitos atendidos pelo software.
Esforço Medidas relacionadas à avaliação da quantidade de trabalho envolvido na realização das
atividades do processo de desenvolvimento de software. O esforço é normalmente medido
a partir da quantidade de horas, e está diretamente relacionado ao escopo do produto de
software a ser desenvolvido e a produtividade de equipe desenvolvimento.
Produtividade Medidas relacionadas à avaliação da capacidade de produção da equipe do projeto.
Qualidade Medidas relacionadas à avaliação da capacidade do processo e produto de software em
atender as necessidades dos envolvidos, a partir de critérios de aceitação pré-
estabelecidos.
Tempo Medidas relacionadas à avaliação do período de tempo (prazo) envolvido na realização
das atividades do processo de desenvolvimento de software.
 42

Depois de identificado o grupo de categorias de medição, cada uma das 869 medidas
foi categorizada de acordo com seu objetivo de medição em uma das seis categorias. A Tabela
1 abaixo apresenta um resumo quantitativo da distribuição das medidas em relação às
categorias de medição.

Tabela 1: Distribuição de medidas por categoria

Categoria Quantidade de medidas

Qualidade 314
Escopo 252
Tempo 109
Esforço 87
Custo 82
Produtividade 22
Não categorizadas 3

Nota-se que a maior quantidade de medidas identificadas propõe-se a medir aspectos

relacionados à qualidade de produto e processo. Além disto, três medidas da lista não foram
classificadas pelo fato de tratarem de aspectos do processo de desenvolvimento de software
não relacionados ao objetivo de medição de nenhuma das seis categorias, são elas:
“Distribuição de probabilidade para uma quantidade estimada ou estatística relacionada a uma
população” (STUTZKE, 2005), “Impacto tecnológico” e “Resultados de pesquisa”
(MCGARRY et al, 2002).
O Quadro 11 apresenta exemplos de categorização de medidas. O levantamento
completo por ser visualizado no APÊNDICE A, onde neste passo da pesquisa foi preenchida a
coluna de “Categoria” do quadro de medidas.

Quadro 11: Exemplos de categorização de medidas

Categoria Medida Referências

Qualidade Número de defeitos produzidos por fase Xu (2006)
Qualidade Cobertura de testes Grady (1994), Paul et al (1999) e SEI
(2006b)
Escopo Número de requisitos Florac e Carleton (1999), Lindström
(2004) e SEI (2006b)
Escopo Quantidade de mudanças aceitas, mas não implementadas Kulpa e Johnson (2008)
Escopo Reuso de código Kulik e Weber (2002) e
Lindström (2004)
Escopo Número de itens de riscos técnicos SEI (2006b)

3.2.3. Consolidação de medidas redundantes

A partir da categorização das medidas, o passo seguinte foi avaliar individualmente as

informações de nome, descrição e fórmula de cálculo das medidas de mesma categoria, com o
 43

objetivo de identificar semelhanças entre elas e conseqüentemente consolidar medidas

redundantes.
Neste passo, medidas de diferentes nomes, referenciadas por diferentes autores, porém
que possuem mesma fórmula ou descrição foram consolidadas, através da atribuição de
nomenclatura comum. Vale ressaltar que nem todos os trabalhos analisados identificam a
fórmula e descrição das medidas citadas. Nos casos onde não foi possível comparar estas
características, a consolidação foi realizada unicamente a partir das semelhanças na
nomenclatura das medidas analisadas.
O Quadro 12 apresenta dois exemplos da análise realizada para eliminação de
redundâncias a partir do nome e descrição das medidas. No caso da medida de ‘Quantidade de
defeitos’, para consolidar as 8 medidas diferentes citadas pelos autores, foram analisados
primeiramente os nomes das medidas onde se podem perceber semelhanças entre as medidas,
como nos exemplos: ‘Número de defeitos’, ‘Número de defeitos produzidos por fase’ e
‘Número inicial de defeitos’. Posteriormente, as descrições das medidas foram analisadas e
comparadas, como no caso da medida ‘Dados de defeitos’, onde através da descrição foi
possível identificar que se tratava de um quantitativo de defeitos encontrados.

Quadro 12: Exemplos de eliminação de redundância pelo nome e descrição das medidas

Categoria Nome Nome original Descrição Referências

consolidado
Qualidade Quantidade de Dados de defeitos Relatórios de problemas, defeitos Kulpa e
defeitos relatados pelo cliente, defeitos Johnson
relatados pelo usuário, defeitos (2008)
encontrados nas análises, Defeitos
encontrados nos testes, problemas de
capacidade de processo, o tempo e os
custos para identificar o defeito e fixá-
lo, custo estimado da não fixação do
problema
Defeitos Florac e
Carleton
(1999),
McGarry et al
(2002), SEI
(2006a), SEI
(2006b)
Erros Por categoria, a fase onde foram Kulpa e
descobertos, a fase onde foram Johnson
injetados, por tipo e gravidade (2008)
Número de defeitos Número total de defeitos que Agrawal e
escaparam para o cliente e foram Chari (2007)
encontrados durante os primeiros três
meses de uso do software em
produção.
 44

Quadro 12 (cont.): Exemplos de eliminação de redundância pelo nome e descrição das medidas

Categoria Nome Nome original Descrição Referências

consolidado
Qualidade Quantidade de Número de defeitos Xu (2006)
defeitos produzidos por fase
Número de defeitos Lindström
registrados no (2004)
Service Desk
durante o projeto
Número inicial de Número inicial de defeitos presente no Eickelmann e
defeitos código Anant (2003)
Total de defeitos Humphrey
injetados (2000)
Escopo Quantidade de Declaração de Número de linhas de código, IEEE (1992)
linhas de código físico (PSS - independente da quantidade de
código Physical source instruções em cada linha.
statement)
Linha de código Florac e
Carleton
(1999)
Linhas de código McGarry et al
(2002)
Linhas de código Hall e Fenton
(1997)
Linhas de código Kulik e Weber
(2002)
Linhas de código Lindström
(2004)
Linhas de código Xu (2006)
Linhas de código Número atual de linhas de código na Agrawal e
fonte aplicação. Chari (2007)
Linhas de código- Kulpa e
fonte armazenadas Johnson
em bibliotecas e (2008)
colocadas sob
controle da
configuração
Linhas de código- SEI (2006b)
fonte
Milhares de linhas Grady (1994)
de código não
comentadas
(KNCSS)
Quantidade de Buglione e
código total Abran (2005)
Total de linhas de Resemberg e
código Sheppard
(1994)

A análise sobre as medidas de ‘Quantidade de linhas de código’ foi realizada a partir

do nome das medidas, onde é nítida a semelhança, apesar das diferenças no método de
contagem, a exemplo da medida de ‘Milhares de linhas de código não comentadas’. Nesta
avaliação, foi possível identificar que a medida de ‘Declaração de código físico’ é relacionada
 45

à quantidade de linhas de código apenas a partir da sua descrição, já que o seu nome não deixa
claro o objetivo de medição.
Após análise das medidas a partir do nome e descrição, foi realizada a avaliação das
fórmulas das medidas, com o objetivo de identificar semelhanças de cálculo, mesmo em
medidas cujos nomes ou descrição não indicavam a redundância. O Quadro 13 apresenta
exemplos de medidas consolidadas a partir da análise de suas fórmulas.

Quadro 13: Exemplos de eliminação de redundâncias pela fórmula das medidas

Nome
Categoria Nome original Fórmula de cálculo Referências
consolidado
Escopo Produtividade Produtividade global e Kulpa e Johnson
tendências de qualidade (2008)
para cada projeto
Produtividade dos Kulik e Weber (2002)
programadores
Produtividade Becker et al (2006),
McGarry et al (2002),
SEI (2006a), SEI
(2006b) e
Stutzke (2005)
Produtividade Esforço / tamanho Kitchenham et al
(2006)
Produtividade Esforço / unidade de McGarry, Burke e
software Decker (1998)
Escopo Taxa de entrega Parâmetro de LOC / Pessoas Lindström (2004)
produtividade do processo
Produtividade LOC/hora Florac e Carleton
(1999)
Produtividade Novas linhas de Galin e Avrahami
código / dia (2007)
Produtividade Tamanho / IEEE (1992)
Quantidade de horas
Produtividade LOC / pessoa/dia Xu (2006)
(tamanho/esforço)
Produtividade do Milhares de linhas de Galin e Avrahami
desenvolvimento de código por (2005), Galin e
software homem/mês Avrahami (2006)
Qualidade Densidade de Densidade de defeitos Agrawal e Chari (2007)
defeitos Densidade de defeitos Número de defeitos / Buglione e Abran
componente de (2005)
software
Densidade de defeitos Defeitos / KLOC Lindström (2004)
Densidade de defeitos Defeitos / Tamanho Xu (2006)
Densidade de defeitos de Defeitos de Florac e Carleton
compilação compilação / KLOC (1999)
Densidade de defeitos de Defeitos / KLOC Humphrey (2000)
complicação
Densidade de defeitos de Defeitos / KLOC Humphrey (2000)
teste de integração
Densidade de defeitos de Defeitos / KLOC Humphrey (2000)
teste de sistema
Densidade de defeitos de Defeitos / KLOC Humphrey (2000)
teste unitário
 46

Quadro 13 (cont.): Exemplos de eliminação de redundâncias pela fórmula das medidas

Nome
Categoria Nome original Fórmula de cálculo Referências
consolidado
Qualidade Densidade de Densidade de defeitos de Defeitos de testes / Florac e Carleton
defeitos testes KLOC (1999)
Densidade de defeitos Becker et al (2006)
internos
Densidade de defeitos total Total de defeitos / Florac e Carleton
KLOC (1999)
Densidade de erros Numero de erros / Galin e Avrahami
KLOC (2005), Galin e
Avrahami (2006),
Galin e Avrahami
(2007)
Densidade de falhas Kulik e Weber (2002)
Número de defeitos a cada Kulpa e Johnson
lançamento e / ou build de (2008)
produto

No caso das medidas de ‘Produtividade’ e ‘Taxa de entrega’, percebe-se na literatura

divergências de definição, já que muitos autores denominam as duas medidas unicamente
como ‘Produtividade’. Nestes casos, os autores classificam da mesma forma tanto medidas
cuja fórmula de cálculo seja a relação entre o esforço e escopo do produto de software (ex.:
esforço / tamanho) (KITCHENHAM et al, 2006) (MCGARRY; BURKE; DECKER, 1998),
quanto aquelas cuja fórmula de cálculo envolva a relação entre o escopo produzido por
período de tempo (ex.: KLOC / mês) (LINDSTRÖM, 2004) (FLORAC; CARLETON, 1999)
(GALIN; AVRAHAMI, 2007) (IEEE, 1992) (XU, 2006) (GALIN; AVRAHAMI, 2005)
(GALIN; AVRAHAMI, 2006).
A medida de ‘Produtividade’ pode ser definida como a divisão da quantidade de
trabalho gasto no desenvolvimento do software (esforço) pelo seu respectivo tamanho
(FENTON; PLFEEGER, 1997) (GARMUS; HERRON, 2000) (MAXWELL, 2001)
(PUTNAM; MAYERS, 2003). Já para Garmus e Herron (2000), a medida de ‘Taxa de
entrega’ é a capacidade média de entrega de pontos de função por pessoa/mês, sendo que esta
pode ser convertida para produtividade (em horas por pontos de função).
Segundo Maxwell (2001), a produtividade não deve ser confundida com a taxa de
entrega, pois quanto maior for o valor da medida menor é a produtividade e, no caso da
medida de taxa de entrega este raciocínio é invertido.
Sendo assim, apesar de os autores utilizarem nomenclaturas semelhantes para todas
estas medidas, a diferença na fórmula de cálculo resultou em duas medidas distintas: a medida
de ‘Produtividade’ para as que apresentam fórmula de cálculo relacionando esforço e escopo e
 47

a medida de ‘Taxa de entrega’ para as que apresentam na fórmula de cálculo a relação entre o
escopo e tempo.
No outro exemplo do Quadro 13, a medida de ‘Densidade de defeitos’ foi novamente
consolidada a partir da fórmula das medidas relacionadas. Neste caso, apesar de pequenas
diferenças na nomenclatura das medidas, o cálculo de todas as medidas á apresentado pela
relação entre a quantidade de defeitos e o escopo do produto de software, representado pelo
seu tamanho em quantidade de linhas de código (KLOC), tamanho ou quantidade de
componentes.
Seguindo o mesmo procedimento apresentado nos exemplos acima, as 869 medidas
coletadas dos trabalhos referenciados nesta pesquisa foram analisadas a partir de suas
características e foram consolidadas com o objetivo de identificar o conjunto de medidas
realmente diferentes citadas na literatura para cada categoria de medição.
Após a eliminação das medidas redundantes, restou um conjunto de 584 medidas de
características diferentes como pode ser verificado no APÊNDICE A, onde neste passo da
pesquisa foi preenchida a coluna de “Nome consolidado”.

3.2.4. Mapeamento das medidas em relação ao CMMI-DEV

O conjunto completo de medidas consolidadas foi então mapeado para as áreas de

processo do modelo CMMI-DEV a partir da aplicabilidade de cada medida em realizar gestão
quantitativa das diferentes áreas de processo do modelo. Esta avaliação foi realizada baseado
na prática genérica 2.8 (GP 2.8) e na meta genérica 4 (GG 4) do CMMI-DEV.
Segundo o SEI (2006a), a GP 2.8 envolve o monitoramento e controle do processo em
relação ao planejamento e a tomada de ações corretivas. Já a GG 4 do modelo descreve o
processo como sendo quantitativamente gerenciado, sendo atendida através da definição de
objetivos quantitativos para o processo e da capacidade de estabilizar o desempenho de um ou
mais subprocessos a fim de determinar a capacidade de o processo atingir os seus objetivos de
desempenho.
A Tabela 2 apresenta o mapeamento quantitativo das medidas em relação às áreas de
processos do CMMI-DEV. Conforme pode ser visto na tabela, uma mesma medida de
desempenho pode ser aplicável a mais de uma área de processo ou até mesmo a todas as áreas
de processos do modelo.
 48

Tabela 2: Distribuição de medidas por área de processo

Área de Processo (AP) Quantidade de medidas

Engenharia Integração de produto 47
Desenvolvimento de requisitos 44
Gerenciamento de requisitos 28
Solução técnica 90
Validação 145
Verificação 144
Gerenciamento de processos Inovação organizacional e implantação 38
Desempenho do processo organizacional 10
Definição do processo organizacional + IPPD 40
Foco do processo organizacional 11
Treinamento organizacional 24
Gerenciamento de projetos Monitoramento e controle do projeto 30
Planejamento do projeto 87
Gerenciamento integrado do projeto + IPPD 47
Gerenciamento quantitativo do projeto 11
Gerenciamento de riscos 30
Gerenciamento de acordos com fornecedores 21
Suporte Análise de causas e resoluções 10
Análise de decisões e resoluções 6
Garantia da qualidade do processo e produto 18
Medição e análise 5
Gerenciamento de configuração 27
Medidas aplicáveis a todas as APs 114

O mapeamento das áreas de processos do CMMI-DEV a cada medida de desempenho

foi inicialmente realizado a partir de trabalhos onde os autores já apresentam esta relação.
Sendo assim, a soma de 377 medidas citadas por Kulpa e Johnson (2008) e SEI (2006a) foram
diretamente mapeadas às áreas de processos do modelo CMMI-DEV, a partir da indicação
dos atores. Exemplos de medidas mapeadas segundo esse critério são apresentados na Quadro
14.

Quadro 14: Exemplos de medidas cuja relação com as APs do CMMI-DEV é apresentada na literatura

Categoria Nome Referências APs do CMMI-DEV aplicáveis citadas nas

consolidado referências
Qualidade Cobertura de SEI (2006b) Verificação (VER) e Validação (VAL)
testes
Qualidade Cobertura de Kulpa e Johnson Verificação (VER) e Validação (VAL)
testes (2008)
Qualidade Eficácia de SEI (2006b) Verificação (VER) e Validação (VAL)
revisão
Qualidade Eficácia de Kulpa e Johnson Verificação (VER) e Validação (VAL)
revisão (2008)
 49

Quadro 14 (cont.): Exemplos de medidas cuja relação com as APs do CMMI-DEV é apresentada na
literatura

Categoria Nome consolidado Referências APs do CMMI-DEV aplicáveis citadas nas

referências
Qualidade Desempenho dos Kulpa e Desempenho do processo organizacional (OPP),
processos Johnson (2008) Inovação organizacional e implantação (OID) e
Definição do processo organizacional (OPD)
Escopo Nível de risco SEI (2006b) Gerenciamento de riscos (RSKM)
Escopo Pontos de função SEI (2006b) Todas
Escopo Taxa de diagramas Kulpa e Solução técnica (TS)
concluídos Johnson (2008)
Escopo Taxa de objetivos de SEI (2006b) Medição e análise (MA)
medição endereçados
Tempo Taxa de marcos no Kulpa e Todas
prazo Johnson (2008)
Custo Custo despendido nas Kulpa e Gerenciamento de configuração (CM)
atividades de CM Johnson (2008)

Para o conjunto restante de medidas, não foi possível identificar diretamente nos
trabalhos referenciados o mapeamento com as áreas de processos do modelo CMMI-DEV.
Para estas medidas, conforme exemplificado no Quadro 15, foi feita uma análise das
características e objetivo de medição, procurando identificar quais áreas de processos do
modelo poderiam ser gerenciadas quantitativamente a partir de cada medida.
O objetivo desta pesquisa é criar um catálogo de medidas que permita a gestão
quantitativa de projetos de desenvolvimento de software. Com este foco, o conjunto de 584
medidas, devidamente categorizadas e mapeadas para as APs do CMMI-DEV, foi novamente
filtrado, selecionado somente as medidas mapeadas para áreas de processos do grupo de
Engenharia do modelo. Esta seleção foi realizada, pois as seis áreas de processos de
engenharia (Integração de produto - PI, Desenvolvimento de requisitos - RD, Gerenciamento
de requisitos - REQM, Solução técnica - TS, Validação - VAL e Verificação - VER)
correspondem aos processos básicos da produção de software e consistem na maior parte do
esforço envolvido em projetos de desenvolvimento de software. Após a seleção, 345 medidas
mapeadas para as APs de engenharia do modelo CMMI-DEV permaneceram no escopo desta
pesquisa.
 50

Quadro 15: Exemplos de medidas cuja relação com as APs do CMMI-DEV foi identificada a partir de
suas características

Categoria Nome Referências APs do CMMI-DEV Avaliação

consolidado aplicáveis
Custo Índice de McGarry et al Todas À medida que pertence ao grupo de
desempenho (2002), Kulik e medidas de análise de valor agregado
de custos Weber (2002), é aplicável a todas as áreas de
PMI (2004), SEI processos do CMMI-DEV, pois
(2006a), SEI permite avaliar o desempenho de
(2006b), Wang e qualquer atividade de processo a
Li (2005) partir do seu custo real e valor
agregado.
Escopo Volatilidade Agrawal e Chari Gerenciamento de A medida de volatilidade de
de requisitos (2007), Becker Requisitos (REQM), requisitos tem por objetivo
et al (2006), Desenvolvimento de identificar a razão do total de
Kulpa e Johnson Requisitos (RD), requisitos que sofre mudanças
(2008), Gerenciamento de durante o projeto. Esta informação é
Lindström Configuração (CM) importante para avaliação do
(2004), SEI desempenho dos processos de
(2006b) elicitação e especificação de
requisitos (RD); dos processos de
entendimento e comprometimento
dos requisitos junto aos usuários, e
também do gerenciamento das
mudanças nos requisitos (REQM);
do processo de gerenciamento de
mudanças do projeto como um todo
(CM).
Qualidade Densidade de Agrawal e Chari Solução Técnica (TS), A medida de densidade de defeitos
defeitos (2007), Becker Desenvolvimento de entregues tem por objetivo identificar
entregues et al (2006), SEI Requisitos (RD), a taxa de defeitos encontrada pelo
(2006b), Xu Integração de Produto cliente ou usuário, após a avaliação
(2006) (PI), Verificação interna e entrega do produto. Sendo
(VER) e Validação assim, esta medida, além de
(VAL) possibilitar a avaliação da qualidade
do produto gerado pelos processos
técnicos (TS, PI e RD), permite
também avaliar a eficácia dos
processos de verificação e validação
(VER e VAL) na descoberta de
defeitos antes da entrega do produto
ao usuário ou cliente.

3.2.5. Seleção das medidas mais referenciadas na literatura

Apesar da realização dos passos anteriores que resultaram em uma diminuição do

universo de medidas, o número de 345 medidas de desempenho permanece elevado para a
definição de um catálogo para gestão quantitativa de projetos de software. Lembrando que o
objetivo do catálogo de medidas é estabelecer um instrumento de referência prático e genérico
o bastante para ser utilizado por diferentes organizações, estabelecendo um framework
uniforme de medição.
 51

Preocupado em manter as características esperadas do catálogo, o quarto e último

passo da seleção de medidas envolveu a ordenação das medidas pré-selecionadas por
quantidade de citações na literatura especializada. A partir desta classificação, foram
selecionadas para a elaboração do catálogo, medidas referenciadas por três ou mais autores,
de forma a garantir que o catálogo seja composto por um conjunto reduzido e representativo
de medidas, comumente utilizadas por organizações de desenvolvimento de software.
A Tabela 3 apresenta a lista de 48 medidas de desempenho que foram citadas por mais
de três autores e são relacionadas com as áreas de processo de Engenharia do modelo CMMI-
DEV.
 52

Tabela 3: Lista de medidas referenciadas por três ou mais autores

Combelles e Rowe (1994)

McGarry, Burke e Decker

Herbsleb e Grinter (1998)
Chikofsty e Rubin (1999)

Galin e Avrahami (2005)

Buglione e Abran (2005)

Gopal, Mukhopadhyay e
Florac e Carleton (1999)

Kulpa e Johnson (2008)

Kitchenham t al (2006)
Agrawal e Chari (2007)

Resemberg e Sheppard
Quant. de referências

Kulik e Weber (2002)

McGarry et al (2002)

Hall e Fenton (1997)

SEI (2006a) (2006b)

Debou, Kuntzmann-

Eickelmann e Anant
Becker et al (2006)

Humphrey (2000)

Wang e Li (2005)
Lindström (2004)

Paul et al (1999)
Krishnan (2005)

Stutzke (2005)
Medida / Referências

(2006) (2007)

Grady (1994)

IEEE (1992)

PMI (2004)

Xu (2006)
(2003)

(1998)

(1994)
1. Esforço 14 X X X X X X X X X X X X X X
2. Quantidade de linhas de código 13 X X X X X X X X X X X X X
3. Densidade de defeitos 10 X X X X X X X X X X
4. Quantidade de pontos de função 10 X X X X X X X X X X
5. Quantidade de defeitos 09 X X X X X X X X X
6. Produtividade 08 X X X X X X X X
7. Tamanho 08 X X X X X X X X
8. Taxa de defeitos 07 X X X X X X X
9. Taxa de remoção de defeitos 07 X X X X X X X
10. Taxa de retrabalho 07 X X X X X X X
11. Variação de prazo 07 X X X X X X X
12. Prazo de ciclo 07 X X X X X X
13. Cobertura de testes 05 X X X X X
14. Complexidade 05 X X X X X
15. Complexidade ciclomática 05 X X X X X
16. Prazo 05 X X X X X
17. Custo real 05 X X X X X
18. Estimativa no término 05 X X X X X
19. Estimativa para terminar 05 X X X X X
20. Índice de desempenho de custos 05 X X X X X
21. Índice de desempenho de custos cumulativo 05 X X X X X
22. Índice de desempenho de prazo 05 X X X X X
23. Orçamento no término 05 X X X X X
 Tabela 3 (cont.): Lista de medidas referenciadas por três ou mais autores 53

Combelles e Rowe (1994)

McGarry, Burke e Decker

Herbsleb e Grinter (1998)
Chikofsty e Rubin (1999)

Galin e Avrahami (2005)

Buglione e Abran (2005)

Gopal, Mukhopadhyay e
Florac e Carleton (1999)

Kulpa e Johnson (2008)

Kitchenham t al (2006)
Agrawal e Chari (2007)

Resemberg e Sheppard
Quant. de referências

Kulik e Weber (2002)

McGarry et al (2002)

Hall e Fenton (1997)

SEI (2006a) (2006b)

Debou, Kuntzmann-

Eickelmann e Anant
Becker et al (2006)

Humphrey (2000)

Wang e Li (2005)
Lindström (2004)

Paul et al (1999)
Krishnan (2005)

Stutzke (2005)
Medida / Referências

(2006) (2007)

Grady (1994)

IEEE (1992)

PMI (2004)

Xu (2006)
(2003)

(1998)

(1994)
24. Quantidade de requisitos 05 X X X X X
25. Taxa de entrega 05 X X X X X
26. Valor agregado 05 X X X X X
27. Valor planejado 05 X X X X X
28. Variação de custo (EVA) 05 X X X X X
29. Variação de prazo (EVA) 05 X X X X X
30. Variação no término 05 X X X X X
31. Volatilidade de requisitos 04 X X X X X
32. Custo 04 X X X X
33. Custo da qualidade 04 X X X X
34. Densidade de defeitos entregues 04 X X X X
35. Esforço de retrabalho 04 X X X X
36. Estabilidade de requisitos 04 X X X X
37. Prazo médio para falha 04 X X X X
38. Variação de esforço 04 X X X X
39. Eficácia de detecção de defeitos 03 X X X
40. Eficácia de revisão 03 X X X
41. Eficácia de testes 03 X X X
42. Esforço de revisão 03 X X X
43. Quantidade de defeitos de revisão 03 X X X
44. Quantidade de mudanças 03 X X X
45. Quantidade de páginas de documento 03 X X X
46. Reuso de código 03 X X X
47. Taxa de mudanças 03 X X X
48. Variação de tamanho 03 X X X
 54

Neste passo foi necessário realizar novamente uma avaliação de medidas redundantes.
Porém, neste momento a análise não focou as características de nome, descrição e fórmula de
cálculo das medidas, como apresentado anteriormente no item 3.2.3. A avaliação procurou
identificar medidas diferentes, mas de mesmo objetivo, ou seja, mesma aplicação na gestão
quantitativa dos processos. Nestes casos, apesar das medidas de possuírem nomes, descrições
e fórmulas diferentes, essas provêm informações que permitem avaliar as mesmas áreas de
processos sobre a perspectiva das mesmas categorias de medição.
As 48 medidas foram analisadas individualmente e depois comparadas em conjunto, a
fim de identificar objetivos de medição semelhantes e então eliminar as redundantes. A
Tabela 4 abaixo apresenta os grupos de medidas analisados e a conclusão para permanência
no catálogo apenas das medidas mais referenciadas na literatura.

Tabela 4: Medidas eliminadas pela redundância de objetivo

Quantidade
APs do CMM-DEV
Categoria Medida de Redundância de objetivo
aplicáveis
referências
Tempo Variação de 7 Todas Ambas as medidas avaliam a relação
prazo entre o realizado e o planejado da
Variação de 5 perspectiva de tempo para todas as APs
prazo (EVA) do CMMI-DEV. Sendo assim, a medida
com maior quantidade de referências
(Variação de prazo) foi mantida no
conjunto de medidas do catálogo.
Qualidade Densidade de 11 Solução Técnica (TS), As três medidas relacionadas com a
defeitos Desenvolvimento de quantidade de defeitos por produto de
Taxa de 7 Requisitos (RD), software avaliam os processos técnicos e
defeitos Integração de Produto (PI), de verificação e validação sobre a
Densidade de 4 Verificação (VER) e perspectiva de qualidade. Sendo assim,
defeitos Validação (VAL) apenas a medida de maior quantidade de
entregues referências (Densidade de defeitos) foi
mantida no conjunto de medidas do
catálogo.
Quantidade 9 Todas A medida de ‘Quantidade de defeitos de
de defeitos revisão’ é uma especialização da medida
Quantidade 3 de ‘Quantidade de defeitos’. Sendo
de defeitos assim, apenas a medida de maior
de revisão quantidade de referências (Quantidade de
defeitos) foi mantida no conjunto de
medidas do catálogo.
 55

Tabela 5 (cont.): Medidas eliminadas pela redundância de objetivo

Quantidade
APs do CMM-DEV
Categoria Medida de Redundância de objetivo
aplicáveis
referências
Qualidade Eficácia de 3 Verificação (VER) e As três medidas têm por objetivo avaliar a
revisão Validação (VAL) eficácia da detecção de defeitos durante o
Eficácia de 3 desenvolvimento, antes da entrega dos
testes produtos. Neste caso, a quantidade de
Eficácia de 3 referências é igual para as três medidas.
detecção de Sendo assim, apesar das medidas ‘Eficácia
defeitos de revisão’ e ‘Eficácia de testes’ serem uma
especialização da medida ‘Eficácia de
detecção de defeitos’, decidiu-se manter as
duas medidas especializadas no catálogo,
pois estas permitem avaliar
independentemente o desempenho dos
processos de revisão técnica e testes.
Escopo Quantidade de 13 Solução Técnica (TS), A medida de tamanho é genérica, possuindo
linhas de Integração de Produto como especializações possíveis as outras três
código (PI), Verificação (VER) citadas. Neste caso, as especializações de
e Validação (VAL). ‘Quantidade de linhas de código’ e
Quantidade de 10 Todas ‘Quantidade de pontos de função’ são
pontos de amplamente referenciadas na literatura e,
função portanto foram selecionadas para
Tamanho 8 Todas composição do catálogo em detrimento da
Quantidade de 5 Todas medida de ‘Tamanho’.
requisitos A medida de ‘Quantidade de requisitos’ é
apresentada aqui, pois também é uma
especialização da medida excluída de
‘Tamanho’.

Volatilidade 5 Gerenciamento de Estas medidas de ‘Estabilidade de requisitos’

de requisitos Requisitos (REQM),
Estabilidade 4 Desenvolvimento de
de requisitos Requisitos (RD),
Gerenciamento de
Configuração (CM)
Complexidade 5 Solução Técnica (TS), As duas medidas possuem o mesmo objetivo
ciclomática Integração de Produto
Complexidade 5 (PI), Verificação (VER) complexidade do produto a ser construído.
e Validação (VAL).
e ‘Volatilidade de requisitos’ possuem como
fórmula o percentual de requisitos alterados
(Volatilidade de requisitos), ou não alterados
(Estabilidade de requisitos) em relação ao
total de requisitos do projeto. Apesar da
diferença na fórmula de cálculo, as duas
medidas permitem avaliar as mesmas áreas
de processo em relação às mudanças no
escopo do projeto. Sendo assim, apenas a
medida de maior quantidade de referências
(Volatilidade de requisitos) foi mantida no
conjunto de medidas do catálogo.
de medição, que é a avaliação da
Neste caso, como ambas as medidas
possuem a mesma quantidade de referências,
foi mantida no catálogo de medidas a medida
de ‘Complexidade ciclomática’ por esta
possuir uma definição bem estabelecida na
literatura, diferentemente do termo
‘Complexidade’, que é muito amplo e
portanto possui diferentes interpretações.
 56

Tabela 5 (cont.): Medidas eliminadas pela redundância de objetivo

Quantidade APs do
Categoria Medida de CMM-DEV Redundância de objetivo
referências aplicáveis
Custo Índice de 5 Todas As duas medidas têm o mesmo objetivo de medição.
desempenho de A única diferença entre as duas é que o ‘Índice de
custos desempenho de custos acumulativo’ apresenta a
Índice de 5 medição de forma acumulada para um conjunto de
desempenho de atividades ou projeto. Neste caso, optou-se por
custos manter apenas o ‘Índice de desempeno de custos’
cumulativo pois a sua fórmula também permite a avaliação
acumulativa da medição.
Custo real 5 Todas Ambas as medidas possuem o mesmo objetivo de
Custo 4 medição, que é identificar o custo realizado pelo
projeto. Sendo assim, a medida com maior
quantidade de referências (Custo real) foi mantida no
conjunto de medidas do catálogo.
Esforço Esforço 14 Todas A medida de ‘Esforço de revisão’ é uma
Esforço de 3 VER, VAL especialização da medida de ‘Esforço’. Esta última,
revisão e IPM por sua vez, é mais genérica e pode ser aplicada na
medição de diferentes processos. Sendo assim, a
medida mais genérica e com maior quantidade de
referências (Esforço) foi mantida no conjunto de
medidas do catálogo.

Ao final deste passo da pesquisa, restaram 37 medidas de desempenho de processos

para composição do catálogo. O Quadro 16 lista o conjunto final de medidas do catálogo,
apresentando a descrição e classificação quanto ao tipo de cada medida (básica ou derivada).

Quadro 16: Conjunto final de medidas do catálogo

Tipo Medida Descrição

Básica 1. Custo real Os custos totais realmente incorridos e registrados na realização do trabalho
(CR) executado durante um determinado período de tempo para uma atividade do
cronograma ou um componente da estrutura analítica do projeto. O custo real às
vezes pode representar somente as horas de mão-de-obra direta, somente os custos
diretos ou todos os custos, inclusive custos indiretos. Também chamado de custo
real do trabalho realizado (CRTR) (PMI, 2004).
2. Esforço Quantidade de horas despendidas pela equipe durante atividades específicas de
manutenção e desenvolvimento de um projeto (CHIKOFSTY; RUBIN, 1999).
3. Esforço de Quantidade de horas despendidas pela equipe para correção de defeitos nos
retrabalho produtos do projeto.
4. Orçamento no A soma de todos os valores de orçamento estabelecidos para o trabalho a ser
término (ONT) realizado em um projeto, componente da estrutura analítica do projeto ou
atividade do cronograma. O valor planejado total do projeto (PMI, 2004).
5. Prazo Período de tempo planejado ou decorrido para uma ou mais atividades, fases,
disciplinas ou para o projeto completo.
6. Prazo de ciclo Tempo total necessário desde o início até o final do projeto (MCGARRY;
BURKE; DECKER, 1998).
7. Prazo médio Quanto tempo o software é executado em média antes de uma falha
para falha (LINDSTRÖM, 2004).
 57

Quadro 16 (cont.): Conjunto final de medidas do catálogo

Tipo Medida Descrição

Básica 8. Quantidade de Quantidade de defeitos identificados nas atividades de verificação e
defeitos validação dos produtos do projeto.
9. Quantidade de Quantidade de linhas de código do software construído (SEI, 1992).
linhas de código
10. Quantidade de Quantidade de mudanças registradas nos itens de configuração da linha de
mudanças base do projeto (MCGARRY et al, 2002) (SEI, 2006b).
11. Quantidade de Número total de páginas não brancas contidas em um documento (IEEE,
páginas de 1992).
documento
12. Quantidade de Medida funcional de tamanho de software considerando apenas as
pontos de função funcionalidades solicitadas e recebidas pelos respectivos usuários,
independentemente da forma de implementação escolhida (IFPUG, 2004).
13. Quantidade de Contagem do número de requisitos do projeto (LINDSTRÖM, 2004).
requisitos
14. Valor agregado O valor do trabalho terminado expresso em termos do orçamento aprovado
(VA) atribuído a esse trabalho para uma atividade do cronograma ou componente
da estrutura analítica do projeto. Também chamado de custo orçado do
trabalho realizado (COTR). (PMI, 2004).
15. Valor planejado O orçamento autorizado atribuído ao trabalho agendado que será realizado
(VP) para a atividade do cronograma ou componente da estrutura analítica do
projeto. Também chamado de custo orçado do trabalho agendado (COTA)
(PMI, 2004).
Derivadas 16. Cobertura de Mede o percentual de um software que foi efetivamente testado, a partir da
testes quantidade de linhas de código, pontos de função, quantidade de requisitos
ou quantidade de casos de testes executados.
17. Complexidade Mede o número de grafos linearmente independentes em um módulo de
ciclomática código. Utilizado para análise de riscos durante o desenvolvimento
(LINDSTRÖM, 2004) (MCCABE, 1976).
18. Custo da Determinação dos custos incorridos para garantir a qualidade. Os custos de
qualidade prevenção e de avaliação (custo da conformidade) incluem custos de
planejamento da qualidade, controle da qualidade (CQ) e garantia da
qualidade para assegurar a conformidade com os requisitos (ou seja,
treinamento, sistemas de CQ, etc.). Os custos de falhas (custo da não-
conformidade) incluem custos para retrabalhar produtos, componentes ou
processos que não estão em conformidade, custos de trabalho referente à
garantia, de desperdício e de perda de reputação (PMI, 2004).
19. Densidade de Quantidade de defeitos encontrados em relação ao tamanho do software
defeitos (LINDSTRÖM, 2004) (GALIN; AVRAHAMI, 2005) (GALIN;
AVRAHAMI, 2006) (GALIN; AVRAHAMI, 2007).
20. Eficácia de Número total de defeitos encontrados nas revisões internas versus aqueles
revisão encontrados pelo cliente ou usuário final após a entrega (KULPA;
JOHNSON, 2008)
21. Eficácia de testes Número total de defeitos encontrados nos testes internos versus aqueles
encontrados pelo cliente ou usuário final após a entrega (KULPA;
JOHNSON, 2008)
22. Estimativa no O custo total previsto de uma atividade do cronograma, de um componente
término (ENT) da estrutura analítica do projeto ou do projeto, quando o escopo definido do
trabalho for terminado. ENT é igual ao custo real (CR) mais a estimativa
para terminar (EPT) de todo o trabalho restante. ENT = CR mais EPT. A
ENT pode ser calculada com base no desempenho até a data em questão ou
estimada pela equipe do projeto com base em outros fatores, caso em que é
freqüentemente chamada de última estimativa revisada (PMI, 2004).
23. Estimativa para O custo previsto necessário para terminar todo o trabalho restante de uma
terminar (EPT) atividade do cronograma, um componente da estrutura analítica do projeto
ou o projeto (PMI, 2004).
 58

Quadro 16 (cont.): Conjunto final de medidas do catálogo

Tipo Medida Descrição

Derivadas 24. Índice de Uma medida da eficiência de custos em um projeto. É a relação entre o
desempenho de valor agregado (VA) e os custos reais (CR). IDC = VA dividido por CR.
custos (IDC) Um valor maior ou igual a um indica uma condição favorável e um valor
menor que um indica uma condição desfavorável (PMI, 2004).
25. Índice de Uma medida da eficiência do cronograma em um projeto. É a relação
desempenho de entre o valor agregado (VA) e o valor planejado (VP). O IDP é calculado
prazo (IDP) dividindo-se o VA pelo VP. Um IDP maior ou igual a um indica uma
condição favorável e um valor menor que um indica uma condição
desfavorável (PMI, 2004).
26. Produtividade Produtividade para realização das atividades do projeto. Medida a partir da
relação entre esforço e tamanho do software (KITCHENHAM et al, 2006)
(MCGARRY; BURKE; DECKER, 1998).
27. Reuso de código Percentual de reuso de código no software construído. Calculado a partir
da quantidade de linhas de código reutilizadas em relação ao total de
linhas de código do software (POULIN; CARUSO, apud MASCENA; DE
ALMEIDA; DE LEMOS MEIRA, 2005).
28. Taxa de entrega Capacidade de entrega do projeto, medida a partir do tamanho do software
entregue por unidade de tempo (hora, dia ou mês) (FLORAC;
CARLETON, 1999) (GALIN; AVRAHAMI, 2007) (IEEE, 1992) (XU,
2006) (GALIN; AVRAHAMI, 2005) (GALIN; AVRAHAMI, 2006).
29. Taxa de mudanças Número de mudanças em relação ao tamanho do projeto de software
(quantidade de requisitos, quantidade de linhas de código ou quantidade
de pontos de função) (KULPA; JOHNSON, 2008) (RESEMBERG;
SHEPPARD, 1994).
30. Taxa de remoção Quantidade de defeitos resolvidos e fechados em relação ao total de
de defeitos defeitos do projeto.
31. Taxa de retrabalho Percentual de esforço de retrabalho executado no projeto em relação à
quantidade total de esforço do projeto (STUTZKE, 2005).
32. Variação de custo É igual ao valor agregado (VA) menos o custo real (CR). A variação de
(VC) custos no final do projeto será a diferença entre o orçamento no término
(ONT) e a quantia real gasta (PMI, 2004).
33. Variação de Variação do esforço atual em relação ao esforço planejado para o projeto
esforço (XU, 2006).
34. Variação de prazo Variação da duração atual em relação à duração planejada para o projeto
(XU, 2006).
35. Variação de Variação do tamanho atual do software em relação ao tamanho planejado
tamanho para o projeto (XU, 2006).
36. Variação no Diferença entre o valor orçado para o projeto e a estimativa no término,
término (VNT) baseada no desempenho real.
37. Volatilidade de Percentual de mudanças nos requisitos do projeto durante o seu
requisitos desenvolvimento (AGRAWAL; CHARI, 2007) (KULPA; JOHNSON,
2008).

A distribuição completa das medidas do catálogo em relação às categorias e áreas de

processos é apresentada na Quadro 17. A partir deste quadro é possível identificar que o
conjunto de 37 medidas de desempenho selecionadas para o catálogo provê instrumentos de
gestão quantitativa das áreas de processo do grupo de engenharia do modelo CMMI-DEV,
permitindo a avaliação dos processos em diferentes perspectivas, representadas pelas
categorias de medição.
 59

Quadro 17: Distribuição das medidas do catálogo por categoria e área de processo

Categoria / Área Desenvolvimento de Gerenciamento de Integração de

Solução técnica (TS) Verificação (VER) Validação (VAL)
de Processo requisitos (RD) requisitos (REQM) produto (PI)
Tempo • Prazo • Prazo • Prazo • Prazo • Prazo • Prazo
• Índice de • Índice de • Índice de • Índice de • Índice de • Índice de
desempenho de desempenho de desempenho de desempenho de desempenho de desempenho de
prazo prazo prazo prazo prazo prazo
• Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo
• Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo
Qualidade • Quantidade de • Quantidade de • Quantidade de • Quantidade de • Quantidade de • Quantidade de
defeitos defeitos defeitos defeitos defeitos defeitos
• Densidade de • Densidade de • Densidade de • Densidade de • Taxa de remoção de • Taxa de remoção de
defeitos defeitos defeitos defeitos defeitos defeitos
• Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho
• Esforço de • Esforço de • Esforço de • Prazo médio para • Cobertura de testes • Cobertura de testes
retrabalho retrabalho retrabalho falha • Prazo médio para • Prazo médio para
• Prazo médio para • Prazo médio para • Prazo médio para • Esforço de falha falha
falha falha falha retrabalho • Eficácia de testes • Eficácia de testes
• Eficácia de revisão • Eficácia de revisão
• Esforço de • Esforço de
retrabalho retrabalho
Produtividade • Produtividade • Produtividade • Produtividade • Produtividade • Produtividade • Produtividade
• Taxa de entrega • Taxa de entrega • Taxa de entrega • Taxa de entrega • Taxa de entrega • Taxa de entrega
 Quadro 17 (cont.): Distribuição das medidas do catálogo por categoria e área de processo 60
Categoria / Área Desenvolvimento de Gerenciamento de Integração de
Solução técnica (TS) Verificação (VER) Validação (VAL)
de Processo requisitos (RD) requisitos (REQM) produto (PI)
Escopo • Quantidade de • Quantidade de • Quantidade de linhas • Quantidade de linhas • Quantidade de linhas • Quantidade de linhas
pontos de função pontos de função de código de código de código de código
• Valor agregado • Valor agregado • Quantidade de • Quantidade de • Quantidade de • Quantidade de
• Volatilidade de • Volatilidade de pontos de função pontos de função pontos de função pontos de função
requisitos requisitos • Complexidade • Valor agregado • Complexidade • Complexidade
• Variação de • Variação de ciclomática • Variação de ciclomática ciclomática
tamanho tamanho • Valor agregado tamanho • Valor agregado • Valor agregado
• Quantidade de • Quantidade de • Reuso de código • Quantidade de • Variação de • Variação de
requisitos requisitos • Variação de mudanças tamanho tamanho
• Quantidade de • Quantidade de tamanho • Taxa de mudanças • Quantidade de • Quantidade de
mudanças mudanças • Quantidade de páginas de páginas de
• Taxa de mudanças • Taxa de mudanças requisitos documento documento
• Quantidade de • Quantidade de • Quantidade de
mudanças requisitos requisitos
• Taxa de mudanças • Quantidade de • Quantidade de
mudanças mudanças
• Taxa de mudanças • Taxa de mudanças

Esforço • Esforço • Esforço • Esforço • Esforço • Esforço • Esforço

• Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço
Custo • Orçamento no • Orçamento no • Orçamento no • Orçamento no • Orçamento no • Orçamento no
término término término término término término
• Custo real • Custo real • Custo real • Custo real • Custo real • Custo real
• Valor planejado • Valor planejado • Valor planejado • Valor planejado • Valor planejado • Valor planejado
• Estimativa para • Estimativa para • Estimativa para • Estimativa para • Estimativa para • Estimativa para
terminar terminar terminar terminar terminar terminar
• Estimativa no • Estimativa no • Estimativa no • Estimativa no • Estimativa no • Estimativa no
término término término término término término
• Índice de • Índice de • Índice de • Índice de • Índice de • Índice de
desempenho de desempenho de desempenho de desempenho de desempenho de desempenho de
custos custos custos custos custos custos
• Variação de custo • Variação de custo • Variação de custo • Variação de custo • Variação de custo • Variação de custo
(EVA) (EVA) (EVA) (EVA) (EVA) (EVA)
• Variação no término • Variação no término • Variação no término • Variação no término • Variação no término • Variação no término
• Custo da Qualidade • Custo da Qualidade
 61

A fim de permitir a avaliação do desempenho das diferentes áreas de processos do

modelo CMMI-DEV, as medidas do catálogo devem ser analisadas em função do processo
que se deseja gerenciar quantitativamente. Neste sentido, o método de medição e o modelo de
análise de cada medida devem ser adaptados em relação às características do processo,
envolvendo a análise de dados coletados dos produtos e outros resultados específicos do
processo. O Quadro 18 apresenta exemplos de interpretações para uma mesma medida para
diferentes áreas de processo.

Quadro 18: Exemplos de diferentes interpretações das medidas para cada área de processo

Medidas Áreas de processos Interpretações

Variação de Desenvolvimento de Para avaliar a variação de prazo de desenvolvimento de requisitos, devem
prazo requisitos (RD) ser coletadas as informações de prazo planejado e prazo real de atividades
específicas do cronograma do projeto, como por exemplo: ‘reunião de
levantamento de requisitos’, ‘especificação e documentação de requisitos’
e ‘reunião de análise e consolidação de requisitos pela equipe do projeto’.
Solução técnica Para avaliar a variação de prazo de solução técnica, devem ser coletadas
(TS) as informações de prazo planejado e prazo real de atividades específicas
do cronograma do projeto, como por exemplo: ‘definição da arquitetura
de software’, ‘especificação dos componentes de software’ e
‘implementação dos componentes de software’.
Verificação (VER) e Para avaliar a variação de prazo de verificação e validação, devem ser
Validação (VAL) coletadas as informações de prazo planejado e prazo real de atividades
específicas do cronograma do projeto, como por exemplo: ‘definir
ambiente de verificação e validação’, ‘revisão de produto’, ‘realização de
testes no software’ e ‘analisar resultados de verificações e validações’.
Densidade Desenvolvimento de Para avaliar a densidade de defeitos de desenvolvimento de requisitos,
de defeitos requisitos (RD) deve ser coletada a informação de quantidade de defeitos de produtos
deste processo, como por exemplo: defeitos de revisão técnica de
especificações de requisitos e defeitos do software encontrados durante os
testes que foram originados da falta de informação ou erros nas
especificações de requisitos.
Solução técnica Para avaliar a densidade de defeitos de solução técnica, deve ser coletada
(TS) a informação de quantidade de defeitos de produtos deste processo, como
por exemplo: defeitos de revisão técnica nas especificações de
componentes ou produtos da arquitetura, defeitos de sintaxe do código-
fonte e defeitos do software encontrados nos testes que foram originados
de falhas na lógica dos programas ou da não implementação de regras de
negócio especificadas.
Integração de Para avaliar a densidade de defeitos de integração de produto, deve ser
produtos (PI) coletada a informação de quantidade de defeitos de produtos deste
processo, como por exemplo: defeitos encontrados nos testes de sistema e
aceitação causados pela ausência de componentes no produto integrado ou
causados pela integração indevida de componentes não validados ou cujas
versões sejam ultrapassadas.
Taxa de Desenvolvimento de Para avaliar a taxa de mudanças de desenvolvimento de requisitos, devem
mudanças requisitos (RD) ser coletadas, por exemplo, as informações de quantidade de mudanças
nos requisitos após a sua aceitação pelo usuário em relação ao total de
requisitos do projeto.
Verificação (VER) e Para avaliar a taxa de mudanças de verificação e validação, devem ser
Validação (VAL) coletadas, por exemplo, as informações de quantidade de mudanças
ocorridas nos produtos após o início da verificação e validação (alterações
nos documentos de requisitos, alterações no código-fonte,...) em relação à
quantidade de produtos verificados e validados.
 62

3.3. Consolidação do catálogo

Após a seleção das 37 medidas para composição do catálogo de medidas, a etapa

seguinte da pesquisa foi especificar cada um dos indicadores, detalhando suas características,
o processo de medição e os métodos e técnicas para gestão quantitativa.
Para tal, inicialmente foi necessário identificar um modelo de documento para
especificação dos indicadores do catálogo, conforme apresentado a seguir.

3.3.1. Seleção do modelo de especificação de indicador

O processo de identificação de um modelo de especificação de indicador iniciou-se

pelo levantamento dos diferentes modelos existentes na literatura. Entre os modelos
identificados, foram selecionados para análise detalhada os propostos pelo Practical Software
Measurement (PSM) (DoD, 2004), pelo Software Engineering Institute (SEI, 2004) e pela
ISO 15.939 (ISO/IEC, 2002).
A seleção do modelo a ser utilizado foi realizada a partir da comparação dos três
modelos pré-selecionados. Conforme apresentado na Quadro 4, as informações dos modelos
de documento foram avaliadas com o objetivo de selecionar o mais completo, ou seja, àquele
que contenha a maior quantidade de informações sobre as medidas, permitindo maior
detalhamento das especificações.
Cada seção de um modelo foi comparada com seções dos outros dois modelos de
documento, mapeando seções cujo conteúdo seja semelhante. A partir deste paralelo foi
possível identificar, por exemplo, que a seção de ‘Medidas básicas’ do modelo do PSM,
contempla as mesmas informações expressas na seção de mesmo nome do modelo da ISO
15.939, e nas seções de ‘Elementos de dados’ e ‘Definição’ do modelo do SEI.
Apesar de bastante completo, o modelo de especificação de indicador do PSM foi
adaptado para esta pesquisa, a fim de adequar as seções do documento aos requisitos para a
gestão quantitativa de projetos.
A primeira adaptação foi utilizar na seção ‘Categoria de informação’ do documento o
conjunto das seis categorias de medição propostas nesta pesquisa (Tempo, Qualidade,
Produtividade, Escopo, Esforço e Custo) ao invés das categorias propostas pelo próprio PSM.
A segunda adaptação realizada no modelo foi alterar a seção de ‘Conceito mensurável’
do documento para ‘Objetivo de medição'. No modelo do PSM, o conteúdo da seção
‘Conceito mensurável’ confunde-se com as informações contidas na seção de ‘Entidades e
 63

atributos’, fato confirmado nos exemplos de medidas especificadas divulgado pelo próprio
PSM.
As seções de ‘Modelo de analise’, ‘Critério de decisão’ e ‘Interpretação do indicador’
do modelo foram interpretadas com foco na gestão quantitativa de projetos. Nestas seções,
para atender aos requisitos da área de processos do modelo CMMI-DEV, técnicas e métodos
de controle estatístico de processos foram inseridas como parte integrante do modelo,
aprimorando as técnicas e modelos de medição apresentados nos exemplos divulgados pelo
PSM.
As demais seções do modelo de especificação de indicador foram mantidas sem
alteração, conforme descrito no modelo do PSM.
O modelo de documento de especificação utilizado nesta pesquisa, adaptado a partir
do modelo do PSM proposto por DoD (2004), é apresentado a seguir, descrevendo os
objetivos e exemplos de cada seção do documento.

3.3.1.1. Modelo de documento de especificação de indicador

Nesta seção é apresentado o modelo de documento a ser utilizado na especificação dos

indicadores do catálogo. Conforme modelo do PSM proposto DoD (2004), para uma melhor
visualização das informações dos indicadores, as informações relacionadas do modelo de
documento são delimitadas com bordas, no formato de quadros. Apesar da estrutura, os
quadros do modelo de documento não serão referenciados nesta pesquisa, pois são
considerados apenas uma forma alternativa de representação o conteúdo das seções do
modelo.
Descrição da necessidade de informação
Necessidade de Descrever que questionamentos são feitos pelo usuário do indicador na tomada de
informação decisão a respeito do desempenho do processo sendo medido.
Categoria de Definir o(s) grupo(s) lógico(s) de necessidades de informação que caracterizam o
informação indicador em questão, conforme categorias descritas no Quadro 10.
Objetivo de medição
Descrever o objetivo de medição do indicador em questão, resumindo como o
Objetivo de medição indicador satisfaz os questionamentos apresentados na seção de ‘Necessidade de
informação’.
Entidade e atributos
Entidades relevantes Identificar o objeto que será medido. As entidades incluem elementos dos processos
e/ou produtos de um projeto, como por exemplo: tarefas do cronograma, estimativas,
planos, recursos e entregas.
Atributos Identificar as propriedades ou características de uma entidade que são quantificadas
para obtenção da medida básica.
 64

Especificação de medida básica

Medidas básicas Identificar as medidas básicas ou diretas, responsáveis por medir um atributo único a
partir de um método para quantificá-lo. Estas medidas são independentes de outras
medidas, como por exemplo: Quantidade de linhas de código planejadas, custo
acumulado até a data, esforço de revisão, etc.
Métodos de medição Listar a seqüência lógica de operações a serem realizadas para coleta e cálculo de cada
medida básica.
Tipos de métodos Identificar o tipo de método utilizado para quantificar um atributo, podendo ser
subjetivo ou objetivo, conforme apresentado na seção 2.2.1.
Escala Identificar para cada medida básica, o conjunto ordenador de valores ou categorias
assumido para a medida. Exemplos:
• Inteiros, de zero a infinito
• Decimais, de zero a infinito
Tipos de escalas Identificar para cada medida básica, conforme os tipos de valores descritos no Quadro
3.
Unidade de medição Identificar para cada medida básica a unidade que será utilizada para representar a
medida, tal como: linhas de código, defeitos, pontos de função, etc.
Especificação de medida derivada
Medidas derivadas Identificar as medidas derivadas, calculadas a partir de duas ou mais medidas básicas.
Função de medição Descrever a fórmula utilizada para cálculo de cada medida derivada.
Especificação de indicador
Descrição do Apresentar e descrever a visualização gráfica de uma ou mais medidas (base e
indicador e amostra derivadas) para apoiar o usuário em obter a informação para análise e tomada de
decisão.

É importante apresentar nesta seção um esboço do indicador, normalmente na forma de

gráfico ou diagrama, conforme ferramentas de controle estatístico apresentadas na
seção 2.3.5Erro! Fonte de referência não encontrada..
Modelo de analise Descrever o processo de análise do indicador, aplicando os critérios de decisão para
definir possíveis ações de resposta de acordo com os resultados quantitativos do
indicador.

Nesta seção devem ser apresentadas as cartas de controle adotadas para o indicador,
bem como a forma de análise destas cartas focadas na estabilidade do processo e na
identificação de causas especiais de variação.
Critério de decisão Descrever um conjunto de critérios para avaliação e interpretação dos resultados do
indicador

Nesta seção devem ser apresentadas as regras de instabilidade de processos

apresentadas para análise dos gráficos de controle, conforme apresentado na seção
2.3.5.5.
Interpretação do Apresentar a interpretação do indicador de exemplo apresentado na descrição do
indicador indicador, de acordo com o modelo de análise e os critérios de decisão, apresentando as
situações de desvio e ações de tratamento das causas especiais de variação;
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta Descrever com que freqüência os dados são coletados.
de dados
Responsável Identificar a pessoa designada para a coleta dos dados.
Fase ou atividade de Identificar a(s) fase(s) ou atividade(s) onde os dados são coletados.
coleta de dados
Ferramentas Listar as ferramentas utilizadas para a coleta dos dados, como por exemplo: ferramenta
utilizadas para coleta de cronograma, ferramenta de contagem de linhas de código, etc.
de dados
Verificação e Identificar as verificações e validações que serão executadas para garantir que a
Validação integridade e precisão dos dados coletados.
Repositório de dados Listar as ferramentas e/ou locais de armazenamento dos dados coletado, como por
coletados exemplo, repositórios de arquivos, planilhas ou bases de dados.
 65

Procedimento de análise de dados (para cada indicador)

Freqüência de Descrever com que freqüência os dados são analisados e reportados (esta freqüência
reporte dos dados deve ser igual ou menor do que a coleta).
Responsável Identificar a pessoa responsável pela análise e reporte dos resultados.
Fase ou atividade de Identificar a(s) fase(s) ou atividade(s) onde os dados são analisados.
análise dos dados
Fonte de dados para Listar as fontes de dados para a análise.
análise
Ferramentas Listar as ferramentas utilizadas na análise, como por exemplo, ferramentas de controle
utilizadas para estatístico de processos.
análise de dados
Revisão, reporte e Descrever quando os resultados são revisados e reportados, bem como o usuário final
usuário dos relatórios de análise do indicador.
Informação adicional
Guia de análise Descrever qualquer informação ou guia adicional em relação às variações para esta
adicional medida.
Considerações de Listar quaisquer requisitos de implementação ou de processo que seja necessário para o
implementação sucesso da medida.

A seção a seguir apresenta a seleção dos indicadores e suas medidas relacionadas para
composição do catálogo proposto nesta pesquisa.

3.3.2. Seleção do conjunto de indicadores a serem especificados

A partir da definição do conjunto de 37 medidas e do modelo de documento de

especificação, iniciou-se o processo de detalhamento das informações de cada indicador de
desempenho do catálogo.
O modelo proposto pelo PSM (DoD, 2004) e utilizado como base nesta pesquisa
agrupa as medidas básicas e derivadas relacionadas a um mesmo conceito ou aspecto do
processo de software em um indicador único. O indicador, por sua vez, é representado
normalmente na forma gráfica e consolida as informações das medidas relacionadas.
Sendo assim, antes de iniciar o detalhamento do catálogo, foi necessário identificar os
indicadores a serem especificados e o conjunto de medidas que cada indicador se propõe a
representar graficamente. Para isso foi realizada uma análise de como as medidas se
relacionam, com o objetivo de agrupá-las em indicadores que permitam uma melhor gestão
quantitativa dos processos.
Durante a seleção dos indicadores, percebeu-se que a medida de Complexidade
ciclomática deveria ser apresentada em um indicador separado dos demais, já que o seu
objetivo de medição não se relaciona com os outros indicadores selecionados para a
composição do catálogo. Porém, esta medida trata especificamente de avaliar a complexidade
de trechos de código ou programa, que são produtos de granularidade muito baixa para a
 66

gestão de projetos. Sendo assim, pode-se concluir que este indicador e sua medida associada
não agregam valor à análise de desempenho de processos, foco desta pesquisa, e, portanto o
mesmo foi excluído do escopo do catálogo de medidas.
O Quadro 19 apresenta o resultado desta análise, contento a relação de indicadores e
medidas selecionados para a especificação do catálogo.
A composição de um determinado indicador pode envolver uma ou várias medidas
derivadas, e estas por sua vez, podem envolver várias medidas básicas. É previsto, portanto,
que algumas medidas básicas sejam compartilhadas, ou seja, que estas apareçam descritas
repetidamente em diferentes indicadores do catálogo. Conforme mostrado no Quadro 19, um
exemplo desta situação é a medida básica de ‘Quantidade de defeitos’, que compõe as
medidas derivadas e indicadores de ‘Densidade de defeitos’, ’Eficácia de revisões e testes’ e
‘Taxa de remoção de defeitos’.
Durante a especificação dos indicadores, percebeu-se a necessidade de especializar
algumas medidas do catálogo, tornando-as mais específicas para utilização em determinados
indicadores. Tomando o mesmo exemplo citado acima, a medida de ‘Quantidade de defeitos’
foi especializada para as medidas de ‘Quantidade de defeitos abertos’ e ‘Quantidade de
defeitos fechados’ de forma a permitir o cálculo da medida derivada de ‘Taxa de remoção de
defeitos’.
As medidas especializadas durante a especificação do catálogo não fazem parte da
lista de medidas apresentada no Quadro 16. Estas são destacadas no Quadro 19, em um nível
mais profundo de endentação e identificadas conforme legenda ao final do quadro.

Quadro 19: Definição dos indicadores e medidas a serem especificadas no catálogo

Indicador Medidas básicas Medidas derivadas

1. Análise de valor agregado
• Valor planejado • Índice de desempenho de custos
• Valor agregado • Índice de desempenho de prazo
• Custo real • Variação de custo
• Orçamento no término o Variação de custo percentual (VC%) (1)
• Estimativa no término
• Estimativa para terminar
• Variação no término
 67

Quadro 19 (cont.): Definição dos indicadores e medidas a serem especificadas no catálogo

Indicador Medidas básicas Medidas derivadas

2. Cobertura de testes • Tamanho do produto de software testado: • Cobertura de testes
o Quantidade de linhas de código, ou
o Quantidade de pontos de função, ou
o Quantidade de requisitos
• Tamanho total do produto de software:
o Quantidade de linhas de código, ou
o Quantidade de pontos de função, ou
o Quantidade de requisitos
3. Custo da qualidade • Custos da conformidade (2) • Custo da qualidade
o Custo de controle da qualidade (CQ) • Percentual de custo da qualidade
(2) (3)
(2)
o Custo da garantia da qualidade
• Custos da não-conformidade (2)
o Custo de retrabalho (2)
o Custo de trabalho em garantia (2)
o Custo de desperdício e de perda de
reputação (2).
• Custo real
4. Densidade de defeitos • Quantidade de defeitos • Densidade de defeitos
o Quantidade de defeitos totais (1) o Densidade de defeitos
o Quantidade de defeitos por tipo (1) totais (1)
• Quantidade de linhas de código o Densidade de defeitos
• Quantidade de pontos de função por tipo (1)
• Quantidade de requisitos
• Quantidade de páginas de documento
5. Eficácia de revisões e • Quantidade de defeitos • Eficácia de testes
testes o Quantidade de defeitos de testes • Eficácia de revisão
internos (1)
o Quantidade de defeitos de revisão
internos (1)
o Quantidade de defeitos de testes
externos (1)
o Quantidade de defeitos de revisão
externos (1)
6. Mudanças de escopo • Quantidade de mudanças • Taxa de mudanças
• Quantidade de linhas de código • Volatilidade de requisitos
• Quantidade de requisitos
o Quantidade de requisitos que
sofreram mudança (1)
o Quantidade total de requisitos do
projeto (1)
• Quantidade de pontos de função
7. Prazo de ciclo • Prazo de ciclo • Prazo de ciclo relativo ao
• Quantidade de linhas de código tamanho (3)
• Quantidade de requisitos
• Quantidade de pontos de função
8. Prazo médio para a • Prazo médio para a falha
falha
9. Produtividade • Esforço • Produtividade
• Quantidade de linhas de código • Taxa de entrega
• Quantidade de requisitos
• Quantidade de pontos de função
• Prazo
10. Reuso de código • Quantidade de linhas de código • Reuso de código
 68

Quadro 19 (cont.): Definição dos indicadores e medidas a serem especificadas no catálogo

Indicador Medidas básicas Medidas derivadas

11. Taxa de remoção de • Quantidade de defeitos • Taxa de remoção de defeitos
defeitos o Quantidade de defeitos
abertos (1)
o Quantidade de defeitos de
fechados (1)
12. Taxa de retrabalho • Esforço de retrabalho • Taxa de retrabalho
o Esforço de retrabalho total (1) o Taxa de retrabalho total (1)
o Esforço de retrabalho por o Taxa de retrabalho por disciplina (1)
(1)
disciplina
• Esforço
o Esforço total do projeto (1)
13. Variação de esforço • Esforço • Variação de esforço
o Esforço planejado (1) o Variação de esforço total (1)
(1)
o Esforço real o Variação de esforço por disciplina
(1)

14. Variação de prazo • Prazo • Variação de prazo

o Prazo planejado (1) o Variação de prazo total (1)
(1)
o Prazo real o Variação de prazo por disciplina (1)
15. Variação de tamanho • Quantidade de linhas de código • Variação de tamanho
• Quantidade de requisitos
• Quantidade de pontos de função
(1) Medidas especializadas a partir das medidas do catálogo.
(2) Medidas básicas não citadas no conjunto final de medidas do catálogo (Quadro 16), porém necessárias
para o cálculo da medida derivada.
(3) Medidas derivadas não citadas no conjunto final de medidas do catálogo (Quadro 16), porém
necessárias para realização do gerenciamento quantitativo do projeto.

O Quadro 20 abaixo apresenta a distribuição dos indicadores do catálogo em relação

às áreas de processos do modelo CMMI-DEV e às categorias de medição propostas nesta
pesquisa. As informações deste quadro foram derivadas do agrupamento de medidas pelos
indicadores do catálogo apresentado no Quadro 19 e da classificação das medidas em relação
ás áreas de processo e categorias de medição, conforme exposto no Quadro 17.
 69

Quadro 20: Distribuição dos indicadores do catálogo por categoria e área de processo

Categoria / Área Desenvolvimento de Gerenciamento de Integração de

Solução técnica (TS) Verificação (VER) Validação (VAL)
de Processo requisitos (RD) requisitos (REQM) produto (PI)
Tempo • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor
agregado agregado agregado agregado agregado agregado
• Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo • Prazo de ciclo
• Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo • Variação de prazo
Qualidade • Densidade de • Densidade de • Densidade de • Densidade de • Taxa de remoção de • Taxa de remoção de
defeitos defeitos defeitos defeitos defeitos defeitos
• Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho • Taxa de retrabalho
• Prazo médio para • Prazo médio para • Prazo médio para • Prazo médio para Cobertura de testes Cobertura de testes
falha falha falha falha • Prazo médio para • Prazo médio para
falha falha
• Eficácia de revisões • Eficácia de revisões
e testes e testes
Produtividade • Produtividade • Produtividade • Produtividade • Produtividade • Produtividade • Produtividade
Escopo • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor
agregado agregado agregado agregado agregado agregado
• Mudanças de escopo • Mudanças de escopo • Mudanças de escopo • Variação de • Variação de • Variação de
• Variação de • Variação de • Reuso de código tamanho tamanho tamanho
tamanho tamanho • Variação de • Mudanças de escopo • Mudanças de escopo • Mudanças de escopo
tamanho
Esforço • Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço • Variação de esforço

Custo • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor • Análise de valor
agregado agregado agregado agregado agregado agregado
• Custo da Qualidade • Custo da Qualidade
 70

A seção a seguir apresenta o passo de seleção de técnicas de controle estatístico de

processos que deverão compor o catálogo de medidas.

3.3.3. Seleção de técnicas para a gestão quantitativa de projetos

Antes de realizar a especificação do catálogo, é necessário avaliar as diversas técnicas

de controle estatístico de processos disponíveis na literatura e selecionar as mais aplicáveis
para a gestão quantitativa de projetos a partir das medidas que compõem o catálogo.
Um ponto importante na decisão das técnicas para controle estatístico de processos é a
seleção do tipo de gráfico de controle a ser utilizado em cada situação. Esta decisão
normalmente é realizada a partir da avaliação do tipo de dado a ser medido e do tamanho da
amostra disponível para apresentação na carta de controle (KULPA; JOHNSON, 2008).
Em razão das características apresentadas na seção 2.3.5.3, os gráficos de controle dos
tipos XmR e u foram selecionadas como principal instrumento de controle estatístico de
processos, sendo a carta do tipo u aplicada somente ao indicador de Densidade de defeitos e a
carta do tipo XmR aplicada para representação gráfica dos indicadores restantes do catálogo.
A seção a seguir descreve o processo de especificação das medidas e apresenta
exemplos de medidas especificadas para o catálogo.

3.3.4. Especificação dos indicadores e consolidação do catálogo

A partir da identificação do conjunto de 15 indicadores de desempenho, que agrupam

as 37 medidas selecionadas para o catálogo, foi possível iniciar a especificação detalhada dos
indicadores. As seções seguintes apresentam as especificações de cada indicador e suas
medidas, conforme o modelo de documento de especificação adaptado para esta pesquisa.

3.3.4.1. Análise de valor agregado

Descrição da necessidade de informação

Necessidade de Qual é o desempenho de prazo, custo e escopo do projeto, quando avaliados de forma
informação integrada?
Categoria de • Prazo
informação • Custo
• Escopo
Objetivo de medição
Avaliar o desempenho do escopo realizado do projeto em relação ao planejamento, e
Objetivo de medição
acompanhar o progresso de prazo e custo real para realização deste escopo.
 71

Entidade e atributos
Entidades relevantes Projeto ou atividades do projeto
Atributos 1. Escopo planejado: Linha de base de escopo planejado para a tarefa ou projeto.
2. Prazo planejado: Linha de base de prazo planejado para a tarefa ou projeto.
Normalmente estimado com base no escopo planejado em relação aos recursos
disponíveis e produtividade destes para realização das tarefas.
3. Custo planejado: Linha de base de custo planejado para a tarefa ou projeto.
4. Custo realizado: Valor real de custo executado até o determinado momento.
5. Prazo realizado: Valor real de prazo executado até o determinado momento.
6. Escopo realizado: Valor real de escopo executado até o determinado momento.
Especificação de medida básica
Medidas básicas 1. Valor planejado (VP)
2. Custo real (CR)
3. Valor agregado (VA)
4. Orçamento no término (ONT)
Métodos de medição 1. Estimativa do custo total planejado para execução do trabalho de uma atividade ou
projeto até um determinado momento, obtida da linha de base do projeto. Este
custo é normalmente estimado com base no custo dos recursos alocados para
realização das tarefas do projeto.
2. Cálculo do custo total realizado na execução do trabalho de uma atividade ou
projeto até um determinado momento, normalmente obtido através do custo
acumulado dos recursos utilizados para a realização da tarefa ou projeto.
3. Cálculo do custo total planejado para execução do trabalho realmente terminado na
atividade ou projeto até um determinado momento. Este valor de custo
corresponde ao valor planejado, multiplicado pelo percentual de conclusão da
atividade ou projeto,
4. Estimativa de custo planejado para execução do trabalho de todo o projeto,
baseado no planejamento original mais mudanças autorizadas (VP total).
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
4. Objetivo
Escala 1. Decimais, de zero a infinito
2. Decimais, de zero a infinito
3. Decimais, de zero a infinito
4. Decimais, maior do que zero a infinito
Tipos de escalas 1. Razão
2. Razão
3. Razão
4. Razão
Unidade de medição 1. Valor monetário (R$)
2. Valor monetário (R$)
3. Valor monetário (R$)
4. Valor monetário (R$)
Especificação de medida derivada
Medidas derivadas 1. Índice de desempenho de custos (IDC)
2. Índice de desempenho de prazo (IDP)
3. Variação de custo (VC)
4. Variação de custo percentual (VC %)
5. Estimativa para terminar (EPT)
6. Estimativa no término (ENT)
7. Variação no término (VNT)
 72

Função de medição 1. IDC = VA / CR

2. IDP = VA / VP
3. VC = VA – CR
4. VC% = (VA – CR) / VA
5.
5.1. EPT è Estimativa para terminar
baseada em uma nova
estimativa, independente e
não calculada, para o trabalho
restante do projeto
5.2. EPT = (ONT - VA) è Estimativa para terminar
baseada em variações típicas:
Esta abordagem é mais
freqüentemente usada quando
as variações atuais são
consideradas atípicas e a
expectativa da equipe é de
que variações semelhantes
não irão ocorrer no futuro.
5.3. EPT = (ONT - VA) / IDC è Estimativa para terminar
baseada em variações típicas:
Esta abordagem é mais
freqüentemente usada quando
as variações atuais são
consideradas típicas, sendo
que deverão se repetir no
futuro.
6. ENT = CR + EPT
7. VNT = ONT – ENT
Especificação de indicador
Descrição do 1. Índice de desempenho de prazo (IDP) e Índice de desempenho de custos
indicador e amostra (IDC): As medidas de IDC e IDP são apresentadas separadamente em gráficos
XmR para avaliação da estabilidade do processo (Figura 7 e Figura 8).

Figura 7: Índice de desempenho de custos (XmR)

 73

Figura 8: Índice de desempenho de prazo (XmR)

2. Valor agregado (VA), Custo real (CR) e Valor planejado (VP): As medidas
básicas da análise de valor agregado são apresentadas em conjunto em um gráfico
de Curva S (Figura 9).

Figura 9: Valor agregado (Curva S)

3. Variação de custo (VC) e Variação de custo percentual (VC%): As medidas de

variação de custo são analisadas em relação a uma escala temporal, apresentando
tanto o valor monetário da variação quanto o percentual mensal e acumulado
(Figura 10).
 74

Variação de custo
R$ 20.000,00 50,00%

R$ - 0,00%
11,14%
-16,36% -23,12% -21,33%
R$ (20.000,00) -50,00%
-35,61% -37,57% -37,60% -40,70%
-53,05% -50,02% -46,38% -49,87% -49,74%
-49,27% -50,24%
-52,58%
-59,22%
-71,47% -68,86% -63,30%
R$ (40.000,00) -100,00%
-102,01%
R$ (60.000,00) -150,00%

R$ (80.000,00) -174,65% -200,00%

R$ (100.000,00) -228,90% -250,00%

jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08 nov/08 dez/08

Variação de custo (VC) Variação de custo percentual (VC %) Variação de custo acumulado percentual (VCa %)

Figura 10: Variação de custo

4. Orçamento no término (ONT), Estimativa no término (ENT) e Variação no

término (VNT): As medidas que avaliam o custo planejado e real ao término do
projeto são apresentadas em relação a uma escala temporal, comparando a
estimativa no término (ENT) com o orçamento no término (ONT) (Figura 11).

Orçamento no término
R$ 3.500.000,00

R$ 3.000.000,00

R$ 2.500.000,00

R$ 2.000.000,00 R$ 1.795.000,00

R$ 1.500.000,00

R$ 1.000.000,00

R$ 500.000,00

R$ -

R$ (500.000,00)

R$ (1.000.000,00)

R$ (1.500.000,00)
jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08 nov/08 dez/08

Estimativa no término (ENT) Variação no término (VNT) Orçamento no término (ONT)

Figura 11: Orçamento no término

Modelo de analise 1. As medidas IDC e IDP são apresentadas separadamente em Gráficos de Controle
X e mR (XmR) e de forma conjunta em um Diagrama de Dispersão:
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4.
2. As medidas VA, CR e VP são apresentadas de forma cumulada em uma Curva S,
onde á possível comparar o valor do trabalho executado (VA) em relação ao custo
despendido para a realização do trabalho (CR) e ao valor de trabalho planejado
(VP). A cada observação destas três medidas, os valores plotados na curva S
permitem avaliar as variações de prazo em valores de tempo e monetário (Setas 1 e
2 na Figura 9, respectivamente) e a variação de custo em valor monetário (Seta 3
na Figura 9). Idealmente, as curvas das medidas VA, CR e VP deveriam ser
plotadas de forma sobreposta, indicando que o projeto ou tarefa está sendo
realizado exatamente dentro do custo e prazo previstos. Valores de CR e VP
superiores a VA indicam que o projeto ou tarefa encontra-se em desvio de
execução em relação ao custo e prazo planejados.
3. As medidas de VC e VC% são apresentadas em um único gráfico temporal de
freqüência mensal, que combina os valores coletados para as medidas com a
 75

variação de custo percentual acumulada. Variações de custo negativas, tanto em

valor monetário quanto percentual, representam que o projeto ou tarefa encontra-se
em desvio em relação ao planejamento. A variação de custo mensal deve ser
analisada, porém o foco de melhoria deve ser sempre a variação acumulada, pois
esta representa a tendência de resultado final para o projeto ou tarefa.
4. As medidas ONT, ENT e VNT são apresentadas em um único gráfico temporal de
freqüência mensal, onde cada mês identifica a estimativa de custo ao término do
projeto, com base no desempenho dos meses anteriores (variação típica). A medida
ENT, apresentada em gráfico de barras, deve ser comparada em relação à medida
ONT, apresentada como linha pontilhada. Observações de ENT superiores a ONT,
bem como observações negativas de VNT, que indicam que o custo estimado do
projeto deverá ser maior do que o planejado.

Os indicadores apresentados para análise de valor agregado devem ser analisados

individualmente, conforme apresentado acima, e em conjunto a partir do seguinte
modelo de análise:
• Eventuais desvios nos indicadores de IDC e IDP devem cruzados com as
informações providas pela curva S. Nesta curva, devem ser identificados os
pontos onde o valor agregado (VA) torna-se inferior ao custo real (CR) ou ao
valor planejado (VA). A partir da identificação de tendência de desvio, devem ser
analisados os processos técnicos com o objetivo de mapear as causas e propor
ações corretivas.
• O valor de IDC deve ser cruzado com as tendências de desvio de variação de
custo e variação de custo percentual, bem como com os indicadores de estimativa
no término, estimativa para terminar e variação no término. Desvios no
desempenho de custos mensal e acumulado são refletidos na previsão futura de
custo final do projeto a partir da aplicação do IDC na fórmula de cálculo de ENT
e EPT.
Critério de decisão 1. As medidas de IDC e IDP são apresentadas em gráficos XmR e em Diagrama de
dispersão. Os critérios de decisão são diferentes para cada uma das formas de
apresentação, conforme segue:
1.1. As representações no gráfico de controle XmR possuem como critérios de
decisão as regras de instabilidade de processo para cada um dos gráficos que
representam o indicador, conforme descrito na seção 2.3.5.5.
2. A avaliação do gráfico de Curva S para as medidas básicas de valor agregado
permite obter as mesmas conclusões que os indicadores de IDC, IDP e VC.
Portanto, como critério de decisão para a Curva S sugere-se que valores de CR e
VP superiores a VA, apresentados de forma crescente em pelo menos dois meses
consecutivos indicam tendência de desvio da tarefa e/ou projeto. Nestes casos,
ações gerenciais são necessárias para recuperar o desvio e trazer o desempenho do
projeto (EV e CR) o mais próximo possível do valor planejado (VP).
3. A avaliação do gráfico de variação de custo permite obter as mesmas conclusões
que os indicadores de IDC, IDP e Curva S. O gráfico de variação de custo possui
como critério de decisão que observações de variação de custo percentual (VC%)
e/ou variação de custo acumulado percentual (VCa%) negativo são consideradas
desvios e, portanto necessitam de ações gerenciais para identificação e resolução
das causas de desvio.
4. A avaliação do gráfico de orçamento no término possui como critério de decisão
que caso uma observação das medidas apresenta valores para ENT superior a ONT
ou uma observação negativas de VNT deve ser tratada como desvio, sendo
identificadas as causas e executadas ações para resolução.
Interpretação do 1. Para as medidas de IDC e IDP:
indicador 1.1. Tanto o gráfico de controle X como o mR para a medida IDC demonstram que
o processo em questão encontra-se estável, não tendo apresentado nenhum
dos padrões de desempenho descritos nas regras dos critérios de decisão.
Neste caso, nenhuma ação gerencial é necessária.
1.2. O gráfico X da medida IDP não possui causas especiais de variação, porém, o
gráfico mR de IDP apresenta na observação realizada em outubro de 2008
um sinal de instabilidade de acordo com Regra 1. Neste caso, o processo é
considerado instável ou fora de controle e, portanto as causas deverão ser
 76

identificadas e tratadas.
2. A curva S do exemplo apresenta, a partir da observação realizada em Março de
2008, tendência de desvio já que os valores de CR e VA são inferiores ao valor de
PV por dois meses consecutivos. Sendo assim, ações gerenciais devem ser
realizadas para tratar os desvios.
3. A partir do gráfico de variação de custos mostrado no exemplo anterior é possível
concluir que em todos os meses apresentados no gráfico, o projeto ou tarefa
medido apresentou desvio superior ao limite estabelecido nos critérios de decisão.
Portanto, neste caso, desde o primeiro mês de medição seria necessário realizar
ações para correção do desempenho do projeto, tornando compatíveis o custo real
e valor agregado pelo trabalho realizado.
4. O gráfico de orçamento no término apresentado no exemplo identifica que os
valores de ENT são superiores a ONT desde a primeira observação das medições.
Sendo assim, são necessárias ações gerenciais para tornar a estimativa de custo
final do projeto igual ou inferior ao valor de ONT.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Diariamente. Coleta do valor de valor planejado para as atividades e/ou projeto
de dados planejadas para realização até a data da coleta.
2. Diariamente. Coleta do custo realizado na execução das atividades até a data da
coleta.
3. Diariamente. Coleta do valor de valor agregado nas atividades realizadas até a data
da coleta.
4. Mensalmente ou a cada mudança. Coleta do orçamento planejado para todo o
projeto a cada oportunidade de reporte da medida ou a cada mudança aprovada no
orçamento do projeto.
Responsável O Gerente do Projeto coleta os valores das medidas básicas de valor agregado.
Fase ou atividade de Em todas as fases do ciclo de vida do projeto.
coleta de dados
Ferramentas 1. Ferramenta de gerenciamento de cronograma e alocação de recursos.
utilizadas para coleta 2. Ferramenta de gerenciamento de cronograma e alocação de recursos.
de dados 3. Ferramenta de gerenciamento de cronograma e alocação de recursos.
4. Ferramenta de gerenciamento de cronograma e alocação de recursos.
Verificação e Auditorias nas linhas de base de planejamento e nos registros de desempenho, esforço e
Validação custo reportados pelas equipes da ferramenta de gerenciamento de cronograma.
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Mensalmente.
reporte dos dados
Para os meses onde o indicador não for coletado, repetir os valores da última análise.
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Em todas as fases do ciclo de vida do projeto.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise
adicional
 77

Considerações de • Os indicadores e medidas apresentadas nesta especificação apresentam diferentes

implementação visões do desempenho de escopo, custo e prazo do projeto. Pode-se concluir que as
representações gráficas apresentadas possuem redundâncias de informação e
objetivos. Sendo assim, não é necessário que todas as representações descritas
sejam utilizadas, desde que a organização e os envolvidos sejam capazes de obter a
visão desejada da análise de valor agregado.
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.2. Cobertura de testes

Descrição da necessidade de informação

Necessidade de Quanto do produto de software teve sua qualidade efetivamente validada por
informação atividades de testes?
Categoria de Qualidade
informação
Objetivo de medição
Avaliar o percentual do escopo do produto de software validado através da execução de
Objetivo de medição
testes.
Entidade e atributos
Entidades relevantes Pacote ou unidade de software
Atributos 1. Tamanho
Especificação de medida básica
Medidas básicas 1. Tamanho do produto de software testado, sendo representado por:
1.1. Quantidade de linhas de código, ou
1.2. Quantidade de pontos de função, ou
1.3. Quantidade de requisitos
2. Tamanho total do produto de software, sendo representado por:
2.1. Quantidade de linhas de código, ou
2.2. Quantidade de pontos de função, ou
2.3. Quantidade de requisitos
Métodos de medição 1. Contagem do tamanho de um pacote ou unidade de software para o qual foram
realizadas atividades de testes
1.1. Contagem da quantidade de linhas de código (SEI, 1992)
1.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
1.3. Contagem do número de requisitos funcionais do software.
2. Contagem do tamanho total de um pacote ou unidade de software
2.1. Contagem da quantidade de linhas de código (SEI, 1992)
2.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
2.3. Contagem do número de requisitos funcionais do software.
Tipos de métodos 1. Objetivo
2. Objetivo
Escala 1.
1.1. Inteiros, de zero a infinito
1.2. Decimais, de zero a infinito
1.3. Inteiros, de zero a infinito
2.
2.1. Inteiros, de zero a infinito
2.2. Decimais, de zero a infinito
2.3. Inteiros, de zero a infinito
 78

Tipos de escalas 1.
1.1. Absoluta
1.2. Razão
1.3. Absoluta
2.
2.1. Absoluta
2.2. Razão
2.3. Absoluta
Unidade de medição 1.
1.1. Linhas de código
1.2. Pontos de função
1.3. Requisitos
2.
2.1. Linhas de código
2.2. Pontos de função
2.3. Requisitos
Especificação de medida derivada
Medidas derivadas 1. Cobertura de testes
Função de medição  Tamanho do produto de software testado 
1.   *100
 Tamanho total do produto de software 
Especificação de indicador
Descrição do 1. Cobertura de testes: Este indicador apresenta na Figura 12 o percentual do
indicador e amostra produto de software testado, em relação ao tamanho total do produto de software.

Figura 12: Cobertura de testes (XmR)

Modelo de analise 1. A medida de Cobertura de testes é apresentada em Gráficos de Controle X e mR

(XmR):
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4.
Critério de decisão 1. A medida de Cobertura de testes possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5.
 79

Interpretação do 1. Os gráficos de controle X e mR da medida de Cobertura de testes do exemplo

indicador acima apresentam desvios na medição coletada no Build 7, já que a medição
excede o limite de controle de 3 sigmas da linha central. Neste caso é necessário
avaliar as causas da baixa cobertura de testes para este Build, inclusive analisando
se houve queda na qualidade para do produto entregue ao cliente.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta do
de dados tamanho do pacote ou unidade de software testado antes da entrega ao cliente.
2. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta do
tamanho total do pacote ou unidade de software entrega ao cliente.
Responsável O Analista de métricas obtém os dados de tamanho do projeto.
Fase ou atividade de Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir durante a
coleta de dados fase de Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que os primeiros testes forem realizados nos pacotes ou unidades de
software até a implantação do produto. Opcionalmente, a medida pode permanecer
sendo coletada durante a operação ou garantia do produto em ambiente de produção.
Ferramentas 1.
utilizadas para coleta 1.1. Ferramenta de contagem de linhas de código
de dados 1.2. Ferramenta ou Relatório de análise de pontos de função
1.3. Ferramenta ou Lista de requisitos
2.
2.1. Ferramenta de contagem de linhas de código
2.2. Ferramenta ou Relatório de análise de pontos de função
2.3. Ferramenta ou Lista de requisitos
Verificação e Auditorias dos registros de tamanho do projeto de software.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de A cada pacote ou unidade de software entregue ao Cliente (Build).
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir durante a
análise dos dados fase de Operação do ciclo de vida do produto: Os dados devem ser analisados a partir
do momento em que os primeiros testes forem realizados nos pacotes ou unidades de
software até a implantação do produto. Opcionalmente, a medida pode permanecer
sendo analisada durante a operação ou garantia do produto em ambiente de produção.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável.
adicional
Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de
implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.
 80

3.3.4.3. Custo da qualidade

Descrição da necessidade de informação

Necessidade de Qual é o custo total para garantir a qualidade do produto de software e para corrigir
informação eventuais falhas de qualidade apresentadas no produto entregue?
Categoria de Custo
informação
Objetivo de medição
Avaliar o custo total da qualidade dos produtos de software entregues, incluindo o
Objetivo de medição custo para prevenir a ocorrência de defeitos e o custo para correção de falhas
apresentadas após a entrega do produto.
Entidade e atributos
Entidades relevantes Projeto
Atributos 1. Custo
Especificação de medida básica
Medidas básicas 1. Custo do controle da qualidade
2. Custo da garantia da qualidade
3. Custo do retrabalho
4. Custo do trabalho em garantia
5. Custo de desperdício e de perda de reputação
6. Custo real
Métodos de medição 1. Cálculo do custo despendido em atividades de controle da qualidade do projeto,
como por exemplo: avaliação dos resultados das atividades de garantia da
qualidade, coleta e análise dos indicadores de qualidade e identificação de ações
gerenciais para solucionar desvios de qualidade.
2. Cálculo do custo despendido em atividades de garanta da qualidade do projeto,
como por exemplo: revisões e testes nos produtos e auditorias nos processos e
produtos do projeto.
3. Cálculo do custo despendido em atividades de correção de falhas apresentadas em
produtos entregues ao cliente, durante a execução do projeto.
4. Cálculo do custo despendido em atividades realizadas no período de garantia do
produto, ou seja, após conclusão do projeto e entrega do sistema ao cliente.
Exemplos deste caso são: correção de falhas, atendimento ao usuário, substituição
de produto.
5. Estimativa do custo da perda de credibilidade e reputação da organização em
virtude de falhas no produto do projeto.
6. Cálculo do custo total realizado na execução do trabalho de uma atividade ou
projeto até um determinado momento.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
4. Objetivo
5. Subjetivo
6. Objetivo
Escala 1. Decimais, de zero a infinito
2. Decimais, de zero a infinito
3. Decimais, de zero a infinito
4. Decimais, de zero a infinito
5. Decimais, de zero a infinito
6. Decimais, de zero a infinito
Tipos de escalas 1. Razão
2. Razão
3. Razão
4. Razão
5. Razão
6. Razão
 81

Unidade de medição 1. Valor monetário (R$)

2. Valor monetário (R$)
3. Valor monetário (R$)
4. Valor monetário (R$)
5. Valor monetário (R$)
6. Valor monetário (R$)
Especificação de medida derivada
Medidas derivadas 1. Custo da qualidade
2. Percentual de custo da qualidade
Função de medição Custo do controle da qualidade +
Custo da garantia da qualidade +
1. Custo do retrabalho +
Custo do trabalho em garantia +
Custo de desperdício e de perda de reputação
 Custo da qualidade 
2.   *100
 Custo real 
Especificação de indicador
Descrição do 1. Custo da qualidade: Este indicador apresenta o custo da qualidade realizado
indicador e amostra mensalmente no projeto, conforme apresentado na Figura 13.

Figura 13: Custo da qualidade (Barras)

2. Percentual de custo da qualidade: Este indicador apresenta a relação entre o

custo da qualidade e o custo total realizado mensalmente no projeto, conforme
apresentado na Figura 14.
 82

Figura 14: Percentual de custo da qualidade (XmR)

Modelo de analise 1. A medida de Custo da qualidade é apresentada em um gráfico temporal de

freqüência mensal, onde cada mês identifica o custo total da qualidade realizada no
projeto. A medida deve ser comparada em relação ao limite de especificação (linha
pontilhada), que representa o custo das atividades de qualidade aprovado no
planejamento do projeto. Observações da medida superiores ao limite de
especificação indicam que o custo da qualidade é maior do que o previsto e,
portanto ações devem ser tomadas.
2. A medida de Percentual de custo da qualidade é apresentada em Gráficos de
Controle X e mR (XmR):
2.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4.
Critério de decisão 1. A avaliação do gráfico de barras da medida de Custo da qualidade possui como
critério de decisão que caso uma observação da medida apresente valor superior ao
limite de especificação, esta deve ser tratada como desvio, sendo identificadas as
causas e executadas ações para resolução.
2. A medida de Percentual de custo da qualidade é apresentada em gráfico XmR.
2.1. As representações no gráfico de controle XmR possuem como critérios de
decisão as regras de instabilidade de processo para cada um dos gráficos que
representam o indicador, conforme descrito na seção 2.3.5.5.
Interpretação do 1. O gráfico do indicador de Custo da qualidade mostrado no exemplo apresenta
indicador desvio em relação ao limite de especificação nos meses de Janeiro e Julho de 2008.
Devem ser identificadas as causas dos desvios e ações gerenciais necessitam ser
realizadas para evitar falhas no atendimento aos objetivos de qualidade e custos do
projeto.
2. Os gráficos X e mR do indicador de Percentual de custo da qualidade não
apresentam sinais de desvio pois atendem a todos os testes descritos nos critérios
de decisão.
 83

Procedimento de coleta de dados (para cada medida básica)

Freqüência da coleta 1. Mensalmente.
de dados 2. Mensalmente.
3. Mensalmente.
4. Mensalmente.
5. Mensalmente.
6. Mensalmente.
Responsável O Gerente do projeto obtém os dados de custos a partir do cronograma e ferramenta de
controle financeiro do projeto.
Fase ou atividade de Durante todo o ciclo de vida do projeto.
coleta de dados
Ferramentas 1. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
utilizadas para coleta 2. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
de dados 3. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
4. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
5. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
6. Ferramentas de gerenciamento financeiro, cronograma e alocação de recursos.
Verificação e Auditorias dos registros de custos do projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de 1. Mensalmente.
reporte dos dados 2. Mensalmente.

Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)

• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida do projeto.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • O indicador de Custo da qualidade não é adequado para aplicação de técnicas de
implementação controle estatístico de processos, pois o valor absoluto da medida de custo da
qualidade varia significativamente para cada projeto, sendo diretamente
relacionada ao escopo de cada projeto. Para aplicação de técnicas de
gerenciamento quantitativo, sugere-se o uso da medida de Percentual de custo da
qualidade.
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.4. Densidade de defeitos

Descrição da necessidade de informação

Necessidade de Qual é a qualidade do produto de software sendo desenvolvido?
informação
Categoria de Qualidade
informação
 84

Objetivo de medição
Avaliar o desempenho dos processos técnicos de desenvolvimento de software através
Objetivo de medição
da qualidade do produto resultante da execução destes processos.
Entidade e atributos
Entidades relevantes Pacote ou unidade de software.
Atributos 1. Quantidade de defeitos
2. Tamanho
Especificação de medida básica
Medidas básicas 1. Quantidade de defeitos totais
2. Quantidade de defeitos por tipo
3. Tamanho, sendo representado por:
3.1. Quantidade de linhas de código, ou
3.2. Quantidade de pontos de função, ou
3.3. Quantidade de requisitos
Métodos de medição 1. Contagem do número de defeitos totais encontrados nos testes de um pacote ou
unidade de software
2. Contagem do número de defeitos encontrados nos testes de um pacote ou unidade
de software, classificados por tipo de defeito ou causa do defeito (Implementação,
Banco de Dados, Projeto, Requisito, Integração, Ambiente, etc.)
3. Contagem do tamanho de um pacote ou unidade de software testado
3.1. Contagem da quantidade de linhas de código (SEI, 1992)
3.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
3.3. Contagem do número de requisitos funcionais do software.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
3.
3.1. Inteiros, de zero a infinito
3.2. Decimais, de zero a infinito
3.3. Inteiros, de zero a infinito
Tipos de escalas 1. Absoluta
2. Nominal
3.
3.1. Absoluta
3.2. Razão
3.3. Absoluta
Unidade de medição 1. Defeitos
2. Defeitos
3.
3.1. Linhas de código
3.2. Pontos de função
3.3. Requisitos
Especificação de medida derivada
Medidas derivadas 1. Densidade de defeitos totais
2. Densidade de defeitos por tipo
Função de medição Quantidade de defeitos totais
1.
Tamanho do pacote ou unidade de software
Quantidade de defeitos por tipo
2.
Tamanho do pacote ou unidade de software
 85

Especificação de indicador
Descrição do 1. Densidade de defeitos: Este indicador apresenta na Figura 15 a razão entre a
indicador e amostra quantidade de defeitos encontrados durante os testes e o tamanho do pacote ou
unidade de software testado. O indicador apresenta também na Figura 16 a
classificação dos defeitos por tipo a fim de identificar os processos que mais
causaram defeitos no produto de software.

Densidade de defeitos (u Chart Skyline)

1,400
1,200
1,000
0,800
0,600
0,400
0,311
0,200
-
(0,200)
(0,400)

Densidade de defeitos (X) LC LCS LCI

Figura 15: u Chart de Densidade de defeitos

Densidade de defeitos (Pareto)

0,070 120,00%
0,058 94,30%100,00%
Densidade de defeitos

0,060 86,08% 100,00%

75,32%
0,050 0,042
63,29% 80,00%
0,040
60,00%
0,030 36,71%
0,019 0,017 40,00%
0,020 0,013
0,009
0,010 20,00%
- 0,00%

Figura 16: Diagrama de Pareto de Densidade de defeitos

Modelo de analise 1. A medida de Densidade de defeitos totais é apresentada em Gráficos de Controle

do tipo u com o objetivo de avaliar a estabilidade do processo de desenvolvimento
de software em relação à qualidade do produto gerado.
1.1. O Gráfico de Controle u apresenta a evolução da Densidade de defeitos nos
diferentes pacotes ou unidades de software produzidos e testados. A análise
deste gráfico deve procurar por sinais de desvios, ou seja, variações
excepcionais do processo que necessitam de investigação detalhada para
identificação e correção das causas de variação. O cálculo da linha central e
limites de controle deste gráfico são realizados de acordo com o
procedimento apresentado na seção 2.3.5.4.
2. A medida de Densidade de defeitos por tipo é apresentada em um Diagrama de
Pareto. Este diagrama apresenta as principais causas dos defeitos encontrados,
apresentando-as ordenadas decrescentemente de acordo com a sua densidade de
defeitos. O objetivo do diagrama de Pareto é apoiar a priorização de ações para
resolução das causas que apresentam a maior densidade de defeitos.
Critério de decisão 1. A medida de Densidade de defeitos totais possui como critérios de decisão as
regras de instabilidade de processo para cada um dos gráficos que representam o
indicador. A cada ocorrência de uma das regras listadas a seguir, o processo deve
ser analisado com objetivo de identificar e eliminar as causas de variação.
1.1. Para o gráfico de controle u, um ou mais pontos fora dos limites de controle
superior (LC + 3 sigmas) e inferior (LC - 3 sigmas).
1.2. Para o diagrama de Pareto, a medida de Densidade de defeitos por tipo não
possui critério objetivo de decisão, sendo que as principais causas de desvio
devem ser prioritariamente tratadas.
 86

Interpretação do 1. O gráfico de controle u do exemplo acima apresenta aos responsáveis pela análise
indicador que os Builds 9, 10, 11, 12, 13, 15 e 18, apresentam sinais de desvio, já que
possuem valor fora dos limites de controle superior e inferior.
2. O Diagrama de Pareto do exemplo acima apresenta aos responsáveis pela análise
que as causas mais comuns de defeitos nos pacotes ou unidades de software são
Integração, seguida de Implementação, Projeto, Requisito, Banco de Dados e
Ambiente. Seguindo a regra de Pareto de que 20% das causas são responsáveis por
80% dos problemas, ações devem ser empregadas prioritariamente nos processo de
Integração, Implementação, Projeto e Requisito, pois estas serão mais efetivas na
melhoria da qualidade dos próximos pacotes ou unidades de software produzidas.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta da
de dados quantidade de defeitos totais do pacote ou unidade de software.
2. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta da
quantidade de defeitos por tipo do pacote ou unidade de software.
3. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta do
tamanho do pacote ou unidade de software.
Responsável O Analista de Testes coleta os dados de quantidade de defeitos e quantidade de defeitos
por tipo, o Analista de métricas obtém o dado de tamanho do pacote ou unidade de
software testado e consolida a informação das medidas.
Fase ou atividade de Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir durante a
coleta de dados fase de Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que os primeiros testes forem realizados nos pacotes ou unidades de
software até a implantação do produto. Opcionalmente, a medida pode permanecer
sendo coletada durante a operação ou garantia do produto em ambiente de produção.
Ferramentas 1. Ferramenta de registro de defeitos de testes
utilizadas para coleta 2. Ferramenta de registro de defeitos de testes
de dados 3.
3.1. Ferramenta de contagem de linhas de código
3.2. Ferramenta ou Relatório de análise de pontos de função
3.3. Ferramenta ou Lista de requisitos
Verificação e Auditorias dos registros de defeitos de testes e tamanho dos pacotes ou unidades de
Validação software.
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de A cada pacote ou unidade de software entregue ao Cliente (Build).
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir durante a
análise dos dados fase de Operação do ciclo de vida do produto: Os dados devem ser analisados a partir
do momento em que os primeiros testes forem realizados nos pacotes ou unidades de
software até a implantação do produto. Opcionalmente, a medida pode permanecer
sendo analisada durante a operação ou garantia do produto em ambiente de produção.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise A análise da evolução da Densidade de defeitos por tipo pode ser realizada avaliando-
adicional se os diferentes Diagramas de Pareto produzidos em cada mês de coleta.
 87

Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de

implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.5. Eficácia de revisões e testes

Descrição da necessidade de informação

Necessidade de Qual é a eficácia dos processos de revisão e testes realizados pela equipe do projeto,
informação em encontrar defeitos antes da entrega do produto ao Cliente?
Categoria de Qualidade
informação
Objetivo de medição
Avaliar o desempenho dos processos de revisão e testes realizados pela equipe do
Objetivo de medição projeto a partir da capacidade destes processos prevenirem a entrega de produtos
defeituosos ao Cliente.
Entidade e atributos
Entidades relevantes 1. Pacote ou unidade de software testado
2. Produto ou documento revisado
Atributos 1. Quantidade de defeitos
Especificação de medida básica
Medidas básicas 1. Quantidade de defeitos de testes internos
2. Quantidade de defeitos de testes externos
3. Quantidade de defeitos de revisão internos
4. Quantidade de defeitos de revisão externos
Métodos de medição 1. Contagem do número de defeitos encontrados pela equipe do projeto nos testes
unitários, integrados e de sistema realizados antes da entrega de um pacote ou
unidade de software.
2. Contagem do número de defeitos encontrados pelo cliente nos testes de aceitação
realizados em um pacote ou unidade de software entregues pelo projeto.
3. Contagem do número de defeitos encontrados pela equipe do projeto nas revisões
realizadas antes da entrega de documentos ou outros produtos do projeto ao
cliente.
4. Contagem do número de defeitos externos encontrados pelo cliente nas revisões
realizadas em documentos ou outros produtos entregues pelo projeto.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
4. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
3. Inteiros, de zero a infinito
4. Inteiros, de zero a infinito
Tipos de escalas 1. Absoluta
2. Absoluta
3. Absoluta
4. Absoluta
Unidade de medição 1. Defeitos
2. Defeitos
3. Defeitos
4. Defeitos
Especificação de medida derivada
Medidas derivadas 1. Eficácia de testes
2. Eficácia de revisão
 88

Função de medição
 Quant. de defeitos de testes internos 
1.   * 100
 Quant. de defeitos de testes internos + externos 
 Quant. de defeitos de revisão internos 
2.   * 100
 Quant. de defeitos de revisão internos + externos 
Especificação de indicador
Descrição do 1. Eficácia de testes: Este indicador apresenta na Figura 17 a razão entre a
indicador e amostra quantidade de defeitos encontrados pela equipe do projeto, nos testes internos, e o
total de defeitos encontrados, incluindo àqueles identificados pelo Cliente nos
testes de aceitação do sistema.

Figura 17: Eficácia de testes (XmR)

2. Eficácia de revisão: Este indicador apresenta na Figura 18 a razão entre a

quantidade de defeitos encontrados pela equipe do projeto, nas revisões internas, e
o total de defeitos encontrados, incluindo àqueles identificados pelo Cliente nas
revisões em produtos entregues pelo projeto.
 89

Figura 18: Eficácia de revisão (XmR)

Modelo de analise 1. A medida de Eficácia de Testes é apresentada em Gráficos de Controle X e mR

(XmR) com o objetivo de avaliar o desempenho dos processos de verificação e
validação do produto de software
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção2.3.5.4.
2. A medida de Eficácia de revisão é apresentada em Gráficos de Controle X e mR
(XmR) com o objetivo de avaliar o desempenho dos processos de verificação e
validação dos outros produtos entregues pelo projeto.
2.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4,
Critério de decisão 1. A medida de Eficácia de testes possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
2. A medida de Eficácia de revisão possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5.
Interpretação do O indicador de Eficácia de Testes do exemplo demonstrou desvio no mês de Maio/07 a
indicador partir da avaliação do gráfico X e nos meses de Maio e Junho/07 do gráfico mR. Em
todos estes pontos a execução do processo infringiu o Teste 1 proposto nos critérios de
decisão para o indicador.

Já o indicador de Eficácia de revisão do exemplo acima apresentou desvios para o

gráfico X nos meses de Abril e Maio/07 e Novembro e Dezembro/07. Nestas duas
ocasiões, 2 ou mais pontos consecutivos apresentaram desempenho além de 2 sigas da
linha central, caracterizando falha ao Teste 2 dos critérios de decisão. Já o gráfico mR
do mesmo indicador apresentou desvio no mês de Jun/07, tendo apresentado
desempenho superior ao limite de controle de 3 sigmas da Linha central (Teste 1).
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta da quantidade de defeitos internos dos pacotes ou unidades
de dados de software testados acumulados até o mês.
2. Mensalmente. Coleta da quantidade de defeitos externos dos pacotes ou unidades
de software testados pelo Cliente acumulados até o mês.
3. Mensalmente. Coleta da quantidade de defeitos internos de revisões realizadas pela
equipe do projeto acumulados até o mês.
4. Mensalmente. Coleta da quantidade de defeitos externos identificados nas
validações de produtos realizadas pelo Cliente acumulados até o mês.
Responsável 1. Analista de testes
2. Analista de testes
3. Gerente de projetos
4. Gerente de projetos
 90

Fase ou atividade de 1. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
coleta de dados durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
2. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
3. Durante todo o ciclo de vida do projeto.
4. Durante todo o ciclo de vida do projeto.
Ferramentas 1. Ferramenta de registro de defeitos de testes
utilizadas para coleta 2. Ferramenta de registro de defeitos de testes
de dados 3. Ferramenta de registro de defeitos de revisão
4. Ferramenta de registro de defeitos de revisão
Verificação e Auditorias dos registros de defeitos de testes e revisões realizadas pela equipe e Cliente
Validação do projeto.
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de 1. Mensalmente.
reporte dos dados 2. Mensalmente.
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de 1. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
análise dos dados durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
2. Durante todo o ciclo de vida do projeto.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e • Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do
usuário projeto)
• Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de
implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.
 91

3.3.4.6. Mudanças de escopo

Descrição da necessidade de informação

Necessidade de Qual é o nível de mudanças no escopo do projeto?
informação
Categoria de Escopo
informação
Objetivo de medição
Avaliar o volume de mudanças no escopo do projeto a fim de identificar situações de
Objetivo de medição
risco para execução do mesmo.
Entidade e atributos
Entidades relevantes Produtos do projeto
Atributos 1. Quantidade de mudanças
2. Tamanho
Especificação de medida básica
Medidas básicas 1. Quantidade de mudanças
2. Quantidade de requisitos que sofreram mudanças
3. Quantidade total de requisitos do projeto
4. Tamanho, sendo representado por:
4.1. Quantidade de linhas de código, ou
4.2. Quantidade de pontos de função, ou
4.3. Quantidade de requisitos
Métodos de medição 1. Contagem do número de solicitações de mudanças de qualquer tipo aprovadas para
o projeto no período
2. Contagem do número de requisitos do projeto afetados por solicitações de
mudança aprovadas no período. Caso um requisito seja afetado por duas
solicitações de mudanças diferentes, o mesmo é contado duas vezes.
3. Contagem do número total de requisitos do escopo do projeto.
4. Contagem do tamanho de um pacote ou unidade de software testado
4.1. Contagem da quantidade de linhas de código (SEI, 1992)
4.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
4.3. Contagem do número de requisitos funcionais do software.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
4. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
3. Inteiros, de zero a infinito
4.
4.1. Inteiros, de zero a infinito
4.2. Decimais, de zero a infinito
4.3. Inteiros, de zero a infinito
Tipos de escalas 1. Absoluta
2. Absoluta
3. Absoluta
4.
4.1. Absoluta
4.2. Razão
4.3. Absoluta
 92

Unidade de medição 1. Mudanças

2. Requisitos
3. Requisitos
4.
4.1. Linhas de código
4.2. Pontos de função
4.3. Requisitos
Especificação de medida derivada
Medidas derivadas 1. Taxa de mudanças
2. Volatilidade de requisitos
Função de medição Quantidade de mudanças
1.
Tamanho
Quantidade de requisitos que sofreram mudanças
2.
Quantidade total de requisitos do projeto
Especificação de indicador
Descrição do 1. Taxa de mudanças: Este indicador apresenta na Figura 19 a razão entre a
indicador e amostra quantidade de mudanças aprovadas no escopo do projeto e o tamanho do escopo
do projeto.

Figura 19: Taxa de mudanças (XmR)

2. Volatilidade de requisitos: Este indicador apresenta na Figura 20 a razão entre a

quantidade de requisitos que sofreram mudanças e o total de requisitos do projeto.
 93

Figura 20: Volatilidade de requisitos (XmR)

Modelo de analise 1. A medida de Taxa de mudanças é apresentada em Gráficos de Controle X e mR

(XmR) com o objetivo de avaliar a freqüência de mudanças no escopo do projeto
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
2. A medida de Volatilidade de requisitos é apresentada em Gráficos de Controle X e
mR (XmR) com o objetivo de avaliar o nível de instabilidade dos requisitos que
fazem parte do escopo do projeto.
2.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A medida de Taxa de mudanças possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
2. A medida de Volatilidade de requisitos possui como critérios de decisão as regras
de instabilidade de processo para cada um dos gráficos que representam o
indicador, conforme descrito na seção 2.3.5.5
Interpretação do 1. O gráfico de controle XmR da medida de Taxa de Mudanças não apresenta sinais
indicador de instabilidade de processo, já que o seu desempenho passa por todos os testes
previstos nos critérios de decisão.
2. O gráfico de controle XmR da medida de Volatilidade de requisitos apresenta sinal
desvio nos meses de Agosto, Setembro e Outubro de 2007. Neste período, o
desempenho do processo não passa no teste número 2 dos critérios de decisão, já
que apresenta 2 de três pontos consecutivos, além de 2 sigmas da linha central.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta da quantidade de mudanças aprovadas no mês.
de dados 2. Mensalmente. Coleta da quantidade de requisitos afetados por mudanças
aprovadas no mês.
3. Mensalmente. Coleta da quantidade total de requisitos do projeto.
4. Mensalmente. Coleta do tamanho total do escopo do projeto.
 94

Responsável O Analista de métricas obtém os dados de quantidade de mudanças e tamanho do

projeto.
Fase ou atividade de Durante todo o ciclo de vida do projeto.
coleta de dados
Ferramentas 1. Relatórios de controle de mudanças do projeto
utilizadas para coleta 2. Relatórios de controle de mudanças do projeto
de dados 3. Ferramenta ou lista de requisitos do projeto
4.
4.1. Ferramenta de contagem de linhas de código
4.2. Ferramenta ou Relatório de análise de pontos de função
4.3. Ferramenta ou Lista de requisitos
Verificação e Auditorias dos registros de mudanças e tamanho do projeto de software.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Mensalmente.
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida do projeto,
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável.
adicional
Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.7. Prazo de ciclo

Descrição da necessidade de informação

Necessidade de Qual é o prazo total para finalização do projeto de software?
informação
Categoria de Tempo
informação
Objetivo de medição
Avaliar o período de tempo total necessário para realização do projeto de software,
Objetivo de medição desde o início até o final do projeto com a entrega do produto no ambiente de produção
do cliente.
Entidade e atributos
Entidades relevantes Projeto
Atributos 1. Prazo
2. Tamanho
 95

Especificação de medida básica

Medidas básicas 1. Prazo de ciclo
2. Tamanho, sendo representado por:
2.1. Quantidade de linhas de código, ou
2.2. Quantidade de pontos de função, ou
2.3. Quantidade de requisitos
Métodos de medição 1. Quantidade de dias úteis contados a partir do início do projeto até a sua finalização
com a implantação do produto de software em ambiente de produção.
2. Contagem do tamanho de um pacote ou unidade de software testado
2.1. Contagem da quantidade de linhas de código (SEI, 1992)
2.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
2.3. Contagem do número de requisitos funcionais do software.
Tipos de métodos 1. Objetivo
2. Objetivo
Escala 1. Inteiros, de zero a infinito
2.
2.1. Inteiros, de zero a infinito
2.2. Decimais, de zero a infinito
2.3. Inteiros, de zero a infinito
Tipos de escalas 1. Razão
2.
2.1. Absoluta
2.2. Razão
2.3. Absoluta
Unidade de medição 1. Dias
2.
2.1. Linhas de código
2.2. Pontos de função
2.3. Requisitos
Especificação de medida derivada
Medidas derivadas 1. Prazo de ciclo relativo ao tamanho
Função de medição Prazo de ciclo
1.
Tamanho
Especificação de indicador
Descrição do 1. Prazo de ciclo: Este indicador apresenta o prazo total para desenvolvimento do
indicador e amostra projeto, conforme apresentado na Figura 21.

Figura 21: Prazo de ciclo (barras)

2. Prazo de ciclo relativo ao tamanho: Este indicador apresenta a relação entre o

 96

prazo de total para desenvolvimento do projeto e o seu tamanho, conforme

apresentado na Figura 22.

Figura 22: Prazo de ciclo relativo ao tamanho (XmR)

Modelo de analise 1. A medida de Prazo de ciclo é apresentada em um gráfico temporal de freqüência

mensal, onde cada mês identifica a duração total para conclusão do projeto. A
medida deve ser comparada em relação ao limite de especificação (linha
pontilhada), que representa o prazo total aprovado no planejamento do projeto.
Observações da medida superiores ao limite de especificação indicam que o prazo
de ciclo é maior do que o previsto e, portanto ações devem ser tomadas.
2. A medida de Prazo de ciclo relativo ao tamanho é apresentada em Gráficos de
Controle X e mR (XmR):
2.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A avaliação do gráfico de barras da medida de Prazo de ciclo possui como critério
de decisão que caso uma observação da medida apresente valor superior ao limite
de especificação, esta deve ser tratada como desvio, sendo identificadas as causas e
executadas ações para resolução.
2. A medida de Prazo de ciclo relativo ao tamanho é apresentada em gráfico XmR.
2.1. As representações no gráfico de controle XmR possuem como critérios de
decisão as regras de instabilidade de processo para cada um dos gráficos que
representam o indicador, conforme descrito na seção 2.3.5.5
 97

Interpretação do 1. O gráfico do indicador de Prazo de ciclo mostrado no exemplo apresenta desvio

indicador em relação ao limite de especificação nos meses de Fevereiro e Março de 2008,
onde o histórico do projeto apontava para um prazo de ciclo maior do que o prazo
planejado para o projeto (limite de especificação). Devem ser identificadas as
causas dos desvios e ações gerenciais necessitam ser realizadas para evitar falhas
no atendimento aos objetivos de prazo do projeto.
2. O gráfico X do indicador de Prazo de ciclo relativo ao tamanho apresenta desvios
nos meses de Janeiro a Abril de 2008, pois 4 valores consecutivos encontram-se a
mais de +2 sigmas da linha central (Teste 2). Neste mesmo gráfico, os valores da
medida de Maior a Julho de 2008 demonstram que o processo permaneceu
instável, já que estes pontos estão distantes a menos e -3sigmas da linha central
(Teste 1).
3. O gráfico mR do Prazo de ciclo relativo ao tamanho apresenta desvio no mês de
Maio de 2008 onde ocorreu uma considerável alteração no perfil de execução do
processo, com amplitude móvel maior do que +3sigmas da linha central.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Estimativa de prazo total para término do projeto, baseado no
de dados desempenho realizado nas fases anteriores.
2. Mensalmente. Coleta do tamanho do produto de software.
Responsável O Gerente do projeto obtém os dados de prazos a partir do cronograma do projeto.
O Analista de métricas obtém os dados de tamanho.
Fase ou atividade de Durante todo o ciclo de vida do projeto.
coleta de dados
Ferramentas 1. Ferramentas de gerenciamento do cronograma.
utilizadas para coleta 2. Ferramenta ou Relatório de análise de pontos de função.
de dados
Verificação e Auditorias dos registros de prazos e tamanho do projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de 1. Mensalmente.
reporte dos dados 2. Mensalmente.

Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)

• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida do projeto.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização (Painel de controle de indicadores).
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • O indicador de Prazo de ciclo não é adequado para aplicação de técnicas de
implementação controle estatístico de processos, pois o valor absoluto da medida de prazo varia
significativamente para cada projeto, sendo diretamente relacionada ao seu escopo.
Para aplicação de técnicas de gerenciamento quantitativo, sugere-se o uso da
medida de Prazo de ciclo relativo ao tamanho.
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.
 98

3.3.4.8. Prazo médio para a falha

Descrição da necessidade de informação

Necessidade de Quanto tempo o produto de software fica em operação antes da primeira falha ser
informação identificada?
Categoria de Qualidade
informação
Objetivo de medição
Avaliar o nível de qualidade do produto de software entregue a partir da quantidade de
Objetivo de medição
tempo em que este permanece em operação sem apresentar falhas.
Entidade e atributos
Entidades relevantes Atividades do cronograma
Atributos 1. Prazo (duração)
Especificação de medida básica
Medidas básicas 1. Prazo médio para a falha
Métodos de medição 1. Duração em quantidade de dias úteis do cronograma do projeto, contados a partir
da entrega do pacote ou unidade de software (Build), até a data em que a primeira
falha é identificada pelo cliente no ambiente de produção.
Tipos de métodos 1. Objetivo
Escala 1. Inteiros, de zero a infinito
Tipos de escalas 1. Razão
Unidade de medição 1. Dias
Especificação de medida derivada
Medidas derivadas Não aplicável
Função de medição Não aplicável
Especificação de indicador
Descrição do 1. Prazo médio para a falha: Este indicador apresenta na Figura 23, para cada Build
indicador e amostra de software entregue, a quantidade de dias úteis decorridos desde a entrega do
pacote ou componente de software até a identificação da primeira falha em
ambiente de produção.

Figura 23: Prazo médio para a falha (XmR)

Modelo de analise 1. A medida de Prazo médio para a falha é apresentada em Gráficos de Controle X e
mR (XmR):
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
 99

gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais

do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A medida de Prazo médio para a falha possui como critérios de decisão as regras
de instabilidade de processo para cada um dos gráficos que representam o
indicador, conforme descrito na seção 2.3.5.5
Interpretação do 1. O gráfico de controle mR da medida de Prazo médio para a falha do exemplo
indicador acima apresenta um desvio em relação ao Teste 1 dos critérios de decisão, para a
medida coletada no Build 8. Neste caso, o gráfico mR demonstra que a amplitude
móvel entre o Build 7 e 8 é superior a 3 sigmas da média (linha central), e portanto
as causas devem ser identificadas para manter o desempenho do processo.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta da
de dados quantidade de dias úteis decorridos da entrega do Build até a identificação da
primeira falha pelo Cliente.
Responsável O Analista de testes obtém o prazo médio para a falha.
Fase ou atividade de Nas fases de Transição do ciclo de vida do projeto e prosseguir durante a fase de
coleta de dados Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que pacotes ou unidades de software sejam entregues ao cliente até a
implantação do produto. Opcionalmente, a medida pode permanecer sendo coletada
durante a operação ou garantia do produto em ambiente de produção.
Ferramentas 1. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
utilizadas para coleta esforço.
de dados
Verificação e Auditorias nos prazos do cronograma do projeto, registrados pelo Gerente do Projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados

Procedimento de análise de dados (para cada indicador)

Freqüência de A cada pacote ou unidade de software entregue ao Cliente (Build).
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Nas fases de Transição do ciclo de vida do projeto e prosseguir durante a fase de
análise dos dados Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que pacotes ou unidades de software sejam entregues ao cliente até a
implantação do produto. Opcionalmente, a medida pode permanecer sendo coletada
durante a operação ou garantia do produto em ambiente de produção.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável.
adicional
Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de
implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.
 100

3.3.4.9. Produtividade

Descrição da necessidade de informação

Necessidade de • Qual é a produtividade do processo de desenvolvimento de software em prática na
informação organização?
• Qual é a capacidade de entrega das equipes executando o processo de
desenvolvimento em prática na organização?
Categoria de Produtividade
informação
Objetivo de medição
Avaliar a produtividade e capacidade de entregas do processo de desenvolvimento de
Objetivo de medição
software em prática frente aos objetivos da organização.
Entidade e atributos
Entidades relevantes 1. Pacote ou unidade de software
2. Atividades do cronograma
Atributos 1. Tamanho
2. Esforço
3. Prazo
Especificação de medida básica
Medidas básicas 1. Tamanho, representando por:
1.1. Quantidade de linhas de código, ou
1.2. Quantidade de pontos de função, ou
1.3. Quantidade de requisitos
2. Esforço realizado
3. Prazo realizado
Métodos de medição 1. Contagem do tamanho real de um pacote ou unidade de software.
1.1. Contagem da quantidade de linhas de código (SEI, 1992)
1.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
1.3. Contagem do número de requisitos funcionais do software.
2. Quantidade de horas de esforço total realizadas para desenvolvimento do pacote ou
unidade de software.
3. Duração em quantidade de horas, dias ou meses realizada para desenvolvimento do
pacote ou unidade de software.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
Escala 1.
1.1. Inteiros, de zero a infinito
1.2. Decimais, de zero a infinito
1.3. Inteiros, de zero a infinito
2. Decimais, de zero a infinito
3. Decimais, de zero a infinito
Tipos de escalas 1.
1.1. Absoluta
1.2. Razão
1.3. Absoluta
2. Razão
3. Razão
Unidade de medição 1.
1.1. Linhas de código
1.2. Pontos de função
1.3. Requisitos
2. Horas
3. Horas, dias ou meses
 101

Especificação de medida derivada

Medidas derivadas 1. Produtividade
2. Taxa de entrega
Função de medição Esforço realizado
1.
Tamanho
Tamanho
2.
Prazo realizado
Especificação de indicador
Descrição do 1. Produtividade: Este indicador apresenta na Figura 24 a produtividade do processo
indicador e amostra de desenvolvimento de software a partir da razão entre o esforço realizado no
desenvolvimento de um pacote ou unidade de software e o escopo (tamanho) real
do pacote ou unidade de software desenvolvido.

Figura 24: Produtividade (XmR)

2. Taxa de entrega: Este indicador apresenta na Figura 25 a capacidade de entrega

do processo de desenvolvimento de software por período de tempo, a partir da
razão entre o escopo (tamanho) real do pacote ou unidade de software entregue e o
prazo para desenvolvimento deste.
 102

Figura 25: Taxa de entrega (PF/mês) (XmR)

Modelo de analise 1. As medidas de Produtividade e Taxa de entrega são apresentadas em Gráficos de

Controle X e mR (XmR) com o objetivo de avaliar a estabilidade do processo de
desenvolvimento de software.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4

As medidas de Produtividade e Taxa de entrega devem ser analisadas separadamente,

conforme apresentado acima, e em conjunto já que um processo produtivo que realize
muito escopo (ex.: pontos de função) com pequena quantidade de esforço (horas), pode
não atender a quantidade de entregas por período (Taxa de entregas) necessário para
um determinado projeto. Sendo assim, a relação entre as medições não é diretamente
proporcional e para avaliar com segurança o desempenho do processo de
desenvolvimento de software, ambas devem ser constantemente avaliadas.
Critério de decisão 1. As medidas Produtividade e Taxa de Entrega possuem como critérios de decisão as
regras de instabilidade de processo para cada um dos gráficos que representam o
indicador, conforme descrito na seção 2.3.5.5
Interpretação do Os gráficos de controle XmR do exemplo acima apresentam aos responsáveis pela
indicador análise que:
• A observação de Taxa de entrega (gráfico X) do Build 1 excedeu o limite
superior de 3 sigmas e portanto não atendeu ao Teste 1. Neste mesmo Build, a
Produtividade demonstra desempenho adequado. Neste caso, o prazo para
desenvolvimento do Build 1 (Taxa de entrega) foi elevado em relação à média
de desempenho da organização, porém o esforço realizado foi adequado
 103

(Produtividade). É possível concluir que poucos recursos foram atribuídos ao

projeto no desenvolvimento deste Build, de forma que o prazo foi elevado,
mas o esforço gasto foi adequado.
• A observação de Produtividade (gráfico X) do Build 5 excedeu o limite
superior de 3 sigmas e portanto não atendeu ao Teste 1. Neste mesmo Build, a
Taxa de entrega demonstra desempenho adequado, inferior á linha central da
linha de base do processo. É possível concluir que mais recursos foram
atribuídos ao projeto neste momento, de forma que foi possível desenvolver o
produto em prazo inferior, porém através de um esforço elevado.

Estes sinais demonstram que o processo pode estar fora de controle e deve então ser
analisado criticamente para identificar as causas de variação ações para correção.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Após entrega de um pacote ou unidade de software (Build).
de dados 2. Após entrega de um pacote ou unidade de software (Build).
3. Após entrega de um pacote ou unidade de software (Build).
Responsável • O Analista de métricas realiza contagem do tamanho do pacote ou unidade de
software, do esforço e prazo realizado.
• O Gerente do Projeto consolida as informações das medidas.
Fase ou atividade de Durante todo o ciclo de vida, para as fases onde sejam entregues pacotes ou unidades
coleta de dados de software (Build)
Ferramentas 1. Ferramenta de registro do tamanho do escopo do projeto.
utilizadas para coleta 2. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
de dados esforço.
3. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
esforço.
Verificação e Revisões e auditorias nas contagens de tamanho realizadas e nos registros de esforço e
Validação prazos do projeto.
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de 1. Ao final de cada fase, para as fases onde ocorre entrega de um pacote ou unidade
reporte dos dados de software (Build).
2. Ao final de cada fase, para as fases onde ocorre entrega de um pacote ou unidade
de software (Build).
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida, para as fases onde ocorre entrega de um pacote ou
análise dos dados unidade de software (Build).
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização (Painel de controle de indicadores).
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.
 104

3.3.4.10. Reuso de código

Descrição da necessidade de informação

Necessidade de Quanto do produto de software foi desenvolvido a partir de código reutilizado?
informação
Categoria de Escopo
informação
Objetivo de medição
Objetivo de medição Avaliar o percentual de código reutilizado dentro do produto de software desenvolvido.
Entidade e atributos
Entidades relevantes Pacote ou unidade de software
Atributos 1. Tamanho
Especificação de medida básica
Medidas básicas 1. Quantidade de linhas de código reutilizadas
2. Quantidade total de linhas de código
Métodos de medição 1. Contagem da quantidade de linhas de código dos componentes de software
reutilizados no pacote ou unidade de software (SEI, 1992)
2. Contagem da quantidade total de linhas de código do pacote ou unidade de
software (SEI, 1992).
Tipos de métodos 1. Objetivo
2. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
Tipos de escalas 1. Absoluta
2. Absoluta
Unidade de medição 1. Linhas de código
2. Linhas de código
Especificação de medida derivada
Medidas derivadas 1. Reuso de código
Função de medição  Quantidade de linhas de código reutilizadas 
1.   *100
 Quantidade total de linhas de código 
Especificação de indicador
Descrição do 1. Reuso de código: Este indicador apresenta na Figura 26, para cada Build de
indicador e amostra software entregue, o percentual de linhas de código reutilizadas em relação à
quantidade total de linhas de código do produto ou unidade de software construído.

Figura 26: Reuso de código (XmR)

 105

Modelo de analise 1. A medida de Reuso de código é apresentada em Gráficos de Controle X e mR

(XmR):
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A medida de Reuso de código possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
Interpretação do 1. Os gráficos de controle X e mR da medida de Reuso de código do exemplo acima
indicador apresentam desvios nas medições coletadas a partir do Build 6. Estas observações
da medida falham aos testes 2 e 3 dos critérios de decisão, já que apresentam 7
pontos consecutivos acima de 1 sigma da linha central, sendo 5 deles acima de 2
sigmas. Neste caso é necessário avaliar a necessidade de redefinir a linha de base
do processo, pois a medição indica que houve uma mudança no desempenho do
processo de reuso (positiva neste caso).
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta da
de dados quantidade de linhas de código em componentes reutilizados no pacote ou unidade
de software.
2. A cada pacote ou unidade de software entregue ao Cliente (Build). Coleta da
quantidade de linhas de código total do pacote ou unidade de software.
Responsável O Analista de métricas obtém os dados de quantidade de linhas de código.
Fase ou atividade de Nas fases de Transição do ciclo de vida do projeto e prosseguir durante a fase de
coleta de dados Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que pacotes ou unidades de software sejam entregues ao cliente até a
implantação do produto. Opcionalmente, a medida pode permanecer sendo coletada
durante a operação ou garantia do produto em ambiente de produção.
Ferramentas 1. Ferramenta de contagem de linhas de código
utilizadas para coleta 2. Ferramenta de contagem de linhas de código
de dados
Verificação e Auditorias dos registros de tamanho do projeto de software.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de A cada pacote ou unidade de software entregue ao Cliente (Build).
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Nas fases de Transição do ciclo de vida do projeto e prosseguir durante a fase de
análise dos dados Operação do ciclo de vida do produto: Os dados devem ser coletados a partir do
momento em que pacotes ou unidades de software sejam entregues ao cliente até a
implantação do produto. Opcionalmente, a medida pode permanecer sendo coletada
durante a operação ou garantia do produto em ambiente de produção.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
 106

Informação adicional
Guia de análise Este indicador é simples e fácil de coletar, porém ele pode acarretar em conclusões
adicional incorretas sobre o total de reuso do sistema. Esta limitação da medida deve-e ao fato de
que a medida básica de “Quantidade de linhas de código reutilizadas” é igual ao total
de linhas de códigos dos componentes reutilizados. Sendo assim, mesmo nos casos
onde apenas parte do componente (algumas funções ou métodos) tenha sido
efetivamente reutilizada, todas as linhas de código serão contabilizadas e portanto o
cálculo da medida derivada resultará em um valor impreciso (POULIN e CARUSO,
apud MASCENA, DE ALMEIDA E DE LEMOS MEIRA, 2005, p. 74).
Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de
implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.11. Taxa de remoção de defeitos

Descrição da necessidade de informação

Necessidade de Qual é a eficiência dos processos técnicos na resolução dos defeitos identificados nos
informação testes do produto de software?
Categoria de Qualidade
informação
Objetivo de medição
Avaliar o desempenho dos processos na resolução dos defeitos identificados durante os
Objetivo de medição
testes do produto de software.
Entidade e atributos
Entidades relevantes 1. Pacote ou unidade de software testado
Atributos 1. Quantidade de defeitos
Especificação de medida básica
Medidas básicas 1. Quantidade de defeitos de testes abertos
2. Quantidade de defeitos de testes fechados
Métodos de medição 1. Contagem do número de defeitos encontrados pela equipe e Cliente do projeto nos
testes unitários, integrados e de sistema realizados em um pacote ou unidade de
software.
2. Contagem do número de defeitos corrigidos pela equipe do projeto em um pacote
ou unidade de software.
Tipos de métodos 1. Objetivo
2. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
Tipos de escalas 1. Absoluta
2. Absoluta
Unidade de medição 1. Defeitos
2. Defeitos
Especificação de medida derivada
Medidas derivadas 1. Taxa de remoção de defeitos
Função de medição Quant. de defeitos de testes fechados
1.
Quant. de defeitos de testes abertos
Especificação de indicador
Descrição do 1. Taxa de remoção de defeitos: Este indicador apresenta na Figura 27 a razão entre
indicador e amostra a quantidade de defeitos resolvidos (fechados) pela equipe do projeto e a
quantidade de defeitos novos encontrados (abertos) nos testes internos e externos
do sistema.
 107

Figura 27: Taxa de remoção de defeitos (XmR)

Modelo de analise 1. A medida de Taxa de remoção de defeitos é apresentada em Gráficos de Controle

X e mR (XmR) com o objetivo de avaliar o desempenho dos processos de técnicos
do projeto.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A medida de Taxa de remoção de defeitos possui como critérios de decisão as
regras de instabilidade de processo para cada um dos gráficos que representam o
indicador, conforme descrito na seção 2.3.5.5
Interpretação do O indicador Taxa de remoção de defeitos do exemplo demonstrou desvio em relação
indicador aos limites de controle do gráfico X nos período de Setembro a Dezembro/2007. Nestes
pontos a execução do processo infringiu os Testes 2 e 3 propostos nos critérios de
decisão para o indicador.

A instabilidade descrita acima demonstra que o processo a partir deste período tende a
apresentar desempenho satisfatório, com taxa de remoção de defeitos maior do que 1.
Caso este desempenho seja mantido é importante re-estabelecer a linha de base do
processo.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta da quantidade de defeitos identificados (abertos) no mês.
de dados 2. Mensalmente. Coleta da quantidade de defeitos resolvidos (fechados) no mês.
Responsável 1. Analista de testes
2. Analista de testes
 108

Fase ou atividade de 1. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
coleta de dados durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
2. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
Ferramentas 1. Ferramenta de registro de defeitos de testes
utilizadas para coleta 2. Ferramenta de registro de defeitos de testes
de dados
Verificação e Auditorias dos registros de defeitos de testes realizados no projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de 1. Mensalmente.
reporte dos dados
Responsável • Analista de testes do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de 1. Nas fases de Construção e Transição do ciclo de vida do projeto e prosseguir
análise dos dados durante a fase de Operação do ciclo de vida do produto: Os dados devem ser
coletados a partir do momento em que os primeiros testes forem realizados nos
pacotes ou unidades de software até a implantação do produto. Opcionalmente, a
medida pode permanecer sendo coletada durante a operação ou garantia do
produto em ambiente de produção.
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e • Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do
usuário projeto)
• Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • Fase ou atividade do ciclo de vida: A organização deve adaptar o momento de
implementação coleta e análise dos dados do indicador de acordo com as fases e atividades
definidas no modelo de ciclo de vida em prática nos projetos (Ex.: Cascata ou
iterativo).
• Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.12. Taxa de retrabalho

Descrição da necessidade de informação

Necessidade de O quanto de retrabalho está sendo realizado no projeto, decorrente da baixa qualidade
informação do produto entregue?
Categoria de Qualidade
informação
 109

Objetivo de medição
Avaliar o desempenho dos processos técnicos de desenvolvimento de software através
Objetivo de medição da quantidade de retrabalho necessário para solucionar falhas de qualidade do produto
resultante da execução destes processos.
Entidade e atributos
Entidades relevantes Atividades do cronograma
Atributos 1. Esforço de retrabalho
2. Esforço total
Especificação de medida básica
Medidas básicas 1. Esforço de retrabalho total
2. Esforço de retrabalho por disciplina
3. Esforço total do projeto
Métodos de medição 1. Quantidade de horas totais despendidas em atividades de retrabalho. Atividades de
correção de defeitos em produtos já finalizados e entregues pelo projeto ao Cliente.
2. Quantidade de horas despendidas em atividades de retrabalho para cada disciplina
da Engenharia de Software. Atividades de correção de defeitos em produtos de
determinada disciplina da Engenharia de Software já finalizados e entregues pelo
projeto ao Cliente.
3. Quantidade de horas de esforço total do projeto.
Tipos de métodos 1. Objetivo
2. Objetivo
3. Objetivo
Escala 1. Decimais, de zero a infinito
2. Decimais, de zero a infinito
3. Decimais, maior do que zero a infinito
Tipos de escalas 1. Razão
2. Nominal
3. Razão
Unidade de medição 1. Horas
2. Horas
3. Horas
Especificação de medida derivada
Medidas derivadas 1. Taxa de retrabalho total
2. Taxa de retrabalho por disciplina
Função de medição Esforço de retrabalho total
1.
Esforço total do projeto
Esforço de retrabalho por disciplina
2.
Esforço total do projeto
Especificação de indicador
Descrição do 1. Taxa de retrabalho: Este indicador apresenta na Figura 28 a razão entre o esforço
indicador e amostra de retrabalho realizado para ajuste dos produtos do projeto em relação ao esforço
total despendido no projeto. O indicador apresenta na Figura 29 também a
classificação da taxa de retrabalho por disciplina da Engenharia de Software,
auxiliando na priorização de ações gerenciais.
 110

Figura 28: Taxa de retrabalho total (XmR)

Figura 29: Taxa de retrabalho por disciplina (Pareto)

Modelo de analise 1. A medida de Taxa de retrabalho total é apresentada em Gráficos de Controle X e

mR (XmR) com o objetivo de avaliar a estabilidade do processo de
desenvolvimento de software em relação à qualidade do produto gerado.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
2. A medida de Taxa de retrabalho por disciplina é apresentada em um Diagrama de
Pareto. Este diagrama apresenta as disciplinas ordenadas decrescentemente de
acordo com a sua taxa de retrabalho. O objetivo do diagrama de Pareto é apoiar a
priorização de ações para resolução das disciplinas que apresentam a maior taxa de
 111

retrabalho.
Critério de decisão 1. A medida de Taxa de retrabalho total possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
2. A medida de Taxa de retrabalho por disciplina não possui critério objetivo de
decisão, sendo que as disciplinas de maior taxa de retrabalho devem ser
prioritariamente tratadas.
Interpretação do Os gráficos de controle XmR do exemplo acima apresentam aos responsáveis pela
indicador análise que o processo de desenvolvimento gerou produtos com nível de qualidade
estável durante todo o período de análise, sem ter infringido nenhum dos testes de
instabilidade.

O Diagrama de Pareto do exemplo acima apresenta aos responsáveis pela análise que
as disciplinas de maior taxa de retrabalho são Requisitos, Modelagem de negócios,
Implementação e Análise e projeto, nesta ordem. Seguindo a regra de Pareto de que
20% das causas são responsáveis por 80% dos problemas, ações devem ser empregadas
prioritariamente no processo de Requisitos, pois estas serão mais efetivas na melhoria
da qualidade e redução do retrabalho nos próximos meses.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta da quantidade horas despendidas em atividades de
de dados retrabalho e no total de horas despendidas no mês.
2. Mensalmente. Coleta da taxa de retrabalho por disciplinas a partir das
atividades de ajustes de cada disciplina realizada no mês.
3. Mensalmente. Coleta da quantidade de horas totais despendidas no projeto no
mês.
Responsável A equipe de projeto realiza coleta do esforço realizado nas atividades do projeto, o
Gerente do Projeto consolida as informações das medidas.
Fase ou atividade de Durante todo o ciclo de vida.
coleta de dados
Ferramentas 1. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro
utilizadas para coleta de esforço.
de dados 2. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro
de esforço.
3. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro
de esforço.
Verificação e Auditorias dos registros de esforço realizado pela equipe nas atividades do projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Mensalmente.
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise A análise da evolução da Taxa de retrabalho por disciplina pode ser realizada
adicional avaliando-se os diferentes Diagramas de Pareto produzidos em cada mês de coleta. Ou
então plotando as medidas por disciplina individualmente em gráficos de controle.
 112

Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de

implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.13. Variação de esforço

Descrição da necessidade de informação

Necessidade de O esforço do projeto está sendo despendido de acordo com o planejamento?
informação
Categoria de Esforço
informação
Objetivo de medição
Avaliar a precisão do processo de planejamento dos projetos e identificar sinais de
Objetivo de medição
desvios a partir da quantidade de esforço realizada nos projetos.
Entidade e atributos
Entidades relevantes Atividades do cronograma
Atributos 1. Esforço
Especificação de medida básica
Medidas básicas 1. Esforço planejado
2. Esforço real
Métodos de medição 1. Quantidade de horas totais planejadas no cronograma do projeto, de acordo com a
linha de base do cronograma e plano de projeto aprovado.
2. Quantidade de horas de esforço total realizados no projeto.
Tipos de métodos 1. Subjetivo
2. Objetivo
Escala 1. Inteiros, maior do que zero a infinito
2. Inteiros, maior do que zero a infinito
Tipos de escalas 1. Razão
2. Razão
Unidade de medição 1. Horas
2. Horas
Especificação de medida derivada
Medidas 1. Variação de esforço total
derivadas 2. Variação de esforço por disciplina
Função de
 Esforço realizado total - Esforço planejado total 
medição 1.   * 100
 Esforço planejado total 
 Esforço realizado por disciplina - Esforço planejado por disciplina 
2.   * 100
 Esforço planejado por disciplina 
Especificação de indicador
Descrição do 1. Variação de esforço: Este indicador apresenta na Figura 30 a razão entre o
indicador e amostra esforço realizado durante a execução das atividades do projeto e o esforço
planejado na linha de base do projeto. O indicador apresenta na Figura 31 também
a classificação da variação de esforço por disciplina da Engenharia de Software,
auxiliando na priorização de ações gerenciais.
 113

Figura 30: Variação de esforço total (XmR)

Variação de esforço por

disciplina (Pareto)
10,00%

5,00%

0,00%

-5,00%

-10,00%

-15,00%

Figura 31: Variação de esforço por disciplina (Pareto)

Modelo de analise 1. A medida de Variação de esforço total é apresentada em Gráficos de Controle X e

mR (XmR) com o objetivo de avaliar a estabilidade do processo de
desenvolvimento de software em relação ao esforço realizado nas atividades do
projeto.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
2. A medida de Variação de esforço por disciplina é apresentada em um Diagrama de
Pareto. Este diagrama apresenta as disciplinas ordenadas decrescentemente de
acordo com a sua variação de esforço. O objetivo do diagrama de Pareto é apoiar
a priorização de ações para resolução das disciplinas que apresentam a maior
variação de esforço.
 114

Critério de decisão 1. A medida Variação de esforço total possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
2. A medida de Variação de esforço por disciplina não possui critério objetivo de
decisão, sendo que as disciplinas de maior variação de esforço devem ser
prioritariamente tratadas.
Interpretação do Os gráficos de controle XmR do exemplo acima apresentam aos responsáveis pela
indicador análise que a observação de variação de esforço do mês de Julho/2007 excedeu o limite
superior de 3 sigmas e, portanto não passou no Teste 1. Este sinal sinaliza que o
processo pode estar fora de controle e deve então ser analisado criticamente para
identificar as causas de variação ações para correção.

O Diagrama de Pareto do exemplo acima apresenta aos responsáveis pela análise que a
disciplina de maior variação de esforço é Ambiente, seguido das disciplinas de
Gerenciamento de projetos, Requisitos, Gerenciamento de configuração e mudanças,
Modelagem de negócios e Testes, nesta ordem. O diagrama mostra também que as
disciplinas de Análise e projeto, Implantação e Implementação possuem variação de
esforço negativo, tendo realizado esforço menor do que o planejado. Seguindo a regra
de Pareto de que 20% das causas são responsáveis por 80% dos problemas, ações
devem ser empregadas prioritariamente no processo de planejamento e execução da
disciplina de Ambiente, pois será mais efetivo na redução da variação de esforço nos
próximos meses.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta da quantidade horas planejadas para realização em atividades
de dados do projeto no mês.
2. Mensalmente. Coleta da quantidade horas despendidas em atividades do projeto no
mês.
Responsável A equipe de projeto realiza coleta do esforço realizado nas atividades do projeto, o
Gerente do Projeto coleta as informações do esforço planejado do cronograma e
consolida as informações das medidas.
Fase ou atividade de Durante todo o ciclo de vida.
coleta de dados
Ferramentas 1. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
utilizadas para coleta esforço.
de dados 2. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
esforço.
Verificação e Auditorias dos registros de esforço realizado pela equipe nas atividades do projeto.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Mensalmente.
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise A análise da evolução da Variação de esforço por disciplina pode ser realizada
adicional avaliando-se os diferentes Diagramas de Pareto produzidos em cada mês de coleta. Ou
então plotando as medidas por disciplina individualmente em gráficos de controle.
 115

Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de

implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.14. Variação de prazo

Descrição da necessidade de informação

Necessidade de O prazo do projeto está sendo atendido de acordo com o planejamento?
informação
Categoria de Tempo
informação
Objetivo de medição
Avaliar a precisão do processo de planejamento dos projetos e identificar sinais de
Objetivo de medição
desvios a partir da do prazo realizado nos projetos.
Entidade e atributos
Entidades relevantes Atividades do cronograma
Atributos 1. Prazo (duração)
Especificação de medida básica
Medidas básicas 1. Prazo planejado
2. Prazo real
Métodos de medição 1. Duração em quantidade de dias úteis planejadas no cronograma do projeto, de
acordo com a linha de base do cronograma e plano de projeto aprovado.
2. Duração em quantidade de dias úteis realizado no projeto.
Tipos de métodos 1. Subjetivo
2. Objetivo
Escala 1. Inteiros, de zero a infinito
2. Inteiros, de zero a infinito
Tipos de escalas 1. Razão
2. Razão
Unidade de medição 1. Dias
2. Dias
Especificação de medida derivada
Medidas 1. Variação de prazo total
derivadas 2. Variação de prazo por disciplina
Função de   Prazo realizado da atividade − Prazo planejado da atividade  
medição ∑    *100 
1.
 Prazo planejado da atividade  
Quantidade de atividades
  Prz. realizado da atv. da disc. − Prz. planejado da atv. da disc.  
∑    *100 
2.
 Prz planejado da atv da disciplina  
Quantidade de atividades da disciplina
Especificação de indicador
Descrição do 1. Variação de prazo: Este indicador apresenta na Figura 32 a razão entre o prazo
indicador e amostra realizado durante a execução das atividades do projeto em relação ao prazo
planejado na linha de base do projeto. O indicador apresenta na Figura 33 também
a classificação da variação de prazo por disciplina da Engenharia de Software,
auxiliando na priorização de ações gerenciais.
 116

Figura 32: Variação de prazo total (XmR)

Variação de prazo por disciplina

(Pareto)
Julho/2007
80,00%
60,00%
40,00%
20,00%
0,00%
-20,00%

Figura 33: Variação de prazo por disciplina (Pareto)

Modelo de analise 1. A medida de Variação de prazo total é apresentada em Gráficos de Controle X e

mR (XmR) com o objetivo de avaliar a estabilidade do processo de
desenvolvimento de software em relação ao prazo realizado nas atividades do
projeto.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
2. A medida de Variação de prazo por disciplina é apresentada em um Diagrama de
Pareto. Este diagrama apresenta as disciplinas ordenadas decrescentemente de
acordo com a sua variação de prazo. O objetivo do diagrama de Pareto é apoiar a
priorização de ações para resolução das disciplinas que apresentam a maior
variação de prazo.
 117

Critério de decisão 1. A medida Variação de prazo total possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
conforme descrito na seção 2.3.5.5
2. A medida de Variação de prazo por disciplina não possui critério objetivo de
decisão, sendo que as disciplinas de maior variação de prazo devem ser
prioritariamente tratadas.
Interpretação do Os gráficos de controle XmR do exemplo acima apresentam aos responsáveis pela
indicador análise que a observação de variação de prazo dos meses de Julho/2007 (gráficos X e
mR) e Agosto/2007 (gráfico mR) excederam o limite superior de 3 sigmas e, portanto
não passaram no Teste 1. Estes sinais demonstram que o processo pode estar fora de
controle e deve então ser analisado criticamente para identificar as causas de variação
ações para correção.

O Diagrama de Pareto do exemplo acima apresenta aos responsáveis pela análise que a
disciplina de maior variação de prazo no mês de Julho/2007 é Requisitos, seguida das
disciplinas de Análise e projeto, Modelagem de negócios, Implementação e Testes,
nesta ordem. O diagrama mostra também que as disciplinas de Ambiente,
Gerenciamento de configuração e mudanças, Implantação e Gerenciamento de projetos
possuem variação de prazo negativo, tendo realizado suas atividades em prazo inferior
ao. Sendo assim, para tratar o sinal de desvio apresentado no mês de Julho/2007, ações
devem ser empregadas prioritariamente na disciplina de Requisitos, pois será mais
efetivo na redução da variação de prazo nos próximos meses.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Mensalmente. Coleta do prazo (em dias úteis) planejada para as atividades do
de dados projeto concluídas no mês.
2. Mensalmente. Coleta do prazo (em dias úteis) real para as atividades do projeto
concluídas no mês.
Responsável O Gerente do Projeto coleta as informações do prazo planejado e realizado no
cronograma e consolida as informações das medidas.
Fase ou atividade de Durante todo o ciclo de vida.
coleta de dados
Ferramentas 1. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
utilizadas para coleta esforço.
de dados 2. Ferramenta de gerenciamento de cronograma, alocação de recursos e registro de
esforço.
Verificação e Auditorias nos prazos planejado e realizado das atividades do cronograma do projeto,
Validação registrados pelo Gerente do Projeto.
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Mensalmente.
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida.
análise dos dados
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise A análise da evolução da Variação de prazo por disciplina pode ser realizada
adicional avaliando-se os diferentes Diagramas de Pareto produzidos em cada mês de coleta. Ou
então plotando as medidas por disciplina individualmente em gráficos de controle.
 118

Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de

implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.3.4.15. Variação de tamanho

Descrição da necessidade de informação

Necessidade de Houve alteração no escopo do projeto em relação ao utilizado como base para o
informação planejamento?
Categoria de Escopo
informação
Objetivo de medição
Avaliar a precisão dos processos de estimativa de escopo para fins de planejamento das
Objetivo de medição
atividades do projeto e gerenciamento de mudanças no escopo do projeto
Entidade e atributos
Entidades relevantes Pacote ou unidade de software
Atributos 1. Tamanho
Especificação de medida básica
Medidas básicas 1. Tamanho planejado, representando por:
1.1. Quantidade de linhas de código, ou
1.2. Quantidade de pontos de função, ou
1.3. Quantidade de requisitos
2. Tamanho real, representado por:
2.1. Quantidade de linhas de código, ou
2.2. Quantidade de pontos de função, ou
2.3. Quantidade de requisitos
Métodos de medição 1. Contagem do tamanho planejado de um pacote ou unidade de software, conforme
linha de base de escopo do projeto.
1.1. Contagem da quantidade de linhas de código (SEI, 1992)
1.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
1.3. Contagem do número de requisitos funcionais do software.
2. Contagem do tamanho real de um pacote ou unidade de software ao final de uma
fase ou projeto
2.1. Contagem da quantidade de linhas de código (SEI, 1992)
2.2. Contagem da quantidade de pontos de função (IFPUG, 2004)
2.3. Contagem do número de requisitos funcionais do software.
Tipos de métodos 1. Subjetivo
2. Objetivo
Escala 1.
1.1. Inteiros, de zero a infinito
1.2. Decimais, de zero a infinito
1.3. Inteiros, de zero a infinito
2.
2.1. Inteiros, de zero a infinito
2.2. Decimais, de zero a infinito
2.3. Inteiros, de zero a infinito
Tipos de escalas 1.
1.1. Absoluta
1.2. Razão
1.3. Absoluta
2.
2.1. Absoluta
2.2. Razão
2.3. Absoluta
 119

Unidade de medição 1.
1.1. Linhas de código
1.2. Pontos de função
1.3. Requisitos
2.
2.1. Linhas de código
2.2. Pontos de função
2.3. Requisitos
Especificação de medida derivada
Medidas derivadas 1. Variação de tamanho
Função de medição  Tamanho real − Tamanho planejado 
1.   ∗ 100
 Tamanho planejado 
Especificação de indicador
Descrição do 1. Variação de tamanho: Este indicador apresenta na Figura 34 a razão entre o
indicador e amostra escopo (tamanho) real ao final de uma fase ou projeto em relação ao escopo
planejado na linha de base do projeto.

Figura 34: Variação de tamanho (XmR)

Modelo de analise 1. A medida de Variação de tamanho é apresentada em Gráficos de Controle X e mR

(XmR) com o objetivo de avaliar a estabilidade do processo de desenvolvimento
de software em relação ao escopo do projeto.
1.1. O gráfico de controle XmR apresenta o desempenho do processo ao longo do
tempo com o objetivo de avaliar a estabilidade do mesmo. A análise deste
gráfico deve procurar por sinais de desvios, ou seja, variações excepcionais
do processo que necessitam de investigação detalhada para identificação e
correção das causas de variação. O cálculo da linha central e limites de
controle deste gráfico são realizados de acordo com o procedimento
apresentado na seção 2.3.5.4
Critério de decisão 1. A medida Variação de tamanho possui como critérios de decisão as regras de
instabilidade de processo para cada um dos gráficos que representam o indicador,
 120

conforme descrito na seção 2.3.5.5

Interpretação do Os gráficos de controle XmR do exemplo acima apresentam aos responsáveis pela
indicador análise que:
• A observação de variação de tamanho (gráfico X) da iteração de Construção 2
excedeu o limite superior de 3 sigmas e portanto não atendeu ao Teste 1.
• As observações da variação de tamanho (gráfico X) das iterações de
Construção 2 e 3 excedem 2 sigmas da Linha central em dois de três pontos
consecutivos e portanto não atendem ao Teste 2
• As observações da variação de tamanho (gráfico X) das iterações de
Construção 1, 2, 3 e Transição excedem 1 sigma da Linha central em quatro
de cinco pontos consecutivos e portanto não atendem ao Teste 3.
Estes sinais demonstram que o processo pode estar fora de controle e deve então ser
analisado criticamente para identificar as causas de variação ações para correção.
Procedimento de coleta de dados (para cada medida básica)
Freqüência da coleta 1. Ao final do planejamento. Coleta do tamanho planejado como escopo do projeto.
de dados 2. Ao final de cada fase. Coleta do tamanho real do escopo do projeto.
Responsável • O Analista de métricas realiza contagem do tamanho planejado e real do escopo do
projeto
• O Gerente do Projeto consolida as informações das medidas.
Fase ou atividade de Durante todo o ciclo de vida, para as fases onde seja possível realizar contagem real do
coleta de dados tamanho do projeto.
Ferramentas 1. Ferramenta de registro do tamanho do escopo do projeto.
utilizadas para coleta 2. Ferramenta de registro do tamanho do escopo do projeto.
de dados
Verificação e Revisões e auditorias nas contagens de tamanho realizadas.
Validação
Repositório de dados Repositório de medições da organização.
coletados
Procedimento de análise de dados (para cada indicador)
Freqüência de Ao final de cada fase.
reporte dos dados
Responsável • Analista de métricas do projeto e Gerente de projetos (nível do projeto)
• Analista de métricas da organização (nível da organização)
Fase ou atividade de Durante todo o ciclo de vida, para as fases onde seja possível realizar contagem real do
análise dos dados tamanho do projeto
Fonte de dados para Repositório de medições da organização.
análise
Ferramentas Repositório de medições da organização.
utilizadas para
análise de dados
Revisão, reporte e Equipe do projeto, Gerente de projetos e Gerente organizacional (nível do projeto)
usuário Gerente organizacional e Gerente sênior (nível organizacional)
Informação adicional
Guia de análise Não aplicável
adicional
Considerações de • Quantidade de dados mínimos: A quantidade de dados mínimos para a análise de
implementação desempenho do processo é definida conforme exposto na seção 2.3.5.4.

3.4. Considerações finais do capítulo

Este capítulo apresentou a seqüência de nove passos realizados nesta pesquisa para
elaboração do catálogo de medidas. Os passos envolveram desde a identificação das medidas
de desempenho mais referenciadas na literatura, passando pela consolidação e eliminação de
medidas redundantes que resultaram em 37 medidas de desempenho, até a especificação
 121

detalhada das características, instrumentos de medição e de avaliação de 15 indicadores

selecionados para compor o catálogo final desta pesquisa.
O próximo capítulo apresentará o estudo de caso realizado em uma empresa de
tecnologia da informação de forma a aplicar catálogo de medidas proposto em um projeto real
de desenvolvimento de software.
 122

4. EXEMPLO DE USO DO CATÁLOGO DE MEDIDAS

Neste capítulo é apresentado um exemplo de utilização do catálogo de medidas, a

partir dos dados de um projeto de desenvolvimento de software de grande magnitude,
executado em uma organização madura em relação aos processos de níveis 2 e 3 do modelo
CMMI.

4.1. Caracterização do estudo de caso

Algumas medidas do catálogo proposto neste trabalho foram aplicadas em um projeto

de desenvolvimento de software, executado em uma empresa brasileira, especializada em
tecnologia da informação.
A empresa objeto deste estudo de caso desenvolve desde o ano de 2003 um programa
de melhoria de processos baseado nos modelos da família CMM. Pode-se afirmar, portanto
que a maturidade dos processos faz parte da cultura e estratégia da organização, sendo
considerada fundamental para a melhoria da qualidade dos serviços e aumento da
competitividade.
Os dados apresentados neste estudo de caso foram obtidos de um dos projetos da
empresa, que possui como escopo o ciclo de vida completo de desenvolvimento de software.
Este projeto é executado internamente, em uma das unidades fabris da organização
aderente ao Nível 3 do modelo CMMI, tendo apresentado elevado índice de aderência aos
processos técnicos, gerenciais e de suporte exigidos até o 3º nível do modelo. A equipe atual
do projeto, de aproximadamente 30 profissionais, é distribuída em papéis claramente
definidos e agrupados pelas diferentes disciplinas do processo. O projeto conta também com
um gerente de projetos e líderes técnicos, que têm como objetivo orientar a execução do
projeto frente aos seus objetivos.
O projeto em questão faz uso da customização do processo padrão da organização,
baseado no modelo de ciclo de vida iterativo e incremental e utiliza como base as práticas e
modelos do processo unificado (UP). No momento da coleta de dados desta pesquisa, o
projeto encontrava-se na sétima iteração da fase de Construção, já tendo transcorrido dois
anos e oito meses do prazo previsto para a sua execução.
 123

Este exemplo de utilização das medidas do catálogo buscou realizar todos os

procedimentos descritos na especificação das medidas do catálogo, ou seja, utilizar os dados
históricos do projeto selecionado para verificar se é possível aplicar as medidas tais quais
foram especificadas. Dessa forma, os dados históricos do projeto em estudo foram analisados
com o objetivo de avaliar a estabilidade dos seus processos e definir uma linha de base para
avaliação de desempenho futuro.
As seções a seguir apresentam o procedimento adotado para aplicação das medidas no
projeto, bem como os resultados obtidos na avaliação do desempenho dos processos e ações
realizadas para tornar estável o processo em questão.

4.2. Seleção dos processos e medidas de desempenho

Durante o primeiro ano de execução, o projeto objeto deste estudo de caso apresentou
um histórico de baixo desempenho nas disciplinas de engenharia de software, causado pela
instabilidade do escopo no início do projeto e também pela má avaliação da demanda de
trabalho do projeto, o que ocasionou em sub-dimensionamento da equipe alocada durante os
primeiros doze meses de execução.
Após a identificação dos desvios e a necessidade de recuperação do projeto, a equipe
de gestão reavaliou o escopo e esforço necessários para o projeto e focou ações na
implantação de processos de trabalho mais claros e detalhados e no aumento substancial da
equipe do projeto.
A partir da identificação da situação e características do projeto, a primeira etapa deste
estudo de caso envolveu a análise e seleção dos processos críticos do projeto, ou seja, àqueles
para os quais a organização estabeleceu explicitamente metas a serem atendidas ou os
processos cujo histórico tem demonstrado desempenho insatisfatório em relação às
expectativas dos envolvidos no projeto.
A seleção dos processos críticos do projeto é base para a identificação das
necessidades de análise de desempenho, já que os processos críticos para o projeto demandam
um acompanhamento mais preciso, através da aplicação de técnicas e modelos de controle
estatístico de processos.
Baseado no histórico do projeto e nos objetivos traçados para recuperação do
desempenho foram selecionados para os processos técnicos de engenharia de software. A
organização priorizou realizar análise de desempenho do processo de Solução técnica, além
 124

do prazo e custo dos processos de Desenvolvimentos de Requisitos, Engenharia de

Requisitos, Solução técnica, Integração de produto, Verificação e Validação.
A seleção das medidas para realizar análise de desempenho destes processos foi
realizada conforme o Quadro 20 apresentado nesta pesquisa. Os processos selecionados para
análise de desempenho foram cruzados com as categorias de medição desejadas pela
organização a fim de identificar quais indicadores são capazes de fornecer a informação
desejada para a avaliação de desempenho.
Com o objetivo de fornecer instrumentos para a análise de desempenho, foram
selecionados do catálogo os indicadores de ‘Análise de valor agregado’ e ‘Densidade de
defeitos’, e portanto, todas as medidas especificadas nos mesmos. O primeiro indicador foi
selecionado já que, segundo o catálogo, as medidas de desempenho deste indicador
contemplam a todas as Áreas de Processos (APs) de Engenharia do CMMI, avaliando-as
frente às categorias de medição de prazo e custo.
O Quadro 20 sugere para a necessidade de medição do processo de Solução técnica
sob a perspectiva de qualidade, os indicadores de ‘Densidade de defeitos’, ‘Taxa de
retrabalho’ e ‘Prazo médio para falha’. Entre as opções disponíveis, optou-se pelo indicador
de ‘Densidade de defeitos’ em virtude de que, até o momento desta pesquisa, nenhum pacote
de software, ou Build, havia sido entregue ao Cliente para testes e, portanto os indicadores de
‘Taxa de retrabalho’ e ‘Prazo médio para falha’ não teriam informação histórica para
definição da linha de base de desempenho do projeto.
Além dos objetivos organizacionais de desempenho, a seleção dos indicadores baseou-
se também na qualidade dos dados coletados desde o início do projeto. A integridade e
precisão das medidas disponíveis foram avaliadas, bem como a estabilidade dos processos que
produzem os resultados medidos.
A seguir é apresentado o processo realizado de coleta dos dados do projeto, que
serviram de insumo para a análise dos indicadores aplicados.

4.3. Coleta de dados de desempenho dos processos

Conforme apresentado anteriormente, o projeto estudado executa os processos

definidos para a organização, que por sua vez foram criados com base nas práticas dos níveis
2 e 3 do Modelo CMMI. Sendo assim, o projeto dispõe de diferentes instrumentos e
ferramentas estabelecidas na organização para registro e gerenciamento das atividades de
 125

engenharia de software, que foram utilizadas como fonte principal de dados para a análise de
desempenho dos processos.
As principais ferramentas utilizadas na coleta de dados para composição dos
indicadores deste estudo são:
• Ferramenta de cronograma: A organização utiliza como ferramenta de
gerenciamento dos cronogramas dos projetos a versão 2003 da solução de
EPM (Enterprise Project Management) da Microsoft. Neste ambiente, os
cronogramas dos projetos executados na organização são armazenados em um
servidor central (Microsoft Project Server) e gerenciados individualmente nas
estações de trabalho dos Gerentes de Projetos a partir da ferramenta Microsoft
Project Professional. Diariamente, os membros integrantes da equipe do
projeto utilizam a infra-estrutura do Microsoft Project Web Access para
acompanhamento das atividades atribuídas a cada um e registro do esforço
despendido na execução das mesmas.
• Ferramenta de controle de defeitos: A organização dispõe de ferramenta
Mantis, especificamente para registro de defeitos e sugestões de melhoria
identificados em revisões e testes, bem como acompanhamento da resolução
das ocorrências pela equipe técnica.
• Ferramenta de apoio à medição de tamanho: A organização atualmente possui
uma ferramenta desenvolvida internamente para apoiar as atividades de
medição de tamanho, baseada na técnica de análise de pontos de função.
A coleta das medidas básicas de desempenho do projeto sugeridas na especificação do
indicador de Valor agregado foi realizada a partir do cronograma do projeto. As medidas de
Valor planejado (VP) e Orçamento no término (ONT) foram obtidas da linha de base do
cronograma, registrada após a aprovação do planejamento do projeto e que inclui as metas de
esforço, recursos, custo e prazos para cada atividade detalhada no cronograma. As medidas
básicas de Custo real (CR) e Valor agregado (VA) foram obtidas do cronograma a partir do
desempenho realizado na execução das atividades, reportado diariamente pela equipe do
projeto.
Os dados para o indicador de Análise de valor agregado foram coletados mensalmente,
desde o início do projeto em Novembro de 2005, até o mês de Janeiro de 2008, somando 27
observações das medidas.
Com relação ao indicador de “Densidade de defeitos’, o mesmo foi aplicado no projeto
apenas para defeitos identificados nos testes realizados sob os componentes de software
 126

desenvolvidos, portanto, não fez parte do escopo desta pesquisa os defeitos identificados por
atividades de revisão técnica nos produtos do projeto, como requisitos, especificações de
programas e código-fonte. Neste caso, as medidas básicas de Quantidade de defeitos totais e
Quantidade de defeitos por tipo, sugeridas na especificação da medida, foram obtidas a partir
dos registros na ferramenta de controle de defeitos, colocada em prática na organização
durante a execução do projeto. Já a medida básica de Tamanho foi obtida a partir da
estimativa de pontos de função registrada para cada unidade de software testada.
A medida de Densidade de defeitos foi agrupada pelo pacote de software, ou Build,
produzido em cada etapa do projeto. Os dados de quantidade de defeitos foram coletados na
ferramenta Mantis a partir do Build 1 até o Build 20.
Além da quantidade total de defeitos totais por Build do projeto, os defeitos
registrados na ferramenta Mantis foram classificados por tipo, de forma a identificar as causas
e permitir priorizar as ações de melhoria na qualidade do produto.
A partir da coleta dos dados do projeto necessários para composição dos indicadores
de Valor agregado e Densidade de defeitos, foi possível estabelecer os instrumentos para
gestão quantitativa do projeto. A seção a seguir apresenta os passos realizados para
estabelecer a linha de base de desempenho dos processos.

4.4. Definição da linha de base de desempenho dos processos

A organização na qual o projeto é executado atende às práticas do nível 3 do modelo

CMMI, portanto ainda não estabeleceu uma infra-estrutura de gestão quantitativa para todo o
seu portfólio de projetos e não se preocupou com os critérios de estabilidade de processos,
característicos dos níveis 4 e 5 de maturidade. Sendo assim, ao definir a linha de base de
desempenho, foi necessário avaliar a estabilidade dos processos a partir dos critérios de
decisão descritos na especificação das medidas.
De acordo com as seções “Descrição do indicador e amostra” e “Modelo de análise”
da especificação do indicador de Análise de valor agregado, as medidas de Índice de
desempenho de custos (IDC) e Índice de desempenho de prazos (IDP) são analisadas através
do gráfico de controle do tipo Valores individuais e Amplitude móvel (XmR). Nestes casos,
os limites de controle foram calculados a partir dos dados coletados para ambas as medidas
entre Novembro de 2005 e Janeiro de 2008.
O Quadro 21 apresenta os dados envolvidos na definição das linhas de base, bem
como as cartas de controle resultantes.
 127

Quadro 21: Linha de base para as medidas IDC e IDP (XmR)

Índice de desempenho de custos (IDC) Índice de desempenho de prazos (IDP)

IDC (X) IDP (X)

1,00 0 1,800

0,90 0 0 ,9 13
1,600
1,533
0,80 0
0 ,7 74 1,400
0,70 0 1,266
0 ,6 35 1,200
0,60 0
1,000 0,998
0,50 0 0 ,4 96

0,40 0 0,800
0 ,3 57 0,731
0,30 0 0,600

0,20 0 0 ,2 18 0,463
0,400
0,10 0
0 ,0 79
0,200 0,195
0,00 0
0,000

IDC (X ) LC L CS (+ 3 sigmas) + 2 sigmas + 1 sigma L C I (- 3 sigmas) - 2 sigmas - 1 sigma

IDP (X) LC LCS (+3 sigmas) + 2 sigmas + 1 sigma LCI (- 3 sigmas) -2 sigmas - 1 sigma

IDC (mR)
0,600
IDP (mR)
0,500 0,512 1,200
0,400 1,000 0,986
0,300 0,800
0,200
0,157 0,600
0,100
0,400
0,000 0,302
0,200
nov/05

abr/06

nov/06

abr/07

nov/07
dez/05
jan/06
fev/06

jun/06
jul/06

set/06
out/06

dez/06
jan/07
fev/07

jun/07
jul/07

set/07
out/07

dez/07
jan/08
mar/06

mai/06

ago/06

mar/07

mai/07

ago/07

0,000

dez/05

fev/06

dez/06

fev/07

dez/07
nov/05

mar/06
abr/06
mai/06
jun/06
jul/06
ago/06
set/06

nov/06

mar/07
abr/07
mai/07
jun/07
jul/07
ago/07
set/07

nov/07
jan/06

out/06

jan/07

out/07

jan/08
IDC (mR) LC LCS (+3 sigmas)

IDP (mR) LC LCS (+3 sigmas)

Períod Gráfic +3σ -3σ Períod Gráfic +3σ -3σ

LC +2σ - 2σ +1σ -1σ LC +2σ - 2σ +1σ -1σ
o o (LCS) (LCI) o o (LCS) (LCI)
De X 0,496 0,913 0,079 0,774 0,218 0,635 0,357 De X 0,731 1,533 0,000 1,266 0,195 0,998 0,463
Nov/05 0,157 0,512 0,000 Nov/05 0,302 0,986 0,000
a mR a mR
Jan/08 Jan/08

Conforme sugerido pela especificação do indicador de Densidade de defeitos, a linha

de base foi estabelecida em gráfico de controle do tipo u a partir dos dados coletados entre os
Builds 1 e 20, conforme demonstrado no Quadro 22.

Quadro 22: Linha de base para a medida de Densidade de defeitos (u Chart)

Densidade de defeitos (u Chart Skyline)

1,400

1,200

1,000
0,800

0,600
0,46 3
0,400
0,200
-
(0,20 0)

Densidade d e defeitos (X) LC LCS LCI

Período Gráfico Ū
De Build 1 a Build 20 u Chart 0,463

As linhas de base estabelecidas a partir dos resultados históricos fornecem os critérios

para a avaliação do desempenho dos processos. A análise e identificação de desvios das
medidas são apresentadas na seção a seguir.
 128

4.5. Avaliação do desempenho dos processos

A partir dos limites de controle definidos nas linhas de base apresentadas na seção
anterior, é possível avaliar quantitativamente o desempenho real dos processos, identificar as
causas especiais de variação e concluir a respeito da estabilidade dos processos executados
pelo projeto.
Com este intuito, as medidas coletadas no projeto em estudo para os indicadores de
Análise de Valor Agregado e Densidade de defeitos foram representadas em cartas de
controle e outras ferramentas de gestão quantitativa e avaliadas frente aos critérios de decisão
definidos para cada indicador.
No caso do indicador de Análise de Valor Agregado, a Figura 35 mostra a aplicação
dos critérios de decisão sugeridos pela especificação do indicador em relação às cartas de
controle do tipo XmR para a medida de Índice de desempenho de custos (IDC).

IDC (X)
1,000

0,900 4 0,913
0,800
0,774
0,700
0,635
0,600

0,500 0,496

0,400
2,3 0,357
0,300

0,200 0,218

0,100 0,079
0,000

IDC (X) LC LCS (+3 sigmas) + 2 sigmas + 1 sigma LCI (- 3 sigmas) - 2 sigmas - 1 sigma

IDC (mR)
0,600
0,500 0,512
0,400
0,300
0,200
0,157
0,100
0,000
nov/05

abr/06

set/06

nov/06

abr/07

set/07

nov/07
dez/05
jan/06
fev/06

jun/06
jul/06

out/06

dez/06
jan/07
fev/07

jun/07
jul/07

out/07

dez/07
jan/08
mar/06

mai/06

ago/06

mar/07

mai/07

ago/07

IDC (mR) LC LCS (+3 sigmas)

Figura 35: Cartas XmR para medida de IDC do projeto

Segundo o procedimento descrito nas seções “Modelo de análise” e “Critérios de

decisão” do indicador, percebe-se que o desempenho do processo é instável, pois apresenta
causas especiais de variação. No gráfico de controle X, entre Julho de 2006 e Outubro de
2006, o desempenho apresenta sinal de desvio, já que quatro de cinco pontos consecutivos
encontram-se abaixo de menos um sigma da linha central (Teste 3). Dentro do mesmo
conjunto de pontos, os pontos de Setembro e Outubro de 2006 são detectados pelo Teste 2 já
 129

que dois de três pontos consecutivos encontram-se abaixo de menos dois sigmas da linha
central.
Entre Julho de 2007 e Janeiro de 2008, o gráfico de controle X demonstra uma quebra
no desempenho do processo, já que, oito pontos consecutivos são apresentados na parte
superior da linha central (Teste 4).
A análise da medida IDP demonstra apenas desvio no mês de Outubro de 2006 do
gráfico de controle X (Teste 1), conforme apresentada na Figura 36.

IDP (X)
1,800 1
1,600
1,533
1,400
1,266
1,200

1,000 0,998

0,800
0,731
0,600
0,463
0,400

0,200 0,195

0,000

IDP (X) LC LCS (+3 sigmas) + 2 sigmas + 1 sigma LCI (- 3 sigmas) - 2 sigmas - 1 sigma

IDP (mR)
1,200
1,000 0,986
0,800
0,600
0,400
0,302
0,200
0,000
dez/05

fev/06
mar/06

jun/06
jul/06

dez/06

fev/07
mar/07

jun/07
jul/07

dez/07
nov/05

jan/06

abr/06
mai/06

ago/06
set/06
out/06
nov/06

jan/07

abr/07
mai/07

ago/07
set/07
out/07
nov/07

jan/08

IDP (mR) LC LCS (+3 sigmas)

Figura 36: Cartas XmR para a medida IDP do projeto

Com relação ao indicador de Densidade de defeitos, os valores coletados dos Builds

construídos pelo projeto demonstram que, segundo a seção de “Critérios de decisão” do
indicador, os Builds 5, 6, 8, 11, 12, 15 e 19, assinalados na Figura 37, apresentam sinais de
desvio, já que possuem valor fora dos limites de controle superior.
 130

Densidade de defeitos (u Chart Skyline)

1
1,400
1,200 1
1,000
0,800
1
0,600
0,463
0,400
0,200

-
1
(0,200 )

Densidade de defeitos (X) LC LCS LCI

Figura 37: Densidade de defeitos total do projeto

A análise das causas dos desvios apresentados nos indicadores e identificação de ações
corretivas e preventivas são etapas fundamentais da análise de desempenho dos processos.
Neste estudo de caso, seguindo as orientações propostas pela especificação do indicador, a
medida de Densidade de defeitos é também avaliada a partir da classificação da causa dos
defeitos, conforme apresentado na Figura 38. Percebe-se que a maior densidade de defeitos é
relacionada à disciplina de Implementação, sendo esta considerada a causa principal de falhas
nos componentes de software.

Densidade de defeitos (Pareto)

95,06% 97,27% 99,32% 100,00% 100,00% 100,00%
0,350 0,325 82,11% 91,99%
100,00%
70,19%
Densidade de defeitos

0,300 80,00%
0,250
0,200 60,00%
0,150 40,00%
0,100 0,055 0,046
0,050 0,014 0,010 0,009 0,003 - - 20,00%
- 0,00%

Densidade de defeitos
Percentual acumulado

Figura 38: Diagrama de Pareto da Densidade de defeitos por tipo do projeto

A partir da identificação das causas mais prováveis, ações gerenciais e técnicas foram
propostas e implementadas pela organização sob a ótica da disciplina de implementação.
Entre as ações sugeridas, destacam-se:
• Integrar os processos e equipes de análise e implementação, com o objetivo e
facilitar o entendimento do negócio do sistema e reduzir falhas de
implementação.
• Incorporar técnicas de testes unitários no projeto no mesmo ambiente onde o
sistema será verificado e validado pela equipe de testes.
 131

• Aumentar o formalismo para as atividades de revisão técnica de código-fonte e

aderência deste para com o design dos componentes.

4.6. Considerações finais do capítulo

Este capítulo apresentou um exemplo de aplicação prática de medidas do catálogo

proposto nesta pesquisa em um projeto de desenvolvimento de software real, executado em
uma organização brasileira.
A aplicação da pesquisa serviu como exemplo de uso das medidas para a analisar do
desempenho dos processos a partir de instrumentos de controle estatístico de processos
descritos nos indicadores de Análise de valor agregado e Densidade de defeitos.
Contudo, o fato do estudo de caso limitar-se a apenas analisar os dados históricos do
projeto limita a percepção de valor no uso dos indicadores para prevenção de desvios de
desempenho futuro do projeto, bem como não foi possível avaliar os resultados da
implementação de ações corretivas e preventivas.
No entanto, a apresentação neste capítulo dos passos para aplicação dos indicadores do
catálogo em um projeto real, além de demonstrar a utilização das medidas, simplifica o
entendimento e análise dos resultados de desempenho dos processos, facilitando a
implantação do catálogo de medidas nas organizações.
A partir da aplicação deste trabalho, foram feitas recomendações à organização.
Dentre elas:
• Disseminar os seus processos de fábrica relacionados à análise de desempenho
de processos para todas as unidades fabris da organização;
• Ajustar a especificação das medidas atualmente em prática na organização,
incorporando os conceitos de controle estatístico de processos apresentados no
catálogo proposto nesta pesquisa;
• Evoluir a ferramenta de reporte, armazenamento e visualização das medidas
em uso na organização, permitindo a definição de limites variáveis, conforme
desempenho histórico apresentado pelo processo (linha de base);
Portanto, espera-se que a organização adote as boas práticas apresentadas no catálogo
de medidas, a fim de viabilizar aos gestores de projetos instrumentos precisos de análise de
desempenho e previsão de atendimento aos objetivos dos projetos.
No próximo capítulo serão apresentadas as conclusões dessa pesquisa e as
perspectivas de trabalhos futuros.
 132

5. CONCLUSÃO

Projetos de desenvolvimento de software têm demonstrado falhas recorrentes e

resultados insatisfatórios, consumindo normalmente mais tempo e recursos do que o
planejado (BARROS; WERNER; TRAVASSOS, 2006, p. 1).
O sucesso dos projetos de desenvolvimento de software depende da capacidade da
organização em prever o seu desempenho e assumir compromissos atingíveis. Portanto, o
histórico de falhas e a complexidade de gestão de projetos de desenvolvimento de software
requerem que, além da experiência do gerente de projetos, técnicas de gestão quantitativa
sejam aplicadas de forma a identificar objetivamente, através de indicadores de desempenho,
a situação do projeto e prever a sua capacidade em atender os objetivos futuros.
Nesse contexto, um dos problemas enfrentados pelas organizações que aderem aos
programas de medição é a seleção do conjunto adequado de medidas de desempenho, que
sejam relevantes na avaliação do dos processos de engenharia de software.
Com esta motivação em mente, o objetivo desta pesquisa foi estabelecer um catálogo
de medidas que permita a análise de desempenho de processos de desenvolvimento de
software. Para atender a esta expectativa, foram definidos os seguintes objetivos específicos:
i. Selecionar medidas relacionadas às áreas de processos da categoria de
engenharia do CMMI-DEV a partir do conjunto de medidas tipicamente
utilizadas nas organizações e as propostas de medidas encontradas na literatura;
ii. Consolidar as medidas em indicadores de desempenho de processo;
iii. Especificar as medidas e seus indicadores, definindo os métodos de coleta e
análise dos dados e os critérios de decisão sobre o desempenho dos processos,
organizando todas informações em um catálogo;
iv. Realizar um exemplo de aplicação do catálogo de medidas em um projeto de
desenvolvimento de software, considerando a análise de desempenho dos
processos das áreas de processos da categoria de engenharia do CMMI-DEV.
Várias atividades foram realizadas no desenvolvimento desta pesquisa para
desenvolver o catálogo de medidas. Para o objetivo (i) foi realizada uma ampla revisão da
literatura para identificar as medidas de desempenho em prática em organizações que
executam projetos de desenvolvimento de software. Neste passo foram identificadas
inicialmente 869 medidas desempenho citadas em 32 trabalhos pesquisados.
 133

A partir do universo completo de medidas citadas na literatura, foi realizada uma

análise de todas as medidas encontradas, categorizando-as segundo o seu objetivo de
medição, em relação a categorias adaptadas do PSM (MCGARRY et al, 2002) e Kulpa e
Johnson (2008). Neste passo da pesquisa, as medidas foram também classificadas em relação
às áreas de processo do CMMI-DEV que se propõem avaliar. A partir dessa análise, foram
eliminadas redundâncias e foi definido um nome consolidado para cada medida que tivesse
sido definida com nomes distintos por diferentes autores.
Sendo o foco desta pesquisa estabelecer um catálogo sucinto e prático, contendo
apenas as medidas essenciais para a gestão quantitativa dos projetos de desenvolvimento de
software, as medidas foram filtradas, sendo selecionadas apenas aquelas relacionadas às áreas
de processos do grupo de Engenharia do modelo CMMI-DEV e citadas por três ou mais
autores dentre os referenciados nesta pesquisa.
Para alcançar o objetivo (ii), as 37 medidas básicas e derivadas resultantes do objetivo
anterior foram agrupadas em um conjunto de 15 indicadores de desempenho de processos, os
quais deveriam ser especificados posteriormente.
De forma a atender ao propósito deste trabalho, o objetivo (iii) envolveu
primeiramente selecionar e adaptar um modelo de especificação de medidas, selecionar as
técnicas de controle estatístico de processos para os indicadores definidos e a especificação
dos procedimentos de medição de cada indicador. Com essas informações, cada indicador do
catálogo foi especificado, detalhando a composição das medidas básicas e derivadas, a
representação gráfica do indicador, os métodos de análise e os critérios de decisão utilizados
para avaliar se o processo sendo medido encontra-se dentro do desempenho esperado pela
organização. Ao final deste objetivo, os indicadores foram consolidados em um catálogo
indexado a partir das áreas de processos do modelo CMMI-DEV.
O quarto e último objetivo específico previsto para esta pesquisa foi atendido a partir
da aplicação das medidas relacionadas aos indicadores Valor agregado e Densidade de
defeitos, que compõem o catálogo proposto, em um projeto de desenvolvimento de software
real, executado em uma organização brasileira, referência nacional em maturidade de
processos de software baseado no modelo CMMI. Para esta atender a este objetivo, foram
obtidos dados de desempenho das medidas desde o início do projeto, e estes foram então
analisados buscando avaliar a estabilidade dos processos e estabelecer a linha de base de
desempenho.
 134

Ao final do estudo de caso, foram identificadas as situações de instabilidade do

processo e sugeridas ações gerenciais à organização para reduzir a variabilidade e aumentar a
previsibilidade do processo.
Este trabalho gerou as seguintes contribuições para as áreas de medições de software e
gestão quantitativa de projetos:
• Um conjunto de medidas, organizadas em indicadores, desenvolvido a partir da
consolidação das medidas mais citadas na literatura e unificadas no sentido
padronizar a sua nomenclatura, fórmula e métodos de coleta e análise;
• A especificação das medidas de forma a apoiar a análise de desempenho dos
processos de engenharia de software, a partir da descrição dos procedimentos
de coleta, analise e interpretação das medidas especificadas;
• Um mapeamento entre das medidas e de seus indicadores com as áreas de
processo do modelo CMMI-DEV para as quais podem ser aplicados;
• Uma ampla revisão de literatura identificando as medidas de desempenho de
processos de software mais citadas pelos autores e mais utilizadas nas
organizações pesquisadas;
Por fim, este trabalho contribui às organizações interessadas em implementar as
práticas de Medição e Análise, previstas no segundo nível de maturidade do modelo CMMI-
DEV, pois facilita a decisão das medidas e serem utilizadas. O catálogo proposto nesta
pesquisa apresenta também os instrumentos de medição que preparam a organização para a
realização das práticas de controle estatístico de processos previstas a partir do quarto nível de
maturidade do modelo CMMI-DEV.
No entanto, entende-se que outros trabalhos podem ser realizados como as seguintes
perspectivas de pesquisas futuras:
• Apoiar a definição de um plano de medições real de uma organização, a partir
das medidas do catálogo;
• Aplicar o catálogo completo de medidas em projetos reais de desenvolvimento
de software;
• Realizar a análise de desempenho a partir dos dados de um conjunto de
projetos, identificando ações gerenciais para as situações de desvios;
• Estender a definição do catálogo com medidas para as áreas de processos de
outras categorias do CMMI-DEV (Gerenciamento de Processos,
Gerenciamento de Projetos e Suporte);
 135

REFERÊNCIAS BIBLIOGRÁFICAS

ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 25000: Engenharia de

Software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) - Guia do
SQUARE, 2008

AGRAWAL, M.; CHARI, K., Software Effort, Quality, and Cycle Time: A Study of CMM
Level 5 Projects. Software Engineering, IEEE Transactions on, vol. 33, no. 3, pp.145-156,
Mar, 2007.

AGRESTI, W. Lightweight Software Metrics: The P10 Framework. IT Professional, vol. 8,

no. 5, pp. 12-16, Set/Out, 2006.

BARROS, M.O.; WERNER, C. M. L.; TRAVASSOS, G.H. Applying System Dynamics to

Scenario Based Software Risk Management, In: International System Dynamics
Conference, 2000, Bergen, Noruega, Anais... Disponível em:
<http://reuse.cos.ufrj.br/prometeus/publicacoes/SD2000_FullPaper.pdf>. Acesso em: 19 out.
2006.

BASILI, V.; CALDIERA, G.; ROMBACH, H. The Goal Question Metric Approach.
In:______. Encyclopedia of Software Engineering. Volume 1, John Wiley & Sons, Inc., 2.
ed., 2002, pp. 578-583.

BECKER, K. et al. SPDW: A Software Development Process Performance Data Warehousing

Environment. In: Software Engineering Workshop, 2006, Columbia, MD, EUA. Anais…
Abr, 2006. pp.107-118.

BERANDER, P.; JÖNSSON, P. A goal question metric based approach for efficient
measurement framework definition, In: International Symposium on Empirical Software
Engineering, 2006, Rio de Janeiro, Brasil, Anais eletrônicos… Disponível em:
<http://portal.acm.org/citation.cfm?id=1159781>. Acesso em: 04 set. 2007.
 136

BUGLIONE, L.; ABRAN, A. A Model for Performance Management and Estimation. 11th
IEEE International Software Metrics Symposium (METRICS'05), 2005, Washington, DC,
EUA, Anais… Set, 2005. p. 9

CHIKOFKY, E; RUBIN H. Using metrics to justify investment in IT. IT Professional, vol. 1,

no. 2, pp. 75-77, Mar/Abr, 1999.

CHRISSIS, M.; KONRAD M.; SHRUM S. CMMI: guidelines for process integration and
product improvement. 2.ed. Boston: Addison-Wesley, 2003.

DEBOU, C.; KUNTZMANN-COMBELLES, A.; ROWE, A. A quantitative approach to

software process management. Software Metrics Symposium, 1994, London, UK, Anais…
Out, 1994. pp.26-34.

DoD – Departament of Defense e Us Army. Measurement Specification Template, Jan,

2004. Disponível em:
<http://www.psmsc.com/Downloads/MeasurementSpecs/MeasurementSpecTemplateV2Jan04
.zip>. Acesso em: 26 abr. 2008.

EICKELMANN, N; ANANT, A. Statistical Process Control: What You Don’t Measure Can
Hurt You! IEEE Software, vol. 20, no. 2, pp. 49-51, Mar/Abr, 2003.

FENTON, N; PFLEEGER, S. Software Metrics: A Rigorous and Practical Approach.

2.ed. Boston: PWS Publishing Company, 1997.

FIGUEIREDO, R. M. C. Garantia de Qualidade dos Provedores de Serviços de

Aplicativos (ASPs), empregando os Acordos dos Níveis de Serviços (SLAs). Uma
Pesquisa Explanatória. 2002. 290 f. Tese (Doutorado em Engenharia Mecânica) –
Universidade de São Paulo, São Carlos, 2002.

FLORAC W. A.; CARLETON, A. D. Measuring the Software Process: Statistical Process

Control for Software Process Improvement. Reading, MA, EUA: Addison-Wesley, 1999.
 137

GALIN, D.; AVRAHAMI, M. Do SQA Programs Work - CMM Works: A Meta Analysis.
Software - Science, Technology and Engineering, 2005. Proceedings. IEEE International
Conference on , vol., no., pp. 95-100, 22-23 Fev, 2005.

GALIN, D; AVRAHAMI, M. Are CMM Program Investments Beneficial? Analyzing Past

Studies. IEEE Software, vol. 23, no. 6, pp. 81 - 87, Nov/Dez, 2006.

GALIN, D; AVRAHAMI, M. Benefits of a Higher Quality Level of the Software Process:

Two Organizations Compared. Software Quality Professional, vol. 9, no. 4, pp. 27 - 35, Set,
2007.

GARCÍA, F. et al. FMESP: framework for the modeling and evaluation of software processes.
Proceedings of the 2004 workshop on Quantitative techniques for software agile process,
pp. 5 - 13, Nov, 2004.

GARCÍA, F. et al. Towards a consistent terminology for software measurement. Information

and Software Technology. Vol. 48, no. 8, pp. 631-644, Ago, 2006.

GARMUS D.; HERRON, D. Function Point Analysis – Measurement Practices for

successful Software Projects, Addison-Wesley Information Technology Series, 2000.

GOPAL, A; MUKHOPADHYAY, T.; KRISHNAN, M. The Impact of Institutional Forces on

Software Metrics Programs IEEE Transactions on Software Engineering, vol. 31, no. 8,
pp. 679-694, Ago, 2005.

GRADY, R. Practical Software Metrics for Project Management and Process

Improvement, Upper Saddle River, NJ: Prentice Hall, 1992.

GRADY, R. Successfully Applying Software Metrics. Computer, vol. 1, pp. 18-27, Set,
1994.

HALL T.; FENTON, N. Implementing effective software metrics programs. IEEE Software.
vol. 14, no. 2, pp. 55-65, Mar/Abr, 1997.
 138

HERBSLEB J.; GRINTER R. Conceptual Simplicity Meets Organizational Complexity: Case

Study of a Corporate Metrics Program, In: 20 th International Conference on Software
Engineering, 1998, Kyoto, Japão, Anais… Disponível em: <
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=671136>. Acesso em: 09 out. 2007.

HUMPHREY, W. The Team Software ProcessSM (TSPSM). Relatório Técnico CMU/SEI-

2000-TR-023, Nov, 2000.

IEEE. IEEE Std 1045-1992 - Standard for Software Productivity Metrics. Nova Iorque, 1992.

IFPUG - International Function Point Users Group. Count Practices Manual – Release 4.2,
2004.

ISO/IEC - International Organization for Standardization and International Electrotechnical

Commission. ISO/IEC 15939:2002 Software engineering – Software measurement
process, 2002.

ISO/IEC - International Organization for Standardization and International Electrotechnical

Commission. ISO/IEC 12207:2008 Systems and Software Engineering - Software Life
Cycle Processes, 2008.

JOHNSON, M. P; et al. Improving Software Development Management through Software

Project Telemetry. IEEE Software, vol. 22, no. 4, pp. 76-85, Jul/Ago, 2005.

KAN, S. Metrics and models in software engineering. 2.ed. Boston: Addison-Wesley,

2003.

KITCHENHAM, B. et al. Lessons learnt from the analysis of large-scale corporate databases.
Proceedings of the 28th international conference on Software engineering, pp. 439 - 444,
Mai, 2006.

KULIK P.; WEBER C. Software Metrics Best Practices 2001. Dayton, OH, EUA 2002.
Disponível em: <http://java.ittoolbox.com/pub/PK043002.pdf>. Acesso em: 27 ago. 2007.
 139

KULPA, M; JOHNSON, K. Interpreting the CMMI : a process improvement approach.

2nd Ed. CRC Press. 2008

LAWLER, J.; KITCHENHAM, B. Measurement Modeling Technology. IEEE Software,

vol. 20, no. 3, pp. 68-75, Mai/Jun, 2007.

LINDSTRÖN, B. A Software Management Case Study Using GQM. 2004. 95 f.

Dissertação (Mestrado no Departamento de Sistemas de Comunicação) – Instituto de
Tecnologia de Lund. Universidade de Lund, Lund, Suécia, 2004.

MACHADO, C., A-Risk: Um método para identificar e quantificar risco de prazo em

projetos de desenvolvimento de software. 2002, 239 f. Dissertação (Mestrado em Ciências)
– Pontifícia Universidade Católica do Paraná, Curitiba, 2002.

MASCENA, J.C.C.P.; DE ALMEIDA, E.S.; DE LEMOS MEIRA, S.R., A comparative

study on software reuse metrics and economic models from a traceability perspective.
Information Reuse and Integration, Conf, 2005. IRI -2005 IEEE International Conference on,
vol., no., pp. 72-77, 15-17 Aug. 2005.

MAXWELL, K. D. Collecting data for comparability: benchmarking software development

productivity, IEEE Software, vol.18, no.5, pp. 22-25, Set/Out 2001.

MCCABE, T. J. A Complexity Measure. IEEE Transactions on Software Engineering,

vol.SE-2, no.4, pp. 308-320, Dez. 1976. Disponível em:
<http://ieeexplore.ieee.org/iel5/32/35895/01702388.pdf?isnumber=35895∏=JNL&arnumber=
1702388&arnumber=1702388&arSt=+308&ared=+320&arAuthor=McCabe%2C+T.J >.
Acesso em: 25 ago. 2008.

MCGARRY, F.; BURKE, S.; DECKER, B. Measuring the impacts individual process
maturity attributes have on software products. Software Metrics Symposium, 1998. Metrics
1998. Proceedings. Fifth International, vol., no., pp.52-60, 20-21, Nov, 1998.

MCGARRY, J.; et al. Practical Software Measurement: objective information for

decision makers. 1. ed. Boston: Addison-Wesley, 2002.
 140

MORESI, E. Metodologia da Pesquisa. Universidade Católica De Brasília, 2004.

MURDOCH, J. et al. Measuring safety: applying PSM to the system safety domain.
Proceedings of the 8th Australian workshop on Safety critical systems and software, vol.
33, pp. 47 - 55 , 2003.

OAKLAND, J. S. Statistical Process Control. Burlington, MA: Butterworth-Heinemann,

2003.

PAUL, R. et al. Software Metrics Knowledge and Databases for Project Management. IEEE
Transactions on Knowledge and Data Engineering, vol. 11, no. 1, pp. 255-264, Jan/Fev,
1999.

PMI – Project Management Institute. A Guide to the Project Management Body of

Knowledge: PMBOK Guide. 3a ed. 2004. Newtown Square, PA: Four Campus Boulevard,
2004. 1 CD-ROM.

PUTNAM, L.; MYERS, W. Five core metrics. New York, NY: Dorset House Publishing,
2003.

RAFFO, D. Software project management using PROMPT: A hybrid metrics, modeling and
utility framework.
Information and Software Technology, vol. 47, no. 15, pp. 1009-1017, Dez, 2005.

ROSEMBERG, L; SHEPPARD S. Metrics in software process assessment, quality assurance

and risk assessment. Proceedings of the Second International Software Metrics
Symposium, 1994, pp. 10-16, Out, 1994.

SEI – Software Engineering Institute. Software Size Measurement: A Framework for

Counting Source Statements. Pittsburgh, PA, EUA 1992. Disponível em:
<http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr20.92.pdf>. Acesso em: 22 jul.
2008.

SEI – Software Engineering Institute. Experiences in Implementing Measuremente

Programs. Pittsburgh, PA, EUA 2001. Disponível em:
 141

<http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01tn026.pdf>. Acesso em: 20 abr.

2008.

SEI – Software Engineering Institute. Applications of the Indicator Template for

Measurement and Analysis. Pittsburgh, PA, EUA 2004. Disponível em:
<http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn024.pdf>. Acesso em: 19 ago.
2007.

SEI – Software Engineering Institute. CMMI® for Development, Version 1.2. Pittsburgh,
PA, EUA 2006a. Disponível em:
<http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf>. Acesso em: 01 out.
2006.

SEI – Software Engineering Institute. The State of Software Measurement Practice:

Results of 2006 Survey. Pittsburgh, PA, EUA 2006b. Disponível em:
<http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr009.pdf>. Acesso em: 19 ago.
2007.

SOFTEX - Associação para Promoção da Excelência do Software Brasileiro. MPS.Br –

Melhoria de Processo do Software Brasileiro – Guia Geral (Versão 1.2). Brasília, DF,
2007. Disponível em: < http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>.
Acesso em: 27 out. 2007.

STAPENHRUST, T. Mastering Statistical Process Control: A handbook for process

performance using cases. Burlington, MA: Elsevier Butterworth-Heinemann, 2005.

STUTZKE, R. Measuring and Estimating Process Performance. 5th Annual CMMI

Technology Conference and User Group. Denver, Colorado, Nov 2005.

TAKARA, A.; BETTIN, A.; TOLEDO, C. Problems and Pitfalls in a CMMI level 3 to level 4
Migration Process, In: Sixth International Conference on the Quality of Information and
Communications Technology, 2007, Lisboa, Portugal, Anais… Disponível em: <
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4335220&arnumber=4335237&count
=33&index=16>. Acesso em: 02 out. 2007.
 142

VALERIANO, D. Gerenciamento Estratégico e Administração por Projetos. São Paulo:

Makron Books, 2001.

WAKELAND, W. W.; MARTIN, R. H.; RAFFO, D. M. Using Design of Experiments,

Sensitivity Analysis and Hybrid Simulation to Evaluate Changes to a Software Development
Process: A Case Study, In: Prossim 2003, 2003, Portland, OR, EUA, Anais... Disponível
em:
<http://www.sysc.pdx.edu/faculty/Wakeland/papers/SPIP_Manuscript_WakelandMartinRaffo
.pdf>. Acesso em: 5 out. 2006.

WANG, Q; LI, M. Measuring and Improving Software Process in China. isese,., 2005
International Symposium on Empirical Software Engineering, 2005. pp. 183-192

WHEELER, D. J.; CHAMBERS, D. S. Understanding Statistical Process Control.

Knoxville, TN: SPC Press, 1992.

XU, R et al. Research on CMMI-based Software Process Metrics. imsccs, First

International Multi Symposiums on Computer and Computational Sciences - Volume 2
(IMSCCS'06), 2006. pp. 391-397
 143

APÊNDICE A - LISTA COMPLETA DE MEDIDAS CITADAS NA LITERATURA

Categoria Nome consolidado Nome original Referências APs do

CMMI-DEV
aplicáveis
Custo Custo Custo McGarry et al (2002) Todas
Custo Custo Custo Paul et al (1999) Todas
Custo Custo Custo SEI (2006b) Todas
Custo Custo Custo / Orçamento Gopal, Mukhopadhyay e Todas
Krishnan (2005)
Custo Custo ao longo do tempo para o processo de gestão O custo ao longo do tempo para o processo de gestão Kulpa e Johnson (2008) QPM
quantitativa em comparação com o plano quantitativa em comparação com o plano
Custo Custo da gestão do risco versus o custo real dos O custo da gestão do risco versus o custo real dos Kulpa e Johnson (2008) RSKM
riscos riscos
Custo Custo da qualidade O custo da má qualidade Kulpa e Johnson (2008) PPQA, VER,
VAL
Custo Custo da qualidade Custo da qualidade Becker et al (2006) PPQA, VER,
VAL
Custo Custo da qualidade Custo da Qualidade Florac e Carleton (1999) PPQA, VER,
VAL
Custo Custo da qualidade Custo da Qualidade PMI (2004) PPQA, VER,
VAL
Custo Custo da qualidade Os custos para alcançar metas qualidade Kulpa e Johnson (2008) PPQA, VER,
VAL
Custo Custo das atividades de gestão do contrato, em Custos das atividades de gestão do contrato, em Kulpa e Johnson (2008) SAM
comparação com o plano comparação com o plano
Custo Custo das atividades para definição do processo Custos das atividades para definição do processo Kulpa e Johnson (2008) OPD
Custo Custo de prevenção defeito (por exemplo, reuniões Os custos de prevenção defeito (por exemplo, reuniões Kulpa e Johnson (2008) VER, VAL
de análise de causas e implementação de ações), de análise de causas e implementação de ações),
cumulativamente cumulativamente
Custo Custo de produtos comerciais (COTS) Custo de produtos comerciais (COTS) Kulpa e Johnson (2008) SAM
Custo Custo despendido na organização de atividades do Custo despendido na organização de atividades do Kulpa e Johnson (2008) OPF
processo avaliação, desenvolvimento e melhoria, processo avaliação, desenvolvimento e melhoria, em
em comparação com os planos para estas atividades comparação com os planos para estas atividades
Custo Custo despendido nas atividades de CM Custos despendidos nas atividades de CM Kulpa e Johnson (2008) CM
 144
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Custo Custo despendido nas atividades de planejamento Custo despendido nas atividades de planejamento em Kulpa e Johnson (2008) PP
em comparação com o plano comparação com o plano
Custo Custo para identificar e corrigir os defeitos, em O Custo para identificar e corrigir os defeitos, em Kulpa e Johnson (2008) VER, VAL
comparação com o custo estimado de não corrigir comparação com o custo estimado de não corrigir os
os defeitos defeitos
Custo Custo para implementar e testar as alterações Custo para implementar e testar as alterações Kulpa e Johnson (2008) TS
incorporadas, incluindo a estimativa inicial custos incorporadas, incluindo a estimativa inicial custos
reais reais
Custo Custo para incorporar os produtos COTS no projeto Custo para incorporar os produtos COTS no projeto Kulpa e Johnson (2008) SAM
Custo Custo real Custo real (CR - EVA) McGarry et al (2002) Todas
Custo Custo real Custo real (CR - EVA) Kulik e Weber (2002) Todas
Custo Custo real Custo real (CR - EVA) PMI (2004) Todas
Custo Custo real Custo real (CR - EVA) SEI (2006a), SEI (2006b) Todas
Custo Custo real Custo real (CR - EVA) Wang e Li (2005) Todas
Custo Custo-benefício da utilização do processo de Custo-benefício da utilização do processo de avaliação Kulpa e Johnson (2008) DAR
avaliação formal formal
Custo Estimativa no término Estimativa no término (ENT - EVA) McGarry et al (2002) Todas
Custo Estimativa no término Estimativa no término (ENT - EVA) Kulik e Weber (2002) Todas
Custo Estimativa no término Estimativa no término (ENT - EVA) PMI (2004) Todas
Custo Estimativa no término Estimativa no término (ENT - EVA) SEI (2006a), SEI (2006b) Todas
Custo Estimativa no término Estimativa no término (ENT - EVA) Wang e Li (2005) Todas
Custo Estimativa para terminar Estimativa para terminar (EPT - EVA) McGarry et al (2002) Todas
Custo Estimativa para terminar Estimativa para terminar (EPT - EVA) Kulik e Weber (2002) Todas
Custo Estimativa para terminar Estimativa para terminar (EPT - EVA) PMI (2004) Todas
Custo Estimativa para terminar Estimativa para terminar (EPT - EVA) SEI (2006a), SEI (2006b) Todas
Custo Estimativa para terminar Estimativa para terminar (EPT - EVA) Wang e Li (2005) Todas
Custo Financeiro Financeiro SEI (2006a) Todas
Custo Índice de desempenho de custos Índice de desempenho de custos (IDC - EVA) McGarry et al (2002) Todas
Custo Índice de desempenho de custos Índice de desempenho de custos (IDC - EVA) Kulik e Weber (2002) Todas
Custo Índice de desempenho de custos Índice de desempenho de custos (IDC - EVA) PMI (2004) Todas
Custo Índice de desempenho de custos Índice de desempenho de custos (IDC - EVA) SEI (2006a), SEI (2006b) Todas
Custo Índice de desempenho de custos Índice de desempenho de custos (IDC - EVA) Wang e Li (2005) Todas
Custo Índice de desempenho de custos cumulativo IDC cumulativo (IDCC - EVA). McGarry et al (2002) Todas
 145
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Custo Índice de desempenho de custos cumulativo IDC cumulativo (IDCC - EVA). Kulik e Weber (2002) Todas
Custo Índice de desempenho de custos cumulativo IDC cumulativo (IDCC - EVA). PMI (2004) Todas
Custo Índice de desempenho de custos cumulativo IDC cumulativo (IDCC - EVA). SEI (2006a), SEI (2006b) Todas
Custo Índice de desempenho de custos cumulativo IDC cumulativo (IDCC - EVA). Wang e Li (2005) Todas
Custo Orçamento no término Orçamento no término (ONT - EVA) McGarry et al (2002) Todas
Custo Orçamento no término Orçamento no término (ONT - EVA) Kulik e Weber (2002) Todas
Custo Orçamento no término Orçamento no término (ONT - EVA) PMI (2004) Todas
Custo Orçamento no término Orçamento no término (ONT - EVA) SEI (2006a), SEI (2006b) Todas
Custo Orçamento no término Orçamento no término (ONT - EVA) Wang e Li (2005) Todas
Custo Quantidade de mudanças no custo Alterações de cronograma, qualidade e custo Kulik e Weber (2002) CM
Custo Retorno do investimento Relação de custo-benefício em utilizar um processo de SEI (2006b) DAR
avaliação formal
Custo Retorno do investimento Retorno do investimento Gales e Avrahami (2005), PP, OPF,
Galin e Avrahami (2006) QPM, OID
Custo Retorno do investimento Retorno do investimento SEI (2006b) OID
Custo Total de custos de despesas pessoais e viagens Total de custos de despesas pessoais e viagens Lindström (2004) PP, PMC
Custo Total de custos inesperados Total de custos inesperados Lindström (2004) PP, PMC
Custo Valor planejado Valor planejado (PV - EVA) McGarry et al (2002) Todas
Custo Valor planejado Valor planejado (PV - EVA) Kulik e Weber (2002) Todas
Custo Valor planejado Valor planejado (PV - EVA) PMI (2004) Todas
Custo Valor planejado Valor planejado (PV - EVA) SEI (2006a), SEI (2006b) Todas
Custo Valor planejado Valor planejado (PV - EVA) Wang e Li (2005) Todas
Custo Variação de custo Razões dos valores estimados e reais dos parâmetros Kulpa e Johnson (2008) Todas
de planejamento (por exemplo, o tamanho, custo e
cronograma)
Custo Variação de custo Razões dos valores estimados e reais dos parâmetros Kulpa e Johnson (2008) Todas
de planejamento (por exemplo, o tamanho, custo e
cronograma)
Custo Variação de custo Variação de custo Becker et al (2006) Todas
Custo Variação de custo Variação de custo SEI (2006b) SAM
Custo Variação de custo (EVA) Variação de custo (VC - EVA) McGarry et al (2002) Todas
Custo Variação de custo (EVA) Variação de custo (VC - EVA) Kulik e Weber (2002) Todas
Custo Variação de custo (EVA) Variação de custo (VC - EVA) PMI (2004) Todas
 146
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Custo Variação de custo (EVA) Variação de custo (VC - EVA) SEI (2006a), SEI (2006b) Todas
Custo Variação de custo (EVA) Variação de custo (VC - EVA) Wang e Li (2005) Todas
Custo Variação de custo no acordo com o fornecedor Variação de custo no acordo com o fornecedor SEI (2006b) PP
Custo Variação de custo no acordo com o fornecedor Variância de custo no acordo com o fornecedor Kulpa e Johnson (2008) SAM, PMC
Custo Variação de custo por revisão do plano Variância de custo por revisão do plano Kulpa e Johnson (2008) PP
Custo Variação no término Variação no término (VNT - EVA) McGarry et al (2002) Todas
Custo Variação no término Variação no término (VNT - EVA) Kulik e Weber (2002) Todas
Custo Variação no término Variação no término (VNT - EVA) PMI (2004) Todas
Custo Variação no término Variação no término (VNT - EVA) SEI (2006a), SEI (2006b) Todas
Custo Variação no término Variação no término (VNT - EVA) Wang e Li (2005) Todas
Custo Variância de custo por revisão do plano Variância de custo por revisão do plano SEI (2006b) PP
Escopo Acoplamento das atividades no modelo de processo Acoplamento das atividades no modelo de processo García et al (2004) OID, OPD
Escopo Acoplamento entre classes de objetos Acoplamento entre classes de objetos Lindström (2004) TS, VER,
VAL
Escopo As estimativas do total de unidades As estimativas do total de unidades Kulpa e Johnson (2008) Todas
Escopo Atividades alteradas para os planos de mitigação Atividade de mudança para o plano de mitigação de SEI (2006b) RSKM
dos riscos riscos
Escopo Atividades alteradas para os planos de mitigação Atividades alteradas para os planos de mitigação dos Kulpa e Johnson (2008) RSKM
dos riscos riscos (por exemplo, processos, horários,
financiamento)
Escopo Cenários de perigos Cenários de perigos Murdoch et al (2003) RSKM
Escopo Cobertura de requisitos Cobertura de requisitos McGarry et al (2002) RD, REQM
Escopo Complexidade Complexidade Paul et al (1999) TS, VER,
VAL, PI
Escopo Complexidade Complexidade (métricas McCabe, McClure, e Kulpa e Johnson (2008) TS, VER,
Halstead) VAL, PI
Escopo Complexidade Complexidade de produto Agrawal e Chari (2007) TS, VER,
VAL, PI
Escopo Complexidade Complexidade de produto Florac e Carleton (1999) TS, VER,
VAL, PI
Escopo Complexidade Complexidade de produto SEI (2006b) TS, VER,
VAL, PI
Escopo Complexidade ciclomática Complexidade ciclomática McGarry et al (2002) TS, VER,
VAL, PI
 147
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Complexidade ciclomática Complexidade ciclomática Grady (1994) TS, VER,
VAL, PI
Escopo Complexidade ciclomática Complexidade ciclomática Kulik e Weber (2002) TS, VER,
VAL, PI
Escopo Complexidade ciclomática Complexidade ciclomática Lindström (2004) TS, VER,
VAL, PI
Escopo Complexidade ciclomática Complexidade ciclomática Resemberg e Sheppard TS, VER,
(1994) VAL, PI
Escopo Complexidade de código Complexidade de código Hall e Fenton (1997) TS, VER,
VAL, PI
Escopo Complexidade de dados Complexidade de dados Agrawal e Chari (2007) TS, VER,
VAL, PI
Escopo Complexidade de decisão Complexidade de decisão Agrawal e Chari (2007) TS, VER,
VAL, PI
Escopo Componentes críticos de segurança Componentes críticos de segurança Murdoch et al (2003) RSKM
Escopo Contador de perigo Contador de perigo Murdoch et al (2003) RSKM
Escopo Conteúdo incremental - componentes Conteúdo incremental - componentes McGarry et al (2002) TS, PI, VER e
VAL
Escopo Custo para implementar as solicitações de Custo para implementar as solicitações de mudanças Kulpa e Johnson (2008) CM
mudanças
Escopo Dimensões físicas Dimensões físicas McGarry et al (2002) Todas
Escopo Esforço para implementar as solicitações de Esforço para implementar as solicitações de mudanças Kulpa e Johnson (2008) CM
mudanças
Escopo Estabilidade de design Estabilidade de design Paul et al (1999) TS, CM
Escopo Estabilidade de requisitos Estabilidade de requisitos Florac e Carleton (1999) REQM, RD,
CM
Escopo Estabilidade de requisitos Estabilidade de requisitos Paul et al (1999) REQM, RD,
CM
Escopo Estabilidade de requisitos Estabilidade de requisitos/capacidade SEI (2006a) REQM, RD,
CM
Escopo Estabilidade de requisitos Índice de instabilidade de requisitos Xu (2006) REQM, RD,
CM
Escopo Estimativas e reutilização real do sistema Estimativas e reutilização real do sistema Kulpa e Johnson (2008) TS
Escopo Estimativas e tamanho físico real do sistema Estimativas e tamanho físico real do sistema Kulpa e Johnson (2008) PP
 148
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Estimativas e valor real de módulos e unidades de Estimativas e valor real de módulos e unidades de Kulpa e Johnson (2008) TS
design e código. design e código.
Escopo Estimativas e valor real do total de linhas de Estimativas e valor real do total de linhas de código- Kulpa e Johnson (2008) TS, PP
código-novo, modificadas, e reutilizadas novo, modificadas, e reutilizadas
Escopo Exposição ao risco e as alterações na exposição Exposição ao risco e as alterações na exposição para Kulpa e Johnson (2008) RSKM
para cada risco, bem como a percentagem resumida cada risco, bem como a percentagem resumida da
da reserva de gestão reserva de gestão
Escopo Exposição ao risco e as alterações na exposição Exposição ao risco e as alterações na exposição para SEI (2006b) RSKM
para cada risco, bem como a percentagem resumida cada risco, bem como a percentagem resumida da
da reserva de gestão reserva de gestão
Escopo Falta de coesão nos métodos Falta de coesão nos métodos Lindström (2004) TS, VER,
VAL
Escopo Fanout ao quadrado Fanout ao quadrado Grady (1994) TS, VER,
VAL
Escopo Freqüência de mudanças de processo Freqüência de mudanças de processo Wang e Li (2005) OPD, IPM,
OID
Escopo Funções críticas de segurança Funções críticas de segurança Murdoch et al (2003) RSKM
Escopo Integrações de produtos planejadas e realizadas Integrações de produtos planejadas e realizadas SEI (2006b) PI
Escopo Interfaces críticas de segurança Interfaces críticas de segurança Murdoch et al (2003) RSKM
Escopo Limitações físicas (e.g., peso e volume) Limitações físicas (e.g., peso e volume) SEI (2006b) Todas
Escopo Marcos completados na realização de tarefas Marcos completados na realização de tarefas Kulpa e Johnson (2008) IPM
específicas de um grupo para apoiar as atividades específicas de um grupo para apoiar as atividades de
de outros grupos e vice-versa. outros grupos e vice-versa.
Escopo Marcos completados para as atividade de QA em Marcos completados para as atividade de QA em Kulpa e Johnson (2008) PPQA
comparação com o plano comparação com o plano
Escopo Marcos completados para as atividades de CM em Marcos completados para as atividades de CM em Kulpa e Johnson (2008) CM
comparação com o plano comparação com o plano
Escopo Média de linhas de código nos novos arquivos Java Média de linhas de código nos novos arquivos Java Lindström (2004) TS, PP
Escopo Medidas de requisitos Medidas de requisitos Kulik e Weber (2002) REQM, RD
Escopo Métodos balanceados por classe Métodos balanceados por classe Lindström (2004) TS, VER,
VAL
Escopo Mitigações Mitigações Murdoch et al (2003) RSKM
Escopo Modos críticos de segurança Modos críticos de segurança Murdoch et al (2003) RSKM
Escopo Modularidade Modularidade Agrawal e Chari (2007) Todas
 149
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Mudanças durante os primeiros 90 dias após a Mudanças durante os primeiros 90 dias após a Buglione e Abran (2005) CM
implementação implementação
Escopo Mudanças tecnológicas, incluindo quantidade, o Mudanças tecnológicas, incluindo número, o tipo e Kulpa e Johnson (2008) OID, TS
tipo e tamanho de mudanças tamanho de mudanças
Escopo Nível de risco Nível de risco SEI (2006b) RSKM
Escopo Parâmetros características operacionais chaves do Parâmetros características operacionais chaves do Kulpa e Johnson (2008) OPD
ambiente de trabalho ambiente de trabalho
Escopo Percentual de projetos utilizando o conjunto de Percentual de projetos utilizando o conjunto de SEI (2006b) OPF
processos padrão da organização processos padrão da organização
Escopo Perfil de integração de produto-componente Perfil de integração de produto-componente Kulpa e Johnson (2008) PI
Escopo Perfil de subprocessos sob gestão estatística Perfil de subprocessos sob gestão estatística Kulpa e Johnson (2008) QPM
Escopo Perfil de verificação Perfil de verificação Kulpa e Johnson (2008) VER
Escopo Perfis medindo a quantidade itens de ação Perfis medindo o número itens de ação propostos, Kulpa e Johnson (2008) CAR, PMC
propostos, abertos, e concluídos abertos, e concluídos
Escopo Quantidade de pontos de função Pontos de Função Agrawal e Chari (2007) Todas
Escopo Quantidade de pontos de função Pontos de função McGarry et al (2002) Todas
Escopo Quantidade de pontos de função Pontos de Função Grady (1994) Todas
Escopo Quantidade de pontos de função Pontos de função Hall e Fenton (1997) Todas
Escopo Quantidade de pontos de função Pontos de Função IEEE (1992) Todas
Escopo Quantidade de pontos de função Pontos de função Kulik e Weber (2002) Todas
Escopo Quantidade de pontos de função Pontos de função Lindström (2004) Todas
Escopo Quantidade de pontos de função Pontos de função SEI (2006b) Todas
Escopo Quantidade de pontos de função Pontos de Função Xu (2006) Todas
Escopo Quantidade de pontos de função Tamanho em pontos de função Herbsleb e Grinter (1998) Todas
Escopo Quantidade de pontos de função completos Pontos de função completos (full function points) Buglione e Abran (2005) Todas
Escopo Quantidade de pontos de objeto Pontos de objeto Lindström (2004) Todas
Escopo Premissas e avaliações de segurança Premissas e avaliações de segurança Murdoch et al (2003) RSKM
Escopo Profundidade da árvore de heranças de uma classe Profundidade da árvore de heranças de uma classe Lindström (2004) TS, VER,
VAL
Escopo Quantidade de ações corretivas abertas e fechadas Número de ações corretivas abertas e fechadas SEI (2006b) PMC
Escopo Quantidade de alterações do processo definido para Número de alterações do processo definido para o Kulpa e Johnson (2008) IPM
o projeto projeto
Escopo Quantidade de alterações feitas aos requisitos do Número de alterações aos requisitos do acordo com o Kulpa e Johnson (2008) SAM, CM
fornecedor fornecedor
 150
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Quantidade de alternativas consideradas Número de alternativas consideradas SEI (2006b) DAR
Escopo Quantidade de atividades do modelo de processo de Número de atividades do modelo de processo de García et al (2004) OID, OPD
software software
Escopo Quantidade de auditorias de configuração realizadas Número de auditorias de configuração realizadas SEI (2006b) CM
Escopo Quantidade de avaliações de processos de Número de avaliações de processos de fornecedor SEI (2006b) SAM
fornecedor realizadas realizadas
Escopo Quantidade de causas raiz removidas Número de causas removidas Kulpa e Johnson (2008) CAR
Escopo Quantidade de classes e objetos Número de classes e objetos SEI (2006b) Todas
Escopo Quantidade de classes e objetos Número de novas classes Java Lindström (2004) TS, VER,
VAL
Escopo Quantidade de código reutilizado Quantidade de código reutilizado Buglione e Abran (2005) TS, VER,
VAL
Escopo Quantidade de componentes Componentes McGarry et al (2002) TS, PI, VER e
VAL
Escopo Quantidade de dependências de entrada dos Número de dependências de entrada dos produtos de García et al (2004) OID, OPD
produtos de trabalho com as atividades do processo trabalho com as atividades do processo
Escopo Quantidade de dependências de precedência entre Número de dependências de precedência entre as García et al (2004) OID, OPD
as atividades atividades
Escopo Quantidade de dependências de saída dos produtos Número de dependências de saída dos produtos de García et al (2004) OID, OPD
de trabalho com as atividades do processo trabalho com as atividades do processo
Escopo Quantidade de dependências entre os produtos de Número de dependências entre os produtos de trabalho García et al (2004) OID, OPD
trabalho e atividades e atividades
Escopo Quantidade de elementos de processo alterados Número de elementos de processo alterados dentro de Stutzke (2005) OPD, IPM,
dentro de um intervalo de tempo um intervalo de tempo OID
Escopo Quantidade de entradas e saídas Número de entradas e saídas SEI (2006b) Todas
Escopo Quantidade de filhos Número de filhos Lindström (2004) TS, VER,
VAL
Escopo Quantidade de funções Conteúdo incremental - funções McGarry et al (2002) TS, PI, VER e
VAL
Escopo Quantidade de funções Número de funções SEI (2006b) Todas
Escopo Quantidade de instruções de código Declaração de código lógico (LSS - Logical source IEEE (1992) TS, VER,
statement) VAL
Escopo Quantidade de interfaces Interfaces McGarry et al (2002) PI, VER,
VAL
 151
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Quantidade de itens de risco técnico Número de itens de risco técnico SEI (2006b) Todas
Escopo Quantidade de linhas de base de desempenho de Número de linhas de base de desempenho de processo Kulpa e Johnson (2008) OPP
processo criadas e mantidas criadas e mantidas
Escopo Quantidade de linhas de código Declaração de código físico (PSS - Physical source IEEE (1992) TS, PI, PP,
statement) VER, VAL
Escopo Quantidade de linhas de código Linha de código Florac e Carleton (1999) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código McGarry et al (2002) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código Hall e Fenton (1997) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código Kulik e Weber (2002) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código Lindström (2004) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código Xu (2006) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código fonte Agrawal e Chari (2007) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Linhas de código-fonte armazenadas em bibliotecas e Kulpa e Johnson (2008) TS, PI, PP,
colocadas sob controle da configuração VER, VAL
Escopo Quantidade de linhas de código Linhas de código-fonte SEI (2006b) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Milhares de linhas de código não comentadas Grady (1994) TS, PI, PP,
(KNCSS) VER, VAL
Escopo Quantidade de linhas de código Quantidade de código total Buglione e Abran (2005) TS, PI, PP,
VER, VAL
Escopo Quantidade de linhas de código Total de linhas de código Resemberg e Sheppard TS, PI, PP,
(1994) VER, VAL
Escopo Quantidade de linhas de código Java Número total de linhas de código Java Lindström (2004) TS, PP, VER,
VAL
Escopo Quantidade de linhas de código não comentadas Linhas de código não comentadas Lindström (2004) TS, PP, VER,
VAL
Escopo Quantidade de linhas de código não comentadas de Número de linhas de código não comentadas (NCSS) Lindström (2004) TS, PP, VER,
 152
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
testes Junit de testes JUnit VAL
Escopo Quantidade de linhas de código não comentadas Linhas de código não comentadas (NCSS) excluídas Lindström (2004) TS, PP, VER,
excluídas VAL
Escopo Quantidade de linhas de código não comentadas Novas linhas de código não comentadas (NCSS) Lindström (2004) TS, PP, VER,
incluídas VAL
Escopo Quantidade de linhas de código não comentadas Linhas de código não comentadas (NCSS) Lindström (2004) TS, PP, VER,
modificadas modificadas VAL
Escopo Quantidade de linhas de código nos novos arquivos Número de linhas de código nos novos arquivos Java Lindström (2004) TS, PP, VER,
Java VAL
Escopo Quantidade de melhorias de processo propostas Número de melhorias de processo propostas aceitas Kulpa e Johnson (2008) OID, OPD
aceitas por período por período
Escopo Quantidade de melhorias de processo propostas O número de melhorias de processo propostas Kulpa e Johnson (2008) OID, OPD
apresentadas por cada projeto, o grupo e apresentadas por cada projeto, o grupo e departamento
departamento
Escopo Quantidade de melhorias de processo propostas e Número de melhorias de processo submetidas, aceitas SEI (2006b) OPF
implementadas para cada área de processo ou implementadas
Escopo Quantidade de melhorias de processo propostas e O número de melhorias de processo propostas e Kulpa e Johnson (2008) OID, OPD
implementadas para cada área de processo implementadas para cada área de processo
Escopo Quantidade de modelos de desempenho de processo Número de modelos de desempenho de processo Kulpa e Johnson (2008) OPP
criados e mantidos criados e mantidos
Escopo Quantidade de módulos de design Número de módulos de design / unidades entregues Kulpa e Johnson (2008) TS
Escopo Quantidade de mudanças Mudanças na linha de base McGarry et al (2002) Todas
Escopo Quantidade de mudanças Número de mudanças nos itens de configuração SEI (2006b) Todas
Escopo Quantidade de mudanças Número de mudanças por categoria, o tipo e gravidade Kulpa e Johnson (2008) Todas
Escopo Quantidade de mudanças aceitas, mas não Número de solicitações de mudanças aceitas, mas não Kulpa e Johnson (2008) CM, REQM,
implementadas implementadas Todas
Escopo Quantidade de mudanças de engenharia propostas Número de mudanças de engenharia propostas Kulpa e Johnson (2008) CM, REQM,
apresentadas, aprovadas, rejeitadas e apresentadas, aprovadas, rejeitadas e implementadas Todas
implementadas
Escopo Quantidade de mudanças de requisitos Número acumulativo de mudanças nos requisitos Kulpa e Johnson (2008) REQM, CM
Escopo Quantidade de mudanças de requisitos durante a Número de requisitos alterados durante a Kulpa e Johnson (2008) REQM, CM
implementação e testes implementação e testes
Escopo Quantidade de mudanças de requisitos não Número de mudanças de requisitos não contabilizadas SEI (2006b) REQM
contabilizadas depois de estabelecer a linha de base depois de estabelecer a linha de base
 153
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Quantidade de mudanças na equipe Mudanças na equipe McGarry et al (2002) PP, IPM
Escopo Quantidade de mudanças no processo definido para Número de mudanças no processo definido para o SEI (2006b) IPM
o projeto projeto
Escopo Quantidade de mudanças por categoria ao código Número de mudanças por categoria ao código fonte e Kulpa e Johnson (2008) CM, TS
fonte e documentação de apoio documentação de apoio
Escopo Quantidade de mudanças realizadas nos requisitos Número de mudanças realizadas nos requisitos do SEI (2006b) SAM
do fornecedor fornecedor
Escopo Quantidade de opções de customização exercitadas Número de opções de customização exercitadas pelo SEI (2006b) IPM
pelo projeto para criar o seu processo definido projeto para criar o seu processo definido
Escopo Quantidade de páginas de documento Número de páginas SEI (2006b) Todas
Escopo Quantidade de páginas de documento Número de páginas de documento IEEE (1992) VER, VAL
Escopo Quantidade de páginas de documento Número de páginas de documento Xu (2006) VER, VAL
Escopo Quantidade de papéis que participam do processo Número de papéis que participam do processo García et al (2004) OID, OPD
Escopo Quantidade de peças (por exemplo, circuitos Número de peças (por exemplo, circuitos impressos SEI (2006b) Todas
impressos placas, componentes e peças mecânicos) placas, componentes e peças mecânicos)
Escopo Quantidade de pedidos de mudanças processados Número de pedidos de mudanças processados por Kulpa e Johnson (2008) CM, REQM,
por unidade de tempo unidade de tempo Todas
Escopo Quantidade de portas lógica para circuitos Número de portas lógicas para circuitos integrados SEI (2006b) Todas
integrados
Escopo Quantidade de processos e subprocessos incluídos Número de processos e subprocessos incluídos nas Kulpa e Johnson (2008) OPP
nas análises de desempenho de processos da análises de desempenho de processos da organização
organização
Escopo Quantidade de produtos de trabalho do modelo de Número de produtos de trabalho do modelo de García et al (2004) OID, OPD
processo de software processo de software
Escopo Quantidade de propostas de melhoria de processos Número de propostas de melhoria de processos Kulpa e Johnson (2008) OID, OPD
apresentadas, aceitas, ou implementadas apresentadas, aceitas, ou implementadas
Escopo Quantidade de requisitos Número de requisitos Florac e Carleton (1999) Todas
Escopo Quantidade de requisitos Número de requisitos Lindström (2004) Todas
Escopo Quantidade de requisitos Número de requisitos SEI (2006b) Todas
Escopo Quantidade de requisitos Número de requisitos por tipo ou situação Kulpa e Johnson (2008) Todas
Escopo Quantidade de requisitos Requisitos McGarry et al (2002) Todas
Escopo Quantidade de requisitos abordados no produto ou Número de requisitos abordados no produto ou no Kulpa e Johnson (2008) TS
no design do produto design do produto
Escopo Quantidade de requisitos críticos depois do início Número de requisitos críticos depois do início do Lindström (2004) RD, REQM
 154
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
do projeto projeto
Escopo Quantidade de requisitos críticos finalizados Número de requisitos críticos finalizados Lindström (2004) RD, REQM
Escopo Quantidade de requisitos introduzidos a cada fase Número de requisitos introduzidos a cada fase do ciclo SEI (2006b) RD
do ciclo de vida de vida
Escopo Quantidade de revisões aos planos de projeto Número de revisões ao plano SEI (2006b) PP
Escopo Quantidade de revisões aos planos de projeto Número de revisões aos planos de projeto Kulpa e Johnson (2008) PP, CM
Escopo Quantidade de riscos Ações, riscos e problemas SEI (2006a), SEI (2006b) RSKM
Escopo Quantidade de riscos Número de riscos identificados, geridos, monitorados Kulpa e Johnson (2008) RSKM
e controlados
Escopo Quantidade de tokens no documento Número de tokens no documento IEEE (1992) VER, VAL
Escopo Quantidade de turmas de treinamento realizadas Número de turmas de treinamento realizadas SEI (2006b) OT
Escopo Quantidade de vezes em que as mudanças são Número de vezes em que as mudanças são substituídas Kulpa e Johnson (2008) CM
substituídas por outra pessoa (ou quantidade de por outra pessoa (ou número de vezes em que as
vezes em que as pessoas tenham errado versão pessoas tenham errado versão inicial ou linha de base
inicial ou linha de base
Escopo Quantidade e complexidade das interfaces Número e complexidade das interfaces SEI (2006b) Todas
Escopo Quantidade e tamanho de solicitações de mudanças Número e tamanho de solicitações de mudanças após Kulpa e Johnson (2008) REQM, RD,
após o término da fase de requisitos o término da fase de requisitos CM
Escopo Quantidade e tipo de revisões realizadas Número e tipo de revisões realizadas SEI (2006b) PMC
Escopo Quantidade e tipos de riscos organizacionais ou de Número e tipos de riscos organizacionais ou de SEI (2006b) OID
projetos mitigados pela melhoria tecnológica ou de projetos mitigados pela melhoria tecnológica ou de
processo processo
Escopo Quantidade inicial de requisitos críticos Número inicial de requisitos críticos Lindström (2004) RD, REQM
Escopo Rastreabilidade de requisitos Rastreabilidade de requisitos Paul et al (1999) REQM
Escopo Razão entre as dependências de entrada dos Razão entre as dependências de entrada dos produtos García et al (2004) OID, OPD
produtos de trabalho com as atividades e o número de trabalho com as atividades e o número total de
total de dependências dos produtos de trabalho com dependências dos produtos de trabalho com as
as atividades atividades
Escopo Razão entre as dependências de saída dos produtos Razão entre as dependências de saída dos produtos de García et al (2004) OID, OPD
de trabalho com as atividades e o número total de trabalho com as atividades e o número total de
dependências dos produtos de trabalho com as dependências dos produtos de trabalho com as
atividades atividades
Escopo Razão entre os papéis do processo e as atividades Razão entre os papéis do processo e as atividades García et al (2004) OID, OPD
Escopo Razão entre os produtos de trabalho e as atividades Razão entre os produtos de trabalho e as atividades García et al (2004) OID, OPD
 155
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Relacionada a requisitos Relacionada a requisitos SEI (2006a) RD, REQM
Escopo Relacionadas à código Relacionadas à código SEI (2006a) TS
Escopo Requisitos de segurança Requisitos de segurança Murdoch et al (2003) RSKM
Escopo Resposta para uma classe Resposta para uma classe Lindström (2004) TS, VER,
VAL
Escopo Reuso de código Reuso McGarry, Burke e Decker TS
(1998)
Escopo Reuso de código Reuso de código Kulik e Weber (2002) TS
Escopo Reuso de código Reuso de código Lindström (2004) TS
Escopo Situação das solicitações de mudanças Situação das solicitações de mudanças McGarry et al (2002) CM
Escopo Situação dos itens de ação Situação dos itens de ação McGarry et al (2002) PMC, IPM,
QPM
Escopo Situação dos requisitos Situação dos requisitos McGarry et al (2002) RD, REQM
Escopo Situação dos requisitos (percentagem das Situação dos requisitos (percentagem das Kulpa e Johnson (2008) RD, REQM
especificações definidas fora do total aprovado e especificações definidas fora do total aprovado e
proposto; série de requisitos definidos) proposto; série de requisitos definidos)
Escopo Tamanho Tamanho Chikofsty e Rubin (1999) Todas
Escopo Tamanho Tamanho Kitchenham et al (2006) Todas
Escopo Tamanho Tamanho McGarry, Burke e Decker Todas
(1998)
Escopo Tamanho Tamanho atual Lindström (2004) Todas
Escopo Tamanho Tamanho de produto Eickelmann e Anant Todas
(2003)
Escopo Tamanho Tamanho de produto Florac e Carleton (1999) Todas
Escopo Tamanho Tamanho de produto Gopal, Mukhopadhyay e Todas
Krishnan (2005)
Escopo Tamanho Tamanho de produto SEI (2006a) Todas
Escopo Tamanho da base de dados Tamanho da base de dados McGarry et al (2002) TS, PI, VER e
VAL
Escopo Tamanho da página de documento Tamanho da página de documento IEEE (1992) VER, VAL
Escopo tamanho e a complexidade do produto, os produtos O tamanho e complexidade do produto, os produtos Kulpa e Johnson (2008) TS, VER,
componentes, interfaces e documentação componentes, interfaces e documentação VAL
Escopo Tamanho para implementar e testar as alterações Tamanho para implementar e testar as alterações Kulpa e Johnson (2008) TS
incorporadas, incluindo a estimativa inicial e incorporadas, incluindo a estimativa inicial e tamanho
 156
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
tamanho reais reais
Escopo Taxa de atividades de validação completadas Número de atividades de validação completadas SEI (2006b) VAL
Escopo Taxa de atividades de validação completadas Número de atividades de validação concluídas Kulpa e Johnson (2008) VAL
(planejada versus real)
Escopo Taxa de auditorias de qualidade realizadas Número de avaliações formais realizadas no âmbito do Kulpa e Johnson (2008) DAR
projeto (previsto x real)
Escopo Taxa de cursos de formação realizados Número de cursos de formação realizados (por Kulpa e Johnson (2008) OT
exemplo, planejada versus real)
Escopo Taxa de diagramas concluídos Número de diagramas concluídos versus o total Kulpa e Johnson (2008) TS
estimado diagramas
Escopo Taxa de GOTOs Percentual de GOTOs Resemberg e Sheppard TS, VER,
(1994) VAL
Escopo Taxa de mudanças A atividade total de mudança, incluindo número, o Kulpa e Johnson (2008) CM, REQM,
tipo e tamanho de mudanças Todas

Número de alterações à itens de configuração

Número de alterações incorporadas na linha de base

por categoria (por exemplo, interface, a segurança, a
configuração do sistema, o desempenho e a
usabilidade)
Escopo Taxa de mudanças Número de mudanças Resemberg e Sheppard CM, REQM,
(1994) Todas
Escopo Taxa de mudanças Taxa de mudança Florac e Carleton (1999) CM, REQM,
Todas
Escopo Taxa de objetivos de medição endereçados Percentual de objetivos de medição endereçados SEI (2006b) MA
Escopo Taxa de processos atualmente sob controle Número de processos atualmente sob controle SEI (2006b) QPM
estatístico estatístico em relação ao número de processos
planejados
Escopo Taxa de processos estatisticamente estáveis Número de processos estatisticamente estáveis em SEI (2006b) QPM
relação ao número de processos sob controle
estatístico
Escopo Taxa de produtos de trabalho revisados Número de produtos de trabalho revisados em Kulpa e Johnson (2008) VER, VAL
comparação com o plano
 157
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Taxa de projetos utilizando a arquitetura e Percentual de projetos utilizando a arquitetura e SEI (2006b) OPD
elementos de processo do conjunto de processos elementos de processo do conjunto de processos
padrão da organização padrão da organização
Escopo Taxa de projetos utilizando métricas de Percentual de projetos utilizando métricas de SEI (2006b) MA
desempenho e progresso desempenho e progresso
Escopo Taxa de requisitos aprovados para construir Número de requisitos aprovados para construir (versus Kulpa e Johnson (2008) RD, REQM,
o número total de requisitos) TS
Escopo Taxa de requisitos documentados Número real de requisitos documentados (versus o Kulpa e Johnson (2008) RD, REQM
número total estimado de requisitos)
Escopo Taxa de requisitos endereçados no design do Percentual de requisitos endereçados no design do SEI (2006b) TS
produto ou componentes produto ou componente
Escopo Taxa de revisões em pares realizadas Número de revisões em pares realizadas, em Kulpa e Johnson (2008) VER, VAL
comparação com o plano
Escopo Taxa de riscos % de riscos totais do projeto Kulik e Weber (2002) RSKM
Escopo Taxa de solicitações de mudanças Número de solicitações de mudanças versus o número Kulpa e Johnson (2008) CM, REQM,
total de solicitações de mudanças durante a vida do Todas
projeto
Escopo Taxa de treinamentos planejados completados Percentual de treinamentos planejados completados SEI (2006b) OT
Escopo Taxa de unidades codificadas e testadas O número de unidades codificadas e testadas versus o Kulpa e Johnson (2008) TS, VER,
número planejado VAL
Escopo Taxa de verificações realizadas Número de verificações realizadas e planejadas SEI (2006b) VER
Escopo Tempo para implementar as solicitações de Tempo para implementar as solicitações de mudanças Kulpa e Johnson (2008) CM
mudanças
Escopo Trabalho concluído na organização de atividades do Trabalho concluído na organização de atividades do Kulpa e Johnson (2008) OPF
processo avaliação, desenvolvimento e melhoria, processo avaliação, desenvolvimento e melhoria, em
em comparação com os planos para estas atividades comparação com os planos para estas atividades
Escopo Trabalho concluído nas atividades de CM Trabalho concluído nas atividades de CM Kulpa e Johnson (2008) CM
Escopo Trabalho concluído nas atividades de planejamento Trabalho concluído nas atividades de planejamento em Kulpa e Johnson (2008) PP
em comparação com o plano comparação com o plano
Escopo Trabalho concluído nas atividades de QA em Trabalho concluído nas atividades de QA em Kulpa e Johnson (2008) PPQA
comparação com o plano comparação com o plano
Escopo Valor agregado Valor agregado (VA - EVA) McGarry et al (2002) Todas
Escopo Valor agregado Valor agregado (VA - EVA) Kulik e Weber (2002) Todas
Escopo Valor agregado Valor agregado (VA - EVA) PMI (2004) Todas
 158
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Escopo Valor agregado Valor agregado (VA - EVA) SEI (2006a), SEI (2006b) Todas
Escopo Valor agregado Valor agregado (VA - EVA) Wang e Li (2005) Todas
Escopo Variação de avaliações de processos realizadas e Variação de avaliações de processos realizadas e SEI (2006b) PPQA
planejadas planejadas
Escopo Variação de avaliações de produtos realizadas e Variação de avaliações de produtos realizadas e SEI (2006b) PPQA
planejadas planejadas
Escopo Variação de tamanho Precisão da estimativa de tamanho Florac e Carleton (1999) Todas
Escopo Variação de tamanho Crescimento de tamanho SEI (2006b) OPP
Escopo Variação de tamanho Variação de tamanho Becker et al (2006) Todas
Escopo Variação de tamanho Variação de tamanho SEI (2006b) SAM
Escopo Variação de tamanho Variação de tamanho Xu (2006) Todas
Escopo Variação de tamanho de código Crescimento de código SEI (2006a) TS
Escopo Variação de tamanho de código-fonte Aumento percentual de código-fonte planeado versus Kulpa e Johnson (2008) Todas
real
Escopo Volatilidade de requisitos Volatilidade de requisitos Agrawal e Chari (2007) REQM, RD,
CM
Escopo Volatilidade de requisitos Volatilidade de requisitos Lindström (2004) REQM, RD,
CM
Escopo Volatilidade de requisitos Volatilidade de requisitos SEI (2006b) REQM, RD,
CM
Escopo Volatilidade de requisitos Volatilidade de requisitos (isto é, número de exigência Kulpa e Johnson (2008) REQM, RD,
por mudanças por fase) CM
Escopo Volatilidade de requisitos Volatilidade de requisitos Becker et al (2006) REQM, RD,
CM
Escopo Volatilidade do software Volatilidade do software Agrawal e Chari (2007) REQM, RD,
CM
Escopo Volatilidade na categorização dos riscos Volatilidade na categorização dos riscos Kulpa e Johnson (2008) RSKM
Escopo Volatilidade na categorização dos riscos Volatilidade na categorização dos riscos SEI (2006b) Todas
Escopo Volume de dados Volume de dados SEI (2006b) Todas
Escopo Zonas de segurança Zonas de segurança Murdoch et al (2003) RSKM
Esforço Adequação de recursos Adequação de recursos Kulik e Weber (2002) PP
Esforço Atividade de mudanças para o plano do projeto, que Atividade de mudanças para o plano do projeto, que Kulpa e Johnson (2008) PMC
inclui alterações nas estimativas de tamanho dos inclui alterações nas estimativas de tamanho dos
produtos de trabalho, as estimativas de custos, as produtos de trabalho, as estimativas de custos, as
 159
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
estimativas dos recursos, e cronograma estimativas dos recursos, e cronograma
Esforço Carga de trabalho para mudança de segurança Carga de trabalho para mudança de segurança Murdoch et al (2003) RSKM
Esforço Comparação do estimado versus o real para o Comparação do estimado versus o real para o impacto SEI (2006b) RSKM
impacto e esforço de mitigação do risco. e esforço de mitigação do risco.
Esforço Disponibilidade de recursos Disponibilidade de recursos McGarry et al (2002) IPM, PP
Esforço Distribuição de esforço Distribuição de esforço Wang e Li (2005) PP
Esforço Equipe Equipe SEI (2006b) Todas
Esforço Esforço As estimativas do total de esforço Kulpa e Johnson (2008) Todas
Esforço Esforço Esforço Chikofsty e Rubin (1999) Todas
Esforço Esforço Esforço McGarry et al (2002) Todas
Esforço Esforço Esforço Florac e Carleton (1999) Todas
Esforço Esforço Esforço Gopal, Mukhopadhyay e Todas
Krishnan (2005)
Esforço Esforço Esforço Kitchenham et al (2006) Todas
Esforço Esforço Esforço atual Lindström (2004) Todas
Esforço Esforço Esforço de desenvolvimento Resemberg e Sheppard Todas
(1994)
Esforço Esforço Esforço de desenvolvimento de software Agrawal e Chari (2007) Todas
Esforço Esforço Esforço em homem/mês Herbsleb e Grinter (1998) Todas
Esforço Esforço Esforço gasto Debou, Kuntzmann- Todas
Combelles e Rowe (1994)
Esforço Esforço Esforço realizado nas tarefas SEI (2006a), SEI (2006b) Todas
Esforço Esforço Esforço de trabalho Buglione e Abran (2005) Todas
Esforço Esforço Homem/hora IEEE (1992) Todas
Esforço Esforço de codificação Esforço de codificação Xu (2006) TS
Esforço Esforço de configuração e mudanças Esforço de configuração e mudanças Xu (2006) CM
Esforço Esforço de design Esforço de design Xu (2006) TS
Esforço Esforço de garantia da qualidade (QA) Esforço de garantia da qualidade (QA) Xu (2006) PPQA
Esforço Esforço de gerenciamento de projetos Esforço de gerenciamento de projetos Xu (2006) PP, PMC,
IPM
Esforço Esforço de mudanças Esforço de mudança funcional McGarry et al (2002) CM
Esforço Esforço de outras atividades Esforço de outras atividades Xu (2006) Todas
Esforço Esforço de replanejamento devido às solicitações de Esforço de replanejamento devido às solicitações de Kulpa e Johnson (2008) PP, CM
 160
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
mudanças mudanças
Esforço Esforço de requisitos Esforço (total e por atividade de desenvolvimento de Kulpa e Johnson (2008) RD, REQM
requisitos)
Esforço Esforço de requisitos Esforço de requisitos Xu (2006) RD, REQM
Esforço Esforço de revisão Esforço de inspeção Buglione e Abran (2005) VER, VAL
Esforço Esforço de revisão Esforço despendido em revisões pelos pares, em Kulpa e Johnson (2008) VER, VAL
comparação com o plano
Esforço Esforço de revisão Esforço gasto na revisão em pares Lindström (2004) VER, VAL
Esforço Esforço de revisão Esforço para customizar o conjunto de processos SEI (2006b) IPM
padrão da organização para o projeto
Esforço Esforço de suporte Esforço de suporte Xu (2006) Todas
Esforço Esforço de testes Esforço de testes Buglione e Abran (2005) VER, VAL
Esforço Esforço de testes Esforço de testes Xu (2006) VER, VAL
Esforço Esforço de treinamento Esforço de treinamento Xu (2006) OT
Esforço Esforço despendido ao longo do tempo para gerir o Esforço despendido ao longo do tempo para gerir o Kulpa e Johnson (2008) PP, PMC,
projeto em comparação com o plano projeto em comparação com o plano IPM
Esforço Esforço despendido na organização de atividades do Esforço despendido na organização de atividades do Kulpa e Johnson (2008) OPF
processo avaliação, desenvolvimento e melhoria, processo avaliação, desenvolvimento e melhoria, em
em comparação com os planos para estas atividades comparação com os planos para estas atividades
Esforço Esforço despendido nas atividades de CM Esforço despendido nas atividades de CM Kulpa e Johnson (2008) CM
Esforço Esforço despendido nas atividades de planejamento Esforço despendido nas atividades de planejamento Kulpa e Johnson (2008) PP
em comparação com o plano em comparação com o plano
Esforço Esforço despendido nas atividades de QA em Esforço despendido nas atividades de QA em Kulpa e Johnson (2008) PPQA
comparação com o plano comparação com o plano
Esforço Esforço despendido para gerir a avaliação das Esforço despendido para gerir a avaliação das fontes e Kulpa e Johnson (2008) SAM
fontes e seleção de fornecedores seleção de fornecedores
Esforço Esforço e outros recursos despendidos na realização Esforço e outros recursos despendidos na realização de Kulpa e Johnson (2008) PMC
de atividades de acompanhamento e fiscalização atividades de acompanhamento e fiscalização
Esforço Esforço estimado versus real de mitigação dos Esforço estimado versus real de mitigação dos riscos Kulpa e Johnson (2008) RSKM
riscos
Esforço Esforço extra Esforço extra Debou, Kuntzmann- Todas
Combelles e Rowe (1994)
Esforço Esforço gasto em atividades de gestão do risco Esforço gasto em atividades de gestão do risco versus Kulpa e Johnson (2008) RSKM
versus a quantidade de riscos reais o número de riscos reais
 161
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Esforço Esforço gasto em tarefas não planejadas Esforço gasto em tarefas não planejadas Debou, Kuntzmann- PP, IPM
Combelles e Rowe (1994)
Esforço Esforço gasto na principal fase da construção Esforço gasto na principal fase da construção Lindström (2004) TS
Esforço Esforço gasto no suporte e manutenção de projetos Esforço gasto no suporte e manutenção de projetos Lindström (2004) VER, VAL
legados legados
Esforço Esforço para adaptar o conjunto de processos Esforço para adaptar o conjunto de processos padrão Kulpa e Johnson (2008) IPM, OPD
padrão da organização da organização
Esforço Esforço para analisar as alterações propostas para Esforço para analisar as alterações propostas para cada Kulpa e Johnson (2008) CM
cada solicitação de mudança e totais acumulados solicitação de mudança e totais acumulados
Esforço Esforço para incorporar os produtos COTS no Esforço para incorporar os produtos COTS no projeto Kulpa e Johnson (2008) SAM
projeto
Esforço Esforço para reuso Esforço de trabalho para reuso Buglione e Abran (2005) TS
Esforço Esforço real e outros recursos despendidos por um Esforço real e outros recursos despendidos por um Kulpa e Johnson (2008) IPM
grupo para apoiar outro grupo ou grupos, e vice- grupo para apoiar outro grupo ou grupos, e vice-versa
versa
Esforço Estimativa de recursos Estimativa de recursos Hall e Fenton (1997) Todas
Esforço Estimativas e esforço real do sistema Estimativas e esforço real do sistema Kulpa e Johnson (2008) Todas
Esforço Estimativas e valor real para o total de horas de Estimativas e valor real para o total de horas de CPU Kulpa e Johnson (2008) Todas
CPU utilizadas até a data utilizadas até a data
Esforço Freqüência, causas, e a magnitude do esforço Freqüência, causas, e a magnitude do esforço Kulpa e Johnson (2008) PP
replanejamento replanejamento
Esforço Média de dias ausentes não planejados por mês Média de dias ausentes não planejados por mês Lindström (2004) PP, IPM
Esforço Mudanças de equipe (turnover) Mudanças de equipe (turnover) Kulik e Weber (2002) PMC
Esforço O esforço (homem/hora) total estimado e real para O esforço (homem/hora) total estimado e real para Kulpa e Johnson (2008) TS
desenvolver o sistema de trabalho por categoria e desenvolver o sistema de trabalho por categoria e
atividade atividade
Esforço Percentagem do total esforço despendido nas Percentagem do total esforço despendido nas diversas Kulpa e Johnson (2008) Todas
diversas fases do ciclo de vida do projeto fases do ciclo de vida do projeto
Esforço Percentagem do total esforço despendido nas Percentagem do total esforço despendido nas diversas SEI (2006b) Todas
diversas fases do ciclo de vida do projeto fases do ciclo de vida do projeto
Esforço Quantidade de dias de férias não planejadas por mês Número de dias de férias não planejadas por mês Lindström (2004) PP, IPM
Esforço Quantidade de dias parados por doença por mês Número de dias parados por doença por mês Lindström (2004) PP, IPM
Esforço Quantidade de dispensas de treinamento aprovadas Número de dispensas de treinamento aprovadas ao Kulpa e Johnson (2008) OT
ao longo do tempo longo do tempo
 162
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Esforço Quantidade de esforço despendido em GQ em cada Quantidade de esforço despendido em GQ em cada Kulpa e Johnson (2008) PPQA
fase do ciclo de vida fase do ciclo de vida
Esforço Quantidade de horas paradas por falha nas Número de horas paradas por falha nas ferramentas de Lindström (2004) IPM, PP
ferramentas de trabalho trabalho
Esforço Quantidade de horas paradas porque a rede esteve Número de horas paradas porque a rede esteve fora- Lindström (2004) IPM, PP
fora-do-ar do-ar
Esforço Recursos/Equipe Recursos/Equipe SEI (2006a) Todas
Esforço Tamanho da equipe Tamanho da equipe Agrawal e Chari (2007) Todas
Esforço Tamanho da equipe Tamanho da equipe / horas gastas Eickelmann e Anant Todas
(2003)
Esforço Taxa de indisponibilidade por pessoa em um Percentual de indisponibilidade por pessoa em um Debou, Kuntzmann- PP, IPM
departamento departamento Combelles e Rowe (1994)
Esforço Taxa de todo o esforço de desenvolvimento gasto Percentual de todo o esforço de desenvolvimento gasto SEI (2006b) PI
com integração de produtos com integração de produtos
Esforço Utilização Utilização McGarry et al (2002) PP, OT
Esforço Utilização Utilização SEI (2006b) Todas
Esforço Utilização de recursos Utilização de recursos McGarry et al (2002) PP, OT
Esforço Utilização de recursos Utilização de recursos críticos SEI (2006b) Todas
Esforço Variação de esforço Variação de esforço Becker et al (2006) Todas
Esforço Variação de esforço Variação de esforço McGarry, Burke e Decker Todas
(1998)
Esforço Variação de esforço Variação de esforço Xu (2006) Todas
Esforço Variação de esforço Variação de esforço por revisão ao plano SEI (2006b) PP
Esforço Variação de esforço Variância de esforço por revisão do plano Kulpa e Johnson (2008) Todas
Esforço Vazão de recursos Vazão de recursos SEI (2006b) REQM
Produtividade Capacidade de serviço Capacidade de serviço SEI (2006b) PP, PMC,
IPM, OPD,
OID
Produtividade Produtividade Produtividade Becker et al (2006) Todas
Produtividade Produtividade Produtividade McGarry et al (2002) Todas
Produtividade Produtividade Produtividade Kitchenham et al (2006) Todas
Produtividade Produtividade Produtividade McGarry, Burke e Decker Todas
(1998)
Produtividade Produtividade Produtividade SEI (2006a), SEI (2006b) Todas
 163
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Produtividade Produtividade Produtividade Stutzke (2005) Todas
Produtividade Produtividade Produtividade dos programadores Kulik e Weber (2002) Todas
Produtividade Produtividade Produtividade global e tendências de qualidade para Kulpa e Johnson (2008) Todas
cada projeto
Produtividade Produtividade de revisão Taxa de revisão Florac e Carleton (1999) VER, VAL
Produtividade Produtividade de revisão de código Produtividade de revisão de código Humphrey (2000) VER, VAL
Produtividade Produtividade de revisão de design de alto nível Produtividade de revisão de design de alto nível Humphrey (2000) VER, VAL
Produtividade Produtividade de revisão de design detalhado Produtividade de revisão de design detalhado Humphrey (2000) VER, VAL
Produtividade Produtividade de revisão de requisitos Produtividade de revisão de requisitos Humphrey (2000) VER, VAL
Produtividade Taxa de entrega Parâmetro de produtividade do processo Lindström (2004) Todas
Produtividade Taxa de entrega Produtividade Florac e Carleton (1999) Todas
Produtividade Taxa de entrega Produtividade Galin e Avrahami (2007) Todas
Produtividade Taxa de entrega Produtividade IEEE (1992) Todas
Produtividade Taxa de entrega Produtividade Xu (2006) Todas
Produtividade Taxa de entrega Produtividade do desenvolvimento de software Galin e Avrahami (2005), Todas
Galin e Avrahami (2006)
Produtividade Taxa de preparação Taxa de preparação Eickelmann e Anant VER, VAL
(2003)
Produtividade Vazão Vazão McGarry et al (2002) Todas
Qualidade A atividade onde os defeitos foram introduzidos A atividade onde os defeitos foram encontrados Lindström (2004) VER, VAL
Qualidade A limpeza da documentação ao final do projeto é A limpeza da documentação ao final do projeto é Lindström (2004) IPM, CM
agendada ou não agendada ou não
Qualidade Acidentes e Incidentes de segurança Acidentes e Incidentes de segurança Murdoch et al (2003) RSKM
Qualidade Ações e manutenção Ações de manutenção McGarry et al (2002) Todas
Qualidade Aderência a padrões Aderência a padrões McGarry et al (2002) Todas
Qualidade Ambiente de engenharia de software Ambiente de engenharia de software Paul et al (1999) PP, IPM,
PMC
Qualidade Atividades do processo que são invisíveis Atividades do processo que são invisíveis Lindström (2004) OPD
Qualidade Capacidade individual Capacidade individual Agrawal e Chari (2007) PP, IPM, OT
Qualidade Chamadas para o help desk Chamadas para o help desk Buglione e Abran (2005) TS, PI, VER e
VAL
Qualidade Classificação das avaliações pós-treinamento Classificação da avaliação pós-treinamento SEI (2006b) OT
Qualidade Classificação das avaliações pós-treinamento Classificação das avaliações pós-treinamento Kulpa e Johnson (2008) OT
 164
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Classificação de pesquisa de qualidade do programa Classificação de pesquisa de qualidade do programa SEI (2006b) OT
de treinamento de treinamento
Qualidade Classificação derivada de processo Classificação derivada de processo McGarry, Burke e Decker Todas
(1998)
Qualidade Classificação no modelo de referência Classificação no modelo de referência McGarry et al (2002) [OPF, OPD,
OT]
Qualidade Cobertura de revisões Cobertura das revisões em pares SEI (2006b) VER, VAL
Qualidade Cobertura de revisões Cobertura e a eficiência das revisões pelos pares (ou Kulpa e Johnson (2008) VER, VAL
seja, número / quantidade de produtos revisados
comparado ao número total de defeitos encontrados
por hora)
Qualidade Cobertura de testes % de cobertura de testes Kulik e Weber (2002) VER, VAL
Qualidade Cobertura de testes Cobertura de testes Grady (1994) VER, VAL
Qualidade Cobertura de testes Cobertura de testes Paul et al (1999) VER, VAL
Qualidade Cobertura de testes Cobertura de testes SEI (2006b) VER, VAL
Qualidade Cobertura de testes Cobertura e eficiência de teste Kulpa e Johnson (2008) VER, VAL
Qualidade Cobertura de testes Cobertura e eficiência de teste (ou seja, número / Kulpa e Johnson (2008) VER, VAL
quantidade de produtos testados em relação ao número
total de defeitos encontrados por hora)
Qualidade Cobertura e eficácia de revisão Cobertura e a eficiência das revisões pelos pares (ou Kulpa e Johnson (2008) VER, VAL
seja, número / quantidade de produtos revisados
comparado ao número total de defeitos encontrados
por hora)
Qualidade Comparação do real versus estimativas de todos os Comparação do real versus estimativas de todos os Kulpa e Johnson (2008) Todas
itens de planejamento e acompanhamento. itens de planejamento e acompanhamento.
Qualidade Confiabilidade Confiabilidade Paul et al (1999) TS, PI, VER,
VAL
Qualidade Confiabilidade Confiabilidade SEI (2006b) TS, PI, VER,
VAL
Qualidade Confiabilidade Confiabilidade (por exemplo, o tempo médio para a Kulpa e Johnson (2008) QPM
falha normalmente medido durante integração e teste
de sistemas)
Qualidade Conhecimento do desenvolvedor a respeito do Conhecimento do desenvolvedor a respeito do registro Lindström (2004) OT
registro de defeitos de defeitos
 165
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Conhecimento dos desenvolvedores sobre as suas Conhecimento dos desenvolvedores sobre as suas Lindström (2004) OT
responsabilidades responsabilidades
Qualidade Conhecimento dos desenvolvedores sobre padrões e Conhecimento dos desenvolvedores sobre padrões e Lindström (2004) OT
modelos modelos
Qualidade Custo de retrabalho Custo de retrabalho SEI (2006b) RD, TS
Qualidade Custo de retrabalho Custo despendido para retrabalho Kulpa e Johnson (2008) Todas
Qualidade Datas onde o plano do projeto e o cronograma são Datas onde o plano do projeto e o cronograma são Lindström (2004) PP, PMC
criados e a última data de atualização criados e a última data de atualização
Qualidade Densidade de defeitos Defeitos/Questões de qualidade SEI (2006a), SEI (2006b) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos Agrawal e Chari (2007) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos Buglione e Abran (2005) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos Lindström (2004) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos Xu (2006) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de compilação Florac e Carleton (1999) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de compilação Humphrey (2000) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de teste de integração Humphrey (2000) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de teste de sistema Humphrey (2000) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de teste unitário Humphrey (2000) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos de testes Florac e Carleton (1999) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos internos Becker et al (2006) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Densidade de defeitos total Florac e Carleton (1999) TS, RD, PI,
VER, VAL
 166
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Densidade de defeitos Densidade de erros Galin e Avrahami (2005), TS, RD, PI,
Galin e Avrahami (2006), VER, VAL
Galin e Avrahami (2007)
Qualidade Densidade de defeitos Densidade de falhas Kulik e Weber (2002) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos Número de defeitos a cada lançamento e / ou build de Kulpa e Johnson (2008) TS, RD, PI,
produto VER, VAL
Qualidade Densidade de defeitos de requisitos Densidade de defeitos nas especificações de requisitos Kulpa e Johnson (2008) RD
Qualidade Densidade de defeitos de requisitos Densidade de defeitos nas especificações de requisitos SEI (2006b) RD
Qualidade Densidade de defeitos de solução técnica Densidade de defeitos de produtos de solução técnica SEI (2006b) TS
Qualidade Densidade de defeitos de solução técnica Densidade de defeitos em produtos de trabalho de Kulpa e Johnson (2008) TS
solução técnica (número de defeitos por página)
Qualidade Densidade de defeitos entregues Densidade de defeitos encontrados durante o primeiro SEI (2006b) RD, TS, PI,
ano após a liberação do produto VER, VAL
Qualidade Densidade de defeitos entregues Densidade de defeitos entregues Becker et al (2006) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos entregues Densidade de defeitos pós-implantação Agrawal e Chari (2007) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos entregues Densidade de defeitos residual Xu (2006) TS, RD, PI,
VER, VAL
Qualidade Densidade de defeitos para cada elemento de Densidade de defeitos de cada elemento do processo Kulpa e Johnson (2008) OPD
processo do conjunto de processos padrão da de organização do conjunto de processos padrão
organização
Qualidade Densidade de defeitos para cada elemento de Densidade de defeitos para cada elemento de processo SEI (2006b) OPD
processo do conjunto de processos padrão da do conjunto de processos padrão da organização
organização
Qualidade Descobertas nas auditorias de processo Descobertas nas auditorias de processo McGarry et al (2002) PPQA, Todas
Qualidade Desempenho Classificação de desempenho McGarry et al (2002) Todas
Qualidade Desempenho do fornecedor Desempenho do fornecedor SEI (2006b) SAM
Qualidade Desempenho dos processos Capacidade dos processos selecionados Wang e Li (2005) OPP, OID,
OPD
Qualidade Desempenho dos processos Desempenho global dos processos da organização e do Kulpa e Johnson (2008) OPP, OID,
projeto, incluindo a eficácia, qualidade e OPD
produtividade, em comparação com os seus objetivos
 167
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
definidos
Qualidade Desempenho técnico Desempenho técnico McGarry et al (2002) Todas
Qualidade Desempenho, de acordo com planos, Desempenho, de acordo com planos, compromissos, e Kulpa e Johnson (2008) IPM
compromissos, e os procedimentos para a equipe os procedimentos para a equipe integrada, e desvios
integrada, e desvios em relação às expectativas em relação às expectativas
Qualidade Distribuição de defeitos Distribuição de defeitos Xu (2006) TS, RD, PI
Qualidade Distribuição de defeitos Distribuição de severidade de falhas Kulik e Weber (2002) TS, RD, PI
Qualidade Documentos que ainda se encontram na primeira Documentos que ainda se encontram na primeira Lindström (2004) CM
versão versão
Qualidade Efetiva participação em cada curso de formação, em Efetiva participação em cada curso de formação, em Kulpa e Johnson (2008) OT
comparação com a presença planejada comparação com a presença planejada
Qualidade Efetividade e uso da estrutura de equipe integrada Efetividade e uso da estrutura de equipe integrada SEI (2006b) IPM + IPPD
Qualidade Efetividade e uso da visão compartilhada do projeto Efetividade e uso da visão compartilhada do projeto SEI (2006b) IPM + IPPD
Qualidade Efetividade e uso do capítulo de equipe integrada Efetividade e uso do capítulo de equipe integrada SEI (2006b) IPM + IPPD
Qualidade Eficácia de compilação Eficácia de compilação Humphrey (2000) VER, VAL
Qualidade Eficácia de detecção de defeitos Detenção de defeitos McGarry et al (2002) VER, VAL
Qualidade Eficácia de detecção de defeitos Efetividade de detecção de defeitos Florac e Carleton (1999) VER, VAL
Qualidade Eficácia de detecção de defeitos Efetividade na detecção de defeitos Galin e Avrahami (2005), VER, VAL
Galin e Avrahami (2006),
Galin e Avrahami (2007)
Qualidade Eficácia de revisão Eficiência das revisões em pares SEI (2006b) VER, VAL
Qualidade Eficácia de revisão Eficiência de revisão Becker et al (2006) VER, VAL
Qualidade Eficácia de revisão Número total de defeitos encontrados nas revisões e Kulpa e Johnson (2008) VER, VAL
testes internos versus aqueles encontrados pelo cliente
ou usuário final após a entrega
Qualidade Eficácia de revisão de código Eficácia de inspeções e revisões de código Humphrey (2000) VER, VAL
Qualidade Eficácia de revisão de código Eficiência de revisões de codificação e teste unitário Xu (2006) VER, VAL
Qualidade Eficácia de revisão de design Eficácia de inspeções e revisões de design Humphrey (2000) VER, VAL
Qualidade Eficácia de revisão de design Eficiência de revisões de design Xu (2006) VER, VAL
Qualidade Eficácia de revisão de requisitos Eficácia de inspeções de requisitos Humphrey (2000) VER, VAL
Qualidade Eficácia de revisão de requisitos Eficiência de revisões de requisitos Xu (2006) VER, VAL
Qualidade Eficácia de teste antes da compilação Eficácia de teste antes da compilação Humphrey (2000) VER, VAL
Qualidade Eficácia de teste antes do teste de integração Eficácia de teste antes do teste de integração Humphrey (2000) VER, VAL
Qualidade Eficácia de teste antes do teste de sistema Eficácia de teste antes do teste de sistema Humphrey (2000) VER, VAL
 168
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Eficácia de teste antes do teste unitário Eficácia de teste antes do teste unitário Humphrey (2000) VER, VAL
Qualidade Eficácia de teste de integração e sistema Eficácia de teste de integração e sistema Humphrey (2000) VER, VAL
Qualidade Eficácia de teste unitário Eficácia de teste unitário Humphrey (2000) VER, VAL
Qualidade Eficácia de testes Eficiência de testes Grady (1994) VER, VAL
Qualidade Eficácia de testes Eficiência de testes Xu (2006) VER, VAL
Qualidade Eficácia de testes Número total de defeitos encontrados nas revisões e Kulpa e Johnson (2008) VER, VAL
testes internos versus aqueles encontrados pelo cliente
ou usuário final após a entrega
Qualidade Eficácia de treinamento Eficácia de treinamento (por exemplo, percentagem Kulpa e Johnson (2008) OT
dos treinamentos planejados concluída e pontuação
final)
Qualidade Erros de operador Erros de operador McGarry et al (2002) Todas
Qualidade Esforço de retrabalho Esforço de retrabalho SEI (2006b) RD, TS
Qualidade Esforço de retrabalho Esforço despendido para retrabalho Kulpa e Johnson (2008) Todas
Qualidade Esforço de retrabalho Esforço gasto corrigindo defeitos Lindström (2004) Todas
Qualidade Esforço de retrabalho Esforço gasto na correção de erros Debou, Kuntzmann- Todas
Combelles e Rowe (1994)
Qualidade Estabilidade de produtividade Estabilidade de produtividade Wang e Li (2005) OPP
Qualidade Estabilidade de taxa de defeitos Estabilidade de taxa de defeitos Wang e Li (2005) OPP
Qualidade Estabilidade de variação do cronograma Estabilidade de variação do cronograma Wang e Li (2005) OPP
Qualidade Estimativa de defeitos latentes Estimativa de defeitos latentes SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Existência de documentação que defina o processo Existência de documentação que defina o processo de Lindström (2004) OPD, VER,
de registro de defeitos registro de defeitos VAL
Qualidade Experiência da equipe Experiência da equipe McGarry et al (2002) OT, PP, IPM
Qualidade Experiência do supervisor do projeto na indústria de Experiência do supervisor do projeto na indústria de Agrawal e Chari (2007) PP, IPM, OT
software software
Qualidade Experiência do supervisor do projeto no papel de Experiência do supervisor do projeto no papel de Agrawal e Chari (2007) PP, IPM, OT
gerência gerência
Qualidade Falhas Falhas McGarry et al (2002) Todas
Qualidade Fase de detecção de defeitos Fase de detecção de defeitos Debou, Kuntzmann- VER, VAL
Combelles e Rowe (1994)
Qualidade Freqüência de customizações de processo Freqüência de customizações de processo Wang e Li (2005) OPD, IPM
Qualidade Freqüência de utilização de processo Freqüência de utilização de processo Wang e Li (2005) OPD
 169
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Fuga de defeitos para outras fases Fuga de defeitos para outras fases Stutzke (2005) VER, VAL
Qualidade Impacto estimado versus impacto real do risco Impacto estimado versus impacto real do risco Kulpa e Johnson (2008) RSKM
Qualidade Índice de satisfação do cliente Índice de satisfação do cliente Becker et al (2006) Todas
Qualidade Medidas de processo que dizem respeito aos Medidas de processo que dizem respeito aos Kulpa e Johnson (2008) OID
indicadores de satisfação do cliente indicadores de satisfação do cliente
Qualidade Melhoria medida no desempenho dos processos Melhoria medida no desempenho dos processos SEI (2006b) OID
organizações ou nos projetos organizações ou nos projetos
Qualidade Modos de falhas Modos de falhas Murdoch et al (2003) RSKM
Qualidade Mudança na qualidade após melhorias Mudança na qualidade após melhorias Kulpa e Johnson (2008) OID
Qualidade Mudança na qualidade após melhorias Mudança na qualidade após melhorias SEI (2006b) OID, CAR
Qualidade Mudança na qualidade ou desempenho processo Mudança no desempenho do processo após melhorias Kulpa e Johnson (2008) CAR
devido à análise causal e processo de resolução
Qualidade Mudança no desempenho do processo após Mudança no desempenho do processo após melhorias SEI (2006b) OID, CAR
melhorias
Qualidade Mudança no desempenho do processo após Mudança no desempenho do processo após melhorias Kulpa e Johnson (2008) OID
melhorias
Qualidade Nível de maturidade CMMI ou nível de capacidade Nível de maturidade CMMI ou nível de capacidade Kulpa e Johnson (2008) OPF
Qualidade Nível de maturidade CMMI ou nível de capacidade Nível de maturidade CMMI ou nível de capacidade SEI (2006b) OPF
Qualidade O efeito da aplicação de cada melhoria de processo, O efeito da aplicação de cada melhoria de processo, Kulpa e Johnson (2008) OID, OPD
em comparação com os seus objetivos definidos em comparação com os seus objetivos definidos
Qualidade Ocorrência de riscos não identificados Ocorrência de riscos não identificados SEI (2006b) RSKM
Qualidade Origem de defeito Origem de defeito Debou, Kuntzmann- VER, VAL
Combelles e Rowe (1994)
Qualidade Os resultados de cada processo avaliação em Os resultados de cada processo avaliação em Kulpa e Johnson (2008) OPF
comparação com os resultados e recomendações de comparação com os resultados e recomendações de
avaliações anteriores avaliações anteriores
Qualidade Percentual de defeitos removidos por verificação de Percentual de defeitos removidos por verificação de SEI (2006b) VER, VAL
produto produto
Qualidade Percentual do total de defeitos inseridos ou Percentual do total de defeitos inseridos ou SEI (2006b) RD, TS, PI,
encontradas nas diferentes fases do ciclo de vida encontradas nas diferentes fases do ciclo de vida VER, VAL
Qualidade Perfis de falhas Perfis de falhas Paul et al (1999) VER, VAL
Qualidade Prazo médio para falha Tempo entre falhas Kulpa e Johnson (2008) QPM
Qualidade Prazo médio para falha Tempo médio para falha Florac e Carleton (1999) TS, PI, VER,
VAL
 170
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Prazo médio para falha Tempo médio para falha Kulik e Weber (2002) TS, PI, VER,
VAL
Qualidade Prazo médio para falha Tempo médio para falha Lindström (2004) TS, PI, VER,
VAL
Qualidade Prazo médio para falha Tempo médio para falha SEI (2006b) OPF
Qualidade Profundidade de testes Profundidade de testes Paul et al (1999) VER, VAL
Qualidade Progressos na melhoria cursos de formação, em Progressos na melhoria cursos de formação, em Kulpa e Johnson (2008) OT
comparação com os planos de treinamento da comparação com os planos de treinamento da
organização e dos projetos organização e dos projetos
Qualidade Qualidade Qualidade Chikofsty e Rubin (1999) TS, RD, PI
Qualidade Qualidade Qualidade de produto Stutzke (2005) TS, RD, PI
Qualidade Qualidade da documentação Qual a qualidade da documentação Lindström (2004) Todas
Qualidade Qualidade das especificações de requisitos Qualidade das especificações de requisitos Agrawal e Chari (2007) RD, REQM
Qualidade Quantidade de ações corretivas ou itens de ação Número ações corretivas ou itens de ação abertos e Kulpa e Johnson (2008) PMC, IPM
abertos e fechados fechados
Qualidade Quantidade de ações propostas em aberto e por Número de ações propostas em aberto e por quanto SEI (2006b) CAR
quanto tempo tempo
Qualidade Quantidade de auditorias de configuração realizadas Número de auditorias de configuração realizadas Kulpa e Johnson (2008) CM
Qualidade Quantidade de causas especiais de variação Número de causas especiais de variação identificadas Kulpa e Johnson (2008) QPM
identificadas
Qualidade Quantidade de causas especiais de variação Número de causas especiais de variação identificadas SEI (2006b) QPM
identificadas
Qualidade Quantidade de causas raiz removidas Número de causas raiz removidas SEI (2006b) CAR
Qualidade Quantidade de compromissos documentados entre o Número compromissos documentados entre o projeto Kulpa e Johnson (2008) SAM
projeto e o fornecedor e o fornecedor
Qualidade Quantidade de defeitos Dados de defeitos Kulpa e Johnson (2008) Todas
Qualidade Quantidade de defeitos Defeito Florac e Carleton (1999) Todas
Qualidade Quantidade de defeitos Defeitos McGarry et al (2002) Todas
Qualidade Quantidade de defeitos Defeitos SEI (2006a), SEI (2006b) Todas
Qualidade Quantidade de defeitos Erros por categoria, fase onde foram descobertos, a Kulpa e Johnson (2008) Todas
fase foram injetados, por tipo e gravidade
Qualidade Quantidade de defeitos Número de defeitos Agrawal e Chari (2007) Todas
Qualidade Quantidade de defeitos Número de defeitos produzidos por fase Xu (2006) Todas
Qualidade Quantidade de defeitos Número de defeitos registrados no Service Desk Lindström (2004) Todas
 171
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
durante o projeto
Qualidade Quantidade de defeitos Número inicial de defeitos Eickelmann e Anant Todas
(2003)
Qualidade Quantidade de defeitos Total de defeitos injetados Humphrey (2000) Todas
Qualidade Quantidade de defeitos antigos corrigidos durante o Número de defeitos antigos corrigidos durante o Lindström (2004) VER, VAL,
projeto projeto PPQA
Qualidade Quantidade de defeitos como "Não foi possível Número de desvios como "Não foi possível reproduzir Kulpa e Johnson (2008) VER, VAL,
reproduzir o erro" o erro" PPQA
Qualidade Quantidade de defeitos de código por origem Origem dos defeitos no código Lindström (2004) TS, RD, PI
Qualidade Quantidade de defeitos de revisão Defeitos de inspeção Kitchenham et al (2006) Todas
Qualidade Quantidade de defeitos de revisão Defeitos encontrados nas revisões em pares SEI (2006b) Todas
Qualidade Quantidade de defeitos de revisão Número de desvios encontrados na revisão em pares Lindström (2004) Todas
Qualidade Quantidade de defeitos de severidade alta nos Defeitos de severidade alta nos primeiros 6 meses Herbsleb e Grinter (1998) VER, VAL
primeiros 6 meses após o release após o release
Qualidade Quantidade de defeitos de testes Defeitos de testes Kitchenham et al (2006) VER, VAL
Qualidade Quantidade de defeitos de testes Defeitos encontrados nos testes SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Quantidade de defeitos detectados nos produtos Número de defeitos detectados nos produtos Kulpa e Johnson (2008) SAM
fornecidos fornecidos (durante integração e após a entrega)
Qualidade Quantidade de defeitos detectados por categoria Número de defeitos detectados por categoria Kulpa e Johnson (2008) Todas
Qualidade Quantidade de defeitos encontrados durante a Defeitos encontrados durante a integração de produto SEI (2006b) PI
integração de produto
Qualidade Quantidade de defeitos encontrados durante o Número de defeitos encontrados durante o primeiro SEI (2006b) RD, TS, PI,
primeiro ano após a liberação do produto ano após a liberação do produto VER, VAL
Qualidade Quantidade de defeitos encontrados em cada fase do Número de defeitos encontrados durante a validação SEI (2006b) VER, VAL
ciclo de vida para cada fase do ciclo de vida
Qualidade Quantidade de defeitos encontrados em cada fase do Número de defeitos encontrados em cada fase do ciclo Kulpa e Johnson (2008) Todas
ciclo de vida de vida
Qualidade Quantidade de defeitos entregues Defeitos após produção Kitchenham et al (2006) VER, VAL
Qualidade Quantidade de defeitos escalados para a gerência Número de não-conformidades escaladas para a Kulpa e Johnson (2008) Todas
sênior gerência sênior
Qualidade Quantidade de defeitos fechados Defeitos removidos SEI (2006a) VER, VAL
Qualidade Quantidade de defeitos injetados durante cada fase Defeitos injetados ou removidos nas atividades SEI (2006b) Todas
do ciclo de vida
 172
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Quantidade de defeitos injetados durante cada fase Número de defeitos injetados durante cada fase do Kulpa e Johnson (2008) Todas
do ciclo de vida ciclo de vida
Qualidade Quantidade de defeitos injetados em cada etapa, O número de defeitos injetados em cada etapa, Kulpa e Johnson (2008) CAR
cumulativamente, e correções de produtos similares cumulativamente, e correções de produtos similares
Qualidade Quantidade de defeitos introduzidos Número de defeitos introduzidos Florac e Carleton (1999) Todas
Qualidade Quantidade de defeitos não resolvidos Número de desvios como "Ainda não resolvido" Kulpa e Johnson (2008) VER, VAL
Qualidade Quantidade de defeitos não resolvidos Número de relatórios de problemas pendente versus Kulpa e Johnson (2008) VER, VAL
taxa de reparação
Qualidade Quantidade de defeitos removidos por verificação Número de defeitos removidos por verificação de Kulpa e Johnson (2008) VER, VAL
de produto produto (talvez por tipo de verificação, tais como
revisões em pares e ensaios)
Qualidade Quantidade de defeitos reportados pelo cliente Defeitos reportados pelo cliente SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Quantidade de defeitos reportados pelo usuário Defeitos reportados pelo usuário SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Quantidade de documentos introduzidos Número de documentos produzidos internamente Lindström (2004) IPM, OPD
internamente durante o projeto durante o projeto
Qualidade Quantidade de elementos de processo adicionado, Número de elementos de processo adicionado, Stutzke (2005) IPM, OPD
alterado e excluídos durante a adaptação alterado e excluídos durante a adaptação
Qualidade Quantidade de exceções encontradas durante a Número de exceções encontradas durante a integração SEI (2006b) PI
integração de produtos de produtos
Qualidade Quantidade de modelos existentes na equipe Número de modelos existentes na equipe Lindström (2004) IPM, OPD
Qualidade Quantidade de modelos utilizados no projeto Número de modelos utilizados no projeto Lindström (2004) IPM, OPD
Qualidade Quantidade de mudanças em qualidade Alterações de cronograma, qualidade e custo Kulik e Weber (2002) CM, PPQA,
VER, VAL
Qualidade Quantidade de objetivos de medição abordados Número de objetivos de medição abordados Kulpa e Johnson (2008) MA
Qualidade Quantidade de ocorrências de riscos imprevistos Número de ocorrências de riscos imprevistos Kulpa e Johnson (2008) RSKM
Qualidade Quantidade de padrões existentes na organização Número de padrões existentes na organização Lindström (2004) OPD
Qualidade Quantidade de padrões utilizados no projeto Número de padrões utilizados no projeto Lindström (2004) IPM, OPD
Qualidade Quantidade de problemas de coordenação de Número de problemas de coordenação de interfaces SEI (2006b) IPM
interfaces identificados e fechados identificados e fechados
Qualidade Quantidade de problemas de integração Número de problemas de integração identificados e SEI (2006b) PI
identificados e fechados fechados
Qualidade Quantidade de problemas de validação identificados Número de problemas de validação identificados e SEI (2006b) VAL
 173
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
e fechados fechados
Qualidade Quantidade de problemas de verificação Número de problemas de verificação identificados e SEI (2006b) VER
identificados e fechados fechados
Qualidade Quantidade de problemas identificados e fechados Número de problemas identificados e fechados SEI (2006b) OPF
associados com a implantação do conjunto de associados com a implantação do conjunto de
processos padrão da organização processos padrão da organização
Qualidade Quantidade de projetos usando medidas de Número de projetos usando medidas de progresso e Kulpa e Johnson (2008) MA
progresso e desempenho desempenho
Qualidade Quantidade de reclamações dos trabalhadores Número de reclamações dos trabalhadores SEI (2006b) OPD
relacionadas a problemas de ergonometria relacionadas a problemas de ergonometria
Qualidade Quantidade de revisões da gerência sênior para Número revisões da gerência sênior para assegurar a Kulpa e Johnson (2008) PMC
assegurar a aderência ao orçamento e cronograma aderência ao orçamento e cronograma em relação ao
em relação ao plano plano
Qualidade Quantidade de revisões e auditorias versus Número de revisões e auditorias versus número de Kulpa e Johnson (2008) PPQA
quantidade de defeitos encontrados defeitos encontrados
Qualidade Quantidade de solicitações de serviço registradas no Número de solicitações de serviço registradas no Lindström (2004) VER, VAL
Service Desk durante o projeto Service Desk durante o projeto
Qualidade Quantidade de tempo para aprender a utilizar um Quantidade de tempo para aprender a utilizar um Lindström (2004) TS, RD, PI,
programa programa VER, VAL
Qualidade Quantidade de testes unitários realizados Número de testes unitários realizados Lindström (2004) VER, VAL
Qualidade Quantidade de vezes em que o plano do projeto e o Número de vezes em que o plano do projeto e o Lindström (2004) PP, IPM
cronograma são atualizados cronograma são atualizados
Qualidade Quantidade de vezes que os objetivos da equipe não Número de vezes que os objetivos da equipe não Kulpa e Johnson (2008) IPM
foram atingidos foram atingidos
Qualidade Quantidade de violações de contrato do fornecedor Número de violações de contrato do fornecedor ou do Kulpa e Johnson (2008) SAM
ou do vendedor vendedor
Qualidade Quantidade de violações dos procedimentos CM Número de violações dos procedimentos CM Kulpa e Johnson (2008) CM
(descumprimento encontrado em auditorias) (descumprimento encontrado em auditorias)
Qualidade Quantidade e a gravidade das queixas dos clientes Número e a gravidade das queixas dos clientes Kulpa e Johnson (2008) QPM, PMC
relativas a serviços prestados relativas a serviços prestados
Qualidade Quantidade e densidade de defeitos encontrados por Número e densidade de defeitos encontrados por Kulpa e Johnson (2008) VER, VAL
gravidade durante o primeiro ano após a entrega do gravidade durante o primeiro ano após a entrega do
produto ou início do serviço produto ou início do serviço
Qualidade Quantidade e desvios gerados pela auditoria de Número e desvios gerados pela auditoria de qualidade. Stutzke (2005) PPQA
 174
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
qualidade.
Qualidade Quantidade e severidade de defeitos no produto Número e severidade de defeitos no produto liberado SEI (2006b) RD, TS, PI,
liberado VER, VAL
Qualidade Quantidade e severidade de reclamações do cliente Número e severidade de reclamações do cliente no SEI (2006b) RD, TS, PI,
no serviço prestado serviço prestado VER, VAL
Qualidade Quantidade e tipos de prêmios e reconhecimentos O número e tipos de prêmios e reconhecimentos Kulpa e Johnson (2008) OID
recebidos por cada um dos projetos, grupos e recebidos por cada um dos projetos, grupos e
departamentos departamentos
Qualidade Quantidade e tipos de revisões realizadas Número e tipos de revisões realizadas Kulpa e Johnson (2008) PMC
Qualidade Quanto tempo um relatório de problema de Quanto tempo um relatório de problema de integração SEI (2006b) PI
integração permanece aberto permanece aberto
Qualidade Questionários de qualidade do programa de Questionários de qualidade do programa de Kulpa e Johnson (2008) OT
treinamento treinamento
Qualidade Relacionadas à cliente Relacionadas à cliente SEI (2006a) Todas
Qualidade Relacionadas a processo Relacionadas a processo SEI (2006a) Todas
Qualidade Revisão de projeto (design) Revisão de projeto (design) Hall e Fenton (1997) VER, VAL
Qualidade Revisões por pares Revisões por pares SEI (2006a) VER, VAL
Qualidade Satisfação do cliente Satisfação do cliente Wang e Li (2005) Todas
Qualidade Satisfação dos interessados Satisfação dos interessados Wang e Li (2005) Todas
Qualidade Situação das revisões Situação das revisões McGarry et al (2002) VER, VAL
Qualidade Situação dos componentes Situação dos componentes McGarry et al (2002) TS, PI
Qualidade Situação dos relatórios de problemas Situação dos relatórios de problemas McGarry et al (2002) PMC, IPM
Qualidade Situação dos relatórios de problemas de verificação Situação dos relatórios de problemas de verificação Kulpa e Johnson (2008) VER, VAL
(isto é, quanto tempo cada problema foi aberto)
Qualidade Situação dos testes Situação dos testes McGarry et al (2002) VER, VAL
Qualidade Solicitações de suporte Solicitações de suporte McGarry et al (2002) VER, VAL
Qualidade Tamanho médio do nome das variáveis Tamanho médio do nome das variáveis Resemberg e Sheppard TS
(1994)
Qualidade Taxa de auditorias de qualidade realizadas Número de auditorias de processo e atividades versus Kulpa e Johnson (2008) PPQA
o plano
Qualidade Taxa de comentários Percentual de comentários Resemberg e Sheppard TS
(1994)
Qualidade Taxa de confiabilidade das estimativas Taxa de confiabilidade das estimativas Lindström (2004) PP, IPM
Qualidade Taxa de dados de medição que é rejeitado devido a Percentual de dados de medição que é rejeitado devido SEI (2006b) OPP
 175
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
inconsistências em relação à definição da medição a inconsistências em relação à definição da medição
de desempenho de processo de desempenho de processo
Qualidade Taxa de defeitos Número de defeitos por severidade / total de defeitos SEI (2006b) TS, RD, PI
Qualidade Taxa de defeitos Percentual de não-conformidades Florac e Carleton (1999) TS, RD, PI
Qualidade Taxa de defeitos Percentual de reparos recorrentes Galin e Avrahami (2007) TS, RD, PI
Qualidade Taxa de defeitos Percentual do total de defeitos inseridos ou Kulpa e Johnson (2008) TS, RD, PI
encontrados nas diferentes fases do ciclo de vida do
projeto
Qualidade Taxa de defeitos Taxa de defeitos McGarry, Burke e Decker TS, RD, PI
(1998)
Qualidade Taxa de defeitos Taxa de defeitos Wang e Li (2005) TS, RD, PI
Qualidade Taxa de defeitos Taxa de defeitos de código Humphrey (2000) TS, RD, PI
Qualidade Taxa de defeitos Taxa de defeitos de compilação injetados Humphrey (2000) TS, RD, PI
Qualidade Taxa de defeitos Taxa de defeitos de teste unitário Humphrey (2000) TS, RD, PI
Qualidade Taxa de defeitos de design Taxa de defeitos de design Humphrey (2000) TS
Qualidade Taxa de escape de defeitos Taxa de escape de defeitos Kulpa e Johnson (2008) VER, VAL
Qualidade Taxa de escape de defeitos Taxa de escape de defeitos SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Taxa de injeção de defeitos de código Taxa de injeção de defeitos de código Humphrey (2000) TS, PI
Qualidade Taxa de injeção de defeitos de design de alto nível Taxa de injeção de defeitos de design de alto nível Humphrey (2000) TS
Qualidade Taxa de injeção de defeitos de design detalhado Taxa de injeção de defeitos de design detalhado Humphrey (2000) TS
Qualidade Taxa de injeção de defeitos de requisitos Taxa de injeção de defeitos de requisitos Humphrey (2000) RD
Qualidade Taxa de injeção e remoção de defeitos Taxa de injeção e remoção de defeitos Humphrey (2000) VER, VAL
Qualidade Taxa de projetos utilizando a arquitetura e Percentagem de projetos utilizando as arquiteturas Kulpa e Johnson (2008) OPD, IPM
elementos de processo do conjunto de processos processo e elementos de processo da organização do
padrão da organização conjunto de processos padrão
Qualidade Taxa de remoção de defeitos Eficiência na remoção de defeitos Becker et al (2006) VER, VAL
Qualidade Taxa de remoção de defeitos Eficiência na remoção de defeitos Xu (2006) VER, VAL
Qualidade Taxa de remoção de defeitos Número de não-conformidades registradas versus Kulpa e Johnson (2008) VER, VAL,
resolvidas PPQA
Qualidade Taxa de remoção de defeitos Percentual de defeitos removidos antes da primeira Florac e Carleton (1999) VER, VAL
compilação
Qualidade Taxa de remoção de defeitos Quantidade de defeitos abertos e fechados Grady (1994) VER, VAL,
PPQA
 176
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Taxa de remoção de defeitos Taxa de abertura/fechamento de falha Kulik e Weber (2002) VER, VAL
Qualidade Taxa de remoção de defeitos Taxa de remoção de defeitos SEI (2006b) VER, VAL
Qualidade Taxa de remoção de defeitos de design de alto nível Taxa de remoção de defeitos de design de alto nível Humphrey (2000) VER, VAL
Qualidade Taxa de remoção de defeitos de inspeção de código Taxa de remoção de defeitos de inspeção de código Humphrey (2000) VER, VAL
Qualidade Taxa de remoção de defeitos de inspeção de design Taxa de remoção de defeitos de inspeção de design Humphrey (2000) VER, VAL
detalhado detalhado
Qualidade Taxa de remoção de defeitos de requisitos Taxa de remoção de defeitos de requisitos Humphrey (2000) VER, VAL
Qualidade Taxa de remoção de defeitos de revisão de código Taxa de remoção de defeitos de revisão de código Humphrey (2000) VER, VAL
Qualidade Taxa de remoção de defeitos de revisão de design Taxa de remoção de defeitos de revisão de design Humphrey (2000) VER, VAL
detalhado detalhado
Qualidade Taxa de retrabalho Percentual de retrabalho Galin e Avrahami (2005), Todas
Galin e Avrahami (2006),
Galin e Avrahami (2007)
Qualidade Taxa de retrabalho Percentual de tempo de retrabalho SEI (2006b) Todas
Qualidade Taxa de retrabalho Retrabalho Agrawal e Chari (2007) Todas
Qualidade Taxa de retrabalho Retrabalho Chikofsty e Rubin (1999) Todas
Qualidade Taxa de retrabalho Retrabalho McGarry et al (2002) Todas
Qualidade Taxa de retrabalho Retrabalho Stutzke (2005) Todas
Qualidade Taxa de retrabalho Taxa de retrabalho Debou, Kuntzmann- Todas
Combelles e Rowe (1994)
Qualidade Taxa de revisões Taxa de revisões/falha Florac e Carleton (1999) VER, VAL
Qualidade Taxa de tempo de inspeções de design Taxa de tempo de inspeções de design de alto nível Humphrey (2000) VER, VAL
Qualidade Taxa de tempo de inspeções de requisitos Taxa de tempo de inspeções de requisitos Humphrey (2000) VER, VAL
Qualidade Taxa de tempo de revisão de codificação Taxa de tempo de revisão de codificação Humphrey (2000) VER, VAL
Qualidade Taxa de tempo de revisão de design Taxa de tempo de revisão de design detalhado Humphrey (2000) VER, VAL
Qualidade Taxa Livre de Defeitos de compilação Percentual Livre de Defeitos de compilação Humphrey (2000) VER, VAL
Qualidade Taxa Livre de Defeitos de teste de sistema Percentual Livre de Defeitos de teste de sistema Humphrey (2000) VER, VAL
Qualidade Taxa Livre de Defeitos de teste integrado Percentual Livre de Defeitos de teste integrado Humphrey (2000) VER, VAL
Qualidade Taxa Livre de Defeitos de teste unitário Percentual Livre de Defeitos de teste unitário Humphrey (2000) VER, VAL
Qualidade Tempo de falha Tempo de falha Florac e Carleton (1999) VER, VAL
Qualidade Tempo de reparo Tempo de reparo Florac e Carleton (1999) VER, VAL
Qualidade Tempo de resolução de problemas de integração (ou Tempo de resolução de problemas de integração (ou Kulpa e Johnson (2008) PI
seja, há quanto tempo foi aberto cada problema) seja, há quanto tempo foi aberto cada problema)
 177
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Tempo de resolução de problemas de validação (ou Tempo de resolução de problemas de validação (ou Kulpa e Johnson (2008) VAL
seja, há quanto tempo foi aberto cada problema) seja, há quanto tempo foi aberto cada problema)
Qualidade Tempo de retrabalho Cronograma despendido para retrabalho Kulpa e Johnson (2008) Todas
Qualidade Tempo de retrabalho Tempo de retrabalho SEI (2006b) CM
Qualidade Tempo de revisões de código Tempo de revisões de código Florac e Carleton (1999) VER, VAL
Qualidade Tempo de revisões de design Tempo de revisões de design Florac e Carleton (1999) VER, VAL
Qualidade Tempo de suporte Tempo de suporte McGarry et al (2002) TS, RD, PI,
VER, VAL
Qualidade Tempo médio entre falhas Tempo médio entre falhas SEI (2006b) RD, TS, PI,
VER, VAL
Qualidade Tempo médio para reparo Tempo médio para reparo Lindström (2004) PMC, VER,
VAL
Qualidade Tempo médio para reparo Tempo necessário para correção de defeitos Galin e Avrahami (2007) PMC, VER,
VAL
Qualidade Tempo para o qual um problema de validação Tempo para o qual um problema de validação SEI (2006b) VER
permanece em aberto permanece em aberto
Qualidade Tempo para o qual um problema de verificação Tempo para o qual um problema de verificação SEI (2006b) OID
permanece em aberto permanece em aberto
Qualidade Tempo para recuperar Tempo para recuperar McGarry et al (2002) PMC, VER,
VAL
Qualidade Tendências de problemas de coordenação de Tendências de problemas de coordenação de interface Kulpa e Johnson (2008) PI
interface (ou seja, números identificados e fechados)
Qualidade Tendências no desempenho de processos da Tendências no desempenho de processos da Kulpa e Johnson (2008) OPP
organização em relação às mudanças nos produtos organização em relação às mudanças nos produtos de
de trabalho e atributos de tarefa (por exemplo, trabalho e atributos de tarefa (por exemplo,
crescimento de tamanho, o esforço de programação, crescimento de tamanho, o esforço de programação, e
e qualidade) qualidade)
Qualidade Tendências nos relatórios de problemas de Tendências nos relatórios de problemas de Integração Kulpa e Johnson (2008) PI
Integração (por exemplo, número de registros e fechados)
Qualidade Tendências nos relatórios de problemas de Tendências nos relatórios de problemas de validação Kulpa e Johnson (2008) VAL
validação (por exemplo, número registrado e número fechado)
Qualidade Tendências nos relatórios de problemas de Tendências nos relatórios de problemas de verificação Kulpa e Johnson (2008) VER
verificação (por exemplo, números registrados e fechados)
Qualidade Teste de software Teste de software SEI (2006a) VER, VAL
 178
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Qualidade Testes de sistema planejados, executado, passados, Testes de sistema planejados, executado, passados, Kulpa e Johnson (2008) VER, VAL
falhos falhos
Qualidade Tipo de defeito Tipo de defeito Florac e Carleton (1999) Todas
Qualidade Tolerância a falhas Tolerância a falhas McGarry et al (2002) TS, PI, VER e
VAL
Qualidade Utilização de recursos computacionais Utilização de recursos computacionais Paul et al (1999) PP
Qualidade Utilização dos recursos críticos Utilização dos recursos críticos Kulpa e Johnson (2008) PP, PMC
Qualidade Verificação se o padrão de codificação é seguido ou Verificação se o padrão de codificação é seguido ou Lindström (2004) TS
não não
Tempo A realização de marcos no prazo das atividades de A realização de marcos no prazo das atividades de Kulpa e Johnson (2008) QPM
gestão quantitativa do processo, em comparação gestão quantitativa do processo, em comparação com
com o plano aprovado o plano aprovado
Tempo Datas de marcos Datas de marcos McGarry et al (2002) Todas
Tempo Desempenho do caminho crítico Desempenho do caminho crítico McGarry et al (2002) Todas
Tempo Estimativas e cronograma real do sistema Estimativas e cronograma real do sistema Kulpa e Johnson (2008) Todas
Tempo Folga de contingência de cronograma Folga de contingência de cronograma Kulik e Weber (2002) PP, RSKM
Tempo Índice de desempenho de prazo Índice de desempenho de cronograma (SPI) SEI (2006a), SEI (2006b) Todas
Tempo Índice de desempenho de prazo Índice de desempenho de prazos (IDP - EVA) McGarry et al (2002) Todas
Tempo Índice de desempenho de prazo Índice de desempenho de prazos (IDP - EVA) Kulik e Weber (2002) Todas
Tempo Índice de desempenho de prazo Índice de desempenho de prazos (IDP - EVA) PMI (2004) Todas
Tempo Índice de desempenho de prazo Índice de desempenho de prazos (IDP - EVA) SEI (2006a), SEI (2006b) Todas
Tempo Índice de desempenho de prazo Índice de desempenho de prazos (IDP - EVA) Wang e Li (2005) Todas
Tempo Média de tempo de resolução de solicitações de Média de tempo de resolução de solicitações de Lindström (2004) Todas
serviço serviço
Tempo Média de tempo para responder às mudanças nos Média de tempo para responder às mudanças nos SEI (2006b) OID
requisitos de projeto, situações de mercado e requisitos de projeto, situações de mercado e ambiente
ambiente organizacional organizacional
Tempo Monitoramento do cronograma Monitoramento do cronograma SEI (2006a) Todas
Tempo Prazo Cronograma Chikofsty e Rubin (1999) Todas
Tempo Prazo Cronograma Gopal, Mukhopadhyay e Todas
Krishnan (2005)
Tempo Prazo Cronograma Kitchenham et al (2006) Todas
Tempo Prazo Cronograma Kulik e Weber (2002) Todas
Tempo Prazo Cronograma Paul et al (1999) Todas
 179
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Tempo Prazo de análise de requisitos Cronograma de análise de todos os requisitos. Kulpa e Johnson (2008) RD
Tempo Prazo de ciclo Tempo de ciclo Agrawal e Chari (2007) Todas
Tempo Prazo de ciclo Tempo de ciclo McGarry et al (2002) Todas
Tempo Prazo de ciclo Tempo de ciclo Kulpa e Johnson (2008) Todas
Tempo Prazo de ciclo Tempo de ciclo McGarry, Burke e Decker Todas
(1998)
Tempo Prazo de ciclo Tempo de ciclo SEI (2006b) DAR
Tempo Prazo de ciclo Tempo de ciclo para completar um projeto típico de Galin e Avrahami (2005), Todas
software Galin e Avrahami (2006)
Tempo Prazo de ciclo Tempo de ciclo para o release de projeto Herbsleb e Grinter (1998) Todas
Tempo Prazo de definição de requisitos Cronograma de definição de todos os requisitos totais Kulpa e Johnson (2008) RD
Tempo Pressão de cronograma Pressão de cronograma Agrawal e Chari (2007) PP, PMC,
IPM
Tempo Progresso do cronograma Progresso do cronograma SEI (2006a) Todas
Tempo Quantidade de exceções ao contrato para garantir Número de exceções ao contrato para garantir Kulpa e Johnson (2008) SAM
aderência ao cronograma aderência ao cronograma
Tempo Quantidade de mudanças no cronograma Alterações de cronograma, qualidade e custo Kulik e Weber (2002) PP, PMC, CM
Tempo Quantidade de tempo despendido em GQ em cada Quantidade de tempo despendido em GQ em cada fase Kulpa e Johnson (2008) PPQA
fase do ciclo de vida do ciclo de vida
Tempo Relacionadas a cronograma Relacionadas a cronograma SEI (2006a) Todas
Tempo Taxa de marcos de entregas do fornecedor no prazo Datas reais das entregas do contratante ao Kulpa e Johnson (2008) SAM
subcontratado em comparação com o plano
Tempo Taxa de marcos de entregas para o fornecedor no Datas reais de entrega para os produtos contratados em Kulpa e Johnson (2008) SAM
prazo comparação com o plano
Tempo Taxa de marcos no prazo Atendimento ao cronograma Galin e Avrahami (2005), Todas
Galin e Avrahami (2006)
Tempo Taxa de marcos no prazo Conclusão de marcos para atividades de planejamento Kulpa e Johnson (2008) Todas
de projetos em comparação com o plano (estimativas
versus real)
Tempo Taxa de tempo da fase até a data Percentual de tempo da fase até a data Florac e Carleton (1999) Todas
Tempo Taxa de tempo que o ambiente de validação está Percentual de tempo que o ambiente de validação está SEI (2006b) VAL
disponível disponível
Tempo Tempo Tempo McGarry et al (2002) Todas
Tempo Tempo Tempo SEI (2006b) Todas
 180
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Tempo Tempo atual de cada atividade Duração atual de cada atividade Lindström (2004) Todas
Tempo Tempo atual do projeto Duração atual do projeto Lindström (2004) Todas
Tempo Tempo atual na fase Tempo atual na fase Florac e Carleton (1999) Todas
Tempo Tempo da principal fase de construção Duração da principal fase de construção Lindström (2004) TS
Tempo Tempo das atividades para desenvolver um Tempo das atividades para desenvolver um conjunto SEI (2006b) RD
conjunto de requisitos de requisitos
Tempo Tempo de ações para uma mitigação específica Tempo de ações para uma mitigação específica SEI (2006b) RSKM
Tempo Tempo de atividades de auditorias Tempo de atividades de auditorias SEI (2006b) CAR
Tempo Tempo de atividades para implementar uma ação Tempo de atividades para implementar uma ação SEI (2006b) CAR
proposta proposta
Tempo Tempo de coleta, análise e reporte das atividades de Tempo de coleta, análise e reporte das atividades de SEI (2006b) PMC
medição medição
Tempo Tempo de compilação Tempo de compilação Florac e Carleton (1999) TS
Tempo Tempo de execução do estudo de alternativas Tempo de execução do estudo de alternativas SEI (2006b) DAR
Tempo Tempo de interrupção Tempo de interrupção Florac e Carleton (1999) Todas
Tempo Tempo de processo Duração de processo SEI (2006b) Todas
Tempo Tempo de resposta Tempo de resposta SEI (2006b) RD, TS
Tempo Tempo de resposta para tratar as melhorias de O tempo de resposta para tratar as melhorias de Kulpa e Johnson (2008) OID
processo propostas processo propostas
Tempo Tempo de reunião do CCM Tempo de reunião do CCM SEI (2006b) PMC
Tempo Tempo de revisão Tempo de revisão SEI (2006b) PMC
Tempo Tempo de teste Tempo de teste Florac e Carleton (1999) VER, VAL
Tempo Tempo delta Tempo delta Florac e Carleton (1999) Todas
Tempo Tempo estimada de cada atividade Duração estimada de cada atividade Lindström (2004) Todas
Tempo Tempo estimada do projeto Duração estimada do projeto Lindström (2004) Todas
Tempo Tempo gasto com a coleta, análise e registro dos Tempo gasto com a coleta, análise e registro dos dados SEI (2006b) PMC
dados financeiros mensais financeiros mensais
Tempo Tempo gasto em atividades de gestão do risco Tempo gasto em atividades de gestão do risco versus o Kulpa e Johnson (2008) RSKM
versus a quantidade de riscos reais número de riscos reais
Tempo Tempo na fase até a data Tempo na fase até a data Florac e Carleton (1999) Todas
Tempo Tempo para a implantação de um ativo de processo Tempo para a implantação de um ativo de processo SEI (2006b) OT
organizacional organizacional
Tempo Tempo para a realização de treinamento Tempo para a realização de treinamento SEI (2006b) REQM
 181
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Tempo Tempo para análise de uma mudança de requisitos Tempo para análise de uma mudança de requisitos SEI (2006b) TS
proposta proposta
Tempo Tempo para as atividades de design Tempo para as atividades de design SEI (2006b) VAL
Tempo Tempo para as atividades de validação Tempo para as atividades de validação SEI (2006b) VER
Tempo Tempo para as atividades de verificação Tempo para as atividades de verificação SEI (2006b) PPQA
Tempo Tempo para as avaliações Tempo para as avaliações SEI (2006b) RSKM
Tempo Tempo para atividades de análise de riscos Tempo para atividades de análise de riscos SEI (2006b) PMC
Tempo Tempo para coleta e análise de dados para Tempo para coleta e análise de dados para SEI (2006b) MA
monitoramento e controle monitoramento e controle
Tempo Tempo para coleta e revisão de dados de medição Tempo para coleta e revisão de dados de medição SEI (2006b) IPM
Tempo Tempo para customizar o conjunto de processos Tempo para customizar o conjunto de processos SEI (2006b) OT
padrão da organização para o projeto padrão da organização para o projeto
Tempo Tempo para desenvolvimento de um curso Tempo para desenvolvimento de um curso SEI (2006b) OPD
Tempo Tempo para desenvolvimento de um processo ou Tempo para desenvolvimento de um processo ou uma SEI (2006b) REQM
uma mudança de processo mudança de processo
Tempo Tempo para gestão de requisitos Tempo para gestão de requisitos SEI (2006b) VAL
Tempo Tempo para identificar e corrigir os defeitos, em O tempo para identificar e corrigir os defeitos, em Kulpa e Johnson (2008) CAR
comparação com o custo estimado de não corrigir comparação com o custo estimado de não corrigir os
os defeitos defeitos
Tempo Tempo para realização de atividades de implantação Tempo para realização de atividades de implantação SEI (2006b) PI
de uma melhoria selecionada de uma melhoria selecionada
Tempo Tempo para realização de atividades de integração Tempo para realização de atividades de integração de SEI (2006b) OID
de produto produto
Tempo Tempo para recuperar o custo da melhoria Tempo para recuperar o custo da melhoria tecnológica SEI (2006b) PP
tecnológica ou no processo ou no processo
Tempo Tempo para revisão e manutenção dos planos de Tempo para revisão e manutenção dos planos de SEI (2006b) SAM
programa programa
Tempo Tempo para selecionar e estabelecer acordo com Tempo para selecionar e estabelecer acordo com SEI (2006b) SAM
fornecedor fornecedor
Tempo Tempo planejado Tempo de desenvolvimento estimado Buglione e Abran (2005) Todas
Tempo Tempo planejado na fase Tempo planejado na fase Florac e Carleton (1999) Todas
Tempo Tempo real Tempo atual decorrido Buglione e Abran (2005) Todas
Tempo Tempo total de treinamento Tempo total de treinamento Buglione e Abran (2005) OT
Tempo Tempo total na fase Tempo total na fase Florac e Carleton (1999) Todas
 182
Categoria Nome consolidado Nome original Referências APs do
CMMI-DEV
aplicáveis
Tempo Tempo total na fase até a data Tempo total na fase até a data Florac e Carleton (1999) Todas
Tempo Variação de prazo Precisão da estimativa de tempo Florac e Carleton (1999) Todas
Tempo Variação de prazo Magnitude de erro relativo à duração Lindström (2004) Todas
Tempo Variação de prazo Razões dos valores estimados e reais dos parâmetros Kulpa e Johnson (2008) Todas
de planejamento (por exemplo, o tamanho, custo e
cronograma)
Tempo Variação de prazo Variação de cronograma Becker et al (2006) Todas
Tempo Variação de prazo Variação de cronograma Xu (2006) Todas
Tempo Variação de prazo Variação do cronograma Wang e Li (2005) Todas
Tempo Variação de prazo Variação média de prazo Debou, Kuntzmann- Todas
Combelles e Rowe (1994)
Tempo Variação de prazo Variância de cronograma entre o planejado e atual Kulpa e Johnson (2008) Todas
Tempo Variação de prazo (EVA) Variação de prazo (VP - EVA) McGarry et al (2002) Todas
Tempo Variação de prazo (EVA) Variação de prazo (VP - EVA) Kulik e Weber (2002) Todas
Tempo Variação de prazo (EVA) Variação de prazo (VP - EVA) PMI (2004) Todas
Tempo Variação de prazo (EVA) Variação de prazo (VP - EVA) SEI (2006a), SEI (2006b) Todas
Tempo Variação de prazo (EVA) Variação de prazo (VP - EVA) Wang e Li (2005) Todas
Tempo Variação de prazo com o fornecedor Variação de tempo por acordo de fornecedor SEI (2006b) SAM
Tempo Variação de prazo com o fornecedor Variância de cronograma no acordo com o fornecedor Kulpa e Johnson (2008) SAM
Tempo Variação de prazo por revisão do plano Variação de prazo por revisão ao plano SEI (2006b) PP
Tempo Variação de prazo por revisão do plano Variância de cronograma por revisão do plano Kulpa e Johnson (2008) PP
Distribuição de probabilidade para uma quantidade Distribuição de probabilidade para uma quantidade Stutzke (2005) Todas
estimada ou estatística relacionada a uma população estimada ou estatística relacionada a uma população
Impacto tecnológico Impacto tecnológico McGarry et al (2002) OID
Resultados de pesquisa Resultados de pesquisa McGarry et al (2002) OID
 183

ANEXO A - FÓRMULAS DE CÁLCULO DOS GRÁFICOS DE CONTROLE

O Quadro 23 apresenta as fórmulas utilizadas para cálculo dos componentes dos

diferentes tipos de gráficos de controle.

Quadro 23: Fórmulas para cálculo da linha central e limites do gráfico de controle (Adaptado de Florac e
Carleton, 1999, pp. 85-123 e Stapenhrust 2005, pp. 153-164)

Tipo de Linha central (LC) e limites de

Fórmulas base
gráfico controle (LCS e LCI)

X-bar e R 1) Calcular as médias ( X ) e as amplitudes ( R ) para cada Limites do gráfico de médias (X-
(XbarR) bar):
subgrupo de tamanho n :

= X +X 1 2
+K+ X n LCS = X + A R
X 2

X
LC = X
k
n
X
R = X − X
k MAX MIN
LCI = X − A R
X 2
Limites do gráfico de amplitudes
2) Calcular a média geral ( X ) pela média de cada (R):
subgrupo:
LCS = D R 4
X +X +K+
R

= 1 2 X k
LC = R
X k R

LCI = D RR 3
3) Calcular a média das amplitudes ( R ) pela média de
cada amplitude do subgrupo:

= R +R 1 2
+ K + Rk
R k
X-bar e S 1) Calcular as médias ( X ) através da mesma fórmula Limites do gráfico de médias (X-
(XbarS) bar):
apresentada em XbarR e o desvio padrão ( S ) para cada
subgrupo de tamanho n : LCS = X + A R
X 3

∑ (X )
i= n
LC = X
2
i
−X X

S= i =1

n −1 LCI = X − A R
X 3
Limites do gráfico de desvios
padrão (S):
2) Calcular a média geral ( X ) através da mesma fórmula
apresentada em XbarR LCS = B S S 4

3) Calcular a média dos desvios padrão ( S ) pela média de

cada desvio padrão do subgrupo:
LC = S
S

i =k LCI = B S
∑S
S 3
i

S = i =1

k
 184

Quadro 23 (cont.): Fórmulas para cálculo da linha central e limites do gráfico de controle (Adaptado de
Florac e Carleton, 1999, pp. 85-123 e Stapenhrust 2005, pp. 153-164)

Tipo
Linha central (LC) e limites de controle (LCS
de Fórmulas base
e LCI)
gráfico

Xe 1) Calcular a média ( X ) através da mesma Limites do gráfico de valores individuais (X),

mR fórmula apresentada em XbarR e a amplitude onde n = 1 :
(XmR)
móvel ( mR ) para cada dois pontos 3mR
consecutivos no gráfico: LCS X
=X+ = X + 2,660mR
d2
mR = X i i +1
− X i
, onde 1 ≤ i ≤ k − 1
LC =X
X

2) Calcular a média das amplitudes móveis 3mR

LCI X
=X− = X − 2,660mR
( mR ): d2
i =k

∑ mR i sigma =
mR
=
mR

mR = i =1 X d 2 1,128
k Limites do gráfico de amplitudes móveis (mR),
onde n = 1 :

LCS = D mR 4 mR = 3,268mR

LC = mR
mR

LCI = 0 mR

c-chart Número total de defeitos

c =
Soma de eventos da amostra
LCS = c + 3 c
c

LC = cX

LCI = c − 3 c
c

sigma = c c

u- 1) Calcular a taxa de ocorrências pelo tamanho da

u
chart amostra, (Ex.: defeitos/tamanho):
LCS u
=u+3
= c , onde:
i a i
u i
=u
a i LC u
• c é igual à quantidade de
i u
ocorrências (defeitos) LCI u
= u−3
•
a i
a i
é igual à área de oportunidade ou
tamanho da amostra u
sigma =
2) Calcular a média das taxas ( u ): u
a i

u=
∑c i

∑a i
 185

Quadro 23 (cont.): Fórmulas para cálculo da linha central e limites do gráfico de controle (Adaptado de
Florac e Carleton, 1999, pp. 85-123 e Stapenhrust 2005, pp. 153-164)

Tipo de Linha central (LC) e limites de controle (LCS

Fórmulas base
gráfico e LCI)

np-chart 1) Calcular a taxa média de itens

defeituosos LCS = np + 3s
np

np =
Número de ítens defeituosos LC = np
np
Número de amostras
LCI = np − 3s
np
2) Calcular o desvio padrão:
 np 
sigma = s np
s = np1 − 
 n 

p-chart 1) Calcular a taxa média de defeitos

Número total de defeitos LCS = p + 3s
p
p=
Número de ítens verificados LC = pp

2) Calcular a média de itens verificados LCI = p − 3s

p
Número de ítens verificados
n= sigma = s p
Número de amostras
3) Calcular o desvio padrão:

s=
(
p 1− p )
n

A Tabela 5 apresenta os fatores de correção e constantes utilizadas nas fórmulas de

cálculo da linha de central e limites de controle apresentadas no Quadro 23. Os valores da
tabela são constantes tabuladas por estatísticos para conversão de dados de subgrupos de
tamanho n em estimativas imparciais de limites 3 sigmas.

Tabela 5: Tabela de fatores de correção e constantes (Adaptado de Florac e Carleton, 1999, pp. 216-219)

n d2 A2 A3 B3 B4 D3 D4
2 1,128 1,880 2,659 - 3,267 - 3,268
3 1,693 1,023 1,954 - 2,568 - 2,574
4 2,059 0,729 1,628 - 2,266 - 2,282
5 2,326 0,577 1,427 - 2,089 - 2,114
6 2,534 0,483 1,287 0,030 1,970 - 2,004
7 2,704 0,719 1,182 0,118 1,882 0,076 1,924
8 2,847 0,373 1,099 0,185 1,815 0,136 1,864
9 2,970 0,337 1,032 0,239 1,761 0,184 1,816
10 3,078 0,308 0,975 0,284 1,716 0,223 1,777
11 3,173 0,285 0,927 0,322 1,678 0,256 1,744
12 3,258 0,266 0,886 0,354 1,646 0,283 1,717
13 3,336 0,249 0,850 0,382 1,619 0,307 1,693
14 3,407 0,235 0,817 0,407 1,953 0,328 1,672
15 3,472 0,223 0,789 0,428 1,572 0,347 1,653