Medição de Software

Medio de Software e Controle Estatstico de Processos
MEDIO DE SOFTWARE E CONTROLE

ESTATSTICO DE PROCESSOS
Presidente da Repblica
Dilma Vana Rousseff
Ministro da Cincia, Tecnologia e Inovao
Marco Antonio Raupp
Secretrio de Poltica de Informtica
Virglio Augusto Fernandes Almeida
Coordenador Geral de Servios e Programas de Computador
Rafael Henrique Rodrigues Moreira
Comit Editorial
Christiane Gresse von Wangenheim
Diva da Silva Marinho
Jos Carlos Maldonado
Kival Chaves Weber
Rodrigo Quites
Ana Regina Cavalcanti da Rocha

Gleison dos Santos Souza
Monalessa Perini Barcellos
MEDIO DE SOFTWARE E CONTROLE

ESTATSTICO DE PROCESSOS
Maio/2012

N.8 (2012) - Braslia
Ministrio da Cincia, Tecnologia e Inovao
Secretaria de Poltica de Informtica, 2012
232 p.
I. Ministrio da Cincia, Tecnologia e Inovao
Secretaria de Poltica de Informtica
Autores:

Mestre e Doutor em Cincias pela PUC-Rio. Professor Associado do
Programa
de
Engenharia
de
Sistemas
Computao
da
COPPE/Universidade Federal do Rio de Janeiro (UFRJ). Membro da Equipe

Tcnica do Modelo MPS. Implementador MPS. Avaliador Lder MPS.

Mestre e Doutor em Cincias pela UFRJ. Professor Adjunto do Departamento
de Informtica Aplicada da Universidade Federal do Estado do Rio de
Janeiro (UNIRIO). Membro da Equipe Tcnica do Modelo MPS.
Implementador MPS. Avaliador Lder MPS.

Mestre e Doutor em Cincias pela UFRJ. Professor Adjunto do Departamento
de Informtica da Universidade Federal do Esprito Santo (UFES). Membro
da Equipe Tcnica do Modelo MPS. Implementador MPS.
A Julia, Rafael e Joo

- Ana Regina
A minha famlia e amigos que me possibilitaram chegar a esse momento, em

especial ao Thadeu
- Gleison
Ao Alex Sandro, meu esposo e minha pessoa, a Luiza, minha amada filha, ao
meu pai, pedra angular da minha vida
- Monalessa
Agradecimentos
Aos alunos e colegas que passaram pelo grupo de Qualidade de Software da

COPPE, pelas inmeras discusses que geraram conhecimento e amizade.
equipe do PBQP Software/SEPIN/MCTI, em especial a Diva da Silva Marinho e
Kival Chaves Weber pelo constante incentivo rea de Qualidade de Software no
Brasil.
Ao Comit Editorial, pela reviso cuidadosa e pelas pertinentes sugestes a este
livro.
A Larissa Araujo, aluna e amiga, pela gentileza e competncia na elaborao da
capa deste livro.
Aos colegas Adler
Diniz de Souza, Carlos Simes e Rodrigo Magalhes que
contriburam na reviso do livro.

A nossas famlias, pelos exemplos de vida que nos proporcionaram e pelo incentivo
aos nossos projetos profissionais e pessoais.
s inmeras empresas onde atuamos na implementao e avaliao de processos
de software no contexto do Programa MPS.BR, pelas experincias enriquecedoras,
aprendizado constante e slidas amizades.
Prefcio
O Programa Brasileiro da Qualidade e Produtividade em Software (PBQP
Software) foi criado no dia 1 de junho de 1993, em ateno a uma sugesto do
sempre lembrado Dorgival Brando Jnior pai da Qualidade em Informtica no
Brasil. Nos seus dezenove anos de existncia, o movimento pela qualidade e
produtividade em software no Brasil tem sido exemplar.
Dentre as muitas contribuies do PBQP Software, com o objetivo de atingir
padres internacionais de Qualidade e Produtividade no Setor de Software no
Brasil, destacam-se:
tanto o apoio a iniciativas, tais como o Simpsio Brasileiro de

Qualidade de Software (SBQS) realizado anualmente pela Sociedade
Brasileira de Computao (SBC) e o programa mobilizador de
Melhoria de Processo do Software Brasileiro (MPS.BR) coordenado
pela Associao para Promoo da Excelncia do Software Brasileiro
(SOFTEX);
quanto iniciativas da Secretaria de Poltica de Informtica (SEPIN),

do Ministrio da Cincia, Tecnologia e Inovao (MCTI), tais como os
projetos do PBQP Software submetidos anualmente por entidades da
Academia, Governo e Indstria (Tripla Hlice), o prmio Dorgival
Brando Jnior da Qualidade e Produtividade em Software
concedido anualmente ao melhor projeto executado, as pesquisas
peridicas da Qualidade e Produtividade no Setor de Software
Brasileiro e, mais recentemente, a srie de livros do PBQP Software.
Mais uma vez, fiz parte do Comit Editorial que selecionou o livro vencedor
deste ano: 'Medio de Software e Controle Estatstico de Processos', dos autores
Ana Regina Cavalcanti da Rocha/COPPE UFRJ, Gleison dos Santos Souza/UNIRIO e
Monalessa Perini Barcellos/UFES, a quem parabenizo pela obra.
Posteriormente, fui convidado a prefaciar o livro e me senti muito honrado
por esta considerao. Assim, aproveitei a oportunidade para fazer uma releitura
9
dos seus oito captulos: 1 Introduo; 2 Medio de Software; 3 Planejamento

e Execuo de Medies; 4 Conhecimento Bsico para o Controle Estatstico de
Processos e a Gerncia Quantitativa de Projetos; 5 Grficos de Controle; 6
Controle Estatstico de Processos e a Gerncia Quantitativa de Projetos na Prtica;
7 Medidas para Monitorao dos Processos no MR-MPS; 8 Medio no MR-MPS.
A obra uma contribuio fundamental para a melhoria dos processos de
software no Brasil:
tanto na Academia, onde, daqui em diante, ser uma referncia

bibliogrfica obrigatria nos cursos de doutorado e mestrado em
Engenharia de Software e de graduao em Cincia da Computao;
quanto no aprimoramento do conhecimento de Implementadores e

Avaliadores de modelos de maturidade tais como o MPS e o CMMI;
como na evoluo da baixa para alta maturidade nas organizaes

que adotam os modelos MPS ou CMMI.
O livro 'Medio de Software e Controle Estatstico de Processos' tambm

um marco divisrio no programa MPS.BR e no modelo MPS, considerando que:
o Controle Estatstico de Processos (nvel B do modelo de referncia

MR-MPS) uma evoluo do processo Medio (nvel F);
as organizaes que adotam o modelo MPS carecem destas boas

prticas da Engenharia de Software.
Enfim, trata-se de um candidato a caso de sucesso na rea de Qualidade de

Software, baseado nas interaes da Tripla Hlice, visando ao aumento da
competitividade do Setor de Software no Brasil.
Maio de 2012
Kival Chaves Weber
Coordenador Geral do PBQP Software
Coordenador Executivo do Programa MPS.BR
10
Sumrio
Captulo 1 - Introduo.....................................................................................................................14
PARTE I - Medio de Software................................................................. 17

Captulo 2 - Medio de Software .................................................................................................18
2.1 Introduo ............................................................................................................................................. 18
2.2 Conceitos da Medio de Software .............................................................................................. 19
2.3 Medio e Melhoria de Processos de Software ...................................................................... 21
2.4 Medio e Modelos de Processos de Software ....................................................................... 22
2.5 A Definio do Processo de Medio nas Organizaes ..................................................... 29
2.6 Consideraes Finais do Captulo ................................................................................................ 31
Captulo 3 - Planejamento e Execuo de Medies ..............................................................32
3.1 Introduo ............................................................................................................................................. 32
3.2 Objetivos Estratgicos da Organizao e Objetivos de Medio ..................................... 33
3.3 Definio de Objetivos, Medidas e Indicadores...................................................................... 35
3.3.1 O Mtodo GQM (Goal Question Metric)........................................................................ 36
3.3.2 O Mtodo GQ(I)M (Goal Question (Indicator) Measure) ...................................... 38
3.3.3 O mtodo GQM*Strategies ................................................................................................. 39
3.3.4 Practical Software Measurement (PSM)e a norma ISO/IEC15939 .................. 41
3.3.5 Definio e Gerncia de Objetivos de Software Alinhados ao Planejamento
Estratgico .......................................................................................................................................... 42
3.4 As Cinco Medidas Essenciais.......................................................................................................... 44
3.5 Definio dos Procedimentos de Coleta e Armazenamento ............................................. 46
3.6 Definio dos Procedimentos de Anlise .................................................................................. 47
3.7 Definio Operacional de Medidas .............................................................................................. 48
3.8 Execuo da Medio ........................................................................................................................ 52
3.9 Consideraes Finais do Captulo ................................................................................................ 54
PARTE II - Controle Estatstico de Processos ....................................... 56

Captulo 4 - Conhecimento Bsico para o Controle Estatstico de Processos e a
Gerncia Quantitativa de Projetos ...............................................................................................57
4.1 Introduo........................................................................................................................................... 57
4.2 O Poder do Controle Estatstico de Processos ..................................................................... 58
11
4.3 O Comportamento dos Processos.............................................................................................. 62

4.4 Seleo de Subprocessos para o Controle Estatstico ....................................................... 65
4.5 Identificao de Medidas Adequadas para o Controle Estatstico ............................... 70
4.6 Repositrio de Medidas Adequado para o Controle Estatstico ................................... 81
4.7 Consideraes Finais do Captulo.............................................................................................. 84
Captulo 5 - Grficos de Controle ..................................................................................................86
5.1 Introduo ............................................................................................................................................. 86
5.2 Grficos de Controle: O Bsico ...................................................................................................... 86
5.3 Tipos de Grficos de Controle........................................................................................................ 91
5.3.1 Grficos de Controle para Dados de Variveis ......................................................... 92
5.3.2 Grficos de Controle para Dados de Atributos....................................................... 115
5.4 Consideraes Finais do Captulo ............................................................................................. 120
Captulo 6 - Controle Estatstico de Processos e a Gerncia Quantitativa de Projetos
na Prtica ........................................................................................................................................... 123
6.1 Introduo ........................................................................................................................................ 123
6.2 Definio das Baselines de Desempenho ............................................................................. 124
6.2.1 Atualizao de Baselines de Desempenho ............................................................... 125
6.2.2 Um Processo, Vrias Baselines ..................................................................................... 128
6.2.3 Nova Definio de Processo, Nova Baseline .......................................................... 130
6.3 Determinao da Capacidade ................................................................................................... 132
6.4 Obteno de Modelos de Desempenho................................................................................. 137
6.5 Gerncia Estatstica de Processos e Gerncia Quantitativa de Projetos ................. 138
6.6 Melhoria do Desempenho de Processos Estveis e Capazes ......................................... 143
6.6.1 Por onde comear .............................................................................................................. 150
6.7 Consideraes Finais do Captulo ............................................................................................ 151
PARTE III - Medio e Melhoria de Processos de Software ......... 153

Captulo 7 - Medidas para Monitorao dos Processos no MR-MPS............................ 154
7.1 Introduo........................................................................................................................................ 154
7.2 Medio no Nvel G do MR-MPS .............................................................................................. 155
7.2.1 - Medidas relacionadas a Gerncia de Projetos ..................................................... 158
7.2.2 - Medidas relacionadas a Gerncia de Requisitos................................................. 161
7.3 Medio no Nvel F do MR-MPS .............................................................................................. 164
7.3.1 - Medidas relacionadas a Aquisio............................................................................ 165
7.3.2 - Medidas relacionadas a Garantia da Qualidade .................................................. 166
7.3.3 - Medidas relacionadas a Gerncia de Configurao ........................................... 169
12
7.3.4 - Medidas relacionadas a Gerncia de Portflio de Projetos ............................ 170

7.3.5 - Medidas relacionadas a Medio .............................................................................. 172
7.4 Medio no Nvel E do MR-MPS .............................................................................................. 172
7.4.1 - Medidas relacionadas a Avaliao e Melhoria do Processo Organizacional
............................................................................................................................................................... 174
7.4.2 - Medidas relacionadas a Definio do Processo Organizacional .................. 175
7.4.3 - Medidas relacionadas evoluo de Gerncia de Projetos no nvel E ...... 176
7.4.4 - Medidas relacionadas a Gerncia de Recursos Humanos ............................... 178
7.4.5 - Medidas relacionadas a Gerncia de Reutilizao ............................................. 180
7.5 Medio no Nvel D do MR-MPS .............................................................................................. 181
7.5.1 - Medidas relacionadas a Desenvolvimento de Requisitos ............................... 183
7.5.2 - Medidas relacionadas a Integrao do Produto ................................................. 184
7.5.3 - Medidas relacionadas a Projeto e Construo do Produto............................. 185
7.5.4 - Medidas relacionadas a Validao............................................................................ 187
7.5.5 - Medidas relacionadas a Verificao ......................................................................... 189
7.6 Medio no Nvel C do MR-MPS .............................................................................................. 192
7.6.1 - Medidas relacionadas a Desenvolvimento para Reutilizao ....................... 192
7.6.2 - Medidas relacionadas a Gerncia de Decises .................................................... 193
7.6.3 - Medidas relacionadas a Gerncia de Riscos ......................................................... 194
7.7 Medio no Nvel B do MR-MPS .............................................................................................. 195
7.7.1 - Medidas relacionadas ao Controle Estatstico de Processos ......................... 195
7.7.2 - Medidas relacionadas evoluo de Gerncia de Projetos no nvel B ...... 197
7.8 Medio no Nvel A do MR-MPS .............................................................................................. 198
7.8.1 - Medidas relacionadas a Anlise de Causas ........................................................... 199
7.8.2 - Medidas relacionadas Melhoria Contnua dos Processos ........................... 200
7.9 Consideraes Finais do Captulo........................................................................................... 201
Captulo 8 - Medio no MR-MPS................................................................................. 203

8.1 Introduo........................................................................................................................................ 203
8.2 Observaes sobre a Implementao de Medio nas Organizaes ...................... 205
8.3 Medio como Meio para Conhecimento e Monitorao dos Processos de
Software no nvel F do MR-MPS ........................................................................................................ 213
8.4 Medio para a Melhoria dos Processos de Software nos nveis E, D e C do MRMPS .............................................................................................................................................................. 222
8.5 Consideraes Finais do Captulo........................................................................................... 226
13
Captulo 1
Introduo
Medir est presente em diversos aspectos da vida humana. Mede-se o
tamanho e o peso de pessoas e objetos, a rea de um cmodo da casa ou a distncia
entre cidades. Um pediatra mede o peso e a altura de uma criana para conhecer
sua curva de crescimento e tomar as decises pertinentes em caso de desvios.
Medidas so essenciais para o conhecimento, o controle e a tomada de deciso do
pediatra.
Medir, tambm, essencial na Engenharia de Software. importante medir
para entender e controlar processos, produtos e projetos. Medidas fornecem
informaes sobre objetos (processos, produtos e projetos) e eventos (por
exemplo, a fase de testes de um projeto), tornando-os compreensveis e
controlveis [FENTON e PFLEEGER, 1997]. Baseados em medidas possvel
conhecer a qualidade de um produto, a estabilidade e capacidade de um processo
ou o estgio atual de um projeto. Com esse conhecimento possvel controlar,
tomar decises e melhorar a qualidade de processos e produtos. Pode-se, tambm,
realizar ajustes que garantam o xito dos projetos.
Medir software, entretanto, custa caro e envolve um esforo considervel
em termos de recursos humanos. E, mais grave, as medidas nem sempre so teis
para o conhecimento, o controle e a tomada de deciso. Muitas vezes, mede-se
simplesmente por medir ou para atender aos requisitos de um modelo de
maturidade de processos, como o CMMI-DEV [SEI, 2010] ou o MR-MPS [SOFTEX,
2011a]. Nesses casos no se atingem os objetivos da medio de software, nem se
obtm os benefcios que as medidas podem oferecer.
Para realizar medies de software de forma adequada, necessrio um
programa de medio bem planejado. Entretanto, vrios estudos tm mostrado
que as organizaes em geral definem programas de medio precrios e
incapazes de produzir medidas que atendam s suas necessidades [GOH et al.,
1998; FENTON e NEIL, 1999; NIESSINK e VLIET, 2001; GOPAL et al., 2002; WANG e
14
LI, 2005; KITCHENHAM et al., 2006; SARGUT e DEMIRORS, 2006; CURTIS et al.,
2008; RACKZINSKI e CURTIS, 2008; BARCELLOS 2009a].
Em uma pesquisa realizada em janeiro de 2012 pela AMCHAM (Cmara
Americana de Comrcio) [AMCHAM, 2012] com 44 executivos de TI, 73%
afirmaram que a medio peridica e o desenvolvimento de indicadores de
desempenho fazem parte da poltica de suas empresas. Os aspectos chave que
essas empresas focam com as medies, segundo esses executivos, so: melhoria
dos processos (80%); aumento dos lucros e impactos dos processos de TI (55%);
maturidade da rea (18%); gesto de riscos (16%) e comparao com nveis de
mercado (14%). Ainda na percepo desses executivos, quantificar os resultados
de TI traz os seguintes benefcios: direcionar os investimentos na rea (59%);
corrigir falhas nos processos (55%); identificar pontos com potencial para reduo
de custos (43%); aumentar a visibilidade da rea (36%) e justificar investimentos
(34%).
Entretanto, apenas, 14% dos executivos que participaram da pesquisa
afirmaram estarem totalmente satisfeitos com a forma como a medio realizada.
As principais dificuldades apontadas foram: tornar tangveis os benefcios e
retorno das aes (41%); estabelecer indicadores (30%); obter informaes sobre
o impacto da TI em outros setores da empresa (18%); e quantificar a eficincia dos
processos e sistemas (14%).
Medies de software para serem efetivas precisam estar alinhadas s
necessidades de negcio da organizao, isto , aos seus objetivos estratgicos, e
estarem direcionadas s necessidades de informao de gerentes de projetos e
engenheiros de software. Essas necessidades devem ser explicitadas e devem
orientar a definio do que medir e de como analisar e comunicar o resultado das
medidas [MCGARRY et al., 2002; ISO/IEC 2002; BASILI et al., 1994; BARRETO,
2011].
Este livro est dirigido a:
gerentes de projeto interessados em medir e controlar projetos de

desenvolvimento de software;
implementadores de melhoria de processos de software que

queiram conhecer melhor as reas de medio e controle
15
estatstico de processos para implant-las em organizaes de

software;
engenheiros de software;
professores de graduao em Computao;
estudantes de graduao em Computao;
professores de ps-graduao em Engenharia de Software;
estudantes de ps-graduao em Engenharia de Software.
Nos prximos captulos este livro fornecer:
os conceitos relacionados medio, a importncia da medio

em software, o seu papel na melhoria dos processos de software e
os modelos de processo de medio (Captulo 2).
conhecimento e orientaes para planejamento e execuo de

medies em Engenharia de Software (Captulo 3);
conhecimento sobre controle estatstico de processos de software

(Captulos 4, 5 e 6);
conhecimento sobre a evoluo da medio nos nveis de

maturidade MPS (Captulo 7);
conhecimento sobre medio e evoluo da capacidade no MPS

(Captulo 8).
16
PARTE I
Medio de Software
17
Captulo 2
Medio de Software
2.1 Introduo
Medio de software uma avaliao quantitativa de qualquer aspecto dos
processos e produtos de software, que permite seu melhor entendimento e, com
isso, auxilia o planejamento, controle e melhoria do que se produz e de como
produzido [BASS et al., 1999].
O elemento bsico da medio so as medidas. Medidas caracterizam, em
termos quantitativos, uma propriedade de um objeto e fornecem informaes
quantitativas capazes de apoiar tomadas de deciso tcnicas e de negcios. Esse
o principal diferencial entre as organizaes que se beneficiam com os resultados
de seu programa de medio e as organizaes que apenas despendem tempo e
esforo acumulando dados inteis. Somente quando as informaes obtidas
atravs da medio so utilizadas para direcionar as aes necessrias s
organizaes e seus projetos que o objetivo fundamental da medio alcanado
e percebido pelas organizaes [BASILI e ROMBACH, 1994; FENTON e NEIL, 2000;
MC GARRY et al., 2002; BARCELLOS, 2009a].
Neste captulo sero apresentados os principais conceitos relacionados
amedio (seo 2.2). Ser discutida a importncia da medio em software e o seu
papel na melhoria dos processos de software. Ser mostrado como a medio
tratada nas normas internacionais ISO/IEC 12207 Systems and Software
Engineering Software Life Cycle Process [ISO/IEC, 2008] e ISO/IEC 15504
Information Technology Process Assessment [ISO/IEC, 2003], e nos modelos de
maturidade CMMI-DEV - Capability Maturity Model Integration for Development
[SEI, 2010] e MR-MPS Modelo de Referncia para Melhoria de Processo do
Software Brasileiro [SOFTEX 2011a] (seo 2.3). Por fim, ser mostrado como uma
organizao deve definir o seu processo de medio (seo 2.4) e sero
apresentadas as consideraes finais do captulo (seo 2.5).
18
2.2 Conceitos da Medio de Software

A medio de software uma disciplina relativamente recente e, como tal,
ainda no foram estabelecidos padres consensuais para a medio de software.
Em particular, no h consenso para conceitos e terminologias, havendo
duplicaes e inconsistncias nas propostas encontradas na literatura, inclusive,
nos termos mais comuns da rea [GARCA et al., 2006].
Devido a essa heterogeneidade do vocabulrio relacionado medio de
software, BARCELLOS (2009a) desenvolveu uma Ontologia de Medio de
Software que define um vocabulrio comum a esse domnio. A seguir so
apresentados os conceitos dessa ontologia considerados centrais para o
entendimento deste livro:
Medida: quantificao de atributos de entidades. Pode ser medida base

(ex.: prazo estimado para o projeto, prazo real do projeto) ou medida
derivada (ex.: aderncia ao prazo do projeto, dada pela razo entre o prazo
real do projeto e o prazo estimado para o projeto).
Elemento Mensurvel: propriedade de uma entidade que pode ser

quantificada. Ex.: a medida prazo estimado para o projeto quantifica o
elemento mensurvel tempo.
Entidade Mensurvel: entidade que pode ser caracterizada pela

quantificao de seus atributos. Ex.: a medida prazo estimado para o projeto
quantifica o atributo tempo da entidade Projeto P.
Unidade de Medida: unidade por meio da qual uma medida pode ser
expressa. Ex.: a medida prazo estimado para o projeto pode ser expressa em
horas. A medida aderncia ao prazo do projeto no possui unidade de
medida.
Escala: indica os valores que podem ser atribudos a uma medida. Ex.: A
medida prazo estimado para o projeto possui uma escala do tipo Absoluta
que composta pelos nmeros reais positivos.
Procedimento de Medio: procedimento que descreve como a coleta da

medida deve ser realizada. Ex.: A medida aderncia ao prazo do projeto
poderia ter como procedimento de medio: Aplicar a frmula de clculo de
19
medida que determina a razo entre o prazo real do projeto e o prazo

estimado para o projeto.
Procedimento de Anlise de Medio: procedimento que descreve como

os dados coletados para a medida devem ser representados e analisados.
Ex.: A medida aderncia ao prazo do projeto poderia ter como
procedimento de anlise: Representar em histograma as taxas de aderncia
ao prazo dos projetos. Valores superiores a 1 indicam que o projeto levou
mais tempo que o previsto, valores menores que 1 indicam que o projeto
levou menos que o previsto e valores iguais a1 indicam que o projeto levou
exatamente o tempo que foi previsto. Analisar os valores medidos para os
projetos e compar-los uns com os outros. Subagrupar os dados e
represent-los em outros histogramas a fim de identificar e analisar: (i) as
diferenas das taxas de acordo com as caractersticas dos projetos; (ii) as
diferenas das taxas de acordo com a fase em que o projeto se encontra.
Definio Operacional de Medida: detalhamento associado a uma medida

que fornece informaes sobre sua coleta e anlise. Inclui procedimentos de
medio e de anlise, os papis dos responsveis pela medio e pela
anlise da medida, os momentos em que a medio e a anlise devem ser
realizadas e a periodicidade em que elas devem ser realizadas.
Medio: ao de medir, ou seja, de atribuir um valor a uma medida,

executando seu procedimento de medio. Ex.: medio do prazo previsto
para o projeto obtendo-se o valor 500.
Anlise de Medio: ao de analisar os dados coletados para uma medida,

executando seu procedimento de anlise. Ex.: anlise da aderncia ao prazo
do projeto, concluindo-se que os projetos que envolveram o uso de nova
tecnologia apresentaram uma aderncia 10% menor aos prazos previstos
do que a mdia das aderncias dos projetos que no utilizaram novas
tecnologias.
Indicador: medida utilizada para analisar o alcance a objetivos. Ex.:

aderncia ao prazo do projeto poderia ser um indicador para o objetivo
melhorar a aderncia dos projetos aos planos.
20
2.3 Medio e Melhoria de Processos de Software

Processos devem ser tecnicamente corretos e devem ser capazes de atender
s necessidades do negcio. Entretanto, processos podem estar corretos do ponto
de vista da Engenharia de Software e no serem competitivos. Podem consumir
demasiado tempo e esforo ou no produzirem produtos com a qualidade
necessria para satisfazer as necessidades de seus usurios. Processos podem
apresentar problemas e devem ser objeto, continuamente, de melhorias.
importante, nesse contexto, dispor-se de mecanismos capazes de evidenciar
problemas nos processos e apoiar na identificao de objetivos de melhoria.
Um objetivo de melhoria de processo um conjunto de caractersticas
desejadas, definidas para orientar o esforo de melhoria de processos de modo
especfico e mensurvel [SEI, 2010]. Esses objetivos devem agregar valor ao
negcio da organizao e melhorar a qualidade dos produtos desenvolvidos
[BARRETO, 2011].
A melhoria de processos de software pode estar relacionada a: (i) galgar
nveis mais altos de maturidade (melhoria vertical) e/ou (ii) realizar mudanas
visando a uma maior adequao s necessidades da organizao ou melhorias no
desempenho dos processos (melhoria horizontal). Nos dois casos, a melhoria dos
processos deve estar associada a objetivos de melhoria que visam principalmente:
(i) entender as caractersticas dos processos existentes e os fatores que afetam o
seu desempenho; (ii) planejar e implementar aes que modifiquem o processo
para atender melhor s necessidades de negcio; e (iii) avaliar os impactos e os
benefcios obtidos com as mudanas realizadas nos processos [ALBUQUERQUE,
2008; FLORAC e CARLETON, 1999].
Medies so essenciais para a realizao de melhorias em processos de
software porque fornecem dados objetivos que permitem conhecer o seu
desempenho. Os dados coletados para as medidas so a base para a deteco de
problemas no desempenho e de inadequaes nos processos, bem como para a
identificao de oportunidades de melhoria e tomada de deciso. A avaliao do
alcance dos objetivos de melhoria nos processos, tambm, depende de medies.
Cada objetivo definido deve ser associado a indicadores e medidas capazes de
21
apoiar a organizao na avaliao da adequao e eficcia das aes de melhoria

implementadas e do alcance dos objetivos.
Florac e Carleton (1999) identificaram trs objetivos para a medio de
processos de software:
i.
Coletar dados para medir o desempenho do processo.
ii.
Analisar o desempenho do processo.
iii.
Armazenar e utilizar os dados para interpretar os resultados de

observaes e anlises, predizer custos e desempenho futuros, fornecer
baselines e benchmarks, identificar tendncias e avaliar a estabilidade e
capacidade do processo.
Nos nveis iniciais de um programa de melhoria de processos as

organizaes adotam a medio tradicional que basicamente consiste na coleta de
dados da execuo dos projetos e comparao destes com valores previamente
planejados. Apesar dessa abordagem ser adequada para a melhoria de processos
nos nveis iniciais, ela no suficiente para as organizaes que desejam atingir
alta maturidade em seus processos. Nessas organizaes necessrio que a
medio esteja orientada para o controle estatstico de seus processos,
especialmente dos processos mais relevantes para o seu desempenho
[BARCELLOS, 2009a].
2.4 Medio e Modelos de Processos de Software

A crescente demanda por qualidade nos produtos e produtividade no
desenvolvimento de software e o entendimento de que qualidade e produtividade
dependem da qualidade dos processos tm aumentado o interesse das
organizaes pela melhoria de seus processos e pela implantao de modelos de
maturidade nas suas unidades de software.
Existem vrios frameworks de apoio implantao de programas de
melhoria de processos em organizaes de software, onde a medio de software
tem lugar de destaque. Entre eles esto as normas internacionais ISO/IEC 12207
Systems and Software Engineering Software Life Cycle Process [ISO/IEC, 2008] e
ISO/IEC 15504 Information Technology Process Assessment [ISO/IEC, 2003], e
os modelos CMMI-DEV - Capability Maturity Model Integration for Development
22
[SEI, 2010] e MR-MPS Modelo

elo de Referncia para Melhoria de Processo do
d
Software Brasileiro [SOFTEX 2011a].
20
As normas internacionais ISO/IEC 12207 e ISO/IEC 15504 constituem a
base para a definio de modelos de referncia de processos e para a avaliao das
da
organizaes segundo esses modelos.
A norma ISO/IEC 12207 descreve o processo de medio atravs de seu
propsito e resultados esperados. Estabelece que o propsito do processo de
Medio coletar, armazenar, analisar e relatar os dados relativos aos produtos
desenvolvidos e aos processos implementados na unidade organizacional,
organiza
de
forma a apoiar a gerncia efetiva dos processos e demonstrar objetivamente a
qualidade dos produtos. O Quadro 2.1
2.1 mostra os resultados esperados desse
processo na norma. Essa norma no trata de medio orientada ao controle
estatstico.
Quadro 2.1 Resultados Esperados do Processo Medio na ISO/IEC 12207 [ISO/IEC, 2008].
2008]
A norma ISO/IEC 15504 est baseada em duas

duas dimenses: (i) dimenso de
processo, fornecida por um modelo de referncia externo que define um conjunto
de processos caracterizados por seu propsito e resultados esperados; e (ii)
dimenso de capacidade, que consiste em um framework com seis nveis de
d
capacidade de processo. Nessa norma so definidos seis nveis de capacidade. O
nvel 0 (Incompleto) caracterizado por processo no existente ou que falha em
atingir seus objetivos. No nvel 1 (Inicial) o processo geralmente atinge os
objetivos, porm sem padro de qualidade e sem controle de prazos e custos. No
nvel 2 (Gerenciado), o processo planejado e acompanhando e satisfaz requisitos
definidos de qualidade, prazo e custos. No nvel 3 (Estabelecido),
(Estabelecido), o processo
executado e gerenciado com uma adaptao de um processo padro definido,
23
eficaz e eficiente. No nvel 4 (Previsvel), o processo executado dentro de limites

de controle definidos e com medies detalhadas e analisadas. Por fim, no nvel 5
(Em Otimizao), o processo melhorado continuamente de forma disciplinada
A medio tratada nos nveis de capacidade atravs dos atributos de
processo: no Nvel 3 no atributo de processo Implantao do Processo; e no Nvel 4
nos atributos de processo Medio do Processo e Controle do Processo. O Quadro
2.2 apresenta os atributos relacionados a Medio e Controle Estatstico na
ISO/IEC 15504.
Quadro 2.2 Atributos de Processo Relacionados a Medio e Controle Estatstico na ISO/IEC
15504 [ISO/IEC, 2003].
Atributo de Processo 3.2 Implantao do Processo
...
f) Dados apropriados so coletados e analisados, constituindo uma base para o
entendimento do comportamento do processo, para demonstrar a adequao e a
eficcia do processo, e avaliar onde pode ser feita a melhoria contnua do processo.
Atributo de Processo 4.1 Medio do Processo
a) As necessidades de informao dos processos, requeridas para apoiar objetivos
de negcio relevantes da organizao, so identificadas.
b) Objetivos de medio do processo so derivados das necessidades de
informao do processo.
c) Objetivos quantitativos de desempenho dos processos so definidos para apoiar
os objetivos de negcio relevantes.
d) Medidas, bem como a frequncia de realizao de suas medies, so
identificadas e definidas de acordo com os objetivos de medio e os objetivos
quantitativos de desempenho do processo;
e) Resultados das medies so coletados, analisados e comunicados para
monitorar o atendimento dos objetivos quantitativos de desempenho do processo.
f) Resultados de medio so utilizados para caracterizar o desempenho do
processo.
Atributo de Processo 4.2 Controle do Processo
a) Tcnicas de anlise e de controle so identificadas e aplicadas quando pertinente.
b) Limites de controle de variao so estabelecidos para o desempenho normal do
processo.
c) Dados de medio so analisados com relao a causas especiais de variao.
d) Aes corretivas so realizadas para tratar causas especiais de variao.
e) Limites de controle so redefinidos (quando necessrio) seguindo as aes
corretivas.
O modelo CMMI selecionou tpicos que considerou importantes para a

melhoria de processos e agrupou em reas de processo. As reas de processo so
definidas atravs de seu propsito, objetivos e prticas especficas.
O modelo CMMI possui duas representaes: contnua e em estgios. Na
representao contnua cada processo avaliado de forma individual e lhe
atribudo um grau de capacidade. Os nveis de capacidade do CMMI so
24
equivalentes aos nveis de capacidade da norma ISO/IEC 15504. Na representao

em estgios as reas de processo so agrupadas e so definidos cinco nveis de
maturidade:
(Inicial),
(Gerenciado),
(Definido),
(Gerenciado
Quantitativamente) e 5 (Em Otimizao). O Nvel 1 (Inicial) no possui reas de

processo.
No nvel de maturidade 2 do CMMI, tem-se a rea de processo Medio e
Anlise. Essa rea tem como propsito desenvolver e manter uma capacidade de
medio que usada para apoiar necessidades de informaes gerenciais. Medio
e Anlise envolve: (i) especificar os objetivos da medio e anlise de forma que
estejam alinhados aos objetivos e necessidades de informao da organizao; (ii)
especificar medidas, tcnicas de anlise e mecanismos para coleta, armazenamento
de dados, relato de resultados e feedback aos envolvidos; (iii) implementar a
coleta, armazenamento, anlise e comunicao dos dados; e (iv) fornecer
resultados objetivos que possam ser usados para a tomada de deciso e aes
corretivas [SEI, 2010]. O Quadro 2.3 mostra os objetivos e prticas especficas
dessa rea de processo.
Quadro 2.3 Objetivos e Prticas Especficas da rea de Processo Medio e Anlise no CMMI [SEI,
2010].
Objetivo Especfico 1 Alinhar as atividades de medio e anlise
PE 1.1
PE 1.2
PE 1.3
PE 1.4
Estabelecer objetivos de medio

Especificar medidas
Especificar procedimentos de coleta de dados e armazenamento
Especificar procedimentos de anlise
Objetivo Especfico 2 Fornecer resultados das medies

PE 2.1
PE 2.2
PE 2.3
PE 2.4
Coletar dados de medies

Analisar dados
Armazenar dados e resultados
Comunicar resultados
No nvel de maturidade 4 do CMMI, tm-se as reas de processo

Desempenho do Processo Organizacional e Gerncia Quantitativa do Projeto, onde
introduzida a medio orientada ao controle estatstico.
A rea Desempenho do Processo Organizacional tem como propsito
estabelecer e manter um entendimento quantitativo do desempenho de processos
selecionados entre o conjunto de processos padro da organizao como apoio
para atingir objetivos de qualidade e de desempenho do processo e para fornecer
dados de desempenho do processo, baselines e modelos para gerenciar
25
quantitativamente os projetos da organizao. Esta rea de processo envolve: (i)

estabelecer objetivos de qualidade e de desempenho do processo alinhados aos
objetivos de negcio; (ii) selecionar processos/subprocessos para anlise de
desempenho; (iii) estabelecer definies das medidas a serem utilizadas para
anlise do desempenho do processo; e (iv) estabelecer baselines e modelos de
desempenho do processo [SEI, 2010]. O Quadro 2.4 mostra o objetivo e prticas
especficas dessa rea de processo.
Quadro 2.4 Objetivos e Prticas Especficas da rea de Processo Desempenho do Processo
Organizacional no CMMI [SEI, 2010].
Objetivo Especfico 1 Estabelecer baselines e modelos de desempenho
PE 1.1 Estabelecer objetivos de qualidade e de desempenho do processo
PE 1.2 Selecionar processos
PE 1.3 Estabelecer medidas de desempenho do processo
PE 1.4 Analisar o desempenho do processo e estabelecer baselines
PE 1.5 Estabelecer modelos de desempenho do processo
A rea de processo Gerncia Quantitativa do Projeto tem como objetivo

gerenciar quantitativamente o projeto para alcanar a qualidade estabelecida para
o projeto e os objetivos de desempenho do processo. Essa rea de processo
envolve: (i) estabelecer e manter os objetivos de qualidade do projeto e os
objetivos de desempenho do processo; (ii) compor um processo definido para o
projeto que apoie o alcance destes objetivos; (iii) selecionar subprocessos e
atributos crticos para o entendimento do desempenho e que apoiam o alcance dos
objetivos; (iv) selecionar medidas e tcnicas analticas para serem usadas na
gerncia quantitativa; (v) monitorar o desempenho dos processos selecionados
utilizando tcnicas estatsticas e quantitativas; (vi) gerenciar o projeto usando
tcnicas estatsticas e quantitativas para determinar se os objetivos de qualidade
foram alcanados; e (vi) realizar anlise de causas em aspectos selecionados para
tratar deficincias no alcance dos objetivos [SEI, 2010]. O Quadro 2.5 mostra os
objetivos e prticas especficas desta rea de processo.
Quadro 2.5 Objetivos e Prticas Especficas da rea de Processo Gerncia Quantitativa do Projeto
no CMMI [SEI,2010].
Objetivo Especfico 1 Preparar a gerncia quantitativa
PE
PE
PE
PE
1.1
1.2
1.3
1.4
Estabelecer os objetivos do projeto

Compor o processo definido
Selecionar sub-processos e atributos
Selecionar medidas e tcnicas analticas
Objetivo Especfico 2 Gerenciar quantitativamente o projeto

PE 2.1 Monitorar o desempenho dos sub-processos selecionados
PE 2.2 Gerenciar o desempenho do projeto
PE 2.3 Realizar anlise de causas
26
Pode-se observar que as duas reas de processo do Nvel 4 esto fortemente

relacionadas rea de processo Medio e Anlise no que se refere especificao
de medidas, obteno de dados de medio e anlise de dados (PE 1.3 na rea de
processo Desempenho do Processo Organizacional e PE 1.4 na rea de processo
Gerncia Quantitativa de Projetos). Isso mostra, tambm, a importncia do
processo Medio e Anlise para o controle estatstico.
O Modelo de Referncia MR-MPS estabelece sete nveis de maturidade como
uma combinao entre processos e sua capacidade: A (Em Otimizao), B
(Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E
(Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado) sendo o
nvel G o inicial e o nvel A o mais avanado. A cada novo nvel de maturidade mais
processos devem ser implementados, assim como novos atributos de processo
(que determinam o nvel de capacidade).
O processo Medio, presente no Nvel F do MR-MPS, pressupe que as
organizaes definam medidas a partir de seus objetivos organizacionais e as
utilizem para tomadas de deciso. Esse processo tem como propsito coletar,
armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos
processos implementados na organizao e em seus projetos, de forma a apoiar os
objetivos organizacionais [SOFTEX, 2011a]. O Quadro 2.6 apresenta os seus
resultados esperados.
Quadro 2.6 Resultados Esperados do Processo Medio no MR-MPS [SOFTEX 2011a].
Processo Medio Resultados Esperados
MED 1: Objetivos de medio so estabelecidos e mantidos a partir dos objetivos
de negcio da organizao e das necessidades de informao de processos
tcnicos e gerenciais.
MED 2: Um conjunto adequado de medidas, orientado pelos objetivos de
medio, identificado e definido, priorizado, documentado, revisado e, quando
pertinente, atualizado.
MED 3: Os procedimentos para a coleta e o armazenamento de medidas so
especificados.
MED 4: Os procedimentos para a anlise das medidas so especificados.
MED 5: Os dados requeridos so coletados e analisados.
MED 6: Os dados e os resultados das anlises so armazenados.
MED 7: Os dados e os resultados das anlises so comunicados aos
interessados e so utilizados para apoiar decises.
Os nveis de maturidade do MR-MPS tm uma natureza evolutiva,

representada, em parte, pelos atributos de processo (AP), que determinam a
capacidade do processo. Espera-se que em um primeiro momento (nvel G), os
27
processos sejam executados (AP 1.1) e gerenciados (AP 2.1). Depois (nvel F),
tambm, que os produtos de trabalhos sejam gerenciados (AP 2.2). A partir do
nvel E, processos padres devem ser definidos (AP 3.1) e implementados (AP 3.2).
Nos nveis B e A os atributos de processo procuram garantir que os processos
sejam controlados estatisticamente (AP 4.1 e AP 4.2) e otimizados continuamente
(AP 5.1 e AP 5.2).
O Quadro 2.7 apresenta os resultados esperados de atributos de processo
relacionados medio e controle estatstico no MR-MPS.
Quadro 2.7 Resultados Esperados de Atributos do Processo Relacionados a Medio e
Controle Estatstico no MR-MPS [SOFTEX 2011a].
Atributo de Processo 2.1 O Processo gerenciado
RAP 4. (A partir do nvel F). Medidas so planejadas e coletadas para monitorao
da execuo do processo e ajustes so realizados.
Atributo de Processo 3.2 O processo implementado
RAP 21. Dados apropriados so coletados e analisados, constituindo uma base para
o entendimento do comportamento do processo, para demonstrar a adequao e a
eficcia do processo, e avaliar onde pode ser feita a melhoria contnua do processo.
Atributo de Processo 4.1 O Processo medido
RAP 23. As necessidades de informao dos processos, requeridas para apoiar
objetivos de negcio relevantes da organizao, so identificadas.
RAP 24. A partir do conjunto de processos padro da organizao e das
necessidades de informao, so selecionados os processos e/ou subprocessos
que sero objeto de anlise de desempenho.
RAP 25. Objetivos de medio do processo e/ou subprocesso so derivados das
necessidades de informao do processo.
RAP 26. Objetivos quantitativos de qualidade e de desempenho dos processos e/ou
subprocessos so definidos para apoiar os objetivos de negcio.
RAP 27. Medidas, bem como a frequncia de realizao de suas medies, so
identificadas e definidas de acordo com os objetivos de medio do
processo/subprocesso e os objetivos quantitativos de qualidade e de desempenho
do processo.
RAP 28. Resultados das medies so coletados, analisados e comunicados para
monitorar o atendimento dos objetivos quantitativos de qualidade e de desempenho
do processo/subprocesso.
RAP 29. Resultados de medio so utilizados para caracterizar o desempenho do
processo/subprocesso.
Atributo de Processo 4.2 Controle do Processo
RAP 30. Tcnicas de anlise e de controle de desempenho so identificadas e
aplicadas quando necessrio.
RAP 31. Limites de controle de variao so estabelecidos para o desempenho
normal do processo.
RAP 32. Dados de medio so analisados com relao a causas especiais de
variao.
RAP 33. Aes corretivas so realizadas para tratar causas especiais de variao.
RAP 34. Limites de controle so redefinidos, quando necessrio, seguindo as aes
corretivas.
RAP 35. Modelos de desempenho do processo so estabelecidos e mantidos.
28
2.5 A Definio do Processo de Medio nas Organizaes

Para que um programa de medio seja implantado em uma organizao de
forma a produzir os resultados esperados necessrio que esteja apoiado em um
processo capaz de garantir a execuo disciplinada do conjunto de atividades
envolvidas.
O processo de medio pode, portanto, ser definido como um conjunto de
passos que orienta a realizao da medio em uma organizao. Um processo de
medio eficiente fator crtico de sucesso do programa de medio, pois ele que
direciona as atividades a serem realizadas para que com os resultados da anlise
dos dados coletados seja possvel a identificao de tendncias e antecipao aos
problemas [WANG e LI, 2005].
Os modelos de processo, como o CMMI [SEI, 2010] e o MR-MPS [SOFTEX,
2011a], definem os requisitos que o processo de medio de uma organizao
precisa atender. Esses requisitos podem ser agrupados em quatro etapas: (i)
definio das medidas; (ii) coleta e armazenamento das medidas; (iii) anlise das
medidas, e (iv) uso dos resultados da anlise em tomadas de deciso.
Entretanto, os modelos existentes no indicam como dever ser esse
processo nem como ele dever ser executado. Cada organizao deve, ento,
definir seu processo de medio orientando-se pelos requisitos desses modelos e
considerando suas prprias caractersticas e especificidades.
A definio de um processo envolve definir os subprocessos que compem
o processo e suas atividades. Um processo/subprocesso deve estar descrito em
detalhes de forma a poder ser executado de forma consistente. Para isso, cada
atividade deve ser descrita por meio das tarefas que a compem e cada tarefa deve
ser definida a partir dos itens descritos no Quadro 2.8.
Considerando os resultados esperados do MR-MPS, um processo de
Medio poderia ter trs atividades: (i) Definir objetivos e medidas; (ii) Especificar
procedimentos de coleta, armazenamento e anlise; e (iii) Coletar, analisar e
reportar medidas. Cada uma das atividades composta por tarefas. Como exemplo,
o Quadro 2.9 apresenta a atividade Definir objetivos e medidas e suas tarefas.
29
Quadro 2.8 - Itens para descrio de uma tarefa (adaptado de [SOFTEX, 2012]).
Nome da tarefa
Descrio
Pr-tarefa
Identifica a tarefa por um nome.

Descreve a tarefa em detalhes.
Tarefa que deve ser executada antes da tarefa em questo.
Critrios de entrada
Critrios de sada
Condies a serem atendidas para que a tarefa seja iniciada.

Condies a serem atendidas para que a tarefa seja
considerada finalizada.
Quem responde pela execuo da tarefa.
Quem so os envolvidos na execuo da tarefa.
Insumos necessrios para executar a tarefa.
Produtos a serem gerados na execuo da tarefa.
Ferramentas que devem ser utilizadas para a execuo da
tarefa.
Tarefa que deve ser executada aps esta ser finalizada.
Responsveis
Participantes
Produtos requeridos
Produtos gerados
Ferramentas
Ps-tarefa
Quadro 2.9 Definio da Atividade Definir Objetivos e Medidas

Atividade: Definir Objetivos e Medidas
Descrio: Identificar objetivos, indicadores e medidas de forma que estes estejam alinhados s
necessidades e objetivos de informao da organizao.
Tarefa:
Descrio:
Pr-tarefa:
Critrios de entrada:
Critrios de sada:
Responsveis:
Participantes:
Produtos requeridos:
Produtos gerados
Ferramentas:
Ps-tarefa:
Identificar ou rever objetivos de medio

Estabelecer ou revisar objetivos para medies derivados das
necessidades e objetivos de informao da organizao. Deve-se
procurar ter um conjunto no muito grande de objetivos sendo tratados
em um determinado momento. Dessa forma, se o conjunto inicial de
objetivos for grande, ele precisa ser priorizado para que se possa
selecionar os objetivos que sero tratados. Os objetivos devem ser
revistos periodicamente e atualizados, quando necessrio.
Ter iniciado a implantao do processo de Medio ou haver
necessidade de rever o Documento de Indicadores e Medidas.
Objetivos de medio definidos ou revistos
Grupo de Medio
Diretoria, Grupo de Processos
Documento de Indicadores e Medidas
Documento de Indicadores com objetivos identificados ou revistos
Editor de texto
Identificar ou rever questes, indicadores e medidas
Tarefa:
Descrio:
Identificar ou rever questes, indicadores e medidas
Pr-tarefa:
Critrios de entrada:
Identificar ou rever objetivos de medio

Documento de Indicadores e Medidas com objetivos definidos ou revistos
Documento de Indicadores e Medidas com questes, indicadores e
medidas identificados ou revistos
Grupo de Medio
Diretoria, Grupo de Processos
Documento de Indicadores e Medidas com objetivos identificados ou
revistos
Documento de Indicadores e Medidas com questes, indicadores e
medidas identificados ou revistos
Editor de texto
Especificar procedimentos de coleta e armazenamento de dados
Critrios de sada:
Responsveis:
Participantes:
Produtos requeridos:
Produtos gerados
Ferramentas:
Ps-tarefa:
Estabelecer ou revisar questes a serem respondidas para que os

objetivos de medio da organizao possam ser mensurados e especificar
indicadores e medidas para avaliar o alcance dos objetivos definidos.
Questes, indicadores e medidas devem ser revistos periodicamente e
atualizados, quando necessrio.
30
2.6 Consideraes Finais do Captulo

Neste captulo foram discutidos os aspectos fundamentais de medio de
software de forma a constituir a base para o entendimento dos prximos captulos.
Para resolver o problema da heterogeneidade de vocabulrio presente na
literatura foram definidos os conceitos fundamentais relacionados medio de
software a partir de uma ontologia de medio.
Foi discutida a importncia da medio para a melhoria de processos de
software e como a medio tratada nas normas internacionais ISO/IEC 12207,
ISO/IEC 15504 e nos modelos de maturidade CMMI-DEV e MR-MPS.
Um programa de medio para ser efetivo deve estar apoiado em um
processo de medio, definido por cada organizao com detalhes suficientes para
poder ser executado de forma consistente. Esse captulo forneceu algumas
orientaes para a definio desse processo.
No Captulo 3 sero apresentadas as principais abordagens para o
planejamento e execuo de medies de software de modo que as organizaes
possam obter os benefcios esperados de seus programas de medio.
31
Captulo 3
Planejamento e Execuo de Medies
3.1 Introduo
Um bom programa de medio precisa ser planejado e o planejamento
comea com a derivao dos objetivos estratgicos da empresa para a definio
dos objetivos de medio. Essa associao de grande importncia para o sucesso
do programa de medio porque possibilita que o esforo seja concentrado em
reas que contenham aspectos relevantes para a tomada de deciso na organizao
como um todo e na rea responsvel pelo desenvolvimento de software em
particular.
Muitas vezes, por causa de uma definio falha e ambgua, o relacionamento
entre os objetivos estratgicos e os objetivos de medio superficial e
insuficiente para explicar completamente a associao entre eles. Dessa forma, no
se tem a garantia de que as medidas identificadas atendam corretamente s
necessidades de informao dos diferentes nveis de gerncia da organizao
[SOFTEX, 2011b].
Dois mtodos so especialmente importantes para apoio ao planejamento
de medies: GQM (Goal-Question-Metric) [BASILI et al., 1994; SOLINGEN e
BERGHOUT, 1999] e PSM (Practical Software Measurement) [MCGARRY et al.,
2002], tambm descrito na norma internacional ISO/IEC 15939 [ISO/IEC, 2002].
GQM um mtodo bastante utilizado para apoio definio de medidas
devido sua simplicidade de uso e estrutura top down que possibilita a
identificao das medidas a partir de questes associadas aos objetivos de
medio.
PSM define um modelo de informao para medio com uma terminologia
padro e o relacionamento entre os conceitos de medio, associando as
informaes necessrias para atingir os objetivos tcnicos e de negcio aos
atributos a serem medidos. Define tambm um modelo de processo de medio.
Aps a definio dos objetivos de medio de software, o prximo passo
identificar medidas adequadas para responder s necessidades de informao
32
relacionadas aos objetivos. O planejamento de medies se completa com a

definio dos procedimentos de coleta e anlise das medidas e da forma de
armazenamento.
Neste captulo ser mostrado como definir os objetivos de medio de
software a partir dos objetivos estratgicos da organizao e como, a partir dos
objetivos de medio, se pode chegar a um conjunto adequado de medidas (seo
3.2).
Sero apresentados os dois principais mtodos utilizados para apoiar a
definio do Plano de Medio (seo 3.3): GQM [BASILI et al., 1994; SOLINGEN e
BERGHOUT, 1999] e PSM [MC GARRY et al., 2002], [ISO/IEC, 2002]. Sero
apresentadas, tambm, duas importantes variaes do GQM: GQ(I)M (GoalQuestion-(Indicator)-Measure) [PARK et al., 1996] eGQM*Strategies [BASILI et al.,
2007]. Sero, ainda, apresentadas cinco medidas essenciais propostas em
[PUTNAM e MYERS, 2003], a partir das quais podem ser obtidas a maior parte das
medidas utilizadas pelas organizaes (seo 3.4). A partir desses conceitos, sero
apresentados os demais elementos que compem o planejamento de medies
(sees 3.5 a 3.7).
Tambm sero apresentados aspectos relacionados realizao de
medies conforme o planejamento realizado: coleta e armazenamento de dados
para as medidas, anlise de indicadores, comunicao de resultados e tomada de
deciso (seo 3.8). Por fim, sero apresentadas as consideraes finais do captulo
(seo 3.9).
3.2 Objetivos Estratgicos da Organizao e Objetivos de Medio

Organizaes para serem competitivas necessitam planejar a sua estratgia.
Estratgia , assim, um plano que visa dar organizao uma vantagem
competitiva. Para isso a organizao precisa entender o que ela faz, o que deseja se
tornar e como fazer para alcanar essa meta. Precisa, tambm, entender o que no
faz. Uma estratgia deve, portanto, identificar as metas de uma organizao, a
direo necessria para organizar o seu trabalho e atingir essas metas. A definio
da estratgia deve partir da misso da organizao, seguir um processo bem
33
definido, com foco em questes prioritrias, e chegar a um plano de ao possvel

de ser avaliado quanto ao desempenho [LUECKE, 2010].
Metas estratgicas no podem ser definidas apenas baseadas em desejos
dos dirigentes. Pelo contrrio, surgem de uma anlise criteriosa da organizao e
do ambiente externo a ela. Ao analisar a organizao (anlise interna) devem-se
considerar suas foras (pontos fortes) e fraquezas (pontos fracos). Ao analisar o
ambiente externo devem-se considerar as oportunidades e ameaas para a
organizao que tm origem externamente.
O planejamento estratgico pode ser, ento, resumido como a definio de
objetivos estratgicos (tambm chamados de objetivos de negcio), investimentos
e planos, com relao ao futuro de uma organizao, com base nos seus pontos
fortes, buscando eliminar seus pontos fracos, explorando as oportunidades e
reagindo s ameaas [BARRETO, 2011]. A anlise dos pontos fortes, pontos fracos,
oportunidades e ameaas do ambiente externo conhecida pelo acrnimo SWOT
(Strength, Weakness, Oportunities, Threats) [LUECKE, 2010].
O planejamento estratgico um planejamento de longo prazo, voltado para
o que se deseja para o futuro da organizao. Desta forma, os objetivos estratgicos
devem ser refinados em objetivos mais especficos, mais fceis de serem avaliados
quanto ao seu alcance. Para permitir essa avaliao devem ser definidos
indicadores e medidas. Em organizaes de software a avaliao do alcance dos
objetivos est vinculada a medidas relacionadas a processos e produtos de
software.
A elaborao do planejamento estratgico de uma organizao pode ser
apoiada, ainda, pelo uso do Balanced Score Card (BSC) proposto por KAPLAN e
NORTON (1996), um mtodo para descrever, implementar e gerenciar a estratgia
da organizao. Pode ser usado para traduzir a misso da organizao em
objetivos estratgicos e estabelecer um conjunto de indicadores e medidas de
desempenho. O BSC considera quatro perspectivas: (i) financeira; (ii) clientes; (iii)
processos de negcios internos e (iv) aprendizado e crescimento. A Figura 3.1
mostra a estrutura do BSC.
34
Subobjetivos Financeiros
VISO E
ESTRATGIA
Subobjetivos
relacionados aos Clientes
Subobjetivos relacionados
aos Processos de Negcio
Subobjetivos relacionados a
Aprendizado e Crescimento
Figura 3.1 -Estrutura do Balanced Scorecard (adaptado de [KAPLAN e NORTON, 1996]).
Nas
organizaes
desenvolvedoras
de
software,
execuo
do
planejamento estratgico est vinculada execuo dos projetos. Dessa forma, os

projetos devem fornecer medidas que possibilitem avaliar o alcance dos objetivos
estratgicos [BARRETO, 2011].
Fica clara, assim, a necessidade de associao entre os objetivos
estratgicos e os objetivos de medio da organizao. Quando o relacionamento
entre os objetivos estratgicos e os objetivos de medio superficial e
insuficiente, no se tem a garantia de que as medidas identificadas iro atender s
necessidades de informao da organizao [SOFTEX, 2011b].
Os modelos de maturidade CMMI-DEV e MR-MPS tratam a medio desde os
nveis iniciais de maturidade (CMMI-DEV no nvel 2 e o MR-MPS no nvel F)
destacando sempre a necessidade do alinhamento das medidas aos objetivos de
negcio da organizao [SEI, 2010; SOFTEX, 2011a].
Entretanto, definir objetivos de medio de software e medidas alinhados
aos objetivos estratgicos no uma tarefa trivial e necessita do apoio de mtodos
que guiem essa definio.
3.3 Definio de Objetivos, Medidas e Indicadores

Conforme discutido em sees anteriores, no tem sentido uma organizao
medir por medir, sem ter claro o que cada medida pode informar. Medies custam
caro e precisam ser teis para justificar o investimento de recursos humanos e
35
financeiros. As organizaes necessitam, portanto, ter clareza sobre a adequao e

utilidade das medidas que coletam e analisam. Necessitam garantir que essas
medidas podem apoiar a tomada de deciso relacionada a seus objetivos de
negcio.
As abordagens baseadas em objetivos para definio de medidas visam: (i)
identificar objetivos de negcio ou uma questo chave que necessita ser
respondida; (ii) identificar as necessidades de informao necessrias para
determinar se o objetivo foi atingido ou para responder a questo; (iii) quantificar
as necessidades de informao sob a forma de medidas; e (iv) analisar as medidas
para determinar se os objetivos foram alcanados ou se a questo foi respondida
de forma adequada [ALLEN e DAVIS, 2010].
A seguir so apresentados os principais mtodos de apoio definio de
objetivos, medidas e indicadores.
3.3.1 O Mtodo GQM (Goal Question Metric)

O mtodo GQM [BASILI et al., 1994] tem o objetivo de apoiar a definio de
medidas1 alinhadas aos objetivos de negcio da organizao. Baseia-se no
entendimento de que, para realizar medies de forma adequada, uma organizao
necessita primeiramente definir os seus objetivos e os objetivos de seus projetos
para depois relacion-los aos dados necessrios. Por fim, deve fornecer um
framework para anlise e interpretao dos dados com relao aos objetivos
estabelecidos.
O resultado da aplicao do GQM uma estrutura hierrquica com trs
nveis (Figura 3.2): (i) nvel conceitual (Objetivo), (ii) nvel operacional (Questo) e
(iii) nvel quantitativo (Medida).Atravs de uma abordagem top-down e orientada a
objetivos, so definidos objetivos que so refinados em questes. Medidas so,
ento, definidas de forma que sejam adequadas para responder s questes. A
anlise das medidas permite verificar o grau de alcance dos objetivos [SOLINGEN e
BERGHOUT, 1999].
Na Figura 3.3 apresentado um exemplo de uso do mtodo GQM para
1
Conforme os conceitos de medio definidos no Captulo 2 neste livro utiliza-se o termo medida
em vez do termo mtrica. Essa opo consistente com a terminologia utilizada nos modelos CMMI
e MR-MPS.
36
definio de medidas. Nesse exemplo tem-se o objetivo de melhorar as estimativas

de projeto. Esse objetivo pode ser refinado em vrias questes como, por exemplo:
Qual a preciso das estimativas de cronograma do projeto? e Qual a preciso das
estimativas de esforo do projeto?. Essas questes podem ser respondidas atravs
das medidas.
QUESTO
MEDIDA
QUESTO
MEDIDA
OBJETIVO 2
QUESTO
MEDIDA
QUESTO
MEDIDA
QUESTO
MEDIDA
MEDIDA
INTERPRETAO
DEFINIO
OBJETIVO 1
Figura 3.2 Paradigma GQM (adaptado de [BASILI et al., 1994]).
Objetivo
Propsito:
Questo:
Objeto:
Ponto de vista:
Melhorar
preciso
estimativas de projeto
analisado pelo ponto de vista dos gerentes de projeto
Questo 1
Qual a preciso das estimativas de cronograma do projeto?
Medida 1a)
Preciso Total de Cronograma = tempo real de todo o projeto
tempo estimado do projeto
Medida 1b)
Preciso Cronograma por atividade =
tempo real por atividade

tempo estimado por atividade
Questo 2
Qual a preciso das estimativas de esforo do projeto?
Medida 2a)
Preciso Total do Esforo = esforo real de todo o projeto
esforo estimado para o projeto
Medida 2b)
Preciso esforo por atividade =
esforo real por atividade

esforo estimado por atividade
Figura 3.3 Exemplo de uso do mtodo GQM.
O prximo passo aps a definio dos objetivos, questes e medidas

produzir um Plano de Medio e Anlise que deve conter as seguintes informaes
[SOLINGEN e BERGHOUT, 1999]:
37
Definio das medidas.
Possveis valores para as medidas.
Procedimentos para coleta das medidas, que podem ser manuais ou

automatizados.
Responsabilidade pela coleta das medidas.
Definio do momento em que a coleta deve ser realizada.
Procedimentos para anlise das medidas.
Forma de apresentao dos dados para os envolvidos.
Exemplos detalhados de uso de GQM para estabelecer o Plano de Medio e

Anlise podem ser encontrados em [SOLINGEN e BERGHOUT, 1999].
As duas principais variaes do mtodo GQM so os mtodos GQ(I)M (GoalQuestion-(Indicator)-Measure) [PARK et al., 1996] e GQM*Strategies [BASILI et al.,
2007]. A seguir essas duas abordagens so descritas.
3.3.2 O Mtodo GQ(I)M (Goal Question (Indicator) Measure)

O mtodo GQ(I)M uma variao do mtodo GQM, que prope o
alinhamento de medidas e indicadores com os objetivos. Esse mtodo est baseado
no entendimento de que identificar questes e medidas sem visualizar um
indicador muitas vezes no suficiente.
Para se utilizar o mtodo GQ(I)M deve-se seguir os seguintes passos
[GOETHERT e FISHER, 2003; ALLEN e DAVIS, 2010; BARRETO, 2011]:
1. Identificar e priorizar os objetivos de negcio da organizao.
2. Identificar o que se deseja conhecer para entender, avaliar, predizer ou
melhorar as atividades relacionadas ou alcance dos objetivos.
3. Identificar os subobjetivos, o que significa traduzir os objetivos de alto
nvel em subobjetivos relacionados s atividades.
4. Identificar entidades e atributos relacionados aos subobjetivos e
necessrios medio.
5. Formalizar os objetivos de medio.
6. Identificar questes quantificveis e indicadores relacionados s
questes que sero usados para apoiar o alcance dos objetivos.
7. Identificar os elementos de dados que sero coletados para compor os
indicadores que ajudaro a responder s questes.
38
8. Definir as medidas que sero usadas e realizar sua definio

operacional2.
9. Identificar as aes que sero realizadas para implementar as medidas.
10. Preparar um plano para implementar as medidas.
Em [ALLEN e DAVIS, 2010] pode-se encontrar um exemplo detalhado do
uso de GQ(I)M.
Em [GOETHERT e FISHER, 2003] apresentada uma abordagem para
derivar medidas organizacionais utilizando Balanced Scorecard e GQ(I)M. Essa
abordagem possui quatro passos (Figura 3.4): (i) obter e esclarecer a misso e
viso da organizao; (ii) derivar objetivos estratgicos e subobjetivos usando
GQ(I)M; (iii) mapear os subobjetivos no BSC, e (iv) aplicar GQ(I)M para definir os
critrios de sucesso para cada subobjetivo, estabelecer questes relevantes e
definir indicadores para cada subconjunto em cada quadrante do BSC e determinar
medidas para os indicadores.
Esclarecer Misso e
Viso da Organizao
Definir Objetivos
Estratgicos
Balanced Scorecard
Definir Subobjetivos
Mapear Subobjetivos
no BSC
Subobjetivos Financeiros
Subobjetivos
relacionados aos Clientes
Subobjetivos relacionados
aos Processos de Negcio
Subobjetivos relacionados a
Aprendizado e Crescimento
Para cada Quadrante do BSC

Definir Critrios de Sucesso
Aplicar GQ(I)M
INDICADORES
Figura 3.4 Integrao BSC e GQ(I)M (adaptado de [GOETHERT e FISHER, 2003]).
3.3.3 O mtodo GQM*Strategies

Novamente com o objetivo de alinhar a medio de software s estratgias
de negcio das organizaes Basili, Heidrich, Lindvall, Mnch, Regardie e
Trendowicz [BASILI et al., 2007] definiram o mtodo GQM*Strategies, uma
extenso da abordagem GQM.
2
A definio operacional de medidas tratada neste captulo na Seo 3.7
39
Os autores reconhecem que, embora o GQM tenha se mostrado til para a

indstria de software, no fornece uma forma explcita para integrar os objetivos
de medio de software aos objetivos de mais alto nvel da organizao.
GQM*Strategies visa suprir essa carncia fornecendo mecanismos para relacionar
explicitamente os objetivos de medio de software aos objetivos de mais alto
nvel da organizao de software e aos objetivos e estratgias do negcio como um
todo. Dessa forma, essa extenso ao GQM lhe adiciona a capacidade de estabelecer
programas de medio que garantem o alinhamento entre objetivos de negcio e
estratgias, objetivos especficos de software e objetivos de medio.
O GQM*Strategies acrescenta um conjunto de extenses no topo do mtodo
GQM (Figura 3.5), tornando explcitos os objetivos de negcio, as estratgias e os
objetivos de software.
GQM*Strategies compreende os seguintes passos:
1. Selecionar os objetivos de negcio da organizao.
2. Identificar estratgias que apoiam a identificao dos objetivos
especficos de software que contribuem para o alcance dos objetivos
de negcio.
3. Identificar os objetivos de software.
4. Identificar cenrios, isto , um conjunto de aes necessrias para se
alcanar o objetivo de software.
5. Definir objetivos de medio a partir dos cenrios.
6. Derivar questes e medidas a partir dos objetivos de medio.
OBJETIVOS DE NEGCIO
RESULTADOS
Strategies
GQM*Strategies
RESULTADOS
OBJETIVOS DE SOFTWARE
OBJETIVOS DE MEDIO
Figura 3.5 GQM*Strategies (adaptado de [Basili et al., 2007])

QUESTO
MEDIDA
MEDIDA
QUESTO
MEDIDA
MEDIDA
Figura 3.5 GQM*Strategies (adaptado de [Basili et al., 2007]).
40
3.3.4 Practical Software Measurement (PSM)e a norma

ISO/IEC15939
O processo de medio proposto pela ISO/IEC 15939 [ISO/IEC, 2007]
orientado s necessidades de informao da organizao. Para cada necessidade de
informao, o processo gera um produto de informao, a fim de satisfazer a
necessidade de informao identificada. Para isso, o processo considera um
Modelo de Informao de Medio, que estabelece a ligao entre as medidas
definidas e as necessidades de informao identificadas. A Figura 3.6 apresenta o
Modelo de Informao de Medio definido na ISO/IEC 15939.
De acordo com o Modelo de Informao de Medio, as necessidades de
informao so atendidas por conceitos mensurveis definidos em relao s
entidades que podem ser medidas. Essas entidades possuem atributos aos quais
so aplicados mtodos de medio para obter medidas base que so associadas
atravs de funes de medio para compor medidas derivadas. Medidas so
analisadas por modelos de anlise e fornecem indicadores cuja interpretao
representa produtos de informao que atendem s necessidades de informao
inicialmente identificadas.
PSM [McGarry et al.,2002] uma abordagem para medio de software
orientada s necessidades de informao organizacionais aderente ISO/IEC
15939 e, como ela, possui dois componentes: um Modelo de Informao de
Medio e um Processo de Medio.
O Modelo de Informao de Medio, assim como na ISO/IEC 15939, tem
como objetivo estabelecer a ligao entre as medidas definidas e as necessidades
de informao identificadas. Para isso, como mostra a Figura 3.7, o modelo de
informao representa a evoluo de uma necessidade de informao at o Plano
de Medio.
A partir das necessidades de informao, conceitos mensurveis, que
indicam o que deve ser medido para atend-las, devem ser identificados e
modelados em um construtor de medio para estabelecer exatamente que
medidas de que atributos so necessrias. A partir da, o mecanismo de coleta e
organizao dos dados de uma ou vrias instncias do construtor de medio deve
ser definido. O Plano de Medio o resultado formal que agrupa todos os itens
41
anteriores.
Sendo aderente norma ISO/IEC 15939, a relao entre necessidades de
informao e conceito mensurvel do Modelo de Informao do PSM equivale
relao entre esses itens presente no Modelo de Informao de Medio da
ISO/IEC 15939 (representado no lado esquerdo da Figura 3.6). O construtor de
medio, por sua vez, inclui os demais itens presentes no Modelo de Informao da
ISO/IEC 15939 (demais itens representados na Figura 3.6).
Necessidades de Informao
Produto de Informao
Interpretao
Indicador
Modelo de
Anlise
Conceito
Mensurvel
Medida
Derivada
Medida
Base
Funo de
Medio
Medida
Base
Mtodo de
Medio
Entidade
Atributo
Medida
Base
Mtodo de
Medio
Atributo
Figura 3.6 - Modelo de Informao de Medio [ISO/IEC, 2007].
Necessidades
de Informao
Conceito
Mensurvel
Construtor
de Medio
Procedimento
de Medio
Plano de
Medio
Figura 3.7 - Modelo de Informao de Medio [McGARRY et al., 2002].
3.3.5 Definio e Gerncia de Objetivos de Software Alinhados ao

Planejamento Estratgico
A partir da identificao da necessidade de um tratamento integrado para a
definio e gerncia de objetivos de software alinhados aos objetivos de negcio da
42
organizacional, Barreto (2011) definiu uma abordagem para apoiar o

planejamento estratgico, ttico e operacional em organizaes de software, a
monitorao dos objetivos definidos e a execuo de aes corretivas para tratar
os desvios detectados na monitorao.
A abordagem composta por trs componentes (Figura 3.8): (i) um mtodo
para planejamento estratgico, ttico e operacional em organizaes de software;
(ii) uma infraestrutura para monitorao de objetivos e (iii) uma estratgia para
recomendao de aes corretivas.
Componente I - Mtodo para
Planejamento Estratgico,
Ttico e Operacional em
Organizaes de Software
Mtodo para
Planejamento
Estratgico, Ttico
e Operacional
Modelo de Informao
para Planejamento
Estratgico, Ttico e
Operacional
Objetivos e indicadores
de monitorao
Base de
Objetivos
Conceitos para
definio de objetivos
Informaes
de medidas
Componente II - Infra-estrutura
para Monitorao de Objetivos
Coletas das
medidas
Execuo dos
Projetos
Base de
Medidas
Monitorao,
Deteco e
Notificao de
Desvios
Aes
Recomendadas
Anlise das
Aes
Executadas
Recomendao
de Aes
Desvios
Casos
Base de
Casos
Casos
Componente III Estratgia para

Recomendao de Aes Corretivas
Legenda
Troca de informaes e dados
Monitorao de informaes e dados
Figura 3.8 - Definio e Gerncia de Objetivos de Software Alinhados ao Planejamento Estratgico

[BARRETO, 2011].
O mtodo para planejamento estratgico, ttico e operacional apoiado por

um modelo de informao que descreve os conceitos necessrios para a elaborao
do planejamento nos trs nveis. Esse modelo de informao e o mtodo para
planejamento estratgico, ttico e operacional so usados como base para a
definio e utilizao dos demais componentes da abordagem.
43
A aplicao do mtodo permite a definio dos objetivos estratgicos,

tticos e operacionais, bem como a associao de indicadores para a monitorao
dos objetivos. Os objetivos tticos relacionados a software so os objetivos de
software.
Os objetivos definidos so acompanhados atravs da infraestrutura de
monitorao, com base nas medidas coletadas para os indicadores de monitorao.
A infraestrutura de monitorao responsvel por analisar continuamente os
valores coletados para os indicadores, detectar e notificar a ocorrncia de desvios.
Durante a notificao de um desvio so identificados casos similares e as aes
executadas com sucesso nesses casos so recomendadas.
3.4 As Cinco Medidas Essenciais

Putnam e Myers (2003) tratam a questo, amplamente discutida, da
necessidade de tornar a medio de software efetiva e consideram que o primeiro
passo para isso escolher as medidas certas, isto , medidas que ajudem a
organizao a operar com sucesso no mercado. Nesse contexto, identificaram cinco
medidas que consideram essenciais: quantidade de funes (tamanho),
produtividade, tempo, esforo e confiabilidade.
Segundo os autores, qualquer atividade, entre elas o desenvolvimento de
software, pode ser descrita como a seguir, o que mostra a relao entre as cinco
medidas essenciais:
Pessoas, trabalhando em algum nvel de produtividade, produzem
uma quantidade de funes ou um produto de trabalho com
algum nvel de confiabilidade, despendendo esforo em um
intervalo de tempo.
Tempo , normalmente, medido em horas, dias, semanas ou meses,
dependendo do tamanho do projeto.
Esforo medido em homem-ms ou homem-horas.
Qualidade medida em termos de taxa de defeitos (confiabilidade), tendo
em conta que qualquer produto entregue, ainda, com a presena de alguns
defeitos.
Quantidade de funes ou funcionalidade do produto normalmente
44
medido utilizando linhas de cdigo fonte (source lines of code SLOC) ou pontos
por funo.
Produtividade, em geral, medida como linhas de cdigo fonte ou pontos
por funo por homem-ms, utilizando dados histricos da organizao. Segundo
os autores, essa no uma medida precisa e propem que produtividade seja
medida em termos de produtividade do processo, isto a produtividade de toda a
equipe durante as diversas fases do desenvolvimento.
Essas cinco medidas so interdependentes. Se existe o desejo de reduzir o
tempo de desenvolvimento, deve-se aumentar o esforo. Pode-se, tambm,
aumentar a qualidade do esforo, alocando pessoal mais qualificado ao projeto.
Pode-se, ainda, em benefcio da rapidez no desenvolvimento, sacrificar a
confiabilidade e entregar um produto com menor qualidade.
Por outro lado, se o desejo construir um produto melhor, com mais
funcionalidades ou maior confiabilidade necessrio aumentar o tempo ou o
esforo. E ainda, se o desejo for diminuir o custo, o que significa diminuir o esforo,
deve-se diminuir a nfase em desenvolver mais rpido ou desenvolver melhor. O
nico meio de desenvolver melhor, mais rpido e com menor custo aumentando
a produtividade (Tabela 3.1).
Tabela 3.1 Relao entre as Medidas Essenciais (adaptado de [PUTNAM e MYERS, 2003]).
TEMPO
ESFORO
CONFIABILIDADE
TAMANHO
PRODUTIVIDADE
MAIS RPIDO
MELHOR
MAIS BARATO
Entretanto, importante notar que existem limites para o que se pode

aumentar ou diminuir nessas medidas. Existe um tempo mnimo de
desenvolvimento e este depende do tamanho e tipo do produto, das caractersticas
da equipe envolvida e do ambiente de desenvolvimento. De qualquer forma,
diminuir o tempo de desenvolvimento vai significar aumentar o esforo e o custo.
Alm disso, provavelmente, vai significar diminuio da confiabilidade.
45
3.5 Definio dos Procedimentos de Coleta e Armazenamento

Finalizada a identificao das medidas, o prximo passo definir os
procedimentos de coleta e armazenamento dos dados, isto , como ser a obteno
dos dados que sero utilizados nas medies e onde estes ficaro armazenados.
Como a produo de software uma tarefa intelectual, a coleta de dados
requer, muitas vezes, observao e coleta manual e, portanto, realizada por
pessoas. Quando a coleta manual, os responsveis por esta tarefa registram os
dados coletados em formulrios especficos.
Coletas manuais so sujeitas ao vis de quem coleta o dado (que tanto pode
ser involuntrio quanto voluntrio), erros, omisses e atrasos na coleta. O ideal
seria se poder, sempre, fazer coleta de dados de forma automtica. Entretanto, isso
nem sempre possvel. Para garantir que a coleta seja feita de forma adequada,
necessrio definir como ela ser realizada [FENTON e PFLEEGER, 1997].
A definio explcita dos mtodos de coleta de dados ajuda a garantir que os
dados sejam coletados de forma correta e uniforme. Os procedimentos de coleta de
dados incluem a definio de que dados sero coletados, como sero coletados,
quando sero coletados, quem responsvel pela coleta e onde sero
armazenados. Para isso necessrio especificar: (i) a frequncia com que ser
realizada a coleta; (ii) o responsvel pela coleta; (iii) formulrios e/ou ferramentas
utilizadas para a coleta; (iv) instrues e guias de apoio coleta de dados; (v) o
local de armazenamento dos dados; (vi) o responsvel pelo armazenamento,
recuperao e segurana dos dados [SEI, 2010; SOFTEX, 2011b].
importante garantir que os procedimentos de coleta sejam simples e, se
possvel, integrados a outros processos, realizados de forma automtica, sem
alterar a rotina do profissional na execuo da tarefa que gera o dado.
Caso sejam necessrios formulrios para coleta de dados, estes devem ser o
mximo possvel autoexplicativos. Devem, tambm, permitir o registro do dado e o
contexto de coleta para que seja possvel verificar sua confiabilidade e integridade.
Um estudo realizado por Basili e Weiss em projetos da NASA, relatado em
[FENTON e PFLEEGER, 1997], mostrou que metade dos dados coletados
apresentavam problemas e no eram, portanto, teis.
46
Outro aspecto a ser definido, nesse momento, como ser realizado o

armazenamento dos dados, de forma a garantir sua segurana e recuperao
futura. Os modelos CMMI-DEV [SEI, 2010] e MR-MPS [SOFTEX, 2011a] tm como
um de seus requisitos, respectivamente nos nveis 3 e E, a definio de um
repositrio de medidas para a organizao. Entretanto, a realizao de medies
tem incio em nveis anteriores (nvel 2 do CMMI e F do MR-MPS). Embora, nesses
nveis, ainda no seja obrigatria a existncia de um repositrio organizacional de
medidas, recomendvel que desde esses nveis as organizaes j possuam um
repositrio capaz de garantir armazenamento e recuperao adequados dos dados.
No processo Definio do Processo Organizacional presente no Nvel 3 do
CMMI (prtica especfica 1.4) e E do MR-MPS (DFP 6) aparece a exigncia de
criao de um repositrio de medidas, que deve conter: (i) medidas dos processos
e dos produtos; (ii) informaes necessrias para entender e interpretar as
medidas; e (iii) informaes necessrias para verificao da qualidade das
medidas.
A infraestrutura do repositrio de medidas deve ser definida de forma a
considerar a evoluo contnua das medidas dos processos e produtos e, tambm,
a evoluo da organizao para nveis mais altos de maturidade. Diversos
trabalhos definem os requisitos que um repositrio de medidas deve satisfazer
[FENTON e PFLEEGER, 1997; FLORAC e CARLETON, 1999; KITCHENHAM et al.,
2006; KITCHENHAM et al., 2007; BARCELLOS, 2009a]. Uma discusso mais
detalhada sobre o repositrio de medidas pode ser encontrada no prximo
captulo.
3.6 Definio dos Procedimentos de Anlise

A etapa seguinte ao planejamento da realizao de medies a
especificao dos procedimentos para anlise dos dados coletados para as
medidas.
A definio dos procedimentos de anlise tambm deve ser feita antes de se
iniciar a execuo de medies, de forma a garantir que a anlise seja realizada de
forma correta e os resultados sejam relatados de forma a tratar os objetivos de
medio estabelecidos e as necessidades de informao.
A definio dos procedimentos de anlise inclui [SEI, 2010]: (i) especificar e
47
priorizar as anlises a serem realizadas e os relatrios a serem produzidos; (ii)

selecionar os mtodos e ferramentas para anlise de dados; (iii) especificar os
procedimentos administrativos para analisar e comunicar os resultados; (iv) rever
e atualizar o contedo e formato das anlises e relatrios; (v) atualizar medidas e
medies, se necessrio; e (vi) especificar os critrios para avaliar a utilidade dos
resultados das anlises e para avaliar a execuo das medies e anlises.
A seleo dos mtodos e ferramentas para a anlise dos dados inclui: (i)
escolher as tcnicas de apresentao mais adequadas (por exemplo, grficos de
pizza, grficos de barras, histogramas etc.); (ii) escolher a estatstica descritiva
(por exemplo, mdia, mediana ou moda); (iii) definir os critrios para amostragem
quando no for adequado analisar todos os dados; (iv) definir como ser realizada
a anlise caso faltem dados; e (v) selecionar as ferramentas de anlise [SEI, 2010;
FLORAC e CARLETON, 1999].
Assim, para cada medida identificada devem ser definidas as atividades e
responsabilidades pela anlise de dados e como os dados sero comunicados aos
interessados. Essa definio deve incluir: definio da frequncia da anlise de
dados; responsvel pela anlise, dados a serem utilizados, ferramentas de anlise,
metas, verificaes a serem realizadas e forma de comunicao dos resultados
[SOFTEX, 2011 b].
3.7 Definio Operacional de Medidas

A forma de definio das medidas importante para garantir que elas sejam
coletadas e analisadas de forma consistente e independente de quem faz a coletae
a anlise.
Para serem teis as medidas precisam estar bem definidas, o que significa
satisfazer a trs critrios [FLORAC e CARLETON, 1999]:
Comunicao: a definio da medida e a descrio dos valores medidos

devem permitir que se entenda precisamente o que foi medido e como os
dados foram coletados para que seja possvel interpretar corretamente os
resultados.
Repetitividade: a definio da medida deve permitir que pessoas

diferentes possam realizar a medio e obter os mesmos resultados.
48
Rastreabilidade: a origem dos dados deve estar identificada em termos de

tempo, fonte, atividade, produto, ferramenta utilizada para a medio e
responsvel pela coleta.
Esses critrios so a base para as definies operacionais de medidas. Uma
definio operacional incompleta, ambgua ou fracamente documentada possibilita

que diferentes pessoas entendam a medida de maneiras diferentes e,
consequentemente, coletem dados invlidos, realizem medies incomparveis ou
anlises incorretas, o que torna a medio inconsistente e ineficiente
[KITCHENHAM et al., 2001].
A definio operacional de uma medida deve conter as seguintes
informaes:
Nome: nome da medida.
Definio: descrio sucinta da medida.
Mnemnico: sigla utilizada para identificar a medida.
Tipo de Medida: classificao da medida quanto sua dependncia

funcional, podendo uma medida ser uma medida base ou uma
medida derivada.
Entidade Medida: entidade que a medida mede. Exemplos:

organizao, projeto, processo, atividade, recurso humano, recurso
de hardware, recurso de software e artefato, dentre outros.
Propriedade Medida: propriedade da entidade medida que

quantificada pela medida. Exemplos: tamanho, custos, defeitos,
esforo etc.
Unidade de Medida: unidade de medida em relao qual a medida

medida. Exemplos: pessoa/ms, pontos por funo, reais etc.
Tipo de Escala: natureza dos valores que podem ser atribudos

medida. Exemplos: escala nominal, escala intervalar, escala ordinal,
escala absoluta e escala taxa.
Valores da Escala: valores que podem ser atribudos medida.

Exemplos: nmeros reais positivos, {alto, mdio, baixo} etc. Para
medidas com escala do tipo absoluta ou taxa, ao determinar os
valores da escala, preciso identificar a preciso a ser considerada
49
(0, 1 ou 2 casas decimais).
Intervalo Esperado dos Dados: limites de valores da escala

definida de acordo com dados histricos ou com metas estabelecidas.
Exemplo: [0, 10].
Procedimento de Medio: descrio do procedimento que deve

ser realizado para coletar uma medida. A descrio do procedimento
de medio deve ser clara, objetiva, no ambgua e deve incluir onde
os valores medidos devem ser registrados.
Frmula de Clculo de Medida: frmula utilizada no procedimento

de medio de medidas derivadas, para calcular o valor atribudo
medida considerando-se sua relao com outras medidas ou com
outros valores. Exemplo: aderncia ao cronograma = tempo real /
tempo estimado.
Responsvel pela Medio: papel desempenhado pelo recurso

humano responsvel pela coleta da medida. importante que o
responsvel pela medio seja fonte direta das informaes a serem
fornecidas
na
medio.
Exemplos:
analista
de
sistemas,
programador, gerente do projeto etc.
Momento da Medio: momento em que deve ser realizada a coleta

e registro de dados para a medida. O momento da coleta deve ser
uma atividade do processo definido para os projetos ou de um
processo organizacional. Exemplos: na atividade Homologar
Especificao de Requisitos, na atividade Realizar Testes de Unidade
etc.
Periodicidade de Medio: frequncia de coleta da medida.

Exemplos: diria, mensal, uma vez por fase, uma vez por projeto,
uma vez em cada ocorrncia da atividade designada como momento
da medio etc. indispensvel que haja coerncia entre a
periodicidade de medio e o momento de medio.
Procedimento de Anlise: descrio do procedimento que deve ser

realizado para representar e analisar os dados coletados para uma
medida, incluindo, alm do procedimento propriamente dito, as
ferramentas analticas que devem ser utilizadas (por exemplo:
50
histograma). A descrio do procedimento de anlise deve ser clara,

objetiva e no ambgua. Um procedimento de anlise de medio
pode ser baseado em critrios de deciso (por exemplo, utilizando-se
uma meta como referncia) e, nesse caso, os critrios de deciso
considerados (incluindo suas premissas e concluses) devem ser
claramente
estabelecidos.
Medidas
que
no so analisadas
isoladamente no precisam ter procedimento de anlise definido.

Por exemplo: se a medida nmero de requisitos alterados s for
submetida anlise quando utilizada na composio da medida taxa
de alterao de requisitos, no h necessidade de definir seu
procedimento de anlise.
Momento da Anlise de Medio: momento em que deve ser

realizada a anlise de dados coletados para a medida. O momento da
anlise deve ser uma atividade do processo definido para os projetos
ou de um processo organizacional como, por exemplo, em atividades
de monitoramento de projeto.
Periodicidade da Anlise: frequncia de anlise de dados da

medida. Exemplos: diria, mensal, uma vez por fase, uma vez por
projeto, uma vez em cada ocorrncia da atividade designada como
momento da anlise etc. indispensvel que haja coerncia entre a
periodicidade de anlise de medio e o momento da anlise de
medio.
Responsvel pela Anlise: papel desempenhado pelo recurso

humano responsvel pela anlise da medida. importante que o
responsvel pela anlise de medio seja apto a aplicar o
procedimento de anlise e tenha conhecimento organizacional que
propicie a correta interpretao dos dados e fornecimento de
informaes que apoiem as tomadas de deciso. Exemplos: gerente
do projeto, gerente de qualidade etc.
A Figura 3.9 apresenta um exemplo de parte de um Plano de Medio

Organizacional contendo a definio de uma medida.
51
Figura 3.9 Fragmento de um plano de medio contendo a definio de uma medida.
3.8 Execuo da Medio

Aps finalizar as etapas de planejamento conforme descrito nas sees
anteriores, a organizao est apta para iniciar a fase operacional da medio, que
envolve coleta, anlise e armazenamento de dados e resultados das anlises.
A coleta de dados deve ser realizada de acordo com os procedimentos
previamente definidos. Nesse momento so coletados os dados para as medidas
base, verificada a integridade dos dados (antes de serem armazenados) e so
52
calculadas as medidas derivadas.

Medies esto sujeitas a erros, tanto na coleta quanto no registro dos
dados. Para que a anlise possa ser realizada e decises adequadas possam ser
tomadas a partir dos resultados da anlise, os dados coletados devem cumprir um
conjunto de requisitos que garantam a sua credibilidade [FLORAC e CARLETON,
1999; BARCELLOS, 2009a].Dessa forma, importante, aps a coleta, realizar a
verificao da integridade dos dados, que pode incluir a busca por dados que
faltam, a verificao de valores fora dos limites e de comportamentos no usuais
[SEI, 2010].
Aps a coleta, verificao da integridade dos dados e clculo das medidas
derivadas, o prximo passo realizar a anlise dos dados, que inclui: (i) analisar,
interpretar os dados e elaborar concluses preliminares; (ii) realizar medies e
anlises adicionais se, com os resultados da anlise, isso se mostrar necessrio;
(iii) preparar os resultados para apresentao aos interessados; (iv) rever os
resultados preliminares com os envolvidos mais relevantes visando a realizao de
ajustes na anlise e apresentao dos dados; (v) identificar a necessidade de
melhorias no planejamento de medies na organizao [SEI, 2010; SOFTEX,
2011b]. O objetivo final da realizao de medies fornecer informaes para que
a tomada de deciso seja objetiva e baseada em dados. Sendo assim, a anlise de
dados inclui comparar as medidas obtidas com a expectativa de como elas
deveriam ser (valor esperado) e tomar as decises pertinentes em caso de desvios.
O prximo passo armazenar os resultados da anlise de dados e
informaes relacionadas s medidas que permitam seu uso futuro, o que deve ser
feito de acordo com os procedimentos previamente especificados. Essa atividade
envolve, tambm, tornar o contedo armazenado disponvel para as pessoas e
grupos adequados estabelecer mecanismos para controle de acesso que evitem o
uso inadequado das informaes armazenadas [SEI, 2010].
Medies so mais facilmente aceitas e so mais efetivas quando seus
resultados so comunicados e tornados disponveis s partes envolvidas
[MCGARRY et al., 1999].
Medidas podem evidenciar o rumo dos projetos e predizer situaes
futuras. Podem, tambm, mostrar o desempenho dos processos e apoiar a
53
identificao de pontos de melhoria porque permitem o entendimento dos

processos existentes e dos fatores de influncia [FLORAC e CARLETON, 1999; SEI,
2010; SOFTEX, 2011a; BARRETO e ROCHA, 2010].Esse conhecimento deve apoiar a
tomada de deciso e a implementao de aes corretivas.
Uma questo relevante no contexto da execuo de medies em uma
organizao o fato de que os objetivos e as necessidades de informao evoluem.
Medidas podem se tornar inteis porque a coleta se mostrou invivel ou porque
mudou o contexto da organizao, dos processos, dos produtos ou dos projetos.
Nesses casos torna-se necessrio realizar uma reviso nos objetivos de medio,
indicadores e medidas de modo a torn-los, novamente, alinhado s necessidades
de negcio e de informao sobre os processos, produtos e projetos [FLORAC e
CARLETON, 1999; MCGARRY et al., 1999].
A Figura 3.10 apresenta, como exemplo, um roteiro para elaborao do
Relatrio de Medio, que apresenta os resultados das anlises das medidas.

Neste captulo foram apresentadas as principais abordagens para
planejamento de medies. A utilizao de abordagens baseadas em objetivos de
medio, alinhada ao planejamento estratgico e aos objetivos de negcio da
organizao um fator crtico para o sucesso de um programa organizacional de
medio.
De pouco vale, entretanto, ter-se um bom planejamento se a sua execuo
no for feita de forma criteriosa e aderente ao plano. Os procedimentos de coleta,
armazenamento e verificao da integridade dos dados so, desta forma, essenciais
para que os resultados da anlise retratem a realidade da organizao, de seus
processos e produtos. S assim a medio trar os benefcios esperados, ser capaz
de apoiar o programa de melhoria de processos da organizao e a avaliao do
alcance dos objetivos estratgicos e de negcio.
No prximo captulo ser iniciada a discusso sobre o controle estatstico de
processos.
54
Relatrio de Medio
Projeto:
Ms Ref.:
Responsvel:
Empresa:
Controle de Verso do Documento

Verso
Modificaes
Projetos Medidos
Projeto
Cliente
Data
Responsvel
Gerente
Fase
Anlise das Medidas

Objetivo: <objetivo de medio conforme definido no Plano de Medio>
Questo: <questo relacionada ao conforme definido no Plano de Medio>
Medida: <nome da medida conforme o Plano de Medio>
Intervalo Esperado dos Dados: <intervalo definido no Plano de Medio>
Anlise dos Resultados:
<incluir na anlise grfico, apreciao dos resultados e
informaes de contexto pertinentes>
Medida: <nome da medida conforme o Plano de Medio>

Intervalo Esperado dos Dados: <intervalo definido no Plano de Medio>
Anlise dos Resultados:
<incluir na anlise grfico, apreciao dos resultados e
informaes de contexto pertinentes>
<repetir para todos os objetivos, questes e medidas do Plano de Medio>
Figura 3.10 Exemplo de Roteiro para Elaborao do Relatrio de Medio.
55
PARTE II
Controle Estatstico de Processos
56
Captulo 4
Conhecimento Bsico para o Controle Estatstico de
Processos e a Gerncia Quantitativa de Projetos
4.1 Introduo
No contexto de modelos de maturidade de processo, tais como o MR-MPS
[SOFTEX, 2011a] e o CMMI [SEI, 2010], a medio de software realizada de
diferentes formas, dependendo do nvel de maturidade em que a organizao se
encontra. Nos nveis iniciais, tais como os nveis G a C do MR-MPS e os nveis 2 e 3
do CMMI, realizada a medio tradicional, que consiste, basicamente, na definio
de medidas, realizao de estimativas, coleta de dados da execuo dos projetos e
comparao dos dados coletados com os valores estimados. Nos nveis mais
elevados de maturidade, tais como os nveis B e A do MR-MPS e os nveis 4 e 5 do
CMMI, a medio tradicional ainda realizada, mas no suficiente. Nesses nveis
necessrio realizar o controle estatstico dos processos de software para
conhecer seu comportamento, determinar o seu desempenho em execues
anteriores e a partir da prever seu desempenho em projetos correntes e futuros,
verificando se so capazes de atender aos objetivos de desempenho e qualidade
estabelecidos e identificando aes corretivas e de melhoria quando apropriado
[BARCELLOS, 2009a].
O controle estatstico de processos utiliza dados coletados em projetos
executados na organizao para analisar o comportamento dos processos
organizacionais instanciados nos projetos. O objetivo inicial obter processos
estveis, isto , processos cujo comportamento seja repetvel e, consequentemente,
previsvel. Processos instveis devem ter suas causas de instabilidade investigadas
e devem ser identificadas e realizadas aes corretivas para sua estabilizao. Uma
vez estveis, aes que visam melhoria da capacidade dos processos podem ser
identificadas e realizadas, conduzindo melhoria contnua dos processos.
O controle estatstico de processos foi originalmente proposto na rea de
manufatura, visando apoiar a implementao de programas de melhoria contnua
57
em linhas de produo. Apesar de sua utilizao na melhoria de processos no ser

novidade para a indstria em geral, no contexto das organizaes de software ele
pode ser considerado relativamente recente. Assim, comum que existam dvidas
no momento de sua implementao.
Neste captulo apresentada parte do conhecimento bsico necessrio para
que seja possvel implementar adequadamente o controle estatstico de processos.
Esse conhecimento complementado pelo contedo do Captulo 5, onde sero
apresentados os grficos de controle. Na seo 4.2 so apresentados alguns
aspectos relevantes para que se entenda a importncia do controle estatstico de
processos.
Na seo 4.3 so apresentados os conceitos de estabilidade e
capacidade, necessrios anlise do comportamento de processos. Na seo 4.4

abordada a identificao dos subprocessos a serem submetidos ao controle
estatstico. Na seo 4.5 discute-se a identificao de medidas adequadas para o
controle estatstico. Na seo 4.6 so discutidos aspectos que devem ser
considerados para que uma base de medidas seja adequada para o controle
estatstico. Na seo 4.7 so realizadas as consideraes finais do captulo.
4.2 O Poder do Controle Estatstico de Processos

Constantemente as organizaes se questionam se os resultados por elas
esperados esto sendo alcanados. Essa questo pode ser expressa de vrias
maneiras: se os objetivos esto sendo alcanados, se os clientes esto satisfeitos,
se est havendo retorno do investimento, se o desempenho alcanado suficiente
para o crescimento requerido para a sobrevivncia e competitividade da
organizao etc.
Para a maioria das organizaes, responder a essas questes de forma
objetiva e precisa no uma tarefa trivial, pois nem sempre os processos da
organizao so corretamente gerenciados e, com isso, seu desempenho real no
conhecido [FLORAC e CARLETON, 1999]3.
Desempenho de processo pode ser definido como uma medida dos resultados atuais que o
processo alcanou e pode ser caracterizado por medidas de processo (por exemplo: esforo, prazo e
eficincia da remoo de defeitos) e/ou por medidas de produto (por exemplo: confiabilidade e
densidade de defeitos) [SEI, 2010].
58
W. Edwards Deming [DEMING, 1986], reconhecendo a importncia da

gerncia dos processos, inspirou-se nos trabalhos de Walter A. Shewhart
[SHEWHART, 1939] acerca de process-thinking e popularizou sua abordagem para
gerncia e melhoria contnua de processos sob o nome de PDCA Plan, Do, Check,
Act.
Com o passar do tempo, os conceitos, mtodos e prticas associados
gerncia de processos e melhoria contnua foram aceitos pela comunidade de
software, que percebeu que os princpios do process-thinking poderiam ser
aplicados em organizaes de software a fim de alcanar melhoria da qualidade,
produtividade e competitividade.
Gerenciar processos de software envolve definir, medir, controlar e melhorar
os processos de trabalho associados ao desenvolvimento, manuteno e suporte
de produtos e servios de software. A gerncia efetiva dos processos corrobora
para que os produtos e servios gerados atendam aos requisitos da organizao e
dos clientes e, consequentemente, contribuam para o alcance dos objetivos de
negcio da organizao [FLORAC e CARLETON, 1999].
A aceitao e utilizao do process-thinking pelas organizaes de software
levaram percepo de que os mtodos de medio e anlise tradicionais, que
comparam os valores realizados com os valores planejados, no so suficientes
para determinar o desempenho dos processos e responder objetivamente as
questes citadas no primeiro pargrafo desta seo.
Mais uma vez, a comunidade de software reconheceu a utilidade de mtodos
e prticas oriundos da indstria para resolver questes nas organizaes de
software. O controle estatstico de processos passou, ento, das linhas de
produo da manufatura para o desenvolvimento de software [LANTZY, 1992].
Nesse contexto, o controle estatstico de processos pode ser visto como uma
evoluo do processo de medio.
O controle estatstico de processos envolve a utilizao de grficos de
controle e mtodos estatsticos especficos para analisar os dados coletados para
medidas ao longo dos projetos e fornecer informaes sobre o desempenho dos
processos.
59
A utilizao de grficos de controle e mtodos estatsticos prov aos

engenheiros de software e gerentes de projetos uma viso quantitativa do
comportamento dos processos de software. Metaforicamente, os grficos de
controle esto para os gerentes de projeto e engenheiros de software assim como
o painel de controle de um automvel est para seu motorista. O motorista
depende do que mostrado no painel de controle para tomar decises, tais como:
abastecer o carro, colocar gua, diminuir a velocidade nas curvas ou parar em uma
oficina mecnica quando um indicador no painel revela a presena de problemas.
De forma anloga, os grficos de controle compem um painel de controle e guiam
as decises dos gerentes de projetos e engenheiros de software, fornecendo o
conhecimento necessrio sobre o comportamento dos processos.
A principal diferena entre o controle estatstico de processos e a chamada
estatstica clssica que esta, tipicamente, utiliza mtodos de anlise baseados em
dados estticos no tempo. Com isso, na maioria das vezes, independente da ordem
em que os dados forem analisados, o resultado da anlise ser o mesmo. Essas
anlises so relevantes especialmente quando se deseja comparar quo similares
ou diferentes so dois grupos de dados (por exemplo, comparar as densidades de
defeitos em diferentes projetos), porm, no so capazes de, sozinhas, revelarem
se houve ou no melhoria. Em contrapartida, o controle estatstico de processos
combina o rigor da estatstica clssica sensibilidade temporal da melhoria
pragmtica, onde a ordem temporal dos dados fator crucial para sua
representao e anlise. Assim, atravs da associao de mtodos estatsticos com
anlises cronolgicas, o controle estatstico de processos habilita a deteco de
mudanas e tendncias no comportamento dos processos ao longo do tempo
[BENNEYAN et al., 2003].
Alm da diferena da abordagem estatstica adotada, outra diferena
importante entre a medio dita tradicional e o controle estatstico de processos
est no fato de que a medio tradicional visa a um acompanhamento peridico
(bimestral, mensal, quinzenal etc.) dos valores coletados para as medidas,
enquanto que o controle estatstico de processos visa a um acompanhamento mais
frequente (s vezes, dirio) do comportamento dos processos ao longo dos
projetos.
60
Na medio tradicional, tipicamente, as medidas so coletadas e analisadas

aps o trmino do projeto ou de suas fases. Por exemplo, comum que ao final de
uma fase ou do projeto seja analisada a aderncia ao prazo que fora planejado para
aquela fase ou projeto. A informao obtida com essa anlise importante, no
entanto, ela s permite que o gerente tome aes para melhorar a aderncia ao
prazo em uma prxima execuo da fase ou em um novo projeto.
No controle estatstico de processos, as medidas devem ser analisadas
frequentemente. Considerando o exemplo citado anteriormente, a aderncia ao
prazo seria analisada em intervalos menores de tempo (por exemplo: diariamente,
semanalmente ou por atividade). Assim, caso a aderncia aos prazos no fosse
satisfatria, o gerente poderia tomar aes para melhor-la ainda no contexto do
projeto corrente.
Para exemplificar a diferena entre o uso da medio tradicional e do
controle estatstico usando a analogia feita anteriormente nesta seo, considere
que um motorista tem como objetivo levar uma encomenda de uma cidade A para
uma cidade B no prazo de doze horas. Ao longo da viagem, ele observa o painel de
controle a fim de evitar que problemas faam seu automvel parar, o que poderia
interferir no alcance ao objetivo estabelecido. Quando o marcador de nvel de
combustvel informa que o automvel est utilizando a reserva de combustvel, o
motorista atenta-se para o fato de que deve reabastecer antes que o combustvel
se esgote e o automvel pare. Alm disso, conhecendo o consumo mdio do
automvel, o motorista pode determinar aproximadamente quantos quilmetros o
automvel pode percorrer com o combustvel reserva.
Analogamente, um gerente de projetos que utiliza o controle estatstico
pode analisar o comportamento dos processos de seu projeto e, caso no seja
adequado, ele tem condies de realizar aes para adequ-lo no projeto corrente,
a fim de que os objetivos estabelecidos sejam alcanados.
Considere, agora, que o marcador de nvel de combustvel do automvel
apenas sinalize quando o tanque de combustvel est completo e quando est
vazio. Nesse caso, quando o combustvel terminar, o automvel ir parar sem
avisar previamente o motorista, que ter que realizar aes para fazer o
automvel voltar a funcionar, como, por exemplo, pedir carona at o posto mais
61
prximo para comprar alguns litros de combustvel, voltar ao automvel para

abastec-lo com o combustvel adquirido e lev-lo at o posto para o
reabastecimento necessrio. Essas aes demandaro mais tempo do que se o
reabastecimento tivesse sido realizado antes de o combustvel terminar e, com
isso, o objetivo de chegar cidade B em doze horas pode no ser alcanado.
Conhecer o local onde o combustvel terminou permite que o motorista, em uma
nova viagem pelo mesmo trajeto e sob as mesmas condies, pare em um posto e
reabastea o automvel antes de o combustvel terminar. No entanto, o objetivo
da viagem anterior j ter sido comprometido.
Analogamente, um gerente de projetos que adota somente a medio
tradicional pode ficar limitado a realizar melhorias apenas em projetos futuros,
uma vez que, assim como o motorista que s avisado quando o combustvel
termina, pontos que precisam de melhoria, usualmente, s so conhecidos no fim
dos projetos.
4.3 O Comportamento dos Processos

A utilizao do controle estatstico permite conhecer o comportamento dos
processos e fazer previses sobre seu desempenho. O comportamento de um
processo analisado atravs das medidas a ele associadas.
No que tange o comportamento dos processos, dois conceitos so
importantes: estabilidade e capacidade. Um processo considerado estvel se o
mesmo repetvel. A estabilidade permite prever o desempenho do processo em
execues futuras e, com isso, apoia a elaborao de planos que sejam alcanveis.
A previsibilidade a essncia do controle estatstico [WHEELER e CHAMBERS,
2010]. Por outro lado, um processo capaz se ele, alm de ser estvel, alcana os
objetivos e metas da organizao e do cliente.
Em relao estabilidade, importante destacar que intrnseco aos
processos apresentar variaes em seu comportamento. Sendo assim, um processo
estvel no um processo que no apresenta variaes e, sim, um processo que
apresenta variaes aceitveis, que ocorrem dentro de limites previsveis, que
caracterizam a repetitividade de seu comportamento.
As variaes aceitveis, tambm ditas variaes controladas, so
provocadas pelas chamadas causas comuns [SHEWART, 1939]. Elas provocam
62
desvios dentro de um limite previsto para o comportamento do processo. So

variaes que pertencem ao processo, ou seja, so o resultado de interaes
normais dos componentes do processo: pessoas, equipamentos, ambientes e
mtodos. Um exemplo de causa comum, que provoca variaes controladas, pode
ser a diferena de produtividade entre os membros de uma equipe relativamente
homognea. Cada membro executa certo processo com uma determinada
produtividade, sendo assim, as variaes causadas no comportamento desse
processo, por essa diferena de produtividade entre seus executores, so
previsveis. A Figura 4.1 ilustra o conceito de variaes controladas.
Figura 4.1 Variaes controladas (adaptado de [FLORAC e CARLETON, 1999]).
Por outro lado, as chamadas causas especiais [SHEWART, 1939] provocam

desvios que excedem os limites de variao aceitvel para o comportamento do
processo, revelando um processo instvel. As causas especiais so eventos que no
fazem parte do curso normal do processo e provocam mudana no padro de
variao esperado. Considerando processos de software, a incluso de um membro
inexperiente na equipe poder alterar o comportamento do processo alm do
esperado, caracterizando uma causa especial. Dificuldades na utilizao de um
novo aplicativo de apoio execuo do processo tambm podem levar a variaes
no previstas, sendo assim outra causa especial. A Figura 4.2 ilustra o conceito de
variaes no controladas, provocadas por causas especiais.
63
Figura 4.2 Variaes no controladas (adaptado de [FLORAC e CARLETON, 1999]).
Figura 4.3 Estabilizao de um processo (adaptado de [NEUBAUER, 2011]).
importante notar que, embora a estabilidade permita a previsibilidade, o

fato de um processo ser estvel no significa que ele tem um bom desempenho. Por
exemplo, suponha que em uma organizao o processo Planejamento de Projetos,
tem seu comportamento analisado por meio do ndice de aderncia ao prazo e do
ndice de aderncia ao custo. Suponha, ainda, que nos ltimos vinte e quatro meses
o ndice de aderncia ao prazo tenha ficado entre 0,41 e 0,43 e o ndice de aderncia
ao custo tenha ficado entre 0,51 e 0,52. Apesar de o processo ter se comportado de
maneira estvel e previsvel nos ltimos vinte e quatro meses, seu desempenho
no bom.
Uma vez estabilizado, a capacidade do processo deve ser analisada. A
capacidade descreve os limites de resultados que se espera que o processo alcance
para atingir os objetivos estabelecidos [SEI, 2010]. Caso o processo no seja capaz,
ele deve ser alterado atravs da realizao de aes de melhoria que busquem o
alcance da capacidade desejada. Melhorar a capacidade de um processo significa
64
diminuir os limites de variao que so considerados aceitveis para seu

comportamento, ou seja, consiste em tratar as causas comuns.
Considerando o exemplo citado anteriormente, suponha que a organizao
tenha estabelecido que o ndice de aderncia s estimativas dos projetos deve
estar entre 0,8 e 1. Portanto, o processo Planejamento de Projetos, apesar de ser
estvel, no capaz de alcanar o desempenho determinado pela organizao,
precisando ser melhorado.
A capacidade do processo conhecida como voz do processo. Por outro
lado, a capacidade desejada para o processo, estabelecida levando-se em
considerao os objetivos da organizao e do cliente, chamada de voz do cliente
[WHEELEER e POLING, 1998]. Obviamente, desejvel que a voz do processo
atenda a voz do cliente e as aes de melhoria tm esse propsito. Porm, isso nem
sempre possvel.
preciso considerar que, algumas vezes, a capacidade desejada para o
processo no possvel de ser obtida. Nesse caso, os objetivos estabelecidos
devem ser revistos, pois no so realistas. Ou seja, algumas vezes preciso rever a
voz do cliente, considerando a voz do processo.
Retornando novamente ao exemplo citado, uma vez que h uma diferena
considervel entre o desempenho real (voz do processo) do processo
Planejamento de Projetos e os resultados para ele esperados (voz do cliente),
provvel que no seja possvel realizar aes que levem o processo a atingir os
valores esperados. Assim, uma boa prtica seria realizar a melhoria
gradativamente, comeando com uma reviso dos resultados esperados para
tornar a voz do cliente mais realstica e realizando, em seguida, aes de melhoria
para mudar o processo, de modo a atender os novos resultados esperados. Uma
vez que o processo se torne capaz, um novo desempenho esperado (voz do
cliente) pode ser estabelecido e novas melhorias podem ser realizadas.
4.4 Seleo de Subprocessos para o Controle Estatstico

Quando uma organizao decide pela implementao do controle estatstico
de processos, uma das primeiras definies a serem feitas diz respeito ao escopo
no qual o controle estatstico ser utilizado. No contexto da melhoria de processos
de software, isso significa identificar quais subprocessos da organizao sero
65
submetidos ao controle estatstico. Uma vez que, geralmente, o controle estatstico

requer esforo maior do que o despendido na medio tradicional, nem todos os
subprocessos sero controlados estatisticamente. Ento, quais escolher?
Antes de responder essa questo, preciso atentar-se para o termo
subprocesso. Subprocessos, nesse caso, so componentes de um processo maior.
Por exemplo, um processo de desenvolvimento tpico de uma organizao
composto por subprocessos, tais como, desenvolvimento de requisitos, reviso por
pares, teste de integrao etc. [SEI, 2010; BARRETO, 2011].
Voltando questo de quais subprocessos escolher, h duas diretrizes
bsicas que so teis. A primeira delas baseia-se na criticidade dos subprocessos
[SOFTEX, 2011c; SEI, 2010]. Em outras palavras, devem ser selecionados
subprocessos que sejam relevantes (crticos) ao alcance dos objetivos
estabelecidos para a organizao e para os projetos. Esses subprocessos podem ser
identificados a partir de questes como [FERREIRA, 2009]:
Q1. O que necessrio para que o objetivo seja alcanado?
Q2. O que pode contribuir para o fracasso no alcance do objetivo?
Por exemplo, se uma organizao tem como um de seus principais objetivos
diminuir o nmero de defeitos nos produtos entregues ao cliente, os subprocessos
relacionados garantia da qualidade so necessrios para que os defeitos sejam
identificados antes que os produtos sejam entregues. Assim, eles so fortes
candidatos a serem selecionados para o controle estatstico.
Apesar de parecer uma tarefa simples, nem sempre as organizaes
conseguem identificar quais subprocessos so crticos para ela. Algumas vezes,
todos parecem ser crticos e identificar os mais crticos torna-se um desafio. Outras
vezes, as organizaes no conseguem relacionar os subprocessos com os
objetivos e, nesse caso, todos podem parecer no serem crticos.
Quando h dvidas sobre quais subprocessos so crticos (ou quais so os
mais crticos), a utilizao de alguns mtodos comumente aplicados na
investigao de causas de problemas pode ajudar. Nesse contexto, destacam-se o
diagrama de causa e efeito (tambm conhecido como diagrama espinha de peixe ou
diagrama Ishikawa) e o diagrama de Pareto [WHEELER e CHAMBERS, 2010].
66
Os diagramas de causa e efeito so utilizados para representar o

relacionamento entre um problema (o efeito) e suas possveis causas. Conhecer as
causas de um problema permite a investigao dos subprocessos onde as causas
tm origem, o que pode ser bastante til quando os objetivos da organizao esto,
de alguma forma, relacionados a algum problema. Por exemplo, suponha que uma
organizao tenha como um de seus principais objetivos diminuir os custos com
retrabalho. Seguindo a diretriz apresentada, devem ser identificados os
subprocessos que impactam no alcance desse objetivo. Nesse caso, devem-se
buscar os subprocessos que provocam retrabalho. Suponha, ainda, que buscando
representar as razes que levam ao retrabalho, a organizao tenha gerado o
diagrama de causa e efeito ilustrado na Figura 4.4.
Execuo paralela de
atividades com alguma
dependncia
Correo inadequada de
defeitos
Retrabalho
Nmero excessivo de
defeitos
Alterao nos requisitos ao

longo do projeto
Figura 4.4 Diagrama de Causa e Efeito para anlise das causas de retrabalho.
Tendo sido apontadas as causas do retrabalho, os subprocessos onde elas

tm origem podem ser identificados. No entanto, no exemplo dado, mesmo tendo
sido gerado um diagrama relativamente simples, foram identificadas quatro causas
de retrabalho e pode no ser prtico, nem necessrio, controlar estatisticamente os
subprocessos relacionados a todas as causas apontadas.
Nesse caso, para identificar a causa que impacta mais significativamente no
retrabalho, pode-se usar o diagrama de Pareto. A estrutura bsica do diagrama de
Pareto a mesma de um histograma, mostrando quantos resultados foram gerados
por tipo ou categoria de causa identificada. O nome diagrama de Pareto devido ao
Princpio de Pareto, que afirma que uma quantidade consideravelmente pequena
de causas, tipicamente, causar a grande maioria dos problemas. Esse princpio
popularmente conhecido como princpio 80/20 (80% dos problemas se devem a
20% das causas).
67
Retornando ao exemplo, suponha que tenha sido feita uma anlise da

quantidade de horas despendidas em retrabalho nos projetos da organizao para
cada causa identificada, tendo sido construdo o diagrama da Figura 4.5.
Figura 4.5 Diagrama de Pareto para anlise das causas de retrabalho.
Percebendo-se que a causa que mais impacta na quantidade de retrabalho

alterao nos requisitos do projeto, pode-se selecionar para o controle estatstico o
subprocesso onde essa causa tem origem, que poderia ser Levantamento de
Requisitos.
A segunda diretriz bsica para a seleo dos subprocessos diz respeito ao
seu tamanho e frequncia de execuo [BARCELLOS, 2009a]. Como dito
anteriormente, o uso do termo subprocesso indica que devem ser escolhidas
partes do processo. Alm disso, recomenda-se que essas partes no sejam muito
grandes. Subprocessos longos, tipicamente, so executados uma nica vez em cada
projeto, o que no favorece a coleta de dados4 e a tomada de deciso ao longo de
sua execuo durante o projeto.
Subprocessos menores e com execues mais frequentes so bons
candidatos ao controle estatstico. Por exemplo, o subprocesso Inspeo no um
subprocesso de longa durao e pode ser realizado diversas vezes ao longo de um
mesmo projeto, favorecendo a coleta de dados e a tomada de deciso para aes
O volume de dados coletados para uma medida um requisito importante para que seja possvel
aplicar as tcnicas do controle estatstico de processos. Essa questo ser abordada mais adiante
neste livro.
68
corretivas ou de melhoria no subprocesso, que poder ter nova execuo ainda no

mesmo projeto.
Cabe ressaltar que subprocessos muito pequenos tambm no so
adequados ao controle estatstico, pois, assim como os subprocessos muito
grandes, eles no permitem a tomada de deciso baseada na anlise do
comportamento do processo durante sua execuo.
Em relao ao nmero de subprocessos que precisam ser submetidos ao
controle estatstico, no h uma resposta exata, pois depende de diversas variveis,
como a experincia da organizao com o controle estatstico de processos, os
objetivos considerados, os dados disponveis etc. No entanto, o texto do CMMI [SEI,
2010] sugere que seja selecionado pelo menos um subprocesso relevante por fase
do ciclo de vida (atividades relacionadas engenharia do produto), um
subprocesso relacionado gerncia do projeto e um relacionado aos processos de
apoio.
Para evitar a seleo de um grande nmero de subprocessos logo no incio
da implementao do controle estatstico de processos, uma boa prtica priorizar
os subprocessos identificados e selecionar um pequeno conjunto inicial que atenda
a recomendao feita no CMMI. Uma vez implementado o controle estatstico para
os subprocessos selecionados, a organizao ir adquirir experincia e
conhecimento e, com isso, gradativamente, novos subprocessos podero ser
adicionados ao conjunto inicial.
Aps a escolha dos subprocessos que sero submetidos ao controle
estatstico, devem ser identificadas as medidas que sero utilizadas para gerenciar
quantitativamente os subprocessos. Essas medidas sero utilizadas para apoiar a
anlise do alcance dos objetivos estabelecidos e devem satisfazer a um conjunto de
requisitos, que sero apresentados na prxima seo.
Vale destacar que caso um subprocesso seja selecionado para o controle
estatstico, mas no possua medidas adequadas para tal, essas devero ser
definidas e coletadas para, s ento, o subprocesso poder ser submetido ao
controle estatstico. Essa restrio faz com que algumas organizaes selecionem
para o controle estatstico os subprocessos que possuem medidas adequadas,
mesmo que eles no sejam crticos. Essa m deciso as leva a despenderem tempo
69
e recursos para realizar o controle estatstico em subprocessos no significativos,

no obtendo, assim, os benefcios providos por essa abordagem.
Na prxima seo so discutidos alguns aspectos importantes para a
identificao de medidas adequadas para o controle estatstico.
4.5 Identificao de Medidas Adequadas para o Controle

Estatstico
A utilizao do controle estatstico de processos na rea de software
recente e tem sido impulsionada pelo interesse das organizaes em atender os
requisitos estabelecidos em modelos como o MR-MPS e o CMMI, a fim de que o
nvel de capacidade e maturidade dos seus processos seja reconhecido e que isso
se torne uma vantagem competitiva.
Apesar de modelos como esses orientarem as organizaes sobre o que
necessrio realizar para satisfazer seus requisitos, ainda h lacunas sobre como
realizar algumas das aes necessrias para tal.
No contexto da medio de software, alguns problemas que ocorrem desde
o incio do programa de medio, nos nveis iniciais de maturidade, s so
percebidos quando se comea a busca pela alta maturidade e tm incio as prticas
relacionadas ao controle estatstico de processos.
Organizaes que durante a realizao das atividades requeridas nos nveis
iniciais de maturidade, onde a medio comea a ser exigida, simplesmente se
preocupam em atender os requisitos dos modelos, sem vislumbrar os benefcios
reais da medio e sua evoluo, acabam definindo medidas inteis ao pensamento
estatstico exigido nos nveis superiores. Essas organizaes, normalmente,
acumulam dados incorretos e no possuem dados suficientes armazenados ou,
quando possuem, os tm registrados de maneira inadequada.
Como consequncia, essas organizaes acabam tendo que despender
tempo e recursos para arrumar a casa antes de, efetivamente, realizar o controle
estatstico de processos. O controle estatstico requer uma boa fundao, isto ,
processos caracterizados por medidas vlidas e dados de qualidade que possam
ser utilizados para analisar o comportamento e a previsibilidade dos processos
[BARCELLOS, 2009b].
70
Uma organizao, quando realiza a medio adequadamente e segue um

modelo de maturidade, pode comear a se preparar para o controle estatstico de
processos pelo menos em um nvel de maturidade anterior quele onde ele
exigido. Nesse caso, a organizao deve definir medidas visando utilizao futura
pretendida. Porm, quando uma organizao no visa ao controle estatstico desde
nveis anteriores, muito provvel que tenha que realizar adequaes nas medidas
definidas e nos dados coletados, que precise definir novas medidas e coletar mais
dados para, s ento, iniciar as prticas do controle estatstico.
Uma vez selecionados os subprocessos que sero submetidos ao controle
estatstico, as medidas que sero utilizadas para analisar seu comportamento e
gerenci-los quantitativamente devem ser identificadas. Assim, o repositrio de
medidas que contm medidas definidas e dados coletados em projetos executados
ao longo dos nveis de maturidade anteriores deve ser analisado para identificar
quais medidas podem ser utilizadas para os subprocessos selecionados. Caso as
medidas definidas nos nveis anteriores no sejam adequadas, correes devem
ser feitas (quando possvel) ou novas medidas devem ser definidas.
Buscando auxiliar a identificao de medidas adequadas para o controle
estatstico de processos, a seguir apresentado um conjunto de requisitos que uma
medida til ao controle estatstico deve satisfazer. Os requisitos foram extrados de
um instrumento proposto em [BARCELLOS, 2009a], o qual apoia a avaliao de
bases de medidas, visando utilizao no controle estatstico de processos5.
O conjunto de requisitos apresentado pode ser utilizado para identificar,
dentre as medidas disponveis na base de medidas de uma organizao, quais
podem ser utilizadas no controle estatstico. Alm disso, tambm pode ser til
definio de novas medidas adequadas a esse propsito.
importante perceber que a realizao do controle estatstico de processos
A avaliao feita pelo instrumento considera quatro itens: estrutura da base de medidas, plano de
medio, medidas definidas e dados coletados. Ele composto por um conjunto de checklists que
possuem requisitos para a avaliao de cada item. Para cada requisito so identificadas as
inadequaes possveis e, para cada uma delas, so sugeridas aes para adequao. Quando um
requisito no atendido, essas aes guiam a correo do item, caso ele seja passvel de ser
alterado para ser utilizado no controle estatstico de processos.
71
requer a coleta frequente de dados para as medidas e, algumas vezes, a definio

de novas. Assim, necessrio manter a adequao das medidas e dos dados. Nesse
sentido, os requisitos apresentados a seguir tambm podem ser utilizados para
apoiar a anlise da adequao de novos dados coletados e medidas definidas.
R1. A definio operacional da medida correta e satisfatria.
Conforme discutido no Captulo 3, estabelecer definies operacionais
adequadas para as medidas fundamental para que as medies sejam
consistentes, os dados coletados sejam vlidos e seja possvel realizar
comparaes entre eles.
No contexto do controle estatstico de processos, a qualidade das definies
operacionais muito importante. Para ser possvel analisar o comportamento de
um processo, deve ser obtido certo volume de dados (maior que o volume
usualmente requerido na medio realizada nos nveis iniciais de maturidade) e os
dados coletados devem formar grupos homogneos. Isso requer que os dados
sejam coletados de maneira consistente, o que depende diretamente da qualidade
das definies operacionais [BARCELLOS et al., 2010].
Uma medida adequada para uso no controle estatstico de processos deve
apresentar em sua definio operacional as informaes descritas na seo 3.7.
Uma questo importante a ser considerada que a definio operacional de
uma medida deve ser estabelecida de acordo com sua aplicao. Por exemplo,
medidas aplicadas no controle estatstico de processos, que visam anlise de
desempenho, devem ter em suas definies operacionais procedimentos de anlise
que incluem tcnicas do controle estatstico como, por exemplo, o uso de grficos
de controle. Por outro lado, medidas com aplicao no monitoramento e controle
tradicionais, tm em suas definies operacionais procedimentos de anlise que
incluem tcnicas analticas tradicionais como, por exemplo, grficos de barras.
Ainda, tradicionalmente, medidas aplicadas no controle estatstico tm
periodicidade de coleta e de anlise menor do que medidas aplicadas no
monitoramento e controle tradicionais.
Cabe, ainda, notar que, ao longo do tempo, uma mesma medida pode
possuir mais de uma definio operacional, dependendo de sua aplicao. Em uma
organizao que deseja definir e coletar, desde os nveis iniciais de maturidade,
72
medidas que possam ser teis ao controle estatstico no futuro, as definies

operacionais das medidas, inicialmente, devem ser orientadas ao monitoramento e
controle tradicionais. Porm, para que os dados coletados sejam futuramente teis
ao controle estatstico, as definies operacionais das medidas devem garantir que
os dados coletados e armazenados sejam teis ao controle estatstico de processos.
A seguir so apresentados os exemplos de duas definies operacionais para
a medida preciso da estimativa de tempo da fase Especificao e Anlise de
Requisitos do Sistema. Na Tabela 4.1 apresentada a definio estabelecida
considerando a aplicao da medida no monitoramento e controle tradicionais.
Tabela 4.1 Definio da medida Preciso da Estimativa de Tempo da Fase Especificao e Anlise de
Requisitos do Sistema para aplicao no monitoramento e controle tradicionais.
Mnemnico
Preciso da Estimativa de Tempo da Fase Especificao e Anlise

de Requisitos do Sistema
Medida utilizada para quantificar a preciso da estimativa de
durao da fase Especificao e Anlise de Requisitos do Sistema.
PET-EAR
Tipo de Medida
Entidade
Propriedade
Unidade de Medida
Tipo de Escala
Medida Derivada
Fase Especificao e Anlise de Requisitos do Sistema
Preciso da estimativa de tempo
Absoluta
Valor de Escala
Nmeros reais positivos compreendidos utilizando-se preciso de

duas casas decimais.
Intervalo Esperado dos Dados
[0.8, 1.0]
Nome da Medida
Definio
PET-EAR = TE-EAR/ TR-EAR

Onde: TR-EAR = tempo real despendido na fase Especificao e
Frmula de Clculo de Medida
Anlise de Requisitos do Sistema; TE-EAR = tempo estimado para
a fase Especificao e Anlise de Requisitos do Sistema.
Procedimento de Medio
Momento da Medio
Periodicidade de Medio
Calcular a preciso da estimativa de tempo da fase utilizando a

frmula de clculo da medida.
Ao final da fase, na atividade Registrar Dados para Monitoramento
do Projeto.
Uma vez em cada execuo da fase
Analista de Sistemas
Representar em um histograma os dados coletados para a medida
nos projetos da organizao. Analisar se h projetos cuja preciso
da estimativa destoa significativamente das demais ou de um
Procedimento de Anlise de
valor previamente estabelecido pela organizao. Em caso
Medio
afirmativo, conduzir investigao de causas para que,
identificadas as causas, sejam determinadas as aes corretivas
necessrias.
Momento da Anlise de
Atividade Analisar Dados de Monitoramento dos Projetos
Medio
Periodicidade de Anlise de
Mensal
Medio
Responsvel pela Medio
Responsvel pela Anlise
Gerente de Qualidade
73
Na Tabela 4.2 apresentada a definio operacional da medida para

aplicao do controle estatstico de processos. As diferenas entre as definies
aparecem em destaque na Tabela 4.2.
Tabela 4.2 - Definio da medida Preciso da Estimativa de Tempo da Fase Especificao e Anlise de
Requisitos do Sistema para aplicao no controle estatstico de processos.
Mnemnico
Preciso da Estimativa de Tempo da Fase Especificao e Anlise

de Requisitos do Sistema
Medida utilizada para quantificar a preciso da estimativa de
durao da fase Especificao e Anlise de Requisitos do Sistema.
PET-EAR
Tipo de Medida
Entidade
Propriedade
Unidade de Medida
Tipo de Escala
Medida Derivada
Subprocesso Planejamento do Projeto
Preciso da estimativa de tempo
Absoluta
Valor de Escala
Nmeros reais positivos, utilizando-se preciso de duas casas

decimais.
Intervalo Esperado dos Dados
[0.8, 1.0]
Frmula
Medida
PET-EAR = TE-EAR/TR-EAR
Onde: TR-EAR = tempo real despendido em atividades da fase
Especificao e Anlise de Requisitos do Sistema no perodo
considerado; TE-EAR = tempo estimado para atividades da fase
Especificao e Anlise de Requisitos do Sistema no perodo
considerado.
Nome da Medida
Definio
de
Clculo
de
Procedimento de Medio
Momento da Medio
Calcular a preciso da estimativa de tempo utilizando a frmula

de clculo da medida.
Ao final da semana, na Atividade Registrar Dados para
Monitoramento do Projeto
Periodicidade de Medio
Semanal
Responsvel pela Medio
Analista de Sistemas
Representar em um grfico de controle os valores coletados

para a medida no projeto.
Analisar o comportamento do processo em relao baseline

Procedimento de Anlise de
Medio
Momento da Anlise de
Medio
Periodicidade de Anlise de
Medio
Responsvel pela Anlise
de desempenho estabelecida para o processo:

(i) Se os valores coletados para a medida encontrarem-se
dentro dos limites da baseline de desempenho, o
processo apresenta comportamento adequado.
(ii) Se houver valores fora dos limites da baseline, o
comportamento do processo no est adequado.
necessrio investigar as causas da instabilidade no
comportamento do processo e identificar aes
corretivas, quando pertinente.
Atividade Analisar Desempenho dos Processos do Projeto
Semanal
Gerente do Projeto
74
R2. A medida est alinhada a objetivos da organizao e dos projetos.

Uma vez que as medidas utilizadas no controle estatstico de processos
apoiam a anlise do alcance dos objetivos, elas devem estar associadas a pelo
menos um objetivo da organizao e dos projetos.
R3. Os resultados da anlise da medida so relevantes tomada de deciso
para a melhoria de processos.
Os dados coletados para a medida, ao serem analisados, devem fornecer
subsdios relevantes para a tomada de deciso no contexto da melhoria de
processos da organizao ou dos projetos. Medidas que desempenham o papel de
indicadores (diretamente associadas aos objetivos e responsveis por fornecer as
informaes necessrias para a anlise do alcance a esses objetivos) so medidas
relevantes tomada de deciso, bem como suas medidas correlatas.
R4. A medida fornece informaes sobre o desempenho de um subprocesso
crtico.
A medida deve estar relacionada a um subprocesso crtico e deve ser capaz
de fornecer informaes sobre seu desempenho. Medidas que registram
estimativas, por exemplo, so medidas essencialmente de controle e no
descrevem o desempenho dos processos, logo, isoladas, no so aplicveis ao
controle estatstico de processos. Porm, vale ressaltar que medidas que registram
estimativas podem ser utilizadas para formar medidas derivadas que descrevam o
desempenho de um processo. Por exemplo, a medida aderncia ao cronograma,
obtida pela razo entre as medidas prazo estimado e prazo real, uma medida que
prov informaes sobre o desempenho de um processo.
R5. As medidas correlatas medida esto identificadas e so vlidas para o
controle estatstico.
Uma medida que ser utilizada no controle estatstico de processos deve ter
suas medidas correlatas identificadas. Medidas correlatas so aquelas que, como o
prprio nome diz, apresentam algum tipo de relao entre si. Alguns exemplos so
medidas com relaes de causa e efeito (por exemplo: nvel de experincia do
programador influencia na produtividade), medidas utilizadas para compor outras
(por exemplo: nmero de casos de uso alterados = nmero de casos de uso includos
75
+ nmero de casos de uso excludos + nmero de casos de uso modificados) e

medidas relacionadas a um mesmo objetivo do Plano de Medio.
A definio de medidas correlatas, necessrias ao entendimento do
comportamento dos processos, contribui para o alcance dos objetivos
estabelecidos, uma vez que apoia a investigao das causas de variao no
comportamento dos processos, auxiliando a identificao das aes corretivas
adequadas [CAIVANO, 2005]. Por exemplo, a ocorrncia, em um dado perodo, de
uma aderncia ao cronograma muito inferior s demais poderia ser explicada por
uma alta taxa de alterao de requisitos no mesmo perodo. Para ser possvel
identificar esse cenrio, alm da medida referente aderncia ao cronograma, a
medida referente taxa de alterao de requisitos deve ter sido definida e coletada
corretamente.
R6. A medida possui baixo nvel de granularidade.
O nvel de granularidade de uma medida determinado por dois aspectos
presentes em sua definio operacional: a entidade qual a medida associada e
sua periodicidade de medio.
Se for considerado que uma medida coletada uma vez em cada ocorrncia
da entidade qual est associada, medidas associadas a entidades menores, como
por exemplo, componentes de projeto ou de produto (mdulos, artefatos,
atividades ou tarefas) tm granularidade menor que as medidas associadas a
entidades maiores, como um projeto [KITCHENHAM et al., 2001].
Porm, uma medida pode no ser necessariamente coletada uma vez em
cada ocorrncia da entidade qual est associada. A periodicidade de medio,
estabelecida em sua definio operacional, determina a frequncia na qual a
medida deve ser coletada e armazenada, influenciando diretamente no nvel de
granularidade e no nmero de valores coletados [FLORAC et al., 2000].
possvel que uma medida associada a uma entidade que, normalmente,
caracterizaria alto nvel de granularidade, possa ter seu nvel de granularidade
reduzido ao ter sua periodicidade estabelecida. Por exemplo, a medida nmero de
erros reportados pelo cliente pode ser associada entidade projeto e ter
periodicidade de coleta semanal, o que leva coleta e registro de diversos valores
para a medida ao invs de um nico valor ao final do projeto.
76
O nvel de granularidade de uma medida til ao controle estatstico de

processos deve permitir o acompanhamento frequente (s vezes, dirio) dos
processos e projetos. Para isso, a medida deve estar relacionada a entidades
menores, como, por exemplo, atividades ou subprocessos de durao
relativamente curta, ou deve ter uma coleta frequente.
Algumas medidas, apesar de no apresentarem nvel de granularidade
baixo, podem ser teis no controle estatstico como medidas de normalizao. Por
exemplo, a medida nmero de casos de uso do projeto, sozinha, no adequada ao
controle estatstico de processos. Porm, ela pode ser utilizada para normalizar
outras, o que a torna til ao controle estatstico. Por exemplo, a medida nmero de
casos de uso alterados pode ser normalizada pelo nmero de casos de uso do
projeto, a fim de permitir comparaes, o que faz com que a medida nmero de
casos de uso do projeto seja til no contexto do controle estatstico.
R7. A medida passvel de normalizao (se aplicvel).
Algumas vezes, faz-se necessrio normalizar uma medida para que seja
possvel realizar anlises e comparaes. Por exemplo, no correto comparar o
esforo despendido em projetos sem levar o tamanho desses projetos em
considerao. Nesse caso, preciso normalizar o esforo despendido pelo tamanho
dos projetos, para que os dados possam ser analisados em conjunto ou
comparados entre si.
Para que uma medida que precisa ser normalizada seja usada no controle
estatstico de processos, as medidas necessrias para normaliz-la devem estar
disponveis e serem vlidas. Seguindo o exemplo do pargrafo anterior, para
normalizar esforo considerando tamanho, preciso que as medidas de tamanho
estejam disponveis e sejam vlidas.
R8. A medida est normalizada corretamente (se aplicvel).
A normalizao equivocada de uma medida pode mudar o significado dos
dados coletados e, consequentemente, levar a interpretaes errneas sobre o
comportamento dos processos [KITCHENHAM et al., 2007]. Assim, para utilizar no
controle estatstico uma medida que j esteja normalizada, preciso assegurar-se
de que sua normalizao est correta. Por exemplo, para a medida esforo de
codificao, normalizada pelo nmero de linhas de cdigo fonte, preciso
77
assegurar-se de que seja correto normalizar esforo utilizando o tamanho e, alm

disso, de que as medidas nmero de linhas de cdigo fonte e esforo de codificao
sejam referentes mesma poro de cdigo.
R9. Os critrios para agrupamento dos dados para anlise da medida esto
definidos.
Para serem submetidos anlise, os dados coletados para as medidas so
agrupados em conjuntos. O agrupamento dos dados coletados deve ser realizado
buscando-se compor grupos de dados que caracterizem populaes6. Para isso,
necessrio definir os critrios que devem ser considerados para que os dados
coletados para uma determinada medida componham grupos adequados para a
anlise [BALDASSARE et al., 2006].
Uma medida adequada para o controle estatstico de processos tem os
critrios de agrupamento de seus dados definidos e eles so capazes de gerar
grupos de dados relativamente homogneos.
Normalmente, os critrios podem ser os mesmos adotados para
caracterizar e identificar projetos similares. Porm, caso esses critrios sejam
muito amplos, eles no so adequados. Por exemplo, se uma organizao
caracteriza seus projetos apenas pelo paradigma de desenvolvimento adotado e
pelo tipo de cliente (pblico ou privado), esses critrios so insuficientes para o
agrupamento de dados de uma medida para o controle estatstico. Nesse caso, os
critrios de caracterizao dos projetos devem ser refinados ou um novo conjunto
de critrios para determinar o agrupamento dos dados coletados para a medida, ou
para um grupo de medidas (por exemplo, para todas as medidas que forem
utilizadas no controle estatstico), deve ser definido.
R10. A medida no considera dados agregados.
Os dados coletados para uma medida adequada ao controle estatstico no
devem ser referentes a valores agregados, pois estes no permitem uma anlise
acurada e, uma vez agregados, pode ser difcil, ou impossvel, separ-los.
6
Uma populao o conjunto de todos os elementos que compartilham caractersticas em comum e

esto sob investigao [BUSSAB e MORETTIN, 2006 apud FVERO et al., 2009]. Exemplos: o grupo
de pessoas que moram em um determinado bairro e o conjunto de dados coletados para uma
medida em projetos com determinadas caractersticas em uma organizao.
78
Como exemplo de uma medida que considera dados agregados tem-se a

medida esforo de anlise, que quantifica o esforo despendido na fase de Anlise
dos projetos em uma organizao. O valor coletado para essa medida corresponde
agregao dos dados dos esforos despendidos na fase Anlise de todos os
projetos concludos na organizao, o que no til ao controle estatstico dos
processos.
Convm dizer que, em alguns contextos, medidas com dados agregados
podem ser teis. Por exemplo, em uma organizao que possui um escritrio de
projetos, pode ser importante para o gerente ter uma medida que informe o
nmero de horas despendidas semanalmente em manutenes nos projetos. Essa
medida, embora agregue valores de todos os projetos, pode ser utilizada no
controle estatstico, desde que todos os projetos utilizem o mesmo processo. No
entanto, quando uma medida de dados agregados utilizada, deve ser possvel
obter os dados desagregados. Assim, no exemplo dado, deve ser possvel obter o
nmero de horas despendidas semanalmente em manutenes em cada projeto.
R11. Os dados coletados para a medida tm localizao conhecida e acessvel.
Para uma medida ser utilizada no controle estatstico de processos, os
dados para ela coletados devem estar disponveis em local (banco de dados,
arquivo, planilha etc.) conhecido e acessvel, devendo poder ser recuperados.
R12. H volume de dados suficiente para a medida ser aplicada ao controle
estatstico de processos.
Sob o ponto de vista estatstico preciso que exista um volume razovel de
dados adequados para que seja possvel utilizar uma medida no controle
estatstico de processos. Sugere-se pelo menos vinte observaes vlidas7.
R13. No h dados perdidos para a medida ou a quantidade de dados
perdidos no compromete a anlise.
desejvel que no haja valores perdidos para a medida ou, havendo, que
sua quantidade no comprometa os resultados da anlise. Na anlise estatstica a
ordem temporal dos dados relevante, sendo assim, a ausncia de dados pode
7
Dependendo das tcnicas que sero utilizadas na anlise dos dados, o volume mnimo de
observaes desejvel pode variar de 15 [WHELLER, 1997 apud WELLER e CARD, 2008] a 45
[FLORAC e CARLETON, 1999].
79
revelar um comportamento irreal para o processo. Por exemplo, vrios dados

sequencialmente
perdidos
prejudicaro
representao
adequada
do
comportamento do processo.
R14. Os dados coletados so corretos.
Uma medida adequada ao controle estatstico possui dados corretos,
capazes de embasar concluses teis e verdadeiras sobre o comportamento dos
processos.
A coleta e o armazenamento de dados incorretos podem comprometer a
confiabilidade das anlises. Para diminuir a probabilidade de armazenamento de
dados incorretos, o ideal que a validao dos dados seja realizada assim que eles
forem coletados. Caso isso no ocorra, possvel realizar uma verificao dos
dados coletados em relao definio operacional da medida considerando,
principalmente: tipo de escala, valores da escala, intervalo esperado dos dados,
entidade medida, propriedade medida e periodicidade.
R15. Os dados coletados so consistentes.
Os dados coletados para a medida devem ser consistentes, ou seja, devem
ter sido coletados no mesmo momento da execuo do processo ao longo dos
projetos, sob as mesmas condies e devem compor grupos de dados
relativamente homogneos8.
R16. Os dados que descrevem o contexto de coleta da medida esto
armazenados.
A anlise do comportamento de um processo deve considerar, alm dos
dados coletados para a medida, o contexto dos projetos e a dinmica em que os
processos foram executados [TARHAN e DEMIRORS, 2006].
A caracterizao dos projetos capaz de fornecer as principais informaes
de contexto das medies realizadas. No entanto, tambm necessrio registrar as
condies em que as medies foram realizadas, pois elas influenciam na anlise,
agrupamento e comparao dos valores coletados para as medidas [CARD et al.,
2008].
Quando utilizados nos grficos de controle, grupos de dados heterogneos contribuem para a
obteno de limites de controle muito amplos. Grficos de controle sero discutidos mais adiante.
80
Os dados coletados para uma medida aplicada no controle estatstico de

processos devem estar associados a informaes de contexto das medies. Nesse
sentido, para cada valor coletado, as seguintes informaes devem estar
disponveis: momento em que a medio foi realizada (atividade em que a medio
foi realizada e data da medio), executor da medio (seu papel no momento da
medio tambm deve ser conhecido), processo no qual a medio foi realizada,
projeto no qual a medio foi realizada, caractersticas do projeto no qual a medida
foi coletada e condies da medio (dados sobre a execuo do processo no
momento da coleta, como, por exemplo, a informao de que a medida foi coletada
aps alterao na legislao que rege o domnio tratado pelo software em
desenvolvimento no projeto).
4.6 Repositrio
Estatstico
de Medidas
Adequado
para
Controle
Os dados da medio devem ser armazenados de forma que possam ser

recuperados e utilizados para apoiar a tomada de deciso. comum organizaes
comearem a registrar as medidas e os dados coletados em planilhas eletrnicas
ou em alguns aplicativos, havendo pouca ou nenhuma integrao entre eles
[DUMKE e EBERT, 2010].
Quando as organizaes do incio s prticas da medio, as planilhas
parecem ser capazes de atender suas necessidades, mas medida que elas
amadurecem seus processos e evoluem nas prticas da medio, os problemas de
no utilizar um repositrio de medidas que envolva tecnologias adequadas (por
exemplo, sistemas gerenciadores de bancos de dados) tornam-se cada vez mais
expressivos. Por esse motivo, recomenda-se que desde o incio seja utilizado um
repositrio de medidas e que ele possa ser evoludo ao longo do tempo para
satisfazer as necessidades da evoluo do processo de medio.
As organizaes podem desenvolver seus prprios repositrios de medidas
ou podem utilizar ferramentas disponveis no mercado. Alguns aplicativos, como,
por exemplo, o MS Project9, de apoio gerncia de projetos, permitem o
armazenamento de dados para algumas medidas. H, tambm, algumas
http://www.microsoft.com/project
81
ferramentas
desenvolvidas
por
empresas
ou
universidades
visando
especificamente apoiar a coleta, armazenamento e recuperao de medies.

O ideal que o repositrio de medidas seja uma base nica e centralizada.
Caso isso no seja possvel, as diferentes fontes que o compem devem ser
integradas. Se a organizao utiliza vrias ferramentas para coletar e armazenar os
dados, isso pode significar integrar as ferramentas ou reunir os dados
armazenados nos bancos de dados das vrias ferramentas em uma nica base de
dados.
O repositrio de medidas deve ser capaz de armazenar e permitir a
recuperao de dados no s da medio propriamente dita. Dados relacionados
aos projetos e processos tambm so relevantes e devem poder ser armazenados e
recuperados. Nesse sentido, o repositrio de medidas deve ser capaz de armazenar
e permitir a recuperao das seguintes informaes:
Critrios de caracterizao para os projetos.
Projetos e suas caractersticas.
Definies
dos
processos
(atividades,
subatividades,
papis
requeridos, recursos necessrios, artefatos requeridos e produzidos

e procedimentos adotados) e identificao das diferentes verses das
definies.
Verses das definies dos processos que so utilizadas em cada

projeto.
No mbito da medio propriamente dita, a seguir so apresentadas as

principais informaes que o repositrio de medidas deve ser capaz de armazenar
e permitir a recuperao. Algumas das informaes (baselines de desempenho,
modelos de desempenho, desempenho especificado de processo e capacidade de
processo) sero abordadas no Captulo 6.
Objetivos de negcio da organizao relevantes medio.
Objetivos de medio e suas relaes com os objetivos de negcio.
Necessidades de informao de cada objetivo.
Medidas e suas definies operacionais, contendo as informaes

descritas na seo 3.7.
Planos de medio da organizao e dos projetos.
Valores coletados nas medies.
82
Informaes de contexto para cada valor medido, incluindo: projeto

onde a medio foi realizada, momento em que a medio foi
conduzida (processo, atividade e data), executor da medio e
condies da medio.
Resultados das anlises de medies.
Desempenho especificado para os processos.
Baselines de desempenho dos processos.
Capacidade dos processos.
Modelos de desempenho.
O repositrio de medidas deve, tambm, ser capaz de tratar as relaes e

restries que as informaes envolvem. Por exemplo, a capacidade de um
processo calculada considerando uma determinada baseline de desempenho e
um certo desempenho especificado, que devem ter sido estabelecidos para o
mesmo processo para o qual a capacidade foi calculada e utilizando a mesma
medida.
A estrutura que ser criada para que o repositrio de medidas seja capaz de
armazenar e fornecer essas informaes uma deciso de cada organizao. Por
exemplo, uma organizao pode decidir pela aquisio de uma ferramenta que
contemple as informaes citadas, enquanto outra pode decidir por implementar
seu prprio repositrio. Nesse caso, tambm devero ser implementadas
interfaces para entrada e recuperao dos dados.
Em [BARCELLOS, 2009a] foi proposta uma Ontologia de Medio de
Software que descreve o conhecimento acerca do domnio medio de software
incluindo o controle estatstico de processos. A ontologia apresenta os conceitos,
relaes e restries fundamentais a esse domnio e composta por sete
subontologias: Entidades Mensurveis, Objetivos de Medio, Medidas de
Software, Definio Operacional de Medidas, Medio de Software, Resultados da
Medio e Comportamento de Processos de Software.
A Ontologia de Medio de Software pode ser utilizada como modelo
conceitual de referncia para definir a estrutura (classes, relacionamentos e
restries de integridade) de um repositrio de medidas adequado ao controle
estatstico de processos. De fato, a ontologia pode ser utilizada inicialmente como
referncia para construir o repositrio de medidas para a medio tradicional e,
83
depois, para evoluir o repositrio para que ele atenda s necessidades do controle
estatstico de processos.

A aplicao bem sucedida do controle estatstico de processos na
manufatura levou sua utilizao em outras reas, como qumica, eletrnica,
alimentao, negcios, sade e desenvolvimento de software.
Apesar de recente, a utilizao do controle estatstico de processos em
organizaes de software tem sido impulsionada pela competitividade do
mercado, que exige produtos cada vez melhores, em cada vez menos tempo e
consumindo o mnimo de recursos possvel.
O controle estatstico apoia a melhoria dos processos baseando-se na
anlise de seu comportamento. Os grficos de controle utilizados no controle
estatstico fornecem uma viso do comportamento dos processos, facilitando a
identificao de questes que precisam ser investigadas. Outros mtodos, como,
por exemplo, o diagrama de causa e efeito e o diagrama de Pareto, podem ser
utilizados para apoiar a investigao dessas questes e direcionar as aes
necessrias.
A maneira como os mtodos so utilizados e o conhecimento organizacional
envolvido nas investigaes e identificao de aes podem fornecer s
organizaes um diferencial competitivo. Sendo assim, importante ressaltar que
utilizar o controle estatstico de processos no consiste, simplesmente, em montar
grficos. Os grficos de controle so um meio, e no um fim. Eles so um
instrumento que molda a matria-prima (os dados) para que as aes de melhoria
sejam identificadas.
Para aplicar controle estatstico a processos de software preciso pensar
nele antes de comear a realizar suas prticas. Quanto antes uma organizao
vislumbrar a realizao do controle estatstico de processos menor ser o custo de
transio da melhoria de processos baseada em medio tradicional para a
melhoria de processos atravs do controle estatstico de processos. Mas, pensar no
controle estatstico desde os nveis iniciais da melhoria de processos no significa
medir tudo ou qualquer coisa. preciso identificar os processos da organizao
que so mais crticos para o alcance dos objetivos tcnicos e de negcio e
84
determinar como medir esses processos corretamente atravs de medidas

significativas.
comum organizaes gerenciarem seus projetos e processos seguindo a
filosofia do retrovisor, ou seja, olhar para o que passou para fazer melhor da
prxima vez. Essa uma abordagem que funciona, mas tem suas limitaes. A
utilizao do controle estatstico no contexto da melhoria de processos leva
filosofia do painel de controle, isto , olhar para o que est acontecendo no
momento para fazer melhor a partir de j.
85
Captulo 5
Grficos de Controle
5.1 Introduo
Conforme visto ao longo deste livro, o processo de medio consiste na
definio das medidas necessrias obteno de informaes para a tomada de
deciso, na coleta dos dados para as medidas definidas e na anlise dos valores
coletados. Para realizar a representao e anlise dos dados coletados, so
utilizados mtodos analticos que, tipicamente, envolvem grficos. Nos nveis
iniciais de maturidade, os dados so comumente representados em histogramas,
diagramas de barras e diagramas de tendncias.
O controle estatstico de processos segue as mesmas etapas bsicas do
processo de medio tradicional, porm utiliza prticas e tcnicas diferenciadas.
No caso da anlise dos dados, as ferramentas grficas e tcnicas estatsticas
essenciais so os grficos de controle.
Neste captulo apresentado o conhecimento bsico necessrio para se
utilizar os grficos de controle. Na seo 5.2 fornecida uma viso geral dos
grficos de controle e na seo 5.3 so apresentados diversos tipos de grficos de
controle. Na seo 5.4 so realizadas as consideraes finais do captulo.
5.2 Grficos de Controle: O Bsico

Grficos de controle so importantes para o controle estatstico porque so
capazes de mostrar as variaes no comportamento dos processos e de permitir a
anlise de sua estabilidade. Esses grficos associam mtodos de controle
estatstico e representao grfica para quantificar o comportamento de processos
auxiliando a detectar os sinais de variao no comportamento dos processos e a
diferenci-los dos rudos. Os rudos dizem respeito s variaes que so aceitveis
e so intrnsecas aos processos (causas comuns). J os sinais indicam variaes que
precisam ser analisadas (causas especiais) e, se possvel, eliminadas [FLORAC e
CARLETON, 1999].
Existem diversos tipos de grficos de controle e cada um deles mais
adequado em determinadas situaes. O primeiro passo para utilizar um grfico de
controle selecionar o tipo adequado s medidas, dados e contexto a serem
86
analisados. Em seguida, os dados devem ser plotados e os limites das variaes

aceitveis, chamados limites de controle, calculados.
A maneira como os dados sero plotados, se sero agrupados e como os
limites de controle sero calculados so definidos pelo tipo de grfico de controle
que ser utilizado. Cada tipo possui um conjunto de mtodos quantitativos ou
estatsticos associados.
A representao grfica facilita a percepo de valores fora dos limites
esperados, ou seja, a presena de causas especiais. Porm, as causas especiais nem
sempre aparecem fora dos limites, por isso, existem mtodos de anlise estatstica
que orientam sobre como identificar pontos que merecem ateno nos grficos de
controle, mesmo quando no esto fora dos limites permitidos variao.
O layout bsico de um grfico de controle ilustrado na Figura 5.1. Tanto a
linha central quanto os limites superior e inferior so calculados a partir de um
conjunto de valores coletados para as medidas. Os limites superior e inferior ficam
a uma distncia de trs desvios padro () em relao linha central10. A linha
central e os limites no podem ser arbitrrios, uma vez que so eles que refletem o
comportamento atual do processo. Seus valores so obtidos aplicando-se as
expresses e constantes definidas pelo tipo de grfico de controle a ser utilizado.
Figura 5.1 Layout bsico de um grfico de controle.
A Figura 5.2 ilustra um exemplo de aplicao de um grfico de controle para

representar as medidas coletadas em um processo estvel, ou seja, onde no h
10
Estudos estatsticos mostram que em um conjunto de dados normalmente distribudo,

aproximadamente 99,73% dos dados se localizam a uma distncia de 3 da linha central [FLORAC e
CARLETON, 1999].
87
causas especiais. O grfico representa a mdia diria de horas dedicadas a

atividades de suporte por semana em uma determinada organizao. Os limites de
controle e a linha central so indicados por suas siglas em ingls (UCL = Upper
Control Limit; CL = Central Line; LCL = Lower Control Limit). Essa notao ser
utilizada em todos os grficos de controle apresentados daqui em diante.
Figura 5.2 Processo estvel.
Na Figura 5.3 apresentado um grfico que ilustra um processo cujo

comportamento extrapolou os limites de variao aceitveis, sendo identificados
pontos cujas causas de variao (causas especiais) devem ser investigadas. O
grfico representa o nmero de problemas relatados pelos clientes diariamente
rea de suporte de uma organizao que no foram resolvidos.
Figura 5.3 Processo com causas especiais explcitas.
Na Figura 5.3 os pontos que caracterizam a instabilidade do processo esto

acima do limite superior de variao permitido. Porm, conforme mencionado
anteriormente, os pontos de instabilidade, ou seja, aqueles gerados por causas
88
especiais, nem sempre aparecem fora dos limites, existindo outros sinais que
revelam a instabilidade de um processo, como, por exemplo, uma distribuio no
aleatria dos pontos. A presena de padres na distribuio dos pontos, como, por
exemplo, a repetio de ciclos, tendncias de crescimento ou decrescimento,
mudanas bruscas e agrupamentos, pode ser sinal de que o processo est se
comportando de maneira irregular, embora no possua pontos fora dos limites de
controle [FLORAC e CARLETON, 1999].
Existem diversos testes que podem ser utilizados para verificar a
estabilidade de um processo. Dentre eles, h quatro que se destacam [WHEELER e
CHAMBERS, 2010]:
Teste 1: presena de algum ponto fora dos limites de controle 3.
Teste 2: presena de pelo menos dois de trs valores sucessivos do
mesmo lado e a mais de 2 da linha central (chamada zona C).
Teste 3: presena de pelo menos quatro de cinco valores sucessivos
do mesmo lado e a mais de 1 da linha central (chamada zona B).
Teste 4: presena de oito pontos sucessivos no mesmo lado da linha
central.
Embora esses testes venham sendo utilizados h dcadas e sejam
considerados eficientes, possvel que as situaes citadas nos testes 2, 3 e 4 no
representem causas especiais. Quando um processo falha em um desses testes,
uma investigao deve ser conduzida para verificar se h causas especiais ou se, na
verdade, trata-se de rudos que levaram a um falso alarme de instabilidade. A
Figura 5.4 ilustra um processo hipottico instvel que apresenta as situaes
descritas nos quatro testes.
Figura 5.4 Testes de estabilidade.

89
Para exemplificar a utilizao dos testes de estabilidade, considere o grfico

apresentado na Figura 5.2. Suponha que esse grfico tenha sido gerado por um
gerente que desejava analisar a quantidade de horas semanais dedicadas a
atividades de suporte. Para isso, foram registradas as horas de trabalho
despendidas com suporte diariamente. Em seguida, foram obtidas as mdias
dirias de cada semana e o grfico foi construdo.
Percebendo a ausncia de pontos fora dos limites de controle, mas
desejando se certificar da aparente estabilidade do processo, o gerente decidiu
dividir as distncias dos limites de controle em trs zonas (A, B e C) e aplicar todos
os testes de estabilidade. A Figura 5.5 apresenta o grfico com as zonas A, B e C
identificadas. Aplicando-se os testes 1, 2, 3 e 4, percebe-se que o processo
realmente estvel.
Figura 5.5 Grfico com as zonas A, B e C identificadas.
A seguir so apresentados diferentes tipos de grficos de controle e alguns

exemplos de suas aplicaes. Combinaes de grficos e aplicaes mais
sofisticadas do que as que sero apresentadas podem ser realizadas. Algumas
discusses nesse sentido encontram-se em [FLORAC e CARLETON, 1999]. Apesar
de no tratarem especificamente de processos de software, algumas aplicaes
tambm podem ser encontradas em [WHEELER e CHAMBERS, 2010] e [WHEELER,
2000].
90
5.3 Tipos de Grficos de Controle

Existem diversos tipos de grficos de controle e cada um deles mais
adequado em determinadas situaes. Todos os tipos de grficos de controle
seguem o layout bsico mostrado na Figura 5.1.
Cada tipo de grfico de controle possui um conjunto prprio de expresses
matemticas e constantes que so utilizados para plotar os dados e para calcular os
limites de controle. Alm disso, para cada grfico de controle podem ser aplicados
determinados testes para verificar se h causas especiais a serem investigadas.
Normalmente, so aplicados os testes 1 a 4 apresentados anteriormente. Porm,
nem todos esses testes so aplicveis a todos os tipos de grficos de controle.
O primeiro passo para escolher o tipo de grfico de controle a ser utilizado
identificar o tipo de dados que ser tratado. Grficos de controle podem ser
aplicados a duas classes diferentes de dados: dados de variveis e dados de
atributos.
Dados de variveis, comumente, so medidas de fenmenos contnuos
como, por exemplo, esforo, tempo e custo. Dados de atributos, por outro lado,
ocorrem quando uma informao registrada apenas quando uma entidade da
populao analisada satisfaz ou no um critrio ou um conjunto de critrios.
Normalmente, indicam contagens discretas. Por exemplo: nmero de defeitos
encontrados, nmero de membros do projeto que possuem determinada
caracterstica etc.
Para identificar a classificao dos dados, no basta saber se os dados so
discretos ou contnuos. Alm disso, preciso considerar o contexto em que so
coletados e utilizados. Por exemplo, analisar o nmero total de requisitos realizar
uma contagem, logo seria classificado como dado de atributo. Porm, ao se contar
o nmero total de requisitos, esto sendo contadas todas as entidades em uma
populao e no apenas ocorrncias de entidades que tenham um ou mais
atributos especficos. Sendo assim, contagens de entidades que representam o
tamanho total de uma populao devem ser tratadas como dados de variveis, pois
tm natureza contnua, mesmo que haja instncias de contagens discretas nelas.
A seguir so apresentados tipos de grficos de controle para cada tipo de
dados. Para prover melhor entendimento, tambm so apresentados exemplos de
91
aplicao dos grficos11. Convm dizer que os exemplos contm dados hipotticos,
cujo nico fim ilustrar a utilizao dos grficos.
5.3.1 Grficos de Controle para Dados de Variveis

Para dados de variveis sero apresentados cinco tipos de grficos:
a) Grficos X-bar e R (XbarR)
b) Grficos X-bar e S (XbarS)
c) Grficos Individuals and Moving Range (XmR)
d) Grficos Individuals and Median Moving Range (XMmR)
e) Grficos Moving Average and Moving Range (mXmR)
a) Grficos X-bar e R (XbarR)
So adequados para analisar o comportamento do processo atravs de
subagrupamentos de medidas obtidas sob as mesmas condies, em determinados
perodos de tempo. O grfico X-bar (average) analisa a mdia dos valores em cada
subgrupo e o grfico R (range) indica a variao interna dos subgrupos. Esse tipo
de grfico se limita a subgrupos formados por at 10 observaes.
A anlise do comportamento do processo deve ser feita observando-se os
dois grficos. O grfico X-bar permite analisar a tendncia do processo ao longo do
tempo. J o grfico R permite analisar a variao dentro de cada subgrupo.
A seguir so apresentadas as frmulas e constantes para o clculo dos
limites de controle nesse tipo de grfico.
Clculo dos limites:
X-bar
Onde:
UCL X = X + A 2 R
X deve ser calculado para cada subgrupo de tamanho n, para

cada um dos k subgrupos.
CL X = X
LCL X = X A 2 R
X 1 + X 2 + ... + X n
n
Xk =
X 1 + X 2 + ... + X k
k
Onde:
UCL R = D 4 R
R deve ser calculado para cada subgrupo de tamanho n, para

CL R = R
LCL R = D3 R
11
Xk =
R k = X max X min
R=
R 1 + R 2 + ... + R k
k
Os exemplos apresentados foram adaptados de [FLORAC e CARLETON, 1999].
92
Na Figura 5.6 possvel visualizar as representaes de k e n:
Figura 5.6 Representao de k e n (adaptado de [WHEELER e CHAMBERS, 2010]).
Os valores das constantes A2, D3 e D4 presentes nas frmulas variam de

acordo com o tamanho dos subgrupos (n). A Tabela 5.1 apresenta os valores
dessas constantes.
Tabela 5.1 Constantes para clculo dos limites de controle dos grficos X-bar e R.
n
10
A2
1,880
1,023
0,729
0,577
0,483
0,719
0,373
0,337
0,308
D3
0,076
0,136
0,189
0,223
D4
3,268
2,574
2,282
2,114
2,004
1,924
1,864
1,816
1,777
Exemplo: O gerente de um escritrio de projetos deseja analisar a

quantidade de horas semanais que so despendidas em atividades de manuteno
nos projetos. O valor de horas despendidas registrado diariamente. A Tabela 5.2
apresenta os dados coletados em doze semanas.
Tabela 5.2 Dados das horas dedicadas a atividades de manuteno nos projetos.
Semana
1
2
3
4
5
6
7
8
9
10
11
12
Segunda
25,3
22,2
24,4
23,2
20,3
22,2
23,0
22,5
25,0
22,3
21,9
21,6
Tera
21,8
22,5
25,5
22,6
22,9
24,5
20,6
21,7
24,5
23,3
20,9
21,9
Quarta
22,8
21,5
22,2
24,1
26,0
24,0
22,1
24,5
21,3
20,9
22,8
22,4
Quinta
19,9
19,9
21,5
22,9
23,7
22,8
20,9
22,8
20,9
21,3
22,3
21,8
Sexta
21,5
19,7
25,7
22,1
23,2
22,4
24,0
23,7
19,3
20,9
19,3
20,5
93
Como o gerente deseja uma anlise semanal, os dados sero subagrupados

em semanas, para serem analisados. Assim, h 12 subgrupos (12 semanas), cada
um com cinco observaes, uma para cada dia da semana.
Para desenhar os grficos, os limites de controle devem ser calculados.
Usando as frmulas X k =
X 1 + X 2 + ... + X n
e R k = X max X min so calculadas
n
a mdia e a variao em cada subgrupo. Uma vez que so 12 subgrupos, o valor de

k varia de 1 a 12. O valor de n 5, pois cada subgrupo composto por 5
observaes. Na Tabela 5.3 os valores da mdia e da variao de cada subgrupo so
apresentados nas duas ltimas colunas.
Tabela 5.3 Dados das horas dedicadas a atividades de suporte.
Semana
1
2
3
4
5
6
7
8
9
10
11
12
Segunda
25,3
22,2
24,4
23,2
20,3
22,2
23,0
22,5
25,0
22,3
21,9
21,6
Tera
21,8
22,5
25,5
22,6
22,9
24,5
20,6
21,7
24,5
23,3
20,9
21,9
Quarta
22,8
21,5
22,2
24,1
26,0
24,0
22,1
24,5
21,3
20,9
22,8
22,4
Quinta
19,9
19,9
21,5
22,9
23,7
22,8
20,9
22,8
20,9
21,3
22,3
21,8
Sexta
21,5
19,7
25,7
22,1
23,2
22,4
24,0
23,7
19,3
20,9
19,3
20,5
Mdia
22,2
21,1
23,8
22,9
23,2
23,2
22,1
23,0
22,2
21,7
21,4
21,6
Variao
5,4
2,8
4,2
2,0
5,7
2,3
3,4
2,8
5,8
2,4
3,5
2,0
O prximo passo calcular a mdia total e a mdia da variao, que sero as

linhas centrais dos grficos X-bar e R, respectivamente. Assim:
X=
X 1 + X 2 + ... + X 12
= 22,38
12
R=
R1 + R2 + ... + R12
= 3,5
12
Em seguida, deve-se determinar os limites de controle.
Para X-bar:
Para R:
UCL X = X + A 2 R = 22,38 + 0,577 * 3,5 = 24,39

LCL X = X A 2 R = 22,38 0,577 * 3,5 = 20,36
UCL R = D 4 R = 2,114 * 3,5 = 7,39

LCL R = D3 R = indefinido
Calculados os valores dos limites de controle, os grficos podem ser

construdos.
94
Figura 5.7 X-bar e R para mdia de horas dirias dedicadas semanalmente em atividades de
manuteno.
Observando-se os grficos, pode-se dizer que o comportamento do processo

parece ser estvel, pois tanto as mdias quanto as variaes encontram-se dentro
dos limites de controle calculados. O grfico X-bar da Figura 5.7 mostra que ao
longo das doze semanas, a mdia de horas despendidas em atividades de
manuteno semanalmente comportou-se de maneira estvel. O grfico R da
Figura 5.7, por sua vez, indica que em cada semana, a variao entre as horas
despendidas em atividades de manuteno diariamente, tambm pareceu estvel.
Para verificar a aparente estabilidade, podem ser utilizados os quatro testes
apresentados anteriormente. Para isso, necessrio identificar as zonas A, B e C.
Uma vez que a distncia entre a linha central e os limites de 3 , basta calcular o
valor do desvio padro () e indicar as zonas nos grficos.
Para o grfico X-bar, o desvio padro () dado por
A 2 R 0,577 * 3,5
=
= 0,67.
3
3
95
A Figura 5.8 apresenta o grfico com as zonas A, B e C identificadas. Ao

aplicar os testes 1, 2, 3 e 4, confirma-se que o processo estvel.
Figura 5.8 X-bar com as zonas A, B e C identificadas.
Os grficos X-bar e R possuem a limitao de trabalharem com subgrupos

que tenham, no mximo, dez observaes. A partir da, trabalhar com mdias pode
levar obteno de valores no muito adequados para os limites. Para trabalhar
com subgrupos que possuam mais observaes, podem ser utilizados os grficos Xbar e S, descritos a seguir.
b) Grficos X-bar e S (XbarS)
Esses grficos funcionam como os grficos X-bar e R, porm permitem
trabalhar com subgrupos com mais de dez elementos. A diferena em relao aos
grficos X-bar e R est na forma como a variao de cada subgrupo calculada. Nos
grficos X-bar e R ela obtida pela mdia dos valores de cada subgrupo. Nos
grficos X-bar e S, por sua vez, ela obtida pelo desvio padro de cada subgrupo.
Esses grficos tambm podem ser utilizados para trabalhar subgrupos com
menos de dez elementos. Na verdade, a frequncia de utilizao dos grficos X-bar
e R diminuiu na medida em que ferramentas automatizadas de apoio aos clculos
foram desenvolvidas. Como os grficos de controle foram propostos no passado,
era mais fcil calcular a mdia de valores do que o desvio padro e, como em
subgrupos com poucos elementos os resultados de se usar mdia ou desvio padro
no diferiam muito, era comum optar pelos grficos X-bar e R para os casos de
subgrupos com at dez elementos. Atualmente, como no h mais limitaes para
96
realizar clculos, a escolha de qual grfico usar para subgrupos de dados com at
dez elementos no precisa mais ser justificada por aquela questo, podendo ser
mais flexvel.
A seguir so apresentadas as frmulas e constantes para o clculo dos
limites de controle nesse tipo de grfico.
Clculo dos limites:
X-bar
Onde:
X deve ser calculado para cada subgrupo de tamanho n, para

UCL X = X + A 3 S
CL X = X
Xk =
LCL X = X A 3 S
X 1 + X 2 + ... + X n
n
Xk =
X 1 + X 2 + ... + X k
k
Onde:
UCL S = B 4 S
S o desvio padro que deve ser calculado para cada

subgrupo de tamanho n.
CL S = S
i =n
LCL S = B3 S
S=
i =1
( X i X )2
n 1
S=
i=k
i =1
Si
Os valores das constantes A3, B3 e B4 presentes nas frmulas variam de

acordo com o tamanho dos subgrupos (n). A Tabela 5.4 apresenta os valores
dessas constantes para n 15. O procedimento de obteno das constantes para
n>15 pode ser encontrado em [FLORAC e CARLETON, 1999].
Tabela 5.4 Constantes para clculo dos limites de controle dos grficos X-bar e S.
n
A3
B3
B4
10
11
12
13
14
15
2,659 1,954 1,628 1,427 1,287 1,182 1,099 1,032 0,975 0,927 0,886 0,850 0,817 0,789
-
0,030 0,118 0,185 0,239 0,284 0,322 0,354 0,382 0,407 0,428
3,267 2,568 2,266 2,089 1,970 1,882 1,815 1,761 1,716 1,678 1,646 1,619 1,593 1,572
Exemplo: O gerente de um projeto deseja analisar a taxa de inspeo de

cdigo realizada no software do projeto. Essa medida dada pela razo entre o
tamanho do produto inspecionado, em nmero de linhas de cdigo fonte (SLOC), e
o nmero de horas de inspeo realizadas. O esforo alocado em cada inspeo
de uma pessoa, ou seja, no h mais de uma pessoa trabalhando em uma inspeo
ao mesmo tempo. O produto possui cinco releases (ou liberaes) e, em cada uma
delas, foram realizadas treze inspees.
97
A Tabela 5.5 apresenta os dados que foram coletados. As linhas average e S

representam a mdia e o desvio padro de cada release. Para obter esses valores,
i =n
X + X 2 + ... + X n
foram aplicadas as frmulas X k = 1
e
n
i =1
Sk =
( X i X k )2
n 1
para k
variando de 1 a 5 , uma vez que so 5 subgrupos, um para cada release, e para

n=13, pois cada subgrupo formado por 13 observaes (taxas de inspeo).
Tabela 5.5 Dados das taxas de inspeo (SLOC/h) das 5 releases de um produto.
Inspeo
Release 1
Release 2
Release 3
Release 4
Release 5
1
2
3
4
5
6
7
8
9
10
11
12
13
Mdia
Desvio Padro
137,28
80,00
22,00
14,48
24,00
32,40
36,72
22,08
21,68
35,60
78,40
22,96
31,60
52,32
65,80
39,12
48,00
30,16
22,00
27,20
116,56
63,52
63,92
21,20
65,30
73,68
50,56
29,68
50,76
30,30
37,60
21,36
25,76
60,80
19,56
69,44
31,76
8,80
57,89
9,20
74,00
63,36
16,72
67,90
54,23
20,80
22,16
20,80
57,76
36,10
62,08
46,64
45,44
49,87
9,70
103,36
10,72
37,52
38,97
24,30
59,04
103,60
13,92
16,40
50,47
69,52
46,26
28,34
40,93
34,75
34,07
26,37
14,51
19,20
19,02
Aps calculados a mdia e o desvio padro, o prximo passo calcular a

mdia total e o desvio padro total, que sero a linha central do grfico de controle.
X 1 + X 2 + ... + X 5
Assim, X k =
= 43,96
5
S=
i =k
i =1
Si
= 22,63 .
Em seguida, deve-se determinar os limites de controle.
Para X-bar:
Para S:
UCL X = X + A 3 S = 43,96 + 0,85 * 22,63 = 63,20

LCL X = X A 3 S = 43,96 0,85 * 22,63 = 24 ,72
UCL S = B 4 S = 1,619 * 22,63 = 36,64

LCL S = B3 S = 0,382 * 22,63 = 8,64
Calculados os valores dos limites de controle, os grficos podem ser

construdos.
98
Figura 5.9 X-bar e S para taxa de inspeo em 5 releases de um produto.
Observando-se o grfico X-bar, percebe-se que o ponto correspondente

release 1 est fora dos limites de controle, devendo ser conduzida uma
investigao de suas causas. Para realizar essa investigao, deve-se analisar o
comportamento interno dos valores do subgrupo 1 (release 1), pois o ponto fora do
controle no grfico X-bar indica que no subgrupo 1 a mdia dos valores das
observaes foi maior do que as mdias dos demais subgrupos, tendo excedido o
comportamento esperado. Nesse caso, onde h apenas um (sub)grupo sendo
analisado, deve-se utilizar os grficos XmR, descritos a seguir.
c) Grficos Individuals and Moving Range Charts (XmR)
Esses grficos so utilizados quando uma mesma varivel medida
frequentemente. Sua utilizao muito comum no contexto de processos de
software.
99
O grfico X representa os valores individuais coletados, e no mais as

mdias entre os valores de cada subgrupo. O grfico mR (moving range), por sua
vez, representa a variao de um valor em relao ao valor anterior, chamada
variao mvel. Os dois pontos usados para calcular uma variao mvel so
chamados de two-point moving range.
Nesse tipo de grfico de controle os limites de controle superior e inferior
so ditos limites naturais de processo (natural process limit NPL), pois eles
representam a variabilidade associada a medidas individuais e no mais a
agrupamentos de medidas.
A representao de valores individuais, ao invs de mdias de valores
agrupados, permite detectar cinco tipos de situaes mais facilmente: (i) ciclos
repeties regulares do processo; (ii) tendncias movimentos contnuos para
cima ou para baixo; (iii) misturas presena de mais de uma distribuio; (iv)
agrupamentos medidas aglomeradas em um ponto; e, (v) relaes entre o padro
geral de agrupamentos e a especificao do processo.
Os testes 2, 3 e 4 apresentados anteriormente para detectar instabilidade
no processo no so eficientes quando aplicados em grficos moving range
[WHEELER e CHAMBERS, 2010].
A seguir so apresentadas as frmulas para o clculo dos limites de controle
nesse tipo de grfico.
Clculo dos limites:
X
Onde:
UNPL X = X + 2660mR
CL X = X
X=
LNPL X = X 2660mR
1
k
i =k
i =1
Xi
k = nmero de observaes
mR
Onde:
UCL R = 3,268mR
CL R = mR
LCL R = no existe
1 i =r
mR i
r i=1
mR i = X i +1 X i para 1 i k - 1
mR =
r = k-1 e k = nmero de observaes
Exemplo: O gerente de um escritrio de projetos deseja analisar a

quantidade de horas dirias despendidas em atividades de manuteno. Diferente
100
do exemplo apresentado para o grfico de controle X-bar e R, o gerente no est

interessado em analisar a quantidade de horas semanalmente, logo no h
subagrupamentos. Na Tabela 5.6 so apresentados os valores coletados em 20
dias de observao.
Tabela 5.6 - Horas dirias despendidas em atividades de manuteno.
Dia
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Horas (Xi)
50,5
43,5
45,5
39,8
42,9
44,3
44,9
42,9
39,8
39,3
48,8
51,0
44,3
43,0
51,3
46,3
45,2
48,1
45,7
44,1
mR
7,0
2,0
5,7
3,1
1,4
0,6
2,0
3,1
0,5
9,5
2,2
6,7
1,3
8,3
5,0
1,1
2,9
2,4
1,6
Na Tabela 5.6, a coluna mR indica a variao mvel entre dois valores

consecutivos (Xi e Xi+1). Esses dados so necessrios para calcular a mdia dos
valores individuais e a mdia das variaes mveis, que sero as linhas centrais
dos grficos.
Aplicando-se as frmulas X =
1
k
i =k
X
i =1 i
mR =
1
r
i =r
i =1
mR i e considerando
k = 20 e r = 19, foram obtidas a mdia dos valores individuais e a mdia das

variaes mveis, cujos valores so 45,06 e 3,49, respectivamente.
Calculadas as mdias, determinam-se os limites de controle que, como dito
anteriormente, nesse tipo de grfico, so ditos limites naturais de processo.
Para X:
UNPL X = X + 2660mR = 45,06 + 2,660 * 3,49 = 54,34

LNPL X = X 2660mR = 45,06 2,660 * 3,49 = 35,78
Para mR: UCLR = 3,268mR = 3,268* 3,49 = 11,41
101
Construindo-se os grficos de controle, tem-se:
Figura 5.10 Grficos X e mR para horas despendidas em atividades de manuteno.
O grfico X da Figura 5.10 mostra que a quantidade de horas despendidas

em atividades de manuteno nos ltimos 20 dias tem se comportado de maneira
estvel. O grfico mR, por sua vez, indica que as variaes entre as horas
despendidas em um dado dia e as horas despendidas no dia anterior tambm
apresentam comportamento repetvel.
Observe que no grfico mR os pontos comeam a ser plotados a partir do
dia 2. Isso ocorre, pois uma vez que so necessrios dois valores para que seja
possvel obter a variao mvel, somente a partir do segundo dia torna-se possvel
identificar a variao em relao ao dia anterior. Essa caracterstica poder ser
observada tambm nos outros grficos moving range que sero apresentados mais
adiante.
Apesar do comportamento do processo ser estvel, possvel perceber que
em alguns pontos h uma variao maior que em outros. Por exemplo, pelo grfico
102
X possvel notar que em alguns dias (1, 11, 12 e 16) o nmero de horas
despendidas foi maior que nos demais dias. Alm disso, como mostra o grfico mR,
a variao de horas despendidas no dcimo primeiro dia em relao s horas
despendidas no dcimo dia maior que as demais e se destaca no grfico. Embora
essas situaes no tenham desestabilizado o comportamento do processo, o
gerente poderia investigar o que ocorreu nesses dias que fez com que as horas
despendidas em manuteno variassem de maneira mais expressiva.
Os grficos XmR tambm podem ser utilizados para dados discretos quando
estes se referirem a contagens de entidades que representam o tamanho total de
uma populao ou seu status. Nesse caso, embora os dados sejam discretos, eles
caracterizam dados de variveis. Por exemplo, suponha que um gerente esteja
analisando o nmero de problemas no resolvidos nos projetos, registrado no
ltimo relatrio semanal emitido. Nesse relatrio, esto registrados 30 problemas
crticos que no foram resolvidos na referida semana. Suponha, ainda, que o
gerente tenha sido contratado h pouco tempo e que no tem muito conhecimento
sobre o comportamento dessa medida nos ltimos meses. Preocupado com o que
parece ser um nmero muito alto de problemas no resolvidos, o gerente decide
analisar o comportamento do processo de resoluo de problemas nas ltimas 21
semanas, para observar se houve alguma alterao no comportamento do processo
ou se os 30 problemas no resolvidos registrados no ltimo relatrio refletem um
comportamento esperado e usual do processo.
A Tabela 5.7 apresenta os dados das ltimas 22 semanas (as 21 semanas
anteriores e a semana que o gerente est analisando).
Tabela 5.7 Nmero de problemas no resolvidos (NPNR) em 22 semanas.
Semana
10 11 12 13 14 15 16 17 18 19 20 21 22
NPNR (Xi) 17 25 15 17 18 22 19 16 22 19 25 18 25 22 24 16 19 25 22 22 18 30
mR
10
12
O primeiro passo para construir os grficos calcular as mdias dos valores

individuais e das variaes mveis, para obter os limites centrais dos grficos.
Assim, para k = 22 e r =21, obtm-se X =
1
k
i =k
i =1
X i = 20,73 e mR =
1
r
i =r
i =1
mR i = 4,81.
O prximo passo determinar os limites naturais de processo. Ento:
103
Para X:
UNPL X = X + 2660mR = 20,73 + 2,660 * 4,81 = 33,52

LNPL X = X 2660mR = 20,73 2,660 * 4,81 = 7,94
Para mR: UCLR = 3,268mR = 3,268* 4,81 = 15,72

Construindo-se os grficos de controle, tem-se:
Figura 5.11 Grficos X e mR para nmero de problemas no resolvidos.
Analisando-se os grficos possvel observar que o processo de resoluo

de problemas, quando analisado pelo nmero de problemas no resolvidos,
mostra-se com comportamento dentro dos limites esperados. Para o gerente, isso
significa que os 30 problemas no resolvidos registrados no ltimo relatrio
semanal no refletem um nmero diferente do comportamento esperado para o
processo, considerando as ltimas 22 semanas.
Com esse exemplo h oportunidade de retomar uma afirmao feita quando
se falou sobre estabilidade e capacidade neste captulo (seo 4.5) e se destacou
que ter um processo estvel no significa que ele tem um bom desempenho. No
104
exemplo, possvel perceber que o processo tem comportamento repetvel, porm,

aparentemente, o nmero de problemas no resolvidos tem sido repetidamente
alto. Nesse caso, embora o processo seja estvel, ele poderia ser alterado para
tentar diminuir o nmero de problemas no resolvidos.
d) Grficos Individuals and Median Moving Range (XMmR)
Esse tipo de grfico de controle similar aos grficos XmR, porm utiliza a
mediana nos clculos, em substituio mdia. A mediana pode ser mais sensvel
s causas especiais, principalmente quando a variao mvel (moving range)
possui alguns valores que podem elevar ou diminuir os limites. Nesses casos,
utilizar a mediana pode revelar a presena de causas especiais que no
apareceriam se fosse utilizada a mdia.
Convm lembrar que os testes 2, 3 e 4 no devem ser aplicados ao grfico
moving range.
Clculo dos limites:
X
Onde:
UNPL X = X + 3,145Mm R
CL X = X
X=
LNPL X = X 3,145Mm R
1
k
i =k
i =1
Xi
MmR
UCLR = 3,865MmR
CLR = MmR
LCLR = no existe
Para
determinar MmR, os valores de cada moving
range devem ser colocados em ordem crescente. Se

o nmero de moving ranges (k) for mpar, a
mediana moving range (MmR) estar na posio
[(k-1)/2] + 1. Se k for par, a mediana moving
range ser a mdia dos valores das posies k/2 e
k/2 + 1.
Exemplo: Um gerente, analisando o nmero de problemas relatados pelo

cliente que no foram resolvidos no ltimo ms, percebe que a mdia diria de
problemas relatados pelo cliente que no foram resolvidos nesse ms foi 12,39.
Comparando com as mdias dirias dos meses anteriores, o gerente percebe que a
atual est quase 50% acima dos valores anteriores. Ele, ento, utiliza um grfico de
controle XmR para visualizar a situao, porm nenhuma situao que indique a
presena de causas especiais identificada. O gerente analisa, ento, os dados
utilizados para gerar os grficos do ltimo ms e percebe que nos dias 12, 14, 15,
105
18 e 27 houve uma variao muito maior do que nos demais dias, com isso, ao
aplicar a mdia para construir os grficos X e mR, os valores das linhas centrais e
dos limites de controle foram inflados devido aos dados referentes queles dias.
Para refinar a investigao de existncia de causas especiais, o gerente decide
utilizar os grficos de controle XMmR.
A Tabela 5.8 apresenta os dados dirios do ltimo ms e a variao mvel
entre os valores de um dia e do dia anterior (mR).
Tabela 5.8 Nmero de problemas no resolvidos relatados pelos clientes (PNR) no ltimo ms,
com destaque aos dias onde ocorreram as maiores variaes.
Dias
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
PNR (Xi)
12
4
6
15
21
5
11
8
6
4
32
2
7
46
5
25
5
41
22
1
5
13
5
6
5
31
1
5
3
26
6
mR
8
2
9
6
16
6
3
2
2
28
30
5
39
41
20
20
36
19
21
4
8
8
1
1
26
30
4
2
23
20
O primeiro passo para calcular os limites de controle, determinar a mdia

dos valores e a mediana da variao mvel, que sero os limites centrais dos
grficos. Aplicando-se a frmula X =
1
k
i =k
i =1
X i , para k = 31, obtm-se o valor 12,39,
que a mdia dos valores individuais.

Para obter o valor da mediana da variao mvel, os valores das variaes
mveis (mR) devem ser dispostos em ordem crescente. Assim:
106
1 1 2 2 2 2 3 4 4 5 6 6 8 8 8 9 16 19 20 20 20 21 23 23 26 30 30 36 39 41
Uma vez que o nmero de valores de variaes mveis par (k=30), a

mediana ser a mdia dos valores das posies
MmR =
k
2
k
+1 .
2
Ento:
(8 + 9)
= 8,5. O prximo passo calcular os limites de controle:
2
Para X:
Para MmR:
UNPLX = X + 3,145MmR = 12,39 + 3,145* 8,5 = 39,12

LNPLX = X 3,145MmR = 12,39 - 3,145* 8,5 = - 14,34
UCL R = 3,865MmR = 3,865 * 8 ,5 = 32,85
Calculados os valores dos limites, os grficos de controle podem ser

construdos.
Figura 5.12 Grficos X e MmR para nmero de problemas no resolvidos relatados pelo cliente.
Analisando-se os grficos possvel observar que causas especiais foram

identificadas quando foi utilizado o grfico de controle XMmR. No grfico X,
percebe-se que o nmero de problemas registrados nos dias 14 e 18 so maiores
do que os limites que caracterizam a estabilidade do processo. Tambm no grfico
107
MmR possvel perceber a indicao de variaes irregulares (dias 11 a 20). Os

pontos que caracterizam a instabilidade do processo so representados em
formato diferente nos grficos.
Os pontos fora dos limites de controle no foram identificados quando se
analisou o comportamento do processo atravs do grfico de controle XmR. Isso
ocorreu, pois entre as variaes mveis h algumas que distanciam-se
consideravelmente das demais (vide distribuio dos pontos entre os dias 10 e 21
no grfico MmR) e elevam os limites de controle quando so calculados baseandose na mdia, impossibilitando a deteco de algumas situaes de investigao.
e) Grficos Moving Average and Moving Range (mXmR)
Este tipo de grfico de controle segue a filosofia dos grficos moving range
at agora apresentados, porm, alm de considerarem a variao mvel (moving
range), consideram tambm a mdia mvel (moving average), ou seja, a mdia
entre dois valores consecutivos. Esses grficos permitem analisar a variao entre
as mdias e, com isso, focam a avaliao das tendncias do desempenho dos
processos ao longo do tempo.
Os grficos mXmR podem ser utilizados para grupos de dados com
subgrupos de at dez elementos, assim como o grfico de controle X-barR.
Clculo dos limites:
mX
UCL mX = mX + A 2 mR
CL mX = mX
LCL mX = mX A 2 mR
Onde:
X k + X k 1 + ... + X k n +1
, para k n 3 e
n
X + X k 1
mX k = k
, para k n = 2
2
k =N mX k
mX = k =n
Nn +1
mX k =
N = nmero total de observaes individuais

k = nmero de subgrupos
n = tamanho do subgrupo
mR
Onde:
UCL R = D 4 mR
mR deve ser calculado para cada um dos k subgrupos de

tamanho n.
CL R = mR
LCL R = no existe
mR k = X max X min e mR =
mR 1 + mR 2 + ... + mR k
k
108
Os valores das constantes A2 e D4 presentes nas frmulas variam de acordo

com o tamanho dos subgrupos (n). Seus valores foram apresentados
anteriormente na Tabela 5.1.
Para calcular os limites de controle, o primeiro passo identificar o nmero
de subgrupos (k) e seu tamanho (n), para que as frmulas corretas sejam
utilizadas. Algumas vezes, no conjunto de dados a ser analisado no h subgrupos
explcitos, como havia nos exemplos apresentados para os grficos de controle
XbarR e XbarS. Nesses casos, os dados parecem compor um nico grupo de dados,
sem subgrupos. Quando isso acontece, assim como foi feito nos grficos moving
ranging apresentados anteriormente (XmR e XMmR), para obter a variao mvel,
consideram-se dois valores consecutivos e calcula-se a variao entre eles. O
mesmo procedimento adotado para calcular a mdia mvel. Dessa forma,
assume-se que cada par de valores forma um subgrupo de tamanho 2, isto , n=2.
Ento, para k observaes, existem k-1 subgrupos compostos por dois pontos (os
dois pontos que so considerados para calcular a variao ou mdia mvel).
Os testes 2, 3 e 4 no so aplicveis a esse tipo de grfico.
Exemplo: Um gerente de projetos de software, responsvel pelo projeto
que trata do desenvolvimento de componentes para reutilizao em uma
organizao, deseja analisar o progresso do desenvolvimento dos componentes.
Para isso, ele deve analisar os componentes cujo desenvolvimento foi concludo
desde o incio do projeto, h dez meses, at o momento atual. Os dados obtidos
pelo gerente so apresentados na Tabela 5.9.
Tabela 5.9 Componentes para reutilizao concludos (mensal e acumulado).
Ms
10
Componentes concludos em
cada ms
(Produo mensal)
15
40
25
25
35
45
40
45
55
50
Produo acumulada
15
55
80
105 140 185 225 270 325 375
O primeiro passo para calcular os limites de controle, calcular as mdias

das variaes mveis e das mdias mveis, que sero as linhas centrais dos
grficos. Para isso, necessrio identificar o nmero de subgrupos e o nmero de
elementos em cada um deles, para que seja possvel utilizar a frmula correta.
109
No exemplo no h subgrupos explcitos, logo cada par de valores utilizados

para calcular a mdia e variao mveis forma um subgrupo de tamanho 2, e para
k observaes, existem k-1 subgrupos. Ento, nesse exemplo existem 9 subgrupos
de tamanho n=2.
Utilizando-se a frmula mX k =
X k + X k 1
, para a produo mensal, so
2
obtidas as mdias mveis apresentadas na Tabela 5.10.

Tabela 5.10 Clculo das mdias mveis dos valores da produo mensal.
Ms
1
15
Produo mensal
mX (moving average)
Para
mX =
k =N
k =n
obter
mX k
Nn +1
2
40
3
25
27,5 32,5
mdia
das
4
25
5
35
6
45
25
30
40
mdias
mveis,
7
40
8
45
42,5 42,5
9
55
10
50
50
52,5
aplica-se
frmula
considerando N=10 (nmero total de observaes) e n=2
(tamanho dos subgrupos), e obtm-se o valor 38,06.

A Tabela 5.11 apresenta as variaes mveis (moving range) dos valores da
produo mensal.
Tabela 5.11 Clculo das variaes mveis dos valores da produo mensal.
Ms
10
Produo mensal
15
40
25
25
35
45
40
45
55
50
25
15
10
10
10
mR (moving range)
Para calcular a mdia das variaes mveis, aplica-se a frmula

mR =
mR 1 + mR 2 + ... + mR k
, obtendo-se como resultado 9,44.
k
O prximo passo calcular os limites de controle, utilizando-se para as

constantes os valores da Tabela 5.1, referentes a subgrupo de tamanho 2.
Para mX:
Para mR:
UCLmX = mX + A2 mR = 38,06 + 1,880 * 9,44 = 55,81

LCLmX = mX A2 mR = 38,06 1,880 * 9,44 = 20,31
UCL R = D 4 mR = 3,268 * 9,44 = 30,85
Calculados os limites, possvel elaborar os grficos de controle.
110
Figura 5.13 Grficos mX e mR para componentes concludos.
Analisando-se os grficos possvel perceber que o grfico das mdias

mveis (mX) apresenta uma tendncia de crescimento de componentes concludos
e que no h causas especiais. O grfico das variaes mveis (mR) tambm
mostra comportamento dentro dos limites de controle. Entretanto, no possvel
afirmar muito mais que isso. O formato do grfico de controle no permite, por
exemplo, projetar a tendncia de quando todos os componentes sero concludos
ou analisar qual quantidade de componentes ser concluda at certo ms.
Uma forma de representar as tendncias de comportamento dos
processos explicitamente associar os conceitos de mdia mvel e limites de
111
controle com grficos de tendncias. Essa combinao pode ser muito til na
deteco de deslocamentos no comportamento do processo.
Considerando o exemplo, para analisar a tendncia do comportamento do
processo de desenvolvimento de componentes para reutilizao, necessrio
analisar a produo acumulada. Inicialmente, deve-se calcular a mdia mvel
(moving average) para os valores acumulados, conforme mostra a Tabela 5.12.
Tabela 5.12 Clculo da mdia mvel considerando os valores acumulados.
Ms
10
Produo acumulada
15
55
80
105
140
185
225
270
325
375
mX (moving average)
35
67,5 92,5 122,5 162,5 205 247,5 297,5
350
Os valores da mdia mvel devem, ento, ser plotados em um grfico mdia

mvel versus tempo, como mostrado na Figura 5.14.
Figura 5.14 Grfico mdia mvel x tempo para a produo acumulada.
O prximo passo calcular a tendncia do processo. Isso pode ser feito por
meio da anlise de regresso dos valores da mdia mvel. Alternativamente, uma
forma simples de identificar a tendncia do processo dividir os valores das
mdias mveis plotadas no grfico em dois grupos e calcular a mdia de cada um
desses grupos. Em seguida, deve-se plotar os valores obtidos no grfico, cada um
na metade de seu grupo, e traar uma linha unindo-os.
No exemplo, como h nove valores de mdias mveis, eles sero divididos
em dois grupos, um com cinco valores e um com quatro. O primeiro grupo
112
formado pelos valores 35, 67,5, 92,5, 122,5 e 162,5. O segundo grupo formado
pelos valores 205, 247,5, 297,5 e 350. O valor da mdia do primeiro grupo 96 e
do segundo 275. Esses valores indicam a coordenada do eixo vertical (mdia
mvel) dos pontos que precisam ser plotados no grfico para a identificao da
tendncia do processo. Para identificar a coordenada do eixo horizontal (ms),
deve ser calculado o ponto central de cada grupo em relao ao eixo horizontal,
sendo 4 (ponto central entre os meses 2 e 6) para o primeiro grupo e 8,5 (ponto
central entre os meses 7 e 10) para o segundo. Em seguida, uma linha unindo os
dois pontos traada, indicando o comportamento do processo, como mostra a
Figura 5.15.
Figura 5.15 Linha de tendncia do comportamento do processo.
Identificada a tendncia do processo, limites de controle podem ser

inseridos. Isso permitir verificar se a tendncia de comportamento do processo
ir ultrapassar os limites de controle ou no e, caso v ultrapassar, quando isso ir
ocorrer. Os limites de controle da tendncia so obtidos adicionando-se (limite
superior) ou diminuindo-se (limite inferior) da linha de tendncia o valor de 3
calculado para as mdias mveis.
No exemplo, conforme apresentado no grfico mX, o valor de 3 17,75,
uma vez que essa a distncia da linha central at os limites de controle. Na Figura
5.16 apresentado o grfico de tendncia com os limites de controle. A linha slida
113
representa a tendncia de comportamento do grfico e as linhas pontilhadas so os

limites de controle.
Figura 5.16 Grfico de tendncia com limites de controle para componentes concludos.
Analisando-se o grfico da Figura 5.16 possvel perceber que, se o

processo mantiver o comportamento atual, em doze meses tero sido concludos
cerca de 400 componentes. Alm disso, se o processo mantiver seu
comportamento, a tendncia que no ultrapasse os limites de controle, pois,
como ilustra o grfico, os pontos so internos aos limites calculados com base na
tendncia do comportamento do processo.
Grficos desse tipo so teis no apenas para monitorar a estabilidade do
processo, mas tambm provm informaes sobre o status do processo em um
projeto, permitindo uma comparao entre o progresso do desenvolvimento e os
planos. Os limites de controle servem como um mecanismo de alerta para a
gerncia do projeto. Mas, os grficos de tendncia, sozinhos, no trabalham com
limites, isso s possvel atravs de sua combinao com outros tipos de grficos,
como os grficos de controle mXmR aqui apresentados.
A seguir so apresentados tipos de grficos de controle para dados de
atributos.
114
5.3.2 Grficos de Controle para Dados de Atributos

Sero apresentados trs tipos de grficos para dados de atributos:
a) Grfico C (C Chart)
b) Grfico U (U Chart)
c) Grfico Z (Z Chart)
Os grficos XmR e XMmR apresentados anteriormente, tambm podem ser
utilizados para dados de atributos.
a) Grfico C (C Chart)
Esse tipo de grfico pode ser utilizado quando se deseja contar a ocorrncia
de eventos em uma mesma rea de observao. Por exemplo, pode ser utilizado
para representar o nmero de falhas registradas pelos usurios de uma
determinada verso de um sistema ou o nmero de defeitos encontrados em um
ponto de funo. Note que, nesses casos, a rea de observao na qual os eventos
(problemas) so contados constante, ou seja, o nmero de falhas registradas
sempre ser referente a uma mesma verso do sistema e o nmero de defeitos
encontrados sempre ser referente a um Ponto por Funo.
Para utilizar o grfico C, a ocorrncia de defeitos na rea de observao
considerada deve ter um nmero relativamente baixo quando comparado com as
oportunidades de ocorrncia de defeitos nessa rea. Por exemplo, a ocorrncia de
defeitos em um sistema pode ser vista como algo pouco frequente quando se pensa
que, dados o tamanho e a complexidade de um sistema, h inmeras
oportunidades de um defeito ocorrer.
Diferente dos grficos apresentados anteriormente, os quais possuem dois
grficos para representar os dados, o grfico C representa os dados em apenas um.
O mesmo ocorre com os grficos U e Z, que sero apresentados adiante.
Clculo dos limites:
Onde:
UCL c = c + 3 c
CL c = c
c=
nmero total de defeitos

nmero de observaes
LCL c = c 3 c
115
Exemplo: Suponha que um gerente de projetos de software deseje analisar

a quantidade de erros no sistema reportados pelo cliente diariamente. Os dados
obtidos pelo gerente so apresentados na Tabela 5.13.
Tabela 5.13 Nmero de erros no sistema reportados pelo cliente diariamente.
Dia
Nmero de erros
Para construir o grfico, o primeiro passo calcular o limite central. Assim,

c=
nmero total de defeitos 1 + 2 + 1 + 3 + 0 + 2 + 2 + 1 + 3

=
= 1,67 .
nmero de observaes
9
O prximo passo calcular os limites de controle.

UCL c = c + 3 c = 1,67 + 3,88 = 5,55
NPL c = c 3 c = 1,67 3,88 = 2,21
Construindo o grfico, tem-se:
Figura 5.17 C Chart para nmero de erros reportados pelo cliente.
Analisando-se o grfico, percebe-se que o processo estvel. Como o limite

de controle inferior um nmero negativo e, para nmero de erros, isso no
possvel, considera-se 0 (zero) como valor para o limite de controle inferior.
b) Grfico U (U Chart)
Esse tipo de grfico similar ao grfico C, mas considera que os eventos
podem ser medidos em reas de observao diferentes. Por exemplo, para analisar
a quantidade de defeitos detectados em pores de cdigo de tamanhos diferentes,
o grfico C no pode ser utilizado, pois a rea de observao no constante, uma
116
vez que os tamanhos das pores de cdigo analisadas so diferentes. Em

situaes como essa, o grfico U pode ser aplicado.
No grfico U, antes de ser realizada a comparao entre os valores
coletados, eles devem ser transformados em taxas como, por exemplo, nmero de
defeitos por KSLOC.
Assim como no grfico C, para utilizar o grfico U, a ocorrncia de defeitos
na rea de observao considerada deve ser relativamente baixa quando
comparada com as oportunidades de ocorrncia de defeitos nessa rea.
A identificao dos valores no grfico realizada como nos demais grficos
anteriormente apresentados, porm, para o grfico U os limites de controle
superior e inferior so calculados para cada observao. Isso pode parecer
estranho a princpio, mas justifica-se no fato de que cada observao feita em
uma rea de observao diferente, com caractersticas prprias. Por exemplo, ao
se analisar os defeitos detectados em diferentes mdulos, deve-se considerar que
cada mdulo tem sua prpria complexidade e pode ter sido desenvolvido por
diferentes equipes.
Clculo dos limites:
Onde:
UCL u = u + 3
u
ai
CL u = c
LCL u = u 3
u
ai
u=
c
a
, com i variando de 1 a k
ci = valor da i-sima observao

ai = tamanho da i-sima rea de observao
Exemplo: Suponha que um gerente deseje acompanhar a quantidade de

defeitos detectados nas inspees realizadas em um sistema. As inspees so
realizadas por caso de uso do sistema. As pores de cdigo referentes aos casos
de uso possuem tamanhos diferentes, assim, o tamanho do cdigo do caso de uso
deve ser utilizado para normalizar as medidas de defeitos, obtendo-se a taxa de
defeitos por KSLOC em cada caso de uso implementado, o que permitir a anlise
dos dados. Os dados utilizados pelo gerente so apresentados na Tabela 5.14.
117
Tabela 5.14 Dados das inspees de cdigo de casos de uso implementados.

Caso de Uso
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
N de defeitos
28
12
5
9
13
6
3
6
18
12
9
9
3
12
12
4
18
9
4
4
Tamanho do Cdigo (SLOC)

645
570
201
553
654
247
168
493
750
486
586
519
187
754
375
468
628
604
225
468
Defeitos/KSLOC
43,41
21,05
22,39
16,27
19,88
24,29
17,86
12,17
24,00
24,69
15,36
17,34
16,04
15,92
32,00
8,55
28,66
14,90
17,78
8,55
Total
196
9581
O primeiro passo para a elaborao do grfico, calcular o limite central.

Aplicando-se
u=
u=
c
a
com
variando
de
20,
obtm-se
196
= 20,46 defeitos/K SLOC .
9,581
Os limites de controle superior e inferior devem ser calculados para cada

ponto, individualmente. Por exemplo, para o primeiro ponto tem-se:
UCL u = u + 3
u
20,46
= 20,46 + 3
= 37,36
ai
0,645
LCL u = u 3
u
20,46
= 20,46 3
= 3,56
ai
0,645
O mesmo deve ser feito para os demais pontos. Aps determinados os

limites de todos os pontos, constri-se o grfico, como mostra a Figura 5.20.
Na Figura 5.18 possvel observar que o primeiro ponto registrado
encontra-se fora dos limites de controle, indicando instabilidade no processo de
inspeo, cuja causa especial deve ser investigada.
118
Figura 5.18 Grfico U para taxa de defeitos detectados na implementao de casos de uso.
c) Grfico Z (Z Chart)
Esse tipo de grfico utilizado para converter os valores de um grfico U
para a escala baseada no desvio padro (). Em algumas situaes, essa converso
pode facilitar a visualizao de tendncias instabilidade no comportamento do
processo.
Equaes para converso:
sigma u i =
Zi =
u
ai
ui u
sigma u i
Com a converso, os valores so obtidos em unidades sigma, assim, os

limites de controle so dados pelos valores zero, para o limite central, e 3 e 3,
para os limites superior e inferior, respectivamente.
Exemplo: Para construir o grfico Z para o exemplo apresentado no grfico U,
preciso aplicar
a frmula Z i =
ui u
a cada taxa de defeitos/KSLOC, para
sigma u i
converter as taxas U em taxas Z.

Para a primeira taxa de defeitos/KSLOC, representada na primeira linha da
ltima coluna da Tabela 5.14, cujo valor u1 = 43,41, tem-se:
Clculo do valor de sigma u para u1: sigma u i =
u
20,46
=
= 5,63
ai
0,645
119
Clculo do valor de Z para u1: Z i =
ui u
43,41 20,46
=
= 4,08
sigma u i
5,63
Repetindo-se esse procedimento para os demais 19 casos de uso, sero

obtidas as taxas de defeitos/KSLOC, normalizadas em unidades sigma.
A Figura 5.19 ilustra o grfico Z para o exemplo, mostrando a causa
assinalvel acima do limite de controle superior 3. Nesse exemplo, apenas uma
causa assinalvel foi identificada, assim como sua representao no grfico U. No
entanto, quando h grande variao entre os valores das observaes, o grfico Z
mostra-se mais eficiente na deteco de causas especiais do que o grfico U.
Figura 5.19 Grfico Z para defeitos/KSLOC por caso de uso implementado.
Conforme dito anteriormente, os grficos XmR e XMmR tambm so

aplicveis a dados de atributos. Esses grficos poderiam ser utilizados nos
exemplos apresentados para os grficos C e U. Nesses casos, os resultados obtidos
seriam, praticamente, os mesmos.

Com tantos tipos de grficos de controle disponveis, diante de uma
situao, preciso analisar o tipo de dados que est sendo tratado e o contexto em
que a situao est inserida para determinar o tipo de grfico de controle mais
adequado. Vale ressaltar que algumas situaes permitiro o uso de mais de um
tipo de grfico. Em caso de dvidas ou de resultados questionveis, sempre que
possvel, deve-se aplicar mais de um tipo de grfico e comparar os resultados.
Na Tabela 5.15 apresentado um resumo dos oito tipos de grficos de
controle apresentados neste captulo.
120
Tabela 5.15 Tipos de grficos de controle (adaptado de [BARCELLOS, 2009c]).

Tipo de
Grfico de
Controle
Caractersticas
Exemplo de situao onde se

aplica
Para Dados de Variveis
X-bar e R
Adequado para analisar o comportamento do

processo atravs de subagrupamentos de
medidas obtidas, basicamente, sob as
mesmas condies, em determinados
perodos de tempo. O grfico X-bar (average)
analisa a mdia dos valores em cada
subagrupamento e o grfico R (range) indica
a variao interna dos subgrupos. Se limita a
subgrupos formados por at 10 observaes.
X-bar e S
Aplicado nas mesmas situaes que XbarR,

mas tambm considera subgrupos com mais
de 10 observaes.
XmR
Adequado para analisar o comportamento de

um processo quando uma mesma medida
coletada frequentemente. Nesse tipo de
grfico de controle o grfico X representa os
valores individuais das medidas analisadas e
o grfico mX (moving range) representa a
variao mvel existente entre dois valores
consecutivos.
XMmR
Similar ao XmR, porm para analisar as

variaes utilizada a mediana (XmR usa a
mdia), que pode ser mais sensvel s causas
assinalveis, principalmente quando a
variao mvel (moving range) possui alguns
valores que podem elevar ou diminuir os
limites desnecessariamente.
mXmR
Segue a mesma filosofia dos grficos XmR e

XMmR, porm, alm de considerar a variao
mvel (moving range), considera a mdia
mvel (moving average). adequado para
avaliar as tendncias do comportamento dos
processos ao longo do tempo, considerando
valores acumulados.
Um gerente deseja analisar a

quantidade de horas semanais que
so dedicadas em atividades de
manuteno. As horas de trabalho
com manuteno so registradas
diariamente. Para uma anlise
semanal, os dados devem ser
subagrupados por semana. Cada
subgrupo tem 5 observaes (uma
para cada dia da semana).
Um gerente deseja analisar a taxa de
inspeo de cdigo das releases de
um de seus produtos. O produto tem
5 releases e em cada uma delas
foram realizadas 13 inspees.
Como a anlise desejada por
release, os dados devem formar 5
subgrupos de 13 observaes.
Um gerente deseja analisar o esforo
dirio despendido com manuteno
no ltimo ms. Os dados do esforo
so registrados diariamente. Nesse
caso, o gerente deseja analisar uma
nica varivel (esforo) medida
frequentemente, sem necessidade
de criar subgrupos.
Um gerente deseja analisar o esforo
dirio despendido com manuteno
no ltimo ms e observa que, entre
os valores coletados, h trs que
destoam consideravelmente de seus
antecessores.
Um gerente de projetos de software
deseja analisar o progresso do
desenvolvimento das unidades de
um software. Para isso,
mensalmente, devem ser
consideradas, acumuladamente, as
unidades que foram concludas
desde o incio do projeto at o
momento atual.
121
Tipo de
Grfico de
Controle
Caractersticas
Exemplo de situao onde se

aplica
Para Dados de Atributos
C Chart
U Chart
Z Chart
XmR e
XMmR
Adequado para representar a contagem de

eventos em reas de observao constantes.
Adequado para representar a contagem de
eventos que podem ser medidos em reas de
observao diferentes. Por esse motivo, os
limites de controle superior e inferior so
calculados para cada observao. Antes de
ser realizada a comparao entre os valores
coletados, eles devem ser transformados em
taxas.
Converte os valores de um U Chart para a
escala baseada em sigma. adequado para
visualizar tendncias instabilidade no
comportamento do processo por ser mais
sensvel quando h grandes diferenas entre
os valores das observaes.

deseja analisar a quantidade de
falhas de um determinado software
registradas diariamente.
deseja analisar a quantidade de
defeitos encontrados por mdulo
em um determinado software, sendo
que cada mdulo tem um tamanho
diferente.
Idem U Chart.
Idem XmR e XMmR para dados variveis, porm, aplicados a dados atribudos.
122
Captulo 6
Controle Estatstico de Processos e a Gerncia
Quantitativa de Projetos na Prtica
6.1 Introduo
Nos captulos 4 e 5 foi apresentado o conhecimento bsico necessrio para
realizar o controle estatstico de processos. Para que uma organizao inicie, de
fato, o controle estatstico de seus processos, necessrio que os subprocessos que
sero submetidos ao controle estatstico tenham sido selecionados, que a base de
medidas seja adequada para armazenar e fornecer os dados necessrios ao
controle estatstico, que as medidas e seus dados sejam adequados ao controle
estatstico de processos e que a organizao tenha o conhecimento necessrio para
representar e analisar os dados coletados.
O controle estatstico de processos realizado em dois nveis: no nvel
organizacional e no nvel dos projetos. No nvel organizacional, o desempenho dos
processos analisado considerando dados coletados em diversos projetos da
organizao e, uma vez estabilizado, o desempenho esperado para o processo
estabelecido. No nvel dos projetos, o comportamento dos processos analisado no
contexto de cada projeto, verificando-se se o desempenho do processo no projeto
aderente ao desempenho estabelecido no mbito organizacional.
Neste captulo sero tratados aspectos da execuo propriamente dita do
controle estatstico de processos no contexto da melhoria de processos de
software. Na seo 6.2 abordada a determinao das baselines de desempenho,
que descrevem os limites de desempenho dos processos estveis. Na seo 6.3
mostra-se como calcular a capacidade dos processos. Na seo 6.4 discutida a
obteno de modelos de desempenho de processo. Na seo 6.5 so abordadas a
gerncia estatstica de processos e a gerncia quantitativa dos projetos. Na seo
6.6 discute-se a realizao de melhorias em processos estveis e capazes e,
finalmente, na seo 6.7 so feitas as ltimas consideraes do captulo.
123
6.2 Definio das Baselines de Desempenho

Conforme apresentado no Captulo 4, um processo estvel um processo
repetvel e, com isso, pode ter seu desempenho previsto. Quando um processo
torna-se estvel, uma baseline que caracteriza seu comportamento atual pode ser
definida. Esse comportamento descreve o desempenho com o qual as prximas
execues do processo sero comparadas, pois o desempenho que se espera que
o processo apresente quando executado.
A baseline de um processo estvel descrita por meio de seus limites de
controle. Assim, uma vez que o comportamento de um processo seja analisado por
meio de grficos de controle e se mostre estvel, os limites de controle calculados e
representados no grfico caracterizam a baseline de desempenho daquele
processo. Essa baseline deve ser associada definio do processo para a qual foi
estabelecida e s medies que foram consideradas no clculo dos limites. Em
outras palavras, para cada baseline deve ser possvel identificar a definio do
processo e as medies consideradas para estabelec-la. Assim, apesar de,
usualmente, a baseline ser referenciada apenas como os valores dos limites de
controle, deve ficar subentendido que, na verdade, ela definida pelos limites de
controle, pela definio do processo e pelas medies que geraram a distribuio
que resultou nos valores calculados.
Apesar de ser possvel utilizar grficos de controle para verificar a presena
de causas especiais em um conjunto de dados que tenham a partir de trs
observaes [FLORAC e CARLETON, 1999], para estabelecer a primeira baseline de
um processo, desejvel que seja utilizado um volume razovel de dados coletados
em execues do processo. Segundo FLORAC e CARLETON (1999), para medidas
que dizem respeito a subgrupos, desejvel que haja de 25 a 30 subgrupos.
Segundo WHELLER [WHELLER, 1997 apud WELLER e CARD, 2008], 15 subgrupos
so suficientes. Para medidas que consideram valores individuais, desejvel que
haja de 40 a 45 observaes [FLORAC e CARLETON, 1999].
Considerando que o volume de dados requerido para estabelecer uma
baseline relativamente alto, comum que no incio sejam estabelecidas baselines
a partir de um volume menor de dados (usualmente, a partir de 20 observaes,
embora possam ser utilizados menos valores). Essas baselines so ditas trial
124
baselines, pois, uma vez que consideram menos dados do que o volume
estatisticamente recomendado, h risco de que no representem fielmente o
comportamento do processo.
Suponha que um gerente deseje realizar a anlise do comportamento do
processo Levantamento de Requisitos utilizando a medida taxa de alterao de
requisitos, dada pela razo entre o nmero de requisitos alterados e o nmero de
requisitos aprovados para o projeto. Para analisar o comportamento desse
processo, o gerente selecionou dados coletados em diversos projetos com as
mesmas caractersticas e os representou em um grfico de controle, como mostra a
Figura 6.1.
Figura 6.1 Comportamento do processo Levantamento de Requisitos descrito pela medida taxa de
alterao de requisitos.
Observando-se o grfico, nota-se que o processo Levantamento de

Requisitos, quando analisado pela medida taxa de alterao de requisitos, apresenta
comportamento estvel. Assim, uma baseline de desempenho pode ser
estabelecida, sendo caracterizada pelos valores 0,04 e 0,60. Isso significa que se
espera que a execuo do processo Levantamento de Requisitos nos projetos,
resulte em uma taxa de alterao de requisitos que estar entre 0,04 e 0,60.
6.2.1 Atualizao de Baselines de Desempenho

Ao longo do tempo, as baselines estabelecidas para os processos devem ser
atualizadas, considerando novos dados das execues dos processos nos projetos.
Mas, nem sempre que novos dados so coletados, a baseline deve ser revista.
125
A primeira condio para atualizar uma baseline que tenha sido coletado
volume suficiente de dados. Segundo WHEELER e CHAMBERS [2010] no h um
valor exato para esse volume, embora sugira-se pelo menos oito novos dados da
execuo dos processos. Alm disso, necessrio que os novos dados indiquem
que houve mudana no comportamento do processo.
Por exemplo, suponha que tenham sido coletados oito novos dados para o
processo Levantamento de Requisitos do exemplo anterior. Esses dados foram
plotados juntamente com os demais e so mostrados no grfico da Figura 6.2
(observaes 21 a 28).
Figura 6.2 Incluso de novos valores para a medida taxa de alterao de requisitos.
No grfico da Figura 6.2, os limites de controle foram calculados utilizando

os dados de todas as observaes. Note que os valores desses limites (0,04 e 0,61)
praticamente no diferem dos valores dos limites da baseline de desempenho (0,04
e 0,60) e que a distribuio dos novos dados consistente com a distribuio dos
dados iniciais. Isso indica que o processo continua se comportando segundo o
desempenho descrito pela baseline e que ela no deve ser alterada.
Suponha, agora, que com as vrias execues do processo de levantamento
de requisitos nos projetos, os membros das equipes tenham acumulado
conhecimento inerente s suas atividades e, com o passar do tempo, a taxa de
alterao de requisitos nos projetos tenha diminudo. Na Figura 6.3 apresentado
um grfico incluindo oito novos dados (observaes 29 a 36). Os limites de
126
controle apresentados foram calculados considerando todos os dados presentes no

grfico.
Figura 6.3 Reduo na taxa de alterao de requisitos nas ltimas oito observaes.
Apesar de no ter havido mudana significativa nos valores dos limites de

controle (0 e 0,60), quando comparados com os limites da baseline (0,04 e 0,60), a
mudana no comportamento do processo nas ltimas oito observaes
perceptvel.
Nesse caso, esses valores podem ser utilizados para atualizar a
baseline do processo.
Cabe aqui uma ressalva: apesar de oito pontos serem considerados
suficientes para que seja feita uma reviso da baseline, necessria uma anlise do
contexto em que esses valores foram coletados para que seja possvel identificar
se, realmente, o desempenho do processo mudou ou se o processo apresenta
mltiplas variaes12. Como no exemplo foi dito que houve melhoria de
desempenho devido ao conhecimento acumulado pela equipe, uma nova baseline
pode ser estabelecida. Caso o gerente ainda no esteja seguro de que o
desempenho do processo realmente mudou, ele pode aguardar o registro de novos
dados para, s ento, recalcular os limites da baseline.
A Figura 6.4 apresenta o grfico de controle para os valores das oito
ltimas observaes do grfico da Figura 6.3.
De acordo com o novo comportamento do processo, os limites da nova
baseline de desempenho so 0 e 0,31. Embora no grfico o limite inferior (-0,01)
12
Processos com mltiplas variaes sero tratados na seo 6.2.2.
127
esteja representado, assume-se que o limite inferior da baseline zero, uma vez
que a taxa de alterao de requisitos sempre um nmero positivo.
Figura 6.4 Novo comportamento do processo.
6.2.2 Um Processo, Vrias Baselines

Um mesmo processo pode apresentar comportamentos diferentes
dependendo do contexto em que executado. Por exemplo, o processo
Planejamento de Projeto pode ter desempenhos diferentes quando executado em
projetos de tamanhos diferentes. Dessa forma, um mesmo processo pode ter mais
de uma baseline, cada uma caracterizando o desempenho do processo em um dado
contexto.
Suponha que um gerente esteja analisando o comportamento do processo
Inspeo utilizando a medida KSLOC/hora de preparao para inspeo, coletada
para cada componente inspecionado. O gerente representou em um grfico de
controle os dados coletados para os ltimos 34 componentes inspecionados
(Figura 6.5). O grfico de controle revelou comportamento instvel e o gerente
notou que os valores coletados para os componentes 13 a 22 apresentavam
comportamento diferente dos demais.
Ao investigar as causas do comportamento irregular, o gerente descobriu
que os componentes 13 a 22 tinham tamanho superior a 10 KSLOC, enquanto que
os demais componentes no ultrapassavam esse tamanho. Assim, o gerente decidiu
separar os dados e construir dois grficos de controle distintos, um para os
componentes de at 10 KSLOC e outro para os componentes maiores que 10
KSLOC. Esses grficos so apresentados nas Figuras 5.6 e 5.7, respectivamente.
128
Figura 6.5 Comportamento do processo Inspeo segundo a medida KSLOC/hora de preparao

para inspeo.
Figura 6.6 Comportamento do processo Inspeo em componentes de at 10 KSLOC.
Figura 6.7 Comportamento do processo Inspeo em componentes maiores que 10 KSLOC.
129
O comportamento do processo em ambos os casos mostrou-se estvel,

levando percepo de que o processo Inspeo comporta-se de maneira
diferente, quando analisado pela medida KSLOC/hora de preparao para
inspeo, dependendo do tamanho do componente inspecionado. Dessa forma,
duas baselines devem ser estabelecidas para o processo, uma para cada faixa de
tamanho de componente.
6.2.3 Nova Definio de Processo, Nova Baseline

Como dito no incio desta seo, quando se estabelece uma baseline, ela
deve estar associada a uma definio de um processo. A definio de um processo
inclui as atividades e subatividades que o compem, os papis requeridos, os
recursos necessrios, os artefatos requeridos (insumos) e produzidos (produtos) e
os procedimentos (mtodos, tcnicas e roteiros) a serem adotados [FALBO, 2005].
Quando a definio do processo muda, seu comportamento tende a mudar. Assim,
quando a definio do processo alterada, o comportamento do processo deve ser
novamente analisado para verificar se uma nova baseline deve ser estabelecida.
Normalmente, pequenas mudanas na definio de um processo, como,
por exemplo, a mudana do layout de um dos artefatos produzidos ou a alterao
da ordem de algumas atividades, no provocam mudanas significativas em seu
comportamento. Nesses casos a baseline inicialmente estabelecida pode ser
mantida. Porm, mudanas mais expressivas, como a alterao de uma tcnica
utilizada
ou
incluso
de
um
novo
procedimento,
podem
alterar
significativamente o comportamento do processo, exigindo o estabelecimento de

novas baselines.
Suponha que em uma organizao de software, para planejar os projetos,
as estimativas sejam realizadas pelos gerentes com base em seu conhecimento e
experincia. Com o objetivo de analisar o comportamento do processo
Planejamento do Projeto, o gerente da rea de projetos representou em um grfico
de controle dados coletados para a medida aderncia ao cronograma. O
comportamento do processo mostrou-se estvel, tendo sido estabelecida a baseline
de desempenho do processo, cujos limites foram dados pelos valores 0,3 e 1,1,
como mostra a Figura 6.8.
130
Figura 6.8 Aderncia ao cronograma na primeira definio do processo Planejamento do Projeto.
Suponha, agora, que a organizao tenha decidido adotar anlise de

pontos por funo para estimar o tamanho dos projetos e utiliz-lo com base para
estimar prazos e custos. No tendo se atentado para a mudana na definio do
processo, o gerente da rea de software plotou todos os dados coletados nas
execues da nova definio do processo no mesmo grfico que os dados coletados
na definio de processo anterior. O grfico obtido apresentado na Figura 6.9.
Figura 6.9 Mudana no comportamento devido mudana na definio do processo Planejamento

do Projeto.
Observando o grfico, o gerente percebeu a mudana no comportamento

do processo e, ao buscar suas causas, notou que a mudana se deu a partir do uso
da segunda definio do processo. Assim, o gerente selecionou os dados referentes
quela definio e os representou em um novo grfico de controle (Figura 6.10),
131
tendo sido estabelecida uma baseline, diferente da baseline da primeira definio

do processo.
Figura 6.10 Aderncia ao Cronograma na segunda definio do processo Planejamento do Projeto.
Note que os valores dos limites das baselines calculadas nos grficos das
Figuras 5.8, 5.9 e 5.10 so diferentes, especialmente, os limites inferiores. Uma vez
que a baseline de um processo descreve o desempenho que se espera em suas
execues, caso o gerente no estabelecesse uma baseline para cada definio do
processo, o desempenho que seria esperado para as prximas execues do
processo (dado pelos limites 0,48 e 1,03) no seria condizente com seu
desempenho real (dado pelos limites 0,62 e 1,0).
6.3 Determinao da Capacidade

Conforme
discutido no Captulo 4, processos estveis no so,
necessariamente, bons processos. A estabilidade apenas indica que o processo

repetvel, no se incumbindo de diferenciar se o que est se repetindo um bom
ou mau desempenho. Para analisar se o desempenho de um processo bom ou
no, a partir do momento que o processo torna-se estvel, necessrio verificar se
ele capaz.
Um processo dito capaz se seu desempenho atende ou excede s
expectativas da organizao e do cliente, ou seja, se seu desempenho permite
alcanar os objetivos tcnicos e de negcio para ele estabelecidos. O desempenho
do processo, indicado por sua baseline de desempenho, a voz do processo, e o
132
desempenho desejado para o processo, especificado pela organizao com base em

seus objetivos, a voz do cliente.
Uma maneira simples de analisar a capacidade de um processo estvel
utilizar um histograma de frequncia que represente os valores coletados para o
processo durante um perodo de estabilidade. No histograma devem ser
representados os limites de controle da baseline do processo, para caracterizar seu
desempenho e representar a voz do processo. Tambm devem ser representados
os limites de especificao, que identificam os valores que se deseja que o processo
alcance, representando a voz do cliente.
Representados os limites da baseline e de especificao, possvel visualizar
a relao entre eles. Limites da baseline completamente dentro dos limites de
especificao indicam um processo capaz. O contrrio indica que o processo no
capaz de alcanar o desempenho esperado. A Figura 6.11 ilustra o layout bsico do
histograma para anlise de capacidade de processo. Na figura, USL e LSL indicam,
respectivamente, os limites de especificao superior (Upper Specification Limit) e
inferior (Lower Specification Limit), que caracterizam a voz do cliente.
Figura 6.11 - Layout de histograma refletindo a capacidade de processo.
Para exemplificar, considere a seguinte situao: o gerente da rea de

desenvolvimento de software de uma organizao analisou o comportamento do
processo Resoluo de Problemas utilizando a medida tempo mdio para resoluo
133
de problema, que mede semanalmente o tempo mdio decorrido entre o registro

de um problema e sua soluo. Os dados coletados (listados na Tabela 6.1) foram
plotados em um grfico de controle (Figura 6.12), que mostrou que o processo
estvel, tendo sido estabelecida uma baseline de desempenho, caracterizada pelos
valores dos limites de controle.
Tabela 6.1 Tempo mdio (em horas) para resoluo de problema.
Semana
TMRP
10 11
12
13 14
15
16 17 18 19 20
10,1 8,7 9,1 8,0 8,6 8,9 9,0 8,6 8,0 7,9 9,8 10,2 8,9 8,6 10,3 9,3 9,0 9,6 9,1 8,8
Figura 6.12 Grfico de controle para tempo mdio para resoluo de problema.
Suponha, agora, que a organizao tenha estabelecido que o tempo mdio

de resoluo de problema deve ser de, no mximo, 12 horas. Alm disso, o tempo
mnimo no pode ser menor que 4 horas, visto que, por mais simples que seja o
problema, a soluo adotada deve passar por avaliao de qualidade. Para analisar
a capacidade de o processo alcanar esse objetivo, o gerente construiu um
histograma para os dados coletados e representou os limites da baseline de
desempenho do processo (voz do processo), bem como os limites de especificao
(voz do cliente). O histograma construdo apresentado na Figura 6.13.
Analisando-se o histograma possvel perceber que o processo capaz,
uma vez que seus limites esto dentro dos limites de especificao estabelecidos.
134
Figura 6.13 Histograma de capacidade do processo Resoluo de Problemas.
O uso do histograma para analisar a capacidade facilita a visualizao da

distribuio dos dados. Em situaes onde o comportamento do processo no
tenha sido analisado anteriormente em um grfico de controle, o histograma
tambm permite verificar se o processo estvel. Mas, vale reforar que os grficos
de controle so mais apropriados para esse fim.
Tambm possvel utilizar os grficos de controle para analisar
graficamente a capacidade do processo. Para isso, os limites de especificao do
processo devem ser adicionados, como mostra a Figura 6.14.
Figura 6.14 Grfico de controle com limites de controle e de especificao representados.
A utilizao do histograma ou do grfico de controle permite uma anlise

visual da capacidade dos processos. Mas, possvel quantific-la. Para isso, pode
135
ser utilizado o ndice de capacidade (Cp), dado pela razo entre as amplitudes dos
limites de especificao e limites da baseline do processo. Assim: C p =
USL LSL
.
UCL LCL
Quando os limites de especificao tm amplitude maior que os limites

naturais, Cp maior que 1, indicando que o processo capaz. Em contrapartida, Cp
ser menor que 1 quando os limites de especificao tiverem amplitude menor que
os limites naturais, indicando que o processo no capaz.
Para o exemplo das Figuras 6.13 e 6.14, tem-se:
Cp =
USL LSL
12 4
=
= 2,16.
UCL LCL 10,9 7,2
Apesar de ser possvel calcular o ndice de capacidade de um processo sem

representar seu histograma, tal ao no recomendada, pois pode-se obter um
ndice de capacidade maior que 1 e, ainda assim, o processo no ser capaz. No
exemplo, se os limites de especificao fossem 6 e 10, Cp continuaria sendo maior
que 1 (Cp = 1,08) , porm, ao representar os limites em um histograma, fica visvel
que parte do comportamento do processo se encontra acima do limite de
especificao superior, conforme mostra a Figura 6.15.
Figura 6.15 Histograma para processo com Cp > 1 e no capaz.
Algumas abordagens de qualidade como, por exemplo, o Six Sigma [SIVIY et

al., 2005], incluem a anlise visual e utilizam Cp 2 para gerar maior confiana de
que o desempenho especificado ser atendido.
136
6.4 Obteno de Modelos de Desempenho

Com base nos dados utilizados para estabelecer as baselines de desempenho
dos processos, modelos de desempenho podem ser definidos para determinar
relaes quantitativas entre atributos dos processos, ou seja, entre medidas.
O objetivo dos modelos de desempenho permitir a previso de
desempenho futuro dos processos a partir das relaes existentes entre seus
atributos. Assim, modelos de desempenho so utilizados principalmente nas
estimativas que servem de base para o planejamento e na monitorao dos
projetos [SOFTEX, 2011c].
Modelos de desempenho envolvem variveis independentes e dependentes.
As variveis dependentes, como o prprio nome diz, tm seus valores alterados
dependendo do valor da varivel independente. Por exemplo, o valor do esforo
despendido em um projeto depende do tamanho do projeto. Nesse caso, tamanho
varivel independente e esforo varivel dependente.
No contexto do controle estatstico de processos, modelos de desempenho
so estabelecidos apenas para processos estveis, pois, para estabelecer relaes
quantitativas entre medidas, elas devem apresentar comportamento repetvel.
Assim, uma vez estabelecidas baselines para os processos, modelos de desempenho
podem ser obtidos. Quando novos dados so coletados, os modelos de desempenho
podem ser revistos. Caso os novos dados levem definio de novas baselines, um
novo modelo de desempenho deve ser estabelecido.
Como exemplo13, suponha que em uma organizao o gerente de projetos
deseje identificar a relao existente entre o tamanho dos casos de uso e o esforo
despendido em sua especificao. Considere que o processo Desenvolvimento de
Requisitos estvel quando analisado pela medida produtividade de especificao
de caso de uso, que mede o esforo para especificar um ponto de caso de uso. Os
dados que foram considerados para estabelecer a baseline do processo
Desenvolvimento de Requisitos so apresentados na Tabela 6.2
Tabela 6.2 Esforo para especificao de caso de uso e tamanho dos casos de uso .
Caso de Uso 1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20
Esforo
31,8 28,6 37,3 30,8 40,4 33,5 37,3 43,1 32,3 37,1 33,8 33,5 34,5 33,0 38,4 33,6 40,1 32,3 42,6 35,6
Tamanho
13 12 14 12 16 14 14 15 12 15 12 14 15 12 15 14 15 12 16 13
13
Adaptado de [CAMPOS et al., 2007].
137
Para obter o modelo de desempenho, os dados devem ser utilizados em uma

ferramenta estatstica que avalie se h relao entre eles e se possvel
represent-la por meio de uma funo matemtica. Grficos Scatter so adequados
para esse propsito. Na Figura 5.16 apresentado o grfico Scatter para os dados
da Tabela 6.2. A funo matemtica que representa o modelo de desempenho que
quantifica a relao entre as medidas esforo de especificao e tamanho do caso
de uso dada por Esforo = 2,32*Tamanho + 3,572.
Figura 6.16 Modelo de desempenho relacionando esforo de especificao e tamanho de caso de

uso.
6.5 Gerncia Estatstica de Processos e Gerncia Quantitativa de

Projetos
No contexto da melhoria de processos de software, o controle estatstico de
processos realizado nos mbitos organizacional e dos projetos. No nvel
organizacional ocorre a gerncia estatstica dos processos, ou seja, o desempenho
dos processos analisado para que seja possvel identificar o comportamento
esperado para os processos, quando forem executados nos projetos. Nesse nvel,
os dados coletados ao longo dos projetos so utilizados para descrever o
comportamento dos processos da organizao. Dados de diversos projetos que
tenham o mesmo perfil, ou seja, que sejam similares entre si, so agrupados e so
aplicados mtodos do controle estatstico para analisar o comportamento dos
processos e estabelecer baselines e modelos de desempenho.
138
A Figura 6.17 ilustra a utilizao de dados de projetos para iniciar a anlise

do comportamento dos processos e estabelecimento das primeiras baselines e
modelos de desempenho.
Figura 6.17 Iniciando a gerncia estatstica dos processos.
No nvel dos projetos ocorre a gerncia quantitativa dos projetos, que

consiste em gerenciar o desempenho dos processos nos projetos, utilizando as
baselines e modelos de desempenho estabelecidos no nvel organizacional. Assim,
em cada projeto, o desempenho dos processos no projeto comparado com o
desempenho para ele esperado e, caso no seja condizente, aes corretivas devem
ser realizadas. Ainda, o planejamento do projeto pode ser realizado utilizando os
modelos de desempenho definidos no nvel organizacional.
A Figura 6.18 ilustra a utilizao das baselines e modelos de desempenho
para gerenciar quantitativamente os projetos.
Figura 6.18 Uso de baselines e modelos de desempenho na gerncia quantitativa de projetos.
139
importante perceber que a relao entre a gerncia estatstica de

processos e a gerncia quantitativa de projetos constante e via de mo dupla, ou
seja, a gerncia estatstica de processos produz resultados que so utilizados como
insumos pela gerncia quantitativa de projetos e vice-versa. Se por um lado, as
baselines e modelos de desempenho definidas pela anlise de desempenho de
processos so utilizados na gerncia quantitativa dos projetos, esta, por sua vez,
fornece resultados atuais sobre o desempenho dos processos, atravs dos dados
coletados em cada projeto gerenciado quantitativamente, que se tornaro parte
dos dados para o refinamento das baselines e modelos de desempenho dos
processos organizacionais.
A Figura 6.19 ilustra o inter-relacionamento entre a gerncia estatstica de
processos e a gerncia quantitativa de projetos.
Figura 6.19 - Inter-relacionamento constante entre a gerncia estatstica de processos e a gerncia

quantitativa de projetos.
Como exemplo de aplicao da gerncia estatstica de processos e da

gerncia quantitativa de projetos, considere que uma organizao tenha
selecionado o processo de Testes para ser submetido ao controle estatstico de
processos e que uma das medidas selecionadas para descrever o comportamento
desse processo tenha sido taxa de deteco de defeitos, dada pelo nmero de
defeitos detectados por ponto de funo.
Para iniciar a gerncia estatstica dos processos, a organizao utilizou
dados coletados para essa medida em diversos projetos da organizao e os
representou em um grfico de controle (Figura 6.20).
140
Figura 6.20 Desempenho do processo Testes segundo a medida taxa de deteco de defeitos.
Conforme mostra o grfico da Figura 6.20, o processo Testes, quando

descrito pela medida taxa de deteco de defeitos estvel e os limites de controle
apresentados no grfico caracterizam a baseline de desempenho do processo.
Assim, espera-se que em um teste sejam detectados de 2,7 a 15,3 defeitos por
ponto de funo.
Essa primeira parte do exemplo, diz respeito ao que foi ilustrado na
Figura 6.17, ou seja, o uso de dados de projetos para estabelecer a baseline de
desempenho inicial para processo selecionado para o controle estatstico.
Suponha, agora, que um novo projeto esteja sendo iniciado na
organizao e que o processo de Testes faa parte do processo definido para esse
projeto. Para gerenciar o comportamento do processo nesse projeto, o gerente
realiza a gerncia quantitativa do projeto e verifica se o processo est se
comportando conforme esperado. Para isso, o gerente plota os dados da execuo
do processo em grficos de controle, usando os limites da baseline como limites de
controle para os dados.
Suponha, ainda, que na primeira execuo do processo no projeto, a taxa
de deteco de defeitos tenha sido 12, ou seja, o processo comportou-se como
esperado. Na segunda execuo, a taxa de deteco de defeitos foi 2, no
correspondendo ao desempenho esperado. Nesse caso, o gerente do projeto deve
investigar as causas dessa variao e trat-las. Na Figura 6.21 apresentado o
grfico com os dados da execuo do processo, tendo como limites de controle os
141
limites da baseline. Note que o valor da segunda observao est fora do limite de
controle inferior.
Figura 6.21 Dados do desempenho do processo Testes em um dado projeto.
Essa segunda parte do exemplo, diz respeito ao que foi ilustrado na

Figura 6.18, isto , o uso da baseline estabelecida na gerncia estatstica de
processos para gerenciar quantitativamente o projeto.
Resgatando uma discusso que foi realizada no incio do Captulo 4,
quando se falou sobre o poder do controle estatstico de processos, uma das
vantagens
destacadas
foi
possibilidade
de
se
perceber desvios
de
comportamento dos processos to logo ocorram. No exemplo apresentado, assim

que o comportamento do processo de Testes apresentou-se diferente do esperado,
o gerente pde identificar o desvio, propiciando a investigao de causas e
adequao do processo ainda durante o curso do projeto.
Alm disso, caso
existisse um modelo de desempenho relacionando a taxa de deteco de defeitos

nos testes com a taxa de defeitos escapados (defeitos detectados pelo cliente aps
receber o produto) e o gerente soubesse o esforo associado correo de um
defeito escapado, ele poderia prever os custos adicionais para o projeto por no se
ter uma taxa de deteco de defeitos adequada.
Por fim, considere que, alm do projeto citado anteriormente, outros dois
projetos tenham sido realizados na organizao e seus processos definidos tenham
includo o processo de Testes. Ao longo dos projetos, foram coletados novos dados
para a taxa de deteco de defeitos, que podem ser utilizados para refinar a
baseline de desempenho. A Figura 6.22 mostra a incluso dos novos valores
(observaes 21 a 26) ao conjunto de dados inicial.
142
Figura 6.22 Incluso de novos dados do processo de Testes.
Conforme discutido na seo 6.2, o refinamento da baseline de

desempenho a partir de novos dados realizado quando os limites de controle
encontrados considerando os novos dados diferem significativamente dos
anteriores ou quando os novos dados mostram alterao no comportamento do
processo. No exemplo, os limites resultantes praticamente no diferem dos limites
da baseline e sabe-se que no houve mudana no processo, ento no necessrio
refinar a baseline.
6.6 Melhoria do Desempenho de Processos Estveis e Capazes

O controle estatstico de processos apoia a melhoria dos processos atravs
da anlise de seu comportamento e identificao de aspectos que precisam ser
melhorados. Mas, importante ressaltar que utilizar o controle estatstico de
processos no pode ser uma ao isolada. desejvel que sua utilizao seja
realizada no contexto de um programa de melhoria de processos, caso contrrio,
seus resultados tendem a ser pontuais e passageiros.
Todos os processos so executados para produzir resultados. A percepo de
que um processo deve ser melhorado, usualmente, tem incio quando os
resultados por ele alcanados no atendem aos objetivos para ele estabelecidos.
No entanto, processos que produzem resultados condizentes com os objetivos
tambm podem ser melhorados, para que atinjam novos e melhores objetivos.
Logo, processos podem ser continuamente melhorados.
Quando se fala em melhoria contnua de processos baseada no controle
estatstico, deve-se atentar a cinco aspectos [FLORAC e CARLETON, 1999]:
143
a) Desempenho: para melhorar um processo preciso conhecer seu

desempenho, ou seja, preciso saber o que o processo est produzindo
no momento em relao a qualidade, quantidade, custos e tempo.
b) Estabilidade: conhecido o desempenho, preciso analisar se ele
previsvel, ou seja, se o processo estvel e, se no for, preciso
estabiliz-lo.
c) Conformidade: a estabilidade de um processo obtida quando seu
comportamento repetvel dentro de limites de variao estabelecidos.
Para isso, preciso garantir que o processo seja apoiado suficientemente
para que sua execuo possa ser repetida por membros distintos da
organizao. Tal apoio inclui, dentre outros, definio clara e completa
das atividades do processo e ferramental de suporte sua execuo.
d) Capacidade: um processo estvel no necessariamente capaz de
alcanar os objetivos para ele determinados. Processos no capazes
devem ser modificados atravs da realizao de aes de melhoria que
apoiem o alcance aos objetivos da organizao.
e) Melhoria: processos capazes, que produzem resultados satisfatrios,
podem, ainda, ser melhorados para que resultados ainda melhores sejam
produzidos.
Em linha com esses aspectos, que indicam que conhecer o desempenho dos
processos o primeiro passo para melhor-los, FLORAC e CARLETON (1999)
propuseram um framework para medio do comportamento de processos. Na
verdade, o framework proposto extrapola o que sugerido por seu nome, uma vez
que, alm de contemplar a medio do comportamento dos processos, inclui
passos que orientam melhoria contnua. Esse framework pode ser visto como um
ciclo para melhoria contnua baseada no controle estatstico de processos. O
framework ilustrado na Figura 6.23.
144
Figura 6.23 Framework para medio do comportamento de processos [FLORAC e

CARLETON, 1999].
Conforme dito anteriormente neste livro, o controle estatstico de

processos pode ser visto como uma evoluo do processo de medio.
Observando-se atentamente a Figura 6.23 possvel perceber a relao entre as
atividades do framework e o processo de medio. As atividades Entender os
objetivos de negcio, Identificar e priorizar questes e Selecionar e Definir medidas
correspondem ao planejamento da medio. As atividades Coletar, verificar e
armazenar dados e Analisar comportamento do processo correspondem execuo
da medio, ou seja, coleta e anlise dos dados. As demais atividades dizem
respeito melhoria de processo propriamente dita.
A seguir, as atividades do framework so sucintamente descritas.
145
a.
Entender os objetivos de negcio: consiste em entender como os objetivos

de negcio, metas, planos e estratgias da organizao se relacionam
com os processos de software. Ou seja, consiste na identificao das
relaes entre processos e objetivos organizacionais.
b.
Identificar e priorizar questes: consiste em identificar quais so as

necessidades de informao crticas para determinar se o processo ser
capaz de alcanar os objetivos de negcio estabelecidos.
Selecionar e definir medidas: consiste em selecionar e definir as medidas
c.
que sero utilizadas para caracterizar o desempenho dos processos.

d.
Coletar, verificar e armazenar dados: consiste em coletar os dados para

as medidas definidas, verificar se so corretos e armazen-los.
e.
Analisar o comportamento dos processos: consiste em utilizar os mtodos

estatsticos apropriados para representar em grficos de controle os
dados coletados para as medidas, permitindo, assim, a anlise do
comportamento do processo. A anlise do comportamento do processo
pode levar a trs direes:
Remover causas especiais: consiste em realizar aes para tratar as
causas especiais e tornar o comportamento do processo estvel.
Mudar o processo: consiste em realizar alteraes no processo,
tratando suas causas comuns, para que ele seja capaz de produzir os
resultados necessrios ao alcance dos objetivos.
Melhorar continuamente o processo: consiste em realizar aes que
levem o processo a produzir resultados cada vez melhores.
muito importante entender a natureza contnua da melhoria. Assim, uma
vez que os processos esto estveis e so capazes, o papel do controle estatstico

de processos no se encerra. Quando um processo torna-se capaz, um novo ciclo de
melhoria pode (e, normalmente, deve) ser iniciado, estabelecendo-se novos
objetivos para que o processo possa ser melhorado continuamente.
Muitas organizaes, conhecidas pela excelncia de seus programas de
qualidade, estabelecem limites de variao bastante estreitos para os processos e,
146
uma vez que estes so alcanados, a organizao obtm processos estveis,

capazes e com um grau de variabilidade consideravelmente baixo.
Quanto menor a variao dos processos, menores so as chances de desvios
entre os valores planejados e realizados nos projetos, ou seja, maior a aderncia
dos projetos aos cronogramas, oramentos e demais planejamentos estabelecidos.
Quando o processo alterado para tornar-se estvel, capaz ou para sofrer
uma melhoria contnua, estabelecida uma nova definio para o processo, a qual
deve ser executada nos projetos da organizao, para que novos dados sejam
coletados, o comportamento da nova definio do processo seja analisado e o ciclo
apresentado no framework se repita.
Exemplificando a execuo de um ciclo do framework, suponha que uma
organizao esteja recebendo reclamaes dos clientes sobre a demora para
resolver problemas por eles relatados. Com isso, um de seus objetivos de negcio
crticos melhorar o suporte aos clientes. Para monitorar esse objetivo, foi
identificada a necessidade de informao Qual a taxa de problemas reportados pelo
cliente no resolvidos? e foi selecionado o processo Manuteno, responsvel pela
correo de problemas nos sistemas de informao entregues aos clientes, para
ter seu comportamento analisado por meio da medida taxa de problemas no
resolvidos. Para anlise do comportamento foi elaborado o grfico de controle
apresentado na Figura 6.24, que revelou instabilidade no comportamento do
processo.
Figura 6.24 Processo de manuteno instvel.
147
Como o processo instvel, deve ser conduzida uma investigao das

causas dos pontos que se encontram fora dos limites de controle, que indicam o
comportamento esperado para o processo. Suponha que essa investigao tenha
sido conduzida, tendo sido percebido que nas semanas em que a taxa de
problemas no resolvidos extrapolou os limites esperados, ocorreu greve no
transporte pblico levando vrios funcionrios a faltarem o trabalho.
Considerando que essas causas no so inerentes ao processo, ou seja, no
h necessidade de mudar o processo para trat-las, esses pontos podem ser
excludos da anlise do comportamento do processo. Com isso, como mostra a
Figura 6.25, o comportamento do processo torna-se estvel.
Figura 6.25 Processo de manuteno estabilizado.
Uma vez estabilizado, a capacidade do processo deve ser analisada.

Suponha que a organizao tenha estabelecido que a taxa de problemas no
resolvidos no deve ultrapassar 0,25. Nesse caso, como mostra a Figura 6.26, o
processo no capaz. Na figura, o limite especificado para o processo (voz do
cliente) representado pela linha slida verde. A incapacidade do comportamento
do processo (voz do processo) atender o limite especificado bem visvel (limite
de controle superior maior que a meta estabelecida), no tendo, por esse motivo,
sido realizado o clculo do ndice de capacidade.
148
Figura 6.26 Processo de manuteno no capaz.
Buscando tornar o processo capaz, a organizao analisou a definio atual

do processo e decidiu realizar algumas alteraes para minimizar o tempo de
anlise da prioridade de um problema e melhorar a distribuio dos problemas
entre a equipe de execuo das manutenes. Aps essa alterao, o processo
entrou em execuo e foram coletados novos dados para a taxa de problemas no
resolvidos. A anlise do comportamento da nova definio do processo mostrou
que ele tornou-se capaz, como mostra a Figura 6.27.
Figura 6.27 Processo de manuteno capaz.
Suponha, agora, que a organizao, em uma ao de melhoria de um

processo estvel e capaz, tenha decidido diminuir ainda mais a taxa de problemas
no resolvidos, tendo estabelecido que ela no deva ultrapassar 0,20. Essa deciso
levou a mais uma alterao no processo, que passou a adotar alguns princpios do
desenvolvimento gil nas manutenes maiores. O processo entrou em execuo e
teve dados de sua execuo coletados. Como resultado, a anlise do
149
comportamento do processo mostrou que ele manteve-se capaz e com melhor

desempenho (limites mais estreitos), como mostra a Figura 6.28.
Figura 6.28 Processo de manuteno aps melhoria contnua: estvel, capaz e com melhor
desempenho (limites mais estreitos).
Vale destacar que alteraes nos processos podem levar desestabilizao.

Por exemplo, a ltima alterao realizada no processo de manuteno do exemplo
poderia ter resultado em instabilidade e incapacidade. Nesse caso, as causas
deveriam ser investigadas e o ciclo se repetiria.
6.6.1 Por onde comear

Mesmo sabendo como melhorar o desempenho dos processos utilizando o
controle estatstico, fica, ainda, uma questo: por onde comear?
Processos de software so consideravelmente distintos dos processos da
manufatura, onde o controle estatstico de processos teve origem. Implementar as
aes que levam melhoria dos processos de software envolve algumas
dificuldades inerentes a essa rea. Uma delas a dificuldade de no poder
experimentar uma melhoria antes de implement-la sem interferir, ou interferindo
o mnimo possvel, na rotina e produtividade da organizao.
Empresas que desenvolvem software raramente conseguem fazer
experincias de laboratrio para avaliar as propostas de melhoria antes da
implementao. Em diversas reas, para identificar se uma determinada proposta
de melhoria ser realmente efetiva, so realizadas experincias para garantir que,
ao ser implementada a melhoria, os resultados esperados sero obtidos. Por
exemplo, uma indstria de veculos faz testes em laboratrio antes de incluir um
150
novo dispositivo de segurana em seus automveis e disponibiliz-los para a

populao.
Considerando as particularidades do desenvolvimento de software, a fim de
reduzir os riscos e gerenciar consequncias inesperadas, as melhorias devem,
frequentemente, ser introduzidas por meio de projetos piloto, que permitem
avaliar os resultados das modificaes antes de implement-las em toda a
organizao.
A melhoria baseada no controle estatstico de processos tambm pode
seguir essa linha. Ou seja, uma vez identificadas as necessidades de melhoria para
um dado processo, ao invs de alterar o processo e utilizar sua nova definio em
todos os projetos correntes, pode ser selecionado um projeto piloto para utilizar a
nova definio do processo e fornecer resultados iniciais que permitiro decidir
pela implementao ou no da melhoria para a organizao como um todo.

Conhecer e controlar o comportamento dos processos de suma
importncia para as organizaes de software, pois os processos que elas utilizam
para produzir seus produtos e servios tm papel crtico na execuo de planos e
estratgias que buscam alcanar os objetivos organizacionais. Organizaes que
so capazes de controlar seus processos esto hbeis a prever a qualidade de seus
produtos e servios, custos, cronogramas e melhorar a eficincia, eficcia e
rentabilidade de suas operaes tcnicas e de negcios.
Controlar o desempenho dos processos garantir que os processos sejam
previsveis, atendam s necessidades dos clientes e possam ser melhorados
continuamente. Alm disso, garantir que haja estabilidade e que as tendncias
identificadas sejam vlidas para toda a organizao em todos os projetos.
O conhecimento e controle do comportamento dos processos tm incio em
atividades de medio. A medio capaz de fornecer as informaes necessrias
para alcanar os objetivos tcnicos e de negcio, identificando problemas e
tendncias, o que d o embasamento necessrio s tomadas de deciso,
principalmente quelas que dizem respeito melhoria de desempenho dos
processos.
151
No contexto da melhoria de processos de software, o controle estatstico de

processos ocorre nos nveis organizacional e dos projetos. No nvel organizacional
so estabelecidos baselines e modelos de desempenho dos processos, que so
utilizados, no nvel dos projetos, pela gerncia quantitativa, a qual analisa o
comportamento dos processos no projeto, verificando se esto em linha com as
baselines estabelecidas.
A melhoria de processos de software baseada no controle estatstico dos
processos um ciclo contnuo, no qual a anlise do comportamento dos processos
pode levar a trs direes: remover as causas assinalveis para tornar o processo
estvel; mudar o processo para que o mesmo seja capaz de atender os objetivos do
cliente e da organizao; e melhorar continuamente o processo, quando este
capaz.
A utilizao do controle estatstico de processos em organizaes de
software requer criteriosidade. Para as tarefas operacionais, h diversos
aplicativos disponveis no mercado que apoiam a construo dos grficos de
controle e a realizao dos clculos, a partir de um conjunto de dados de entrada.
Alguns exemplos desses aplicativos so o Minitab14 e o Excel (considerando a
utilizao de QI Macros15 para apoio ao controle estatstico de processos).
Mas, indispensvel entender que analisar o comportamento de um processo
no consiste apenas em colocar os dados coletados para as medidas em um aplicativo e,
simplesmente, obter os resultados desejados. Os aplicativos, sozinhos, no so capazes
de analisar o contexto dos dados utilizados. Essa uma tarefa que requer interveno
humana e conhecimento organizacional. A utilizao dos mtodos no apropriados ou
uma interpretao equivocada pode revelar um comportamento irreal para os processos
e, consequentemente, contribuir para a realizao de aes inadequadas e o
estabelecimento de metas no factveis.
14
15
http://www.minitab.com
http://www.qimacros.com/Macros.html
152
PARTE III
Medio e Melhoria de Processos de

Software
153
Captulo 7
Medidas para Monitorao dos Processos no
MR-MPS
7.1 Introduo
Modelos de maturidade, como o MR-MPS [SOFTEX, 2009a] e o CMMI [SEI,
2010], so cada vez mais utilizados por organizaes de software que objetivam
investir em qualidade de software. Esses modelos apresentam um conjunto de
boas prticas de Engenharia de Software organizadas em diferentes nveis de
maturidade, de forma a direcionar de maneira ordenada os esforos das
organizaes na melhoria de seus processos de software. Nveis de maturidade
estabelecem patamares de evoluo de processos, caracterizando estgios de
melhoria da implementao de processos na organizao. O nvel de maturidade
em que se encontra uma organizao permite prever o seu desempenho futuro ao
executar um ou mais processos [SEI, 2010].
Acredita-se que com o uso desses modelos de maturidade as organizaes
possam produzir softwares melhores, com menores custos, estimativas mais
precisas e maior satisfao das equipes e dos clientes. Como dito em captulos
anteriores, prticas de medio de software so um presena constante tanto no
MR-MPS como no CMMI desde seus nveis iniciais: no nvel F do MR-MPS h o
processo Medio e no nvel 2 do CMMI h a rea de processo Medio e Anlise.
No MR-MPS, conforme discutido no Captulo 2, o processo Medio
[SOFTEX, 2011a] pressupe que as organizaes definam medidas a partir de seus
objetivos organizacionais e as utilizem para tomada de deciso. Esse processo tem
um papel importante em implementaes de melhoria de processo de software por
estar por trs de aspectos importantes na evoluo aos nveis de maturidade
subsequentes que culminam nos nveis de alta maturidade (A e B). No entanto,
mesmo atendendo aos requisitos previstos pelos modelos, uma organizao pode
no atingir todo o potencial possvel. Implementaes deficientes desse processo
podem ter impacto indesejado no futuro e na continuidade dos programas de
melhoria das organizaes.
154
A medio pode ser utilizada como um importante instrumento para o

conhecimento do comportamento dos processos de software e tambm para a
monitorao da execuo desses processos. A partir do nvel F do MR-MPS devem
ser definidas medidas referentes a cada um dos processos implementados no nvel
de maturidade ao qual a organizao est aderente. Essa exigncia decorrente do
RAP 4 (Medidas so planejadas e coletadas para monitorao da execuo do
processo e ajustes so realizados) [SOFTEX, 2011a].
As Sees 7.2 a 7.8 discutem exemplos de medidas que podem ser aplicadas
nas organizaes durante a implementao de cada um 7 dos nveis do MR-MPS
(de G a A, respectivamente) e seus processos. So discutidas brevemente as
caractersticas principais de cada nvel de maturidade e os pontos mais
importantes de cada um de seus processos. So apresentadas, tambm, algumas
medidas que podem ser utilizadas para monitorar a execuo de cada um dos
processos em questo. A Seo 7.9 apresenta as consideraes finais do captulo.
Neste captulo utiliza-se o termo medida em detrimento do termo
indicador apenas para simplificao (afinal, todo indicador tambm uma
medida), a discusso das diferenas de significado entre eles pode ser vista no
Captulo 2.
No objetivo desse captulo discutir cada um dos processos e nveis do
MR-MPS em detalhes (para isso, deve-se ler os Guias de Implementao do MRMPS, disponveis em www.softex.br/mpsbr), porm para contextualizar o uso e
importncia das medidas apresentadas so discutidos brevemente os elementos
crticos de cada processo e cada nvel16. O conjunto de medidas aqui apresentadas
no contm as nicas possveis de serem implementadas. Cada organizao deve
avaliar criticamente as mais relevantes para o seu contexto e fazer as adaptaes
necessrias, alm de definir outras medidas conforme pertinente.
7.2 Medio no Nvel G do MR-MPS

preciso olhar os nveis de maturidade do MR-MPS (assim como de outros
modelos de maturidade, como o CMMI), como um caminho para a
institucionalizao da melhoria de processos de software de uma maneira
16
Dada a compatibilidade entre o MR-MPS e o CMMI-DEV, acredita-se que essas observaes

tambm sejam vlidas e teis para organizaes que implementam o CMMI-DEV.
155
abrangente. Muitas vezes, ao se falar sobre melhoria de processos de software no

contexto de modelos de maturidade, se confunde a adoo pura dos requisitos
desses modelos (representados pelos resultados esperados, no MR-MPS, ou
prticas, no CMMI-DEV) desses modelos com a melhoria dos processos. O objetivo
final da adoo de um modelo de maturidade deveria ser a melhoria contnua dos
processos. Quando se inicia a implementao de um nvel de maturidade em uma
organizao, no basta apenas evidenciar o cumprimento dos requisitos exigidos
para garantir a institucionalizao dos processos a mdio e longo prazo. preciso
entender os objetivos e os motivos de cada um desses requisitos e interpret-los
luz da realidade dos projetos e das organizaes.
O fato de se implementar um requisito especfico (por exemplo, a criao de
um cronograma no contexto de um projeto de desenvolvimento) transcende o fato
de se ter um documento onde sejam descritas as atividades do projeto,
responsabilidades e datas e prazos estimados e reais. O objetivo da
institucionalizao de um documento desse tipo possibilitar o planejamento e
controle das atividades necessrias para se desenvolver o software. Um
cronograma pode ser evidenciado de diferentes formas, por exemplo, em um
arquivo do MS-Project, um arquivo do MS-Word, um conjunto de post its em um
quadro ou um conjunto de tarefas relacionadas cadastradas em uma ferramenta de
controle de requisies (issue track systems). A melhor forma de implementar tal
cronograma depende das necessidades dos projetos que o utilizaro e das
caractersticas das organizaes em que os projetos sero executados. Pode ser
simples criar um arquivo no MS-Word com as informaes comumente
encontradas em um cronograma. Mas, se ele no for de fcil criao, utilizao e
manuteno, estar fatalmente fadado a no ser utilizado de fato ou a ser
substitudo por controles paralelos e no oficiais. Pode, tambm, no ser adequado
para possveis evolues almejadas na forma de gerenciar os projetos. Isso pode
colocar em risco os investimentos futuros em melhoria de processo de software da
organizao.
Outra questo pertinente que a evoluo nos nveis de maturidade dos
modelos deve ser vista de uma forma contnua, fluda, e no discreta, em saltos,
apesar da sua estrutura de nveis. Os nveis foram definidos de maneira a agrupar
processos com caractersticas e objetivos similares e, tambm, para possibilitar o
156
ganho contnuo de maturidade das organizaes. Dessa forma, uma boa prtica
adiantar a implementao de alguns aspectos importantes dos nveis subsequentes
para que se possa avaliar a viabilidade de algumas ideias, tratar possveis pontos
de melhoria j identificados, mas no presentes no nvel em questo, ou procurar
facilitar a implantao de aspectos chave dos nveis posteriores antecipadamente
com uma soluo mais simples.
Nenhuma prtica de medio de software prevista ou mesmo esperada no
nvel G do MR-MPS. No entanto, pode-se utilizar os esforos necessrios para a
implementao desse nvel de maturidade para comear a identificar elementos
relevantes dos processos que o compe (Gerncia de Projetos e Gerncia de
Requisitos) de forma a aproveit-los quando da implantao do processo Medio
no nvel F.
A caracterstica fundamental do nvel G do MR-MPS possibilitar s
organizaes o controle mnimo necessrio para a conduo de um projeto de
software. Esse controle necessrio para que o projeto possa ser gerenciado
adequadamente. Dessa forma, foram escolhidos os processo Gerncia de Projetos e
Gerncia de Requisitos para comp-lo. O primeiro processo est relacionado ao
planejamento do projeto baseado no uso de estimativas de tamanho, esforo e
custo e das atividades necessrias para produzir o produto esperado pelo cliente
do projeto e monitorao efetiva do projeto com base nos planos elaborados e
nos eventos que ocorrem durante a sua execuo. O segundo processo est
relacionado ao controle de escopo do projeto (e de suas evolues) e garantia de
um nvel suficiente de qualidade para a especificao dos requisitos que devero
ser construdos e entregues.
Dessa forma, pode-se incluir durante a monitorao do projeto a avaliao
quantitativa de aspectos relacionados gerncia de projetos e de requisitos. Essa
avaliao quantitativa, apesar de no precisar seguir o formalismo previsto pelo
processo Medio do nvel F do MR-MPS, pode representar o embrio da medio
na organizao e, potencialmente, possibilitar desde os nveis inferiores a prtica
da medio de software. A prxima seo discute algumas medidas que podem ser
teis para esse propsito.
157
O objetivo desta seo, assim como de todo o captulo, no ser exaustivo

na identificao de medidas teis e vlidas, mas apenas identificar pontos crticos
que possam ser teis durante a identificao das medidas a serem utilizadas por
uma determinada organizao. Convm lembrar, tambm, que medir por medir ,
no mnimo, um desperdcio de tempo e esforo. Assim como o framework do GQM e
o prprio processo Medio do MR-MPS pontificam, o alinhamento das medidas a
serem coletadas e analisadas com objetivos de negcio ou estratgicos da
organizao importante e necessrio. Caso contrrio, as medidas sero incuas e
no traro benefcios aos envolvidos.
Uma questo importante da definio de boas medidas para a monitorao
da execuo dos processos de software a identificao dos elementos e fatores
crticos associados a cada um dos processos envolvidos. No nvel G, como dito
anteriormente, a questo principal sendo tratada pelo MR-MPS o controle para a
conduo de um projeto de software. Uma forma, ento, de identificar medidas que
podem ser associadas a Gerncia de Projetos e Gerncia de Requisitos a
identificao de seus elementos crticos e de atributos que permitam mensur-los.
Alm disso, tambm importante identificar fatores, como eventos internos e
externos aos projetos, que influenciem na execuo destes processos.
7.2.1 - Medidas relacionadas a Gerncia de Projetos

O processo Gerncia de Projetos tem por propsito estabelecer e manter
planos que definem as atividades, recursos e responsabilidades do projeto, bem
como prover informaes sobre o andamento do projeto que permitam a
realizao de correes quando houver desvios significativos no desempenho do
projeto [SOFTEX, 2011a]. Possui um conjunto extenso de resultados esperados,
sendo alguns relacionados a possibilitar que o gerente do projeto tenha
mecanismos suficientes e necessrios para estimar o esforo e o custo do projeto.
Para que isso seja possvel, o primeiro passo a estimativa do tamanho do
projetos.
Uma medida de tamanho representa, em ltima instncia, a quantidade de
funcionalidades previstas ou existentes (dependendo se uma estimativa
elaborada antes do software ser construdo, no primeiro caso, ou uma contagem a
partir do software j construdo, no segundo caso) em um produto de software.
158
Exemplos de medidas de tamanho bastante utilizadas so Pontos por Funo (PF),

Pontos por Casos de Uso (PCU) e quantidade de linhas de cdigo (SLOC ou KSLOC,
sendo 1KSLOC = 1000 SLOC).
O uso de uma ou outra depende das caractersticas dos projetos. H
situaes em que essas medidas no se aplicam, por exemplo, pode ser difcil
estimar o tamanho de nova verso de um produto legado em uma organizao se
as especificaes disponveis no so claras em termos de entradas, sadas ou
interfaces (que possibilitariam o uso de Pontos por Funo) ou na forma de casos
de uso (que possibilitariam o uso de Pontos por Casos de Uso). Nesses casos, podese, por exemplo, definir uma nova medida de tamanho prpria para o sistema em
questo que mea a complexidade de tarefas simples como incluir um novo boto
de consulta, alterar um relatrio simples, incluir um cadastro complexo. A cada
uma dessas tarefas pode-se associar nmeros e chegar concluso que uma nova
verso do produto equivale a um valor de X pontos de complexidade da
organizao Y (X PCY). Se a classificao de cada tarefa bem definida e explicada,
se o mtodo de contagem permite classificar cada tarefa dentro de uma das
classificaes existentes e o peso relativo de cada classificao de tarefa bem
distribudo, em teoria, essa nova medida PCY equivalente a mtodos mais
estabelecidos como o PF ou PCU.
Medidas de tamanho so consideradas a base para realizar as estimativas
de esforo, tempo e custos dos projetos. A partir da medida de tamanho, pode-se
aplicar um fator de esforo necessrio para produzir uma unidade da medida de
tamanho (por exemplo, 10 homens/hora so necessrios para codificar 1 PF) e,
ento, estimar o esforo total necessrio para se concluir o projeto em questo. A
partir da informao do custo associado a cada hora de trabalho de cada uma das
pessoas envolvidas no projeto, pode-se ter o custo estimado total do projeto em
relao mo de obra.
Exemplos de medidas teis para monitorar essa etapa do planejamento do
projeto podem ser vistas na Tabela 7.1.
Apesar de os exemplos acima serem relacionados comparao dos valores
estimados no incio do projeto com aqueles reais obtidos ao final do projeto, tais
medidas podem ser adaptadas para serem coletadas e analisadas em pontos
159
predeterminados durante a execuo do projeto, por exemplo, em marcos e/ou

pontos de controle. Da mesma forma, as medidas tambm podem ser adaptadas
para analisar o desempenho em atividades e tarefas. Outros exemplos de medidas
neste captulo tambm seguem o mesmo padro.
Tabela 7.1 Medidas associadas a Gerncia de Projetos - planejamento do projeto.
1
Preciso da estimativa de tamanho do projeto

Estimativa de tamanho do projeto medido durante a especificao de requisitos /
Tamanho real do projeto medido aps a finalizao da construo
Para esta medida, quanto menor o erro, melhor. Erros grandes podem significar estimativas
mal realizadas, falta de controle do projeto (com requisitos sendo tornados mais complexos
sem o conhecimento do gerente do projeto ou controle adequado), incapacidade das pessoas
de realizarem a contagem de tamanho adequada durante as fases iniciais do projeto (por
problemas de treinamento e capacitao ou pelo nvel de detalhamento das descries das
funcionalidades insuficiente para uma estimativa adequada) etc.
Caso haja alteraes no escopo do projeto ao longo do tempo, a estimativa de tamanho deve
ser revista para mais ou para menos de acordo com o escopo de cada mudana aprovada.
Preciso da estimativa de tempo do projeto
Estimativa do nmero de dias a serem gastos no projeto de acordo com o primeiro
cronograma elaborado / Tempo real gasto em dias calculado aps o trmino do projeto
mal realizadas, falta de monitorao adequada do projeto (com desvios ao longo da execuo
do projeto no sendo adequadamente identificados e corrigidos) etc.
Perodos de interrupo do projeto, com suspenso de atividades, podem precisar ser
desconsiderados em algumas situaes.
Preciso da estimativa de esforo do projeto
Estimativa inicial do nmero de horas a serem gastas no projeto / Nmero real de horas
gastas calculado aps o trmino do projeto
Alteraes de escopo podem causar distores nos valores calculados e, portanto, devem ser
relatadas e tratadas adequadamente para fazer ajustes pertinentes nos valores coletados.
Preciso da estimativa de custo do projeto
Estimativa inicial do custo de pessoal a serem gastos no projeto / Custo total relativo a
pessoal calculado aps o trmino do projeto
Deve-se ter cuidado para diferenciar os custos associados com mo de obra (cuja variao
pode ser decorrente de falhas no mtodo de estimativa de tempo e/ou esforo utilizado) com
os custos associados a outros elementos como infraestrutura ou viagens (cujos erros podem
ter outras origens). Misturar as informaes pode levar a anlises e aes equivocadas.
Desvios tambm podem ser ocasionados, por exemplo, por aumento de salrio ao longo do
projeto. Informaes de contexto (assim como em quaisquer outras medidas) so importantes
para uma anlise adequada dos valores obtidos.
Esta medida no aplicvel em todos os casos. Muitas vezes, por exemplo, no de
responsabilidade da gerncia do projeto o controle do custo do projeto. Alm disso, em
algumas organizaes o controle do custo do projeto feito de forma indireta por meio do
esforo associado com a execuo das atividades.
Caso relevante, devem ser consideradas variaes decorrentes de depreciao de material,
flutuaes cambiais (quando parte do custo estiver atrelado a moedas estrangeiras) ou
alterao em ndices de reajustes.
De nada vale um plano de projeto bem elaborado se no h um esforo para

mant-lo atualizado e adequado ao projeto enquanto ele conduzido. A
160
monitorao do projeto deve acontecer periodicamente e em marcos e pontos de

controle ao longo do projeto. Registros das monitoraes, dos problemas
encontrados e das aes tomadas para resolv-los devem ser produzidos e
armazenados. A Tabela 7.2 apresenta medidas relacionadas monitorao do
projeto.
Tabela 7.2 Medidas associadas a Gerncia de Projetos - monitorao do projeto.
1
Taxa de aes decorrentes de monitoraes pendentes

Nmero de aes decorrentes de monitorao do projeto ainda no resolvidas / Nmero
total de aes decorrentes de monitorao do projeto
A existncia de muitas aes decorrentes da monitorao de um projeto em aberto pode ser
indicativo de falta de atualizao adequada dos planos e das prprias aes de monitorao,
da incapacidade de o gerente resolver as aes (indicando possivelmente a necessidade de
apoio ou interveno de pessoas em nvel hierrquico mais alto), ou, at mesmo, um
sinalizador de que riscos no previstos para o projeto podem estar acontecendo ou prximos
de acontecer (indicando ameaa para o cumprimento das metas estabelecidas para o projeto)
Esforo gasto na monitorao do projeto
Nmero de horas gastas pelo gerente do projeto realizando revises no planejamento do
projeto
Um esforo pequeno empregado na monitorao do projeto pode ser um indicativo de falta de
controle por parte do gerente do projeto e, potencialmente, pode ser a causa de problemas
relacionados ao possvel fracasso do projeto ou no cumprimento das metas estabelecidas.
Variaes desta medida podem incluir tambm as horas dos participantes de reunies com a
equipe e no apenas o gasto pelo gerente do projeto.
Medidas associadas a Gerncia de Riscos, tambm aplicveis a Gerncia de

Projetos, so discutidas na Seo 7.6.3.
7.2.2 - Medidas relacionadas a Gerncia de Requisitos

O processo Gerncia de Requisitos tem por propsito gerenciar os
requisitos do produto e dos componentes do produto do projeto e identificar
inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho
do projeto [SOFTEX, 2011a]. Os elementos principais do processo Gerncia de
Requisitos so o adequado entendimento dos requisitos pela equipe do projeto e
pelos clientes e o controle do escopo do projeto atravs da gerncia das mudanas
dos requisitos ao longo do projeto.
O entendimento dos requisitos pode ser mensurado a partir da qualidade
das especificaes realizadas. Esse um dos fatores crticos que deveriam ser
medidos em relao a esse processo. Atributos de qualidade comumente aplicveis
a requisitos (apesar de, infelizmente, no serem to aplicados na grande maioria
dos projetos) so: clareza (o quanto o requisito compreensvel), completeza (o
quanto a especificao est completa), omisso (se h elementos necessrios para
161
a compreenso do requisito que no foram fornecidos), inconsistncia (se h

informaes conflitantes na descrio de um requisito ou na informao
relacionada a itens descritos em outros requisitos), rastrevel (se possvel
identificar a origem do requisito ou a sua decomposio em outros elementos de
anlise, projeto ou cdigo) e ambiguidade (se h informao que pode levar a mais
de uma interpretao).
Independentemente da origem dos problemas identificados nos requisitos,
eles no deveriam ter acontecido, pois o natural seria imaginar que os requisitos
tivessem sido especificados e descritos com qualidade adequada. Os defeitos
podem ser identificados tanto pela equipe interna do projeto quanto pelo cliente
(ou fornecedor ou avaliar de requisitos). A documentao do projeto no deveria
ser enviada ao cliente sem antes ter sido atestada a sua qualidade. Por isso,
indicada a existncia de avaliaes tanto internas quanto externas ao projeto. O
fato de o cliente encontrar muitos defeitos na especificao de requisitos tambm
pode interferir na sua percepo da qualidade do produto, por esse motivo, em
geral, deseja-se que as avaliaes internas encontrem o maior nmero de defeitos
possvel.
O custo adicional por uma m qualidade na especificao de requisitos (seja
qual for a sua origem), em geral, no assumido pelo cliente e deve ser absorvido
pelo projeto. Dessa forma, um grande nmero de defeitos nas especificaes de
requisitos ocasiona gasto excessivo de retrabalho e de tempo para completar o
projeto e, consequentemente, aumento de custo para o projeto.
Outro evento que pode interferir na qualidade dos requisitos a alterao
dos requisitos ao longo do projeto. Alteraes de requisitos, por mais que sejam
adequadamente gerenciadas ao longo da durao dos projetos, so eventos no
previstos e, muitas vezes, no desejados. A quantificao do efeito das alteraes
de requisitos no esforo total do projeto importante para mensurar o real
impacto no andamento do projeto e, tambm, pode ser importante informao de
contexto para justificar o aumento do prazo de entrega do projeto ou, at mesmo, a
diminuio da qualidade final do produto.
Para simplificao, nesta seo utilizado de forma genrica o termo
especificao de requisitos. Os requisitos podem abranger um conjunto extenso
162
de nomenclaturas e produtos de trabalho, como, por exemplo, documento de viso,

modelo de anlise, requisitos funcionais etc.
A Tabela 7.3 apresenta medidas relacionadas gerncia de requisitos de um
projeto.
Tabela 7.3 Medidas associadas a Gerncia de Requisitos.
1
Densidade de defeitos identificados na avaliao interna de requisitos

Nmero de defeitos identificados pela equipe na especificao de requisitos / Tamanho do
projeto
A identificao dos defeitos pode ser feita por aqueles que iro desenvolver/codificar os
requisitos ou por meio de uma reviso por pares.
Um nmero alto de defeitos indicativo claro de problemas na especificao de requisitos e
deve ter suas causas e efeitos para o projeto investigados. Valores baixos associados com
medidas de densidade de defeitos nem sempre so indicativos de boa qualidade do produto
de trabalho avaliado. Estas medidas devem ser correlacionadas com outras para avaliar se os
defeitos esto de fato sendo identificados ou se os procedimentos adotados so incapazes
captur-los e efeitos colaterais so gerados em outras etapas do desenvolvimento de software
e/ou produtos de trabalho.
O uso da densidade de defeitos, dada pela diviso pelo tamanho do projeto, prefervel ao uso
do nmero de defeitos puro devido possibilidade, com a normalizao, de comparao entre
projetos com caractersticas e funcionalidades diferentes.
Variaes dessa medida, em geral, incluem classificao dos defeitos por tipo (por exemplo,
omisso, ambiguidade etc.) ou complexidade/impacto para o projeto (simples, mdio, alto). A
estratificao da informao pode possibilitar anlises mais detalhadas e aes mais efetivas.
Densidade de defeitos identificados na avaliao externa de requisitos
Nmero de defeitos identificados pelo cliente na especificao de requisitos / Tamanho do
projeto
Esta medida similar anterior com a diferena da origem da identificao dos defeitos, aqui
pelo cliente do projeto.
Esforo de retrabalho para especificao de requisitos
Nmero de horas gastas pela equipe para corrigir os defeitos identificados na especificao
de requisitos
Os gastos com os acertos na especificao de requisitos deveriam ser relatados e analisados
para avaliar o impacto na conduo do projeto. Um valor alto para o ndice de retrabalho um
possvel indicativo de m qualidade da especificao e, consequentemente, desperdcio de
tempo, dinheiro e esforo.
Variaes desta medida podem ser definidas correlacionando o valor obtido com o esforo
total do projeto ou o esforo gasto para elaborao da primeira verso da especificao de
requisitos (que foi avaliada). As anlises tambm devem ser adaptadas a estes cenrios.
A partir desta medida tambm pode ser derivada uma medida referente ao custo do
retrabalho.
Percentual de esforo para levantamento de requisitos
Nmero de horas gastas para levantamento de requisitos / Nmero de horas gastas para
elaborar a especificao de requisitos
Esta medida pode ser til para ser correlacionada com a densidade de defeitos identificados e
tambm com o esforo de retrabalho para corrigir tais defeitos. Uma das possveis causas da
m qualidade da especificao de requisitos pode ser a insuficincia de informaes obtidas
no levantamento de requisitos que, por sua vez, pode ser ocasionada pelo nmero de horas de
entrevistas insuficiente.
Volatilidade de Requisitos
(Nmero de requisitos alterados + Nmero de requisitos includos + Nmero de requisitos
excludos) / Nmero total de requisitos
Esta medida permite identificar o quanto o escopo do projeto (em relao a requisitos)
modificado ao longo do projeto, uma vez que os requisitos tenham sido aprovados.
Um valor apurado muito alto pode indicar que o escopo do projeto foi mal definido, que no
h um entendimento adequado dos requisitos ou que no est claro o que o cliente deseja. De
163
qualquer forma, valores altos dessa medida podem indicar problemas potenciais para o
projeto.
Uma variao desta medida pode utilizar tambm o tamanho de cada requisito em vez do
nmero de requisitos.
Percentual de esforo adicional devido alterao de requisitos
Nmero de horas gastas no projeto decorrentes de atividades relacionadas s alteraes de
requisitos ocorridas / Nmero total de horas gastas no projeto
Valores muito altos desta medida podem disparar a necessidade de um controle mais efetivo
do escopo do projeto ou de uma participao mais efetiva e ativa dos clientes durante a fase
de levantamento, avaliao e aprovao dos requisitos.
Esta medida pode ser til de ser avaliada junto com outra que mensure a variao de tamanho
do projeto em decorrncia de alteraes de requisitos. A partir da anlise dessas medidas em
conjunto pode ser possvel avaliar o impacto das alteraes de requisitos na produtividade da
equipe.
Das medidas apresentadas nesta seo, tecnicamente, apenas as duas

ltimas so especficas ao processo Gerncia de Requisitos, as demais esto
associadas diretamente a aspectos importantes dos processos de nvel D do MRMPS: Verificao, Validao e Desenvolvimento de Requisitos. No entanto, elas so
apresentadas aqui devido sua utilidade geral e por tratarem de aspectos
importantes que, se negligenciados, podem ter efeito sobre os requisitos e o
sucesso do projeto. Variaes dessas medidas tambm podero ser encontradas na
Seo 7.5, quando os processos de nvel D so discutidos.
7.3 Medio no Nvel F do MR-MPS

A caracterstica principal do nvel F do MR-MPS a gerncia e os
mecanismos de apoio necessrios para que essa gerncia seja efetiva na
organizao. Gerenciar um projeto no consiste apenas em elaborar planos para a
execuo das tarefas que culminaro na entrega de um produto de software a um
cliente e em garantir que tal plano seja seguido. Um conjunto de atividades de
apoio til e necessrio para que a gerncia dos projetos acontea de maneira
efetiva e que os produtos de software construdos tenham uma qualidade
adequada para os seus propsitos. Devido a isso, alm dos processos que compem
o nvel G, o nvel F contm tambm os processos de apoio Garantia da Qualidade,
Gerncia de Configurao e Medio. Aspectos mais elaborados da gerncia so
garantidos pela incluso de processos especficos para a Gerncia do Portflio de
Projetos da organizao e para a gerncia de Aquisio no contexto da execuo de
um projeto de software.
A partir desse nvel, a implementao do processo Medio passa a ser
obrigatria e deve atender a todos os requisitos previstos no Guia Geral [SOFTEX,
164
2011a]. Alm disso, a monitorao da execuo de cada um dos processos do

modelo de referncia deve ser realizada com base na definio, coleta e anlise de
medidas especficas.
Para que as medidas sejam adequadamente identificadas a partir dos
objetivos organizacionais e planejadas quanto forma de coleta e anlise, devem
ser seguidas boas prticas associadas ao processo de Medio discutidas no
Captulo 3 deste livro.
7.3.1 - Medidas relacionadas a Aquisio

O processo Aquisio tem por propsito gerenciar a aquisio de produtos
que satisfaam s necessidades expressas pelo adquirente [SOFTEX, 2011a].
Apesar de o texto do propsito e de seus resultados esperados citarem apenas
produtos, a aquisio de servios tambm est includa no escopo desse processo
desde que os servios sejam entregues como parte do produto final ao cliente.
O objetivo desse processo formalizar a aquisio de produtos e servios
adquiridos de terceiros (por exemplo, a compra de componente de software ou
pea de hardware importante para a concluso do projeto ou a terceirizao de
parte do desenvolvimento) que sejam crticos para o projeto e sob os quais o
gerente do projeto no tem controle direto sobre as tarefas realizadas pelo
fornecedor. Dessa forma, so elementos crticos para o projeto a qualidade final do
produto ou servio entregue pelo fornecedor, o impacto das entregas para o
cronograma e oramento do projeto e a satisfao geral em relao ao fornecedor.
A Tabela 7.4 apresenta medidas relacionadas aquisio de produtos e
servios.
Tabela 7.4 Medidas associadas a Aquisio.
1
Nmero de problemas identificados quando do aceite do produto adquirido

Esta medida pode dar informaes importantes sobre a qualidade final do produto (ou
servio) adquirido do fornecedor. Em geral, os problemas so identificados durante a
avaliao realizada para aceite do produto e/ou durante a incorporao do produto ao
projeto, sendo o ideal que sejam identificados no momento do aceite. Um valor alto associado
a esta medida indicativo que a qualidade do produto entregue insatisfatria.
Nmero de problemas identificados quando da incorporao do produto adquirido ao
projeto
Um valor alto associado a esta medida pode ser um indicativo de que os procedimentos para
aceite do produto adquirido no foram conduzidos de maneira adequada e precisariam ser
revistos ou que a especificao do produto a ser adquirido no foi feita da maneira adequada e
negligenciou aspectos importantes.
Taxa de desvio de cronograma das entregas acordadas com o fornecedor
Nmero de dias para a entrega / Nmero de dias estimado para a entrega
Atrasos no cronograma de entregas do fornecedor podem ter um impacto negativo para o
165
projeto e, portanto, devem ser evitados, principalmente se o produto (ou servio) adquirido
estiver no caminho crtico do projeto.
Taxa de desvio de custo do acordo com o fornecedor
Custo do produto adquirido / Custo estimado do produto adquirido
Caso a aquisio no seja feita com um custo total predeterminado importante avaliar o
impacto de um aumento do custo da aquisio para o oramento total do projeto. Variaes
muito grandes podem tornar o projeto invivel.
Satisfao em relao ao fornecedor
Um aspecto importante a se observar a satisfao geral em relao ao trabalho desenvolvido
pelo fornecedor. Uma forma de avaliar a satisfao por meio da anlise do desempenho do
fornecedor nas medidas discutidas anteriormente. Tambm pode-se realizar uma reavaliao
da pontuao de alguns dos critrios que levaram escolha desse fornecedor.
Valores baixos desta medida podem levar a organizao a rever futuras contrataes desse
mesmo fornecedor. Alm disso, a partir da anlise desta medida pode-se modificar a lista de
possveis fornecedores prioritrios dos projetos ou, at mesmo, dos critrios utilizados para
selecion-los.
7.3.2 - Medidas relacionadas a Garantia da Qualidade

O processo Garantia da Qualidade tem por propsito assegurar que os
produtos de trabalho e a execuo dos processos estejam em conformidade com os
planos, procedimentos e padres estabelecidos [SOFTEX, 2011a].
Um profissional da equipe de garantia de qualidade o guardio dos
processos e deve zelar para que todos sejam seguidos adequadamente. As
atividades bsicas desse profissional so realizar avaliaes de qualidade dos
produtos previstos pelo processo (ou seja, se os documentos esto aderentes aos
padres da organizao e as informaes presentes neles so consistentes,
ntegras e completas) e avaliaes de aderncia aos processos (ou seja, se todas as
tarefas e atividades previstas esto sendo seguidas adequadamente e na ordem
estabelecida). Alm disso, responsabilidade da rea de garantia da qualidade
assegurar que as no conformidades identificadas sejam registradas e
acompanhadas at a sua concluso. Para que isso ocorra, necessrio apoio dos
nveis hierrquicos superiores na organizao, incluindo-se a os patrocinadores
da iniciativa de melhoria de processos. Caso esse apoio no exista, a rea de
garantia da qualidade perde poder, o que ameaa todos os esforos em prol da
melhoria de processos.
Como o efeito mais visvel do trabalho da equipe de garantia da qualidade
a identificao de no conformidades, natural que as medidas mais utilizadas
para dar visibilidade a isso estejam relacionadas ao nmero de no conformidades
encontradas durante as avaliaes de qualidade. Um nmero muito grande de no
conformidades pode indicar a deficincia dos projetos da organizao em vrios
166
aspectos, como, pessoas burlando os processos indiscriminadamente, falta de

treinamento adequado dos profissionais, critrios no condizentes com as
necessidades da organizao, processos e/ou modelos de documentos (templates)
pouco claros e detalhados etc. No parece razovel considerar, no entanto, todas as
avaliaes de qualidade realizadas em conjunto, de forma indiscriminada. Para
anlises mais efetivas deve-se considerar a estratificao das medidas em
diferentes tipos de forma a facilitar e detalhar a anlise das informaes. Por
exemplo, definir medidas que estejam relacionadas individualmente a tipo de
artefato/produto avaliado, processo avaliado, fase ou etapa do processo de
desenvolvimento avaliado, tipo de avaliao realizada (se de produto ou de
processo), criticidade do problema etc.
A Tabela 7.5 apresenta medidas relacionadas garantia da qualidade de
processo e de produto.
Tabela 7.5 Medidas associadas a Garantia da Qualidade.
1
Taxa de no conformidade em avaliaes de qualidade no documento de requisitos

Nmero de no conformidades identificadas em avaliaes de qualidade no documento de
requisitos / Nmero total de critrios observados
Mesmo valores baixos apurados para a medida tambm podem ser motivo de preocupao. A
existncia de poucas no conformidades nesse cenrio pode indicar uma falha dos
procedimentos de garantia da qualidade em assegurar uma correta execuo dos processos.
No incio de um programa de melhoria aceitvel que as pessoas cometam erros devido
pouca familiaridade com os processos. Com o passar do tempo, espera-se que os processos
sejam institucionalizados e, portanto, que os problemas tendam a no serem mais gerados.
Essa medida se refere especificamente ao documento de requisitos (que pode englobar as
especificaes de requisitos, glossrio, matriz de rastreabilidade etc.) por ser, como j dito
anteriormente, um dos mais importantes de qualquer projeto. Obviamente, essa medida pode
ser adaptada para levar em considerao outros produtos de trabalho previsto pelos
processos.
Esta medida considera apenas as avaliaes de qualidade relacionadas ao produto de
trabalho documento de requisitos e no ao conjunto de atividades e/ou tarefas necessrios
para ger-lo. Infelizmente, um problema bastante comum a incapacidade de as organizaes
diferenciarem critrios de avaliao de produto de critrios de avaliao de processo. Nesses
casos, alm de a efetividade das avaliaes poder ser comprometida, a anlise das medidas de
no conformidade pode ser deturpada. As organizaes devem avaliar a possibilidade de ter
medidas diferentes para analisar as no conformidades decorrentes de avaliaes de produto
e de processo.
Variaes desta medida incluem a estratificao dos valores apurados em categorias (por
exemplo, fase ou etapa do processo de desenvolvimento avaliado, criticidade do problema
etc.) de forma a facilitar e detalhar a anlise das informaes.
Alguns dos produtos de trabalho avaliados so dependentes do tamanho do projeto
(principalmente os relacionados s atividades de engenharia, por exemplo, documento de
requisitos, casos de testes etc.). Dessa forma, uma variao desta medida pode considerar,
tambm, a normalizao dos valores pelo tamanho do projeto.
importante destacar que a efetividade dessa medida est relacionada qualidade da
avaliao realizada. Se, por exemplo, a avaliao for superficial, essa medida no ter utilidade
nem significar nada. Outra distoro nesta medida pode ser ocasionada pelo nmero baixo
de critrios considerados na avaliao. Deve-se, portanto, procurar que haja um nmero
adequado de critrios para avaliar os aspectos crticos do produto de trabalho em questo e
167
que estes critrios sejam os mais objetivos e explcitos possveis.

Taxa de no conformidade em avaliaes de aderncia ao processo Gerncia de
Requisitos
Nmero de no conformidades identificadas na avaliao de aderncia ao processo Gerncia
de Requisitos / Nmero total de critrios observados
Esta medida considera apenas as avaliaes de qualidade relacionadas verificao de
aderncia ao processo Gerncia de Requisitos e no forma e contedo dos produtos de
trabalho relacionados, como o documento de requisitos ou os registros do controle de
alterao de requisitos.
A anlise desta medida pode ser realizada de forma similar anterior, referente s avaliaes
de produto. Obviamente, essa medida tambm pode ser adaptada para levar em considerao
outros processos utilizados pela organizao.
Esforo de retrabalho para corrigir problemas identificados em avaliaes de qualidade
Nmero de horas gastas pela equipe para corrigir os problemas identificados em avaliaes
de qualidade
Esta medida, apesar de til, muitas vezes de difcil coleta. No entanto, o esforo de
retrabalho sempre uma informao importante para analisar o custo associado com a no
realizao de uma atividade da maneira adequada em um primeiro momento. Em geral, o
custo de retrabalho no esperado ou desejado e, portanto, deseja-se que seja o menor
possvel.
total do projeto ou o esforo gasto para elaborao da primeira verso da documentao
avaliada. As anlises tambm devem ser adaptadas a estes cenrios.
retrabalho.
Nmero de no conformidades identificadas na auditoria independente de qualidade
Valores altos desta medida podem indicar falhas na execuo do trabalho realizado pela
equipe de qualidade. Aes devem ser tomadas para analisar a razo dos problemas
encontrados que pode ser, por exemplo, por falta de treinamento ou capacitao adequada
dos responsveis pela execuo das atividades de garantia da qualidade, ineficincia em
cumprir os planos estabelecidos ou uma perda de prioridade da execuo das atividades
relacionadas garantia da qualidade.
importante destacar que a efetividade dessa medida est relacionada qualidade da
auditoria independente realizada. Se, por exemplo, a avaliao for superficial, essa medida no
ter utilidade nem significar nada.
Taxa de no conformidades escalonadas
Nmero de no conformidades escalonadas / Nmero total de no conformidades
A necessidade de escalonamento de uma ao corretiva est associada no resoluo de uma
no conformidade aberta. Dessa forma, um valor elevado para esta medida pode ser indicativo
de falta de empenho dos colaboradores da organizao ou de falta de apoio e
comprometimento dos envolvidos para o sucesso da iniciativa de melhoria de processos.
Taxa de no conformidades escalonadas sem resoluo
Nmero de no conformidades escalonadas que no foram resolvidas / Nmero total de no
conformidades escalonadas
A necessidade de escalonamento das aes corretivas uma caracterstica indesejada durante
a conduo de um programa de melhoria de processos, porm o mecanismo fundamental
para reforar a importncia das aes tomadas pela rea de garantia da qualidade para a
organizao como um todo.
Dessa forma, pior que um elevado nmero de no conformidades no resolvidas a falta de
apoio dos nveis hierrquicos superiores em reforar o papel da rea de qualidade, a
necessidade de resoluo dos problemas encontrados e a importncia do programa de
melhoria de processos da organizao.
Valores altos desta medida podem indicar uma falta de prioridade e apoio do programa de
melhoria de processos na organizao. A curto prazo, isso pode fazer com que problemas
graves no sejam corrigidos adequadamente. A mdio e longo prazos, isso pode fazer com que
a iniciativa de melhoria seja abandonada.
Deve-se reforar que a efetividade das medidas relacionadas qualidade

dependente do rigor e profundidade com que as avaliaes so realizadas. Se, por
168
exemplo, a avaliao for superficial, os resultados obtidos no tero utilidade e

tero pouco significado na prtica. Muitas vezes, os critrios dos checklists de
qualidade utilizados pelas organizaes no avaliam aspectos e contedos crticos
e importantes dos processos e/ou dos produtos em questo. Os padres ou
formatos a que se referem o texto dos resultados esperados e o propsito do
processo no so referentes a cor e tamanho de fontes, mas ao contedo do que
deve ser preenchido no documento.
Outra interpretao duvidosa do modelo que as avaliaes previstas pelo
processo Garantia da Qualidade levam em considerao apenas os aspectos
explicitamente previstos nos resultados esperados de um processo. O papel da
garantia de qualidade assegurar que quaisquer processos de interesse da
organizao sejam seguidos, independentemente de eles terem sido definidos para
cumprir os requisitos de um nvel de maturidade ou no.
Dessa forma, se os critrios de avaliao de qualidade no forem adequados,
as medidas que registram as no conformidades, apesar de formalmente bem
definidas, podem no representar nenhuma vantagem para a organizao ou levar
a anlises incorretas.
7.3.3 - Medidas relacionadas a Gerncia de Configurao

O processo Gerncia de Configurao tem por propsito estabelecer e
manter a integridade de todos os produtos de trabalho de um processo ou projeto
e disponibiliz-los a todos os envolvidos [SOFTEX, 2011a]. O aspecto crtico
relacionado a esse processo o controle de todos os produtos de trabalho dos
processos em execuo pela organizao. Esse controle se inicia com a criao dos
produtos de trabalho, pela aprovao e controle de modificaes (conforme
pertinente), at a entrega aos interessados e, tambm, possveis evolues a partir
da. Para que esse controle seja possvel, necessrio identificar quais produtos de
trabalho devem ser considerados itens de configurao, armazen-los de forma
controlada e garantir o controle de suas evolues. Para assegurar que os nveis de
controle adequados e mecanismos necessrios estejam sendo postos de fato em
prtica,
auditorias
de
gerncia
de
configurao
devem
ser
realizadas
periodicamente.
A Tabela 7.6 apresenta medidas relacionadas gerncia de configurao.
169
Tabela 7.6 Medidas associadas a Gerncia de Configurao.

1
Nmero de no conformidades por auditoria de configurao

Da mesma forma como as avaliaes realizadas pela rea de garantia de qualidade, as
auditorias de configurao asseguram que o processo de gerncia de configurao adotado
pelos projetos e pela organizao est sendo adequadamente seguido que os mecanismos de
controle esto sendo adotados em sua plenitude.
Taxa de itens de configurao com no conformidade
Nmero de itens de configurao com no conformidade / Nmero total de itens de
configurao
Um alto ndice de itens de configurao com no conformidades pode indicar problemas
generalizados com os procedimentos de gerncia de configurao adotados e devem,
portanto, ser investigados.
Nmero de erros encontrados durante a liberao de verso (release)
Valores altos para esta medida podem indicar problemas nos procedimentos utilizados para a
construo dos produtos a serem entregues para o usurio final e no apenas para o
empacotamento da verso em questo.
Em geral, esta medida utilizada no contexto de projetos de desenvolvimento, sendo a verso
em questo, uma verso do software produzido no projeto. Uma variao desta medida pode
assumir outros tipos de produtos, como o conjunto de processos padro da organizao em
implementaes de nvel E do MR-MPS ou superiores.
Esforo para realizao das auditorias de gerncia de configurao
Nmero de horas gastas pela equipe para executar as tarefas associadas realizao das
auditorias de gerncia de configurao
As atividades de gerncia de configurao, naturalmente burocrticas em sua maioria, podem
ser bastante demoradas. Dessa forma, pode ser de interesse das organizaes monitorar o
esforo associado a elas.
Variaes desta medida podem estar associadas a tarefas diferentes relacionadas gerncia
de configurao, como, por exemplo, a montagem e liberao (release) de uma verso do
software.
Esforo de retrabalho para corrigir problemas de gerncia de configurao
Nmero de horas gastas pela equipe para corrigir os problemas identificados durante a
execuo das atividades de gerncia de configurao
Assim como todas as atividades relacionadas qualidade, o clculo do esforo gasto em
retrabalho associado s atividades de gerncia de configurao um importante mecanismo
para mensurar o gasto excessivo e o desperdcio de esforo e custo de no se fazer certo da
primeira vez.
total do projeto ou o esforo gasto para a execuo das tarefas relacionadas gerncia de
configurao. As anlises tambm devem ser adaptadas a estes cenrios.
retrabalho.
7.3.4 - Medidas relacionadas a Gerncia de Portflio de Projetos

O processo Gerncia de Portflio de Projetos tem por propsito iniciar e
manter projetos que sejam necessrios, suficientes e sustentveis, de forma a
atender os objetivos estratgicos da organizao [SOFTEX, 2011a]. Dessa forma,
um dos pontos principais desse processo a escolha de projetos que sejam
justificveis luz dos objetivos estratgicos da organizao e que permitam que a
organizao seja eficiente e vivel economicamente. Outro ponto importante o
uso ordenado dos recursos da organizao de forma a maximizar o atendimento
dos objetivos estratgicos da organizao.
170
A Tabela 7.7 apresenta medidas relacionadas gerncia de portflio de

projetos.
Tabela 7.7 Medidas associadas a Gerncia de Portflio de Projetos.
1
Taxa mdia de rentabilidade dos projetos

Somatrio da rentabilidade de cada projeto / Nmero total de projetos
Uma anlise da rentabilidade dos projetos no portflio pode fazer com que alguns critrios de
aceite e recusa de projetos possam ser reavaliados.
Uma anlise da srie histrica de rentabilidade dos projetos no portflio pode ser til para a
organizao avaliar sua sade financeira atual.
Preciso de estimativa de lucro
Lucro apurado para um projeto / Previso de lucro para um projeto
Esta medida pode ser til para avaliar a evoluo da sade financeira da organizao ao longo
do tempo e tambm para calibrar os critrios utilizados para aprovao dos projetos baseados
na expectativa de retorno financeiro esperado com a concluso de um projeto.
Variaes desta medida incluem a preciso de estimativa de receita e de custo.
Contribuio dos projetos de um portflio para o retorno financeiro da organizao
Somatrio do lucro dos projetos de um portflio de projetos / Lucro total da organizao
A anlise da contribuio de um portflio de projetos para o retorno financeiro da
organizao pode fazer com que a organizao reavalie a prioridade relativa entre projetos
e/ou entre os diferentes portflios existentes.
Taxa de alocao mdia de pessoal
Somatrio do nmero de horas trabalhadas pelos colaboradores / (Somatrio do nmero de
colaboradores * Nmero de horas de trabalho de cada colaborador)
Uma taxa de alocao baixa de pessoal pode indicar a existncia de capacidade ociosa na
organizao, que poderia ser alocada a novos projetos ou tarefas. Uma taxa de alocao
superior a 1 pode indicar uma sobrealocao das pessoas que, a longo prazo, pode causar
problemas de satisfao com o trabalho ou custo elevado de horas extras.
Valores muito altos em organizaes com grande nmero de colaboradores compartilhados
entre vrios projetos podem indicar a existncia potencial de muitos conflitos entre os
projetos.
Produtividade mdia dos projetos da organizao
Somatrio do esforo total dos projetos / Somatrio do tamanho total dos projetos
O clculo da produtividade importante para a determinao de estimativas mais precisas
pela organizao e pelos projetos. Um desejo comum a muitas organizaes que a
produtividade dos projetos seja sempre crescente. Caso os valores oscilem muito com o tempo
ou mostrem tendncias de declnio, as razes devem ser investigadas e as aes corretivas
necessrias, tomadas.
Diferentes tipos de projetos tm comportamentos diferentes em relao produtividade. No
possvel comparar, por exemplo, projetos de tamanhos muito diferentes (por exemplo,
pequenos, mdios e grandes) ou utilizando linguagens e tecnologias diferentes (por exemplo,
COBOL, Java e dotNet). Dessa forma, pode ser necessria a estratificao desta medida de
acordo com a classificao dos projetos na organizao.
Nmero de projetos no aceitos por falta de capacidade instalada
Caso muitos projetos sejam recusados por falta de capacidade da organizao de execut-los
pode ser uma sinalizao da necessidade de aumentar os quadros da organizao.
Nmero de projetos no aceitos por no dominar a tecnologia
Caso muito projetos sejam recusados pelo fato de a organizao no dominar a tecnologia
pode indicar necessidade de reviso das tecnologias utilizadas na organizao e a abertura a
novidades neste sentido.
Nmero de projetos cancelados
Um nmero alto de projetos cancelados deve ser investigado, pois pode ser indicativo, por
exemplo, de uma m gesto do projeto, escolha equivocada dos projetos a compor o portflio
por critrios mal definidos ou necessidade de reviso dos objetivos estratgicos da
organizao.
171
7.3.5 - Medidas relacionadas a Medio

O processo Medio tem por propsito coletar, armazenar, analisar e
relatar os dados relativos aos produtos desenvolvidos e aos processos
implementados na organizao e em seus projetos, de forma a apoiar os objetivos
organizacionais [SOFTEX, 2011a]. Os aspectos crticos da execuo desse processo
esto relacionados efetividade das medidas coletadas e das aes tomadas a
partir dos resultados obtidos. A Tabela 7.8 apresenta medidas relacionadas
medio.
Tabela 7.8 Medidas associadas a Medio.
1
Taxa de medidas efetivamente coletadas e analisadas

Nmero de medidas coletadas e analisadas / Nmero total de medidas presentes no plano de
medio
Nem sempre se consegue coletar os dados de todas as medidas identificadas como relevantes
pela organizao. natural imaginar que o valor apurado para esta medida aumente com o
tempo at atingir o valor 1. Aps esse momento inicial, importante monitorar os valores
apurados para identificar possveis problemas que possam estar impedindo a correta
implementao do processo Medio.
Taxa de medidas que esto dentro das metas aceitveis
Nmero de medidas dentro das metas aceitveis / Nmero de medidas coletadas e
analisadas
Esta medida tenta sumarizar a situao geral de todas as medidas coletadas pela organizao.
Vrios fatores podem impactar diferentes medidas ao longo do tempo, porm uma expectativa
geral das organizaes que as medidas convirjam para atender as metas estabelecidas.
Taxa de concluso de aes decorrentes de medio
Nmero de aes decorrentes de medio concludas / Nmero total de aes decorrentes de
medio
Uma das caractersticas esperadas de um programa de medio que as medidas coletadas e
analisadas sirvam para a tomada de deciso. Dessa forma, de se esperar que as aes
derivadas das medidas sejam de fato executadas e concludas adequadamente. Falhar no
registro e anlise dessas aes pode levar o programa de medio ao descrdito e, por fim, ao
cancelamento.
Esforo para coleta e anlise das medidas
Nmero de horas gastas pela equipe para realizar as atividades relacionadas coleta e
anlise das medidas que compem o plano de medio da organizao
A execuo das atividades de coleta e anlise de um programa de medio pode ser bastante
custosa e, portanto, tambm pode ser de interesse da organizao monitor-las.
Uma variao desta medida pode ser definida correlacionando o valor obtido com o esforo
total do projeto. As anlises tambm devem ser adaptadas a esse contexto.
A partir desta medida tambm pode ser derivada uma medida referente ao custo dessas
atividades.
7.4 Medio no Nvel E do MR-MPS

A caracterstica principal do nvel E do MR-MPS a institucionalizao dos
processos padro na organizao. At o nvel F do MR-MPS cada projeto pode
definir sua prpria verso do processo a ser utilizado.
172
A partir do nvel E, os processos em uso na organizao, sejam eles

executados no contexto de projetos ou de atividades organizacionais, devem ser
padronizadas na organizao por meio da definio de um conjunto de processos
padro adequados a situaes especficas de acordo com as diretrizes de
adaptao definidas. Os principais processos responsveis por essa padronizao
so Definio do Processo Organizacional, responsvel pela definio e gerncia
dos ativos de processo da organizao, e Avaliao e Melhoria do Processo
Organizacional, responsvel pela evoluo de forma controlada desses ativos de
processo e pela implantao de eventuais novas verses desses ativos nos projetos
em execuo ou novos projetos a serem iniciados.
No apenas as definies dos processos deve ser padronizada na
organizao, mas tambm a execuo deles. Nesse sentido, o processo Gerncia de
Recursos Humanos tem um papel importante por possibilitar organizao a
capacitao dos seus colaboradores de forma que tenham as competncias
adequadas para atender s necessidades de negcio identificadas. Dessa forma,
deve ser posta em prtica uma poltica de recursos humanos envolvendo
contratao, treinamento e criao de uma infraestrutura para gerncia de
conhecimento adequada, alinhada aos objetivos estratgicos da organizao. Caso
essa poltica no seja eficaz, os esforos para a institucionalizao dos processos
padro da organizao podem correr riscos.
A padronizao dos processos tambm interfere nos procedimentos para
Gerncia de Projetos, motivo pelo qual esse processo tem alguns resultados
esperados evoludos e outros adicionados. Isso necessrio para garantir que os
projetos se beneficiem dos ativos de processo construdos (por exemplo, a base
histrica de estimativas), obrigatoriamente utilize um dos processos padro
devidamente adaptado de acordo com as diretrizes existentes e tambm
contribuam para a evoluo dos ativos de processo.
Por fim, o processo Gerncia de Reutilizao no est diretamente
relacionado padronizao de processos na organizao, mas garante que a
organizao comece a estruturar seus mecanismos para o programa de
reutilizao, que ser alvo do processo Desenvolvimento para Reutilizao do nvel
C do MR-MPS. No entanto, algumas organizaes decidem definir como ativos
173
reutilizveis os ativos de processo, contribuindo, assim, tambm para fomentar a

institucionalizao dos processos.
O processo de Medio no nvel E no possui resultados esperados
adicionais em relao ao que foi definido no nvel F, no entanto, espera-se que a
implementao desse processo j esteja mais madura e que o foco das medidas e as
anlises evoluam para possibilitar a melhoria dos processos e no somente o
controle da execuo de atividades ou projetos especficos. Um exemplo do uso de
medio nesse cenrio pode ser visto no Captulo 8 deste livro.
7.4.1 - Medidas relacionadas a Avaliao e Melhoria do Processo

Organizacional
O processo Avaliao e Melhoria do Processo Organizacional tem por
propsito determinar o quanto os processos padro da organizao contribuem
para alcanar os objetivos de negcio da organizao e para apoiar a organizao a
planejar, realizar e implantar melhorias contnuas nos processos com base no
entendimento de seus pontos fortes e fracos [SOFTEX, 2011a].
O aspecto crtico desse processo est relacionado conduo do programa
de melhoria de processos na organizao. Alm disso, esperada a identificao de
pontos de melhoria nos processos e a constante evoluo dos ativos
organizacionais. Tambm esperado que os efeitos das melhorias implementadas
sejam avaliados para garantir que os ativos estejam, de fato, em uso na organizao
e que as modificaes realizadas ao longo do tempo tenham sido realmente
adequadas e tenham surtido o efeito esperado.
A Tabela 7.9 apresenta medidas relacionadas avaliao e melhoria do
processo organizacional.
Tabela 7.9 Medidas associadas a Avaliao e Melhoria do Processo Organizacional.
1
Nmero de solicitaes de melhorias identificadas

Deve-se ter cuidado com a anlise desta medida, pois o nmero de melhorias identificadas
pode variar muito de acordo com a fase de implantao e execuo do programa de melhoria
de processos em uma organizao. Em geral, um maior nmero de solicitaes de melhorias
identificado nas fases iniciais de implantao dos processos. Com o passar do tempo, a
tendncia que as verses dos processos j definidos tornem-se adequadas s necessidades
das equipes e dos projetos e, assim, os valores associados a essa medida diminuam.
Variaes desta medida podem analisar os valores em perodos predeterminados ou de forma
acumulativa. As anlises devem levar esse fato em considerao.
Taxa de implementao de melhorias
Nmero de melhorias identificadas que foram implementadas / Nmero total de melhorias
identificadas
Da mesma forma que na medida anterior, dependendo do perodo em que o programa de
174
melhoria de processos se encontra na organizao, a interpretao desta medida deve ser

diferenciada.
Valores mais altos de implementao de melhorias, em geral, esto associados s fases iniciais
da implantao de processos ou durante as revises realizadas para ajustes devido a
realinhamento estratgico ou a implementao de novos nveis de maturidade na organizao.
No entanto, valores sempre prximos do zero podem indicar uma lentido, ou at mesmo
descaso, da organizao em relao melhoria dos processos em uso na organizao.
Taxa de melhorias implementadas que surtiram o efeito desejado
Nmero de melhorias cujos efeitos foram considerados satisfatrios / Nmero de melhorias
implementadas
Nem sempre as melhorias implementadas na organizao surtem os efeitos desejados. Caso o
valor desta medida no seja alto, as razes devem ser investigadas.
Esta medida tambm pode ser til para avaliar se as melhorias esto, de fato, sendo avaliadas
para confirmar sua adequao e pertinncia o que pode ser o real motivo de valores baixos
apurados.
Esforo do programa de melhoria de processos
Nmero de horas gastas pela equipe para realizar as atividades relacionadas gerncia e
execuo do programa de melhoria de processos
A gerncia e execuo de um programa de melhoria de processos em uma organizao no
uma tarefa trivial e, provavelmente, demandar esforo e dedicao. A anlise desta medida
pode ser til para controlar a alocao da equipe s atividades relacionadas como tambm
para identificar potencial risco de no se cumprir o cronograma do programa de melhoria de
processos em curso.
O custo do programa de melhoria de processos pode ser derivado de uma variao desta
medida.
7.4.2 - Medidas relacionadas a Definio do Processo

Organizacional
O processo Definio do Processo Organizacional tem por propsito
estabelecer e manter um conjunto de ativos de processo organizacional e padres
do ambiente de trabalho usveis e aplicveis s necessidades de negcio da
organizao [SOFTEX, 2011a]. Dessa forma, esse processo tem um papel
fundamental na padronizao dos processos e demais procedimentos adotados
pela organizao. A identificao de medidas para esse processo dificultada por
dois motivos: a maior parte dos produtos gerados pela sua execuo so os
processos padro da organizao (em geral, com formatos predeterminados) e o
nmero de execues do processo limitado (em geral, so poucos os processos
definidos em um programa de melhoria de processos em comparao com outros
tipos de documentos que existem em maior profuso, como, por exemplo, casos de
uso em projetos de desenvolvimento). A Tabela 7.10 apresenta medidas
relacionadas definio dos processos padro da organizao.
Tabela 7.10 Medidas associadas a Definio do Processo Organizacional.
1
Nmero de inadequaes dos processos padro

Esta medida indica o nmero de inadequaes identificadas nos processos padro da
organizao. Valores elevados desta medida podem indicar a necessidade de uma reviso
geral dos processos em questo.
175
Taxa de projetos na organizao que utilizam os processos padro

Nmero de projetos na organizao que utilizam os processos padro / Nmero total de
projetos na organizao
importante saber o quanto o uso dos processos padro da organizao est sendo, de fato,
institucionalizado. Durante o incio do programa de melhoria de processos, pode ser que esta
medida apresente valores baixos, mas espera-se que, com o tempo, a tendncia seja de
crescimento, com o seu valor chegando a 1.
Valores baixos desta medida podem indicar, por exemplo, a inadequao dos processos
existentes aos projetos atuais ou a falta de apoio da alta gerncia da organizao em obrigar
que os projetos sigam os processos existentes. Outra possvel razo pode ser a inexistncia de
procedimentos de adaptao adequados.
Uma variao desta medida pode considerar apenas os projetos da unidade organizacional em
questo.
7.4.3 - Medidas relacionadas evoluo de Gerncia de Projetos no

nvel E
projeto [SOFTEX, 2011a].
O aspecto crtico relacionado evoluo do processo Gerncia de Projetos
no nvel E o uso dos ativos de processo organizacionais. Assim, a partir do nvel E,
a gere ncia de projetos passa a ser realizada com base no processo definido para o
projeto a partir do conjunto de processos padro da organizao e, tambm, na
integrao de diferentes planos. O uso dos ativos de processo tambm possibilita a
criao e uso de uma base histrica de estimativas na organizao. Quanto melhor
a base de estimativas, mais chances existiro de que o projeto seja planejado de
forma adequada e precisa e, portanto, menos riscos relacionados ao atraso de
cronograma e estouro de oramento tendem a acontecer.
A Tabela 7.11 apresenta medidas relacionadas gerncia de projetos
conforme aplicvel ao nvel E do MR-MPS.
Tabela 7.11 Medidas associadas a Gerncia de Projetos no nvel E.
1
Preciso mdia das estimativas realizadas a partir da base histrica

Somatrio da preciso de estimativas dos projetos / Nmero total de projetos que utilizaram
a base histrica para realizar as estimativas
Se os valores estimados para os projetos se desviarem muito dos obtidos, deve-se investigar a
estrutura (por exemplo, estratificao de projetos e detalhamento de atividades/fases dos
projetos) e contedo (por exemplo, acurcia dos valores base coletados) da base de
estimativas e deve-se tomar as aes pertinentes para melhor-la.
Estimativas so, como o nome diz, valores estimados e, portanto, no conseguem adivinhar
os valores reais que sero obtidos. Dessa forma, natural pensar que os valores reais obtidos
pelos projetos sero diferentes daqueles estimados. No entanto, quanto melhor e mais
176
representativa for a base histrica da organizao, menores sero os erros de estimativas

observados.
Taxa de adaptaes realizadas no processo definido para o projeto
Nmero de adaptaes ao processo padro presentes no processo definido para o projeto /
Nmero possvel de adaptaes ao processo padro da organizao
Esta medida pode ser til para identificar o quo distante do processo padro o processo
definido para um projeto. Valores muito altos desta medida podem sinalizar a necessidade de
definio de um novo processo padro para tipos especficos de projetos.
Uma caracterstica do nvel E (e superiores) do MR-MPS a definio de

processos padro para os diferentes processos exigidos pelo modelo. Associado a
isso, esperado que haja constantemente um melhor detalhamento das atividades
que compem um processo, eliminando atividades que se comportem como
caixaspretas provendo tarefas com granularidade adequada para o entendimento
de todo o processo pelos papis envolvidos e que, tambm, sejam teis para a
montagem de uma base histrica de estimativas adequada.
Dessa forma, com o aumento do detalhamento das atividades necessrias
para conduzir os projetos, pode ser mais fcil a adoo de melhores medidas para
monitorao de prazos e custos do projeto, que permitam indicar se um projeto
provavelmente vai demorar mais tempo (ou custar mais) para ser terminado em
vez de apenas indicar que o projeto est atrasado (ou com custo maior que o
previsto). O conjunto de medidas apresentado na Tabela 7.12 possibilita que, a
partir do progresso atual do projeto, seja possvel dar um indicativo de como ele
caminhar at a sua concluso no que se refere a atrasos ou adiantamentos em
relao ao cronograma e ao custo, respectivamente.
Tabela 7.12 Medidas associadas a Gerncia de Projetos no nvel E monitorao do projeto.
1
Progresso do projeto em relao a cronograma (ou, SPI - Schedule Performance Index)

SPI = EV / PV, onde:
EV (Earned Value) o custo planejado para o trabalho realizado at o momento
considerado; e
PV (Planned Value) o custo planejado para o trabalho que deve ser realizado at um
dado momento, de acordo com a baseline do projeto (planejamento utilizado como
referncia para monitorao e controle do projeto);
O SPI (ou ndice de desempenho de cronograma, em portugus) [PMI, 2008] indica o
desempenho do projeto em relao aos prazos. Ele pode ser usado para estimar como o
projeto caminhar at a sua concluso em relao ao prazo. Se o valor de SPI menor que 1,
ento o projeto est atrasado. Se o valor de SPI maior que 1, ento o projeto est adiantado.
Se o valor 1, ento o projeto est em dia com o cronograma.
Progresso do projeto em relao a custo (ou CPI - Cost Performance Index)
CPI = EV / AC, onde:
EV (Earned Value) o custo planejado para o trabalho realizado at o momento
considerado; e
AC (Actual Cost): o custo real para o trabalho realizado at o momento considerado.
O CPI (ou ndice de desempenho de custo, em portugus) [PMI, 2008] indica o desempenho do
projeto em relao aos custos. Ele pode ser usado para estimar como o projeto caminhar at
177
a sua concluso em relao aos custos. Se o valor de CPI menor que 1, ento o projeto est
custando mais que o planejado. Se o valor de SPI maior que 1, ento o projeto est custando
menos que o planejado. Se o valor 1, ento o custo do projeto est aderente ao que foi
planejado.
7.4.4 - Medidas relacionadas a Gerncia de Recursos Humanos

O processo Gerncia de Recursos Humanos tem por propsito prover a
organizao e os projetos com os recursos humanos necessrios e manter suas
competncias adequadas s necessidades do negcio [SOFTEX, 2011a].
H trs aspectos relevantes dentro do contexto do processo Gerncia de
Recursos Humanos no MR-MPS: o planejamento, recrutamento e avaliao de
recursos humanos; o treinamento organizacional para os colaboradores; e a
existncia de uma poltica de gere ncia de conhecimento. Todas as atividades
relacionadas a esse processo tm uma origem comum que o atendimento a
objetivos estratgicos estabelecidos pela organizao.
A Tabela 7.13 apresenta medidas relacionadas ao planejamento,
recrutamento e avaliao de recursos humanos. Um dos pontos crticos desse
aspecto da Gerncia de Recursos Humanos a capacidade de a organizao ter
disponveis colaboradores competentes o suficiente para que as necessidades de
negcio alinhadas aos objetivos estratgicos definidos e dos projetos em execuo
sejam atendidas.
Tabela 7.13 Medidas associadas a Gerncia de Recursos Humanos.
1
Taxa mdia de rotatividade de pessoal

Nmero de colaboradores que saram da organizao no perodo / Nmero total de
colaboradores na organizao
Uma alta taxa de rotatividade de pessoal pode representar riscos para a organizao tanto
pela falta de mo de obra para executar os projetos, quanto pelo impacto negativo que pode
trazer para os projetos em execuo devido troca de profissionais. Tambm pode
representar aumentos de custos, por exemplo, devido s obrigaes legais ou necessidades de
treinamento e capacitao.
Taxa de captao de pessoal
Nmero de colaboradores contratadas pela organizao no perodo / Nmero total de
colaboradores na organizao
Esta medida deve ser avaliada em conjunto com a medida referente rotatividade de pessoal.
Caso a rotatividade seja alta e a taxa de contratao baixa, pode indicar uma tendncia de
decrscimo (ou insuficincia) da fora de trabalho da organizao que, se no planejada ou
esperada, pode representar riscos futuros.
Uma variao desta medida pode ser referente taxa de capacitao de pessoal qualificado, ou
seja, que no precise de um perodo extenso de treinamento, no onerando assim a
organizao com os custos derivados destas atividades. Indiretamente, essa medida tambm
pode dar um indicativo do poder de atrao desse tipo de profissional que a organizao
possui, indicando possivelmente uma boa imagem da organizao entre a comunidade.
Nvel de satisfao da equipe
importante para uma organizao saber o grau de satisfao de seus funcionrios. A mdio e
178
longo prazos, insatisfaes podem gerar uma alta taxa de rotatividade de pessoal ou baixa
produtividade.
Uma forma de calcular essa medida atravs de uma pesquisa de opinio para capturar o
grau de satisfao entre os colaboradores da organizao. Para cada questo de um
formulrio especfico pode-se calcular a mediana das respostas da questo considerando
valores numricos para as opes disponveis (por exemplo, 1 Discordo Plenamente; 2
Discordo; 3 Indiferente; 4 Concordo; 5 Concordo Plenamente). Por sua natureza, essa
medida, em geral, tem sua coleta realizada em perodos longos, por exemplo, a cada seis
meses.
A Tabela 7.14 apresenta medidas relacionadas ocorrncia dos

treinamentos organizacionais. Um dos pontos crticos desse aspecto da Gerncia
de Recursos Humanos a capacidade de a organizao prover a capacitao
necessria para atender aos seus objetivos estratgicos e de negcio e o quanto a
estratgia definida para isso est sendo efetiva.
Tabela 7.14 Medidas associadas a Gerncia de Recursos Humanos - treinamentos.
1
Nmero mdio de horas de treinamento por colaborador

Muitas organizaes definem metas anuais de treinamento de seus funcionrios. Esta medida
pode ser til para avaliar se essas metas esto sendo cumpridas ou no e, se for o caso, tomar
as aes corretivas necessrias.
Taxa de treinamentos organizacionais previstos no planejamento anual que so
efetivamente realizados
Nmero de treinamentos organizacionais realizados no perodo / Nmero total de
treinamentos organizacionais previstos para serem realizados no perodo
Esta medida tem por objetivo avaliar o quanto o plano de treinamento organizao est sendo
seguido na organizao. Valores baixos apurados podem ser indicativo da lentido do
programa de treinamento, o que pode impactar na qualificao geral dos colaboradores e
causar efeitos colaterais, por exemplo, na produtividade dos projetos ou no grau que os
colaboradores seguem efetivamente os processos.
A falha em realizar os treinamentos planejados tambm pode ter impacto nos objetivos
estratgicos da organizao, que devem direcionar a poltica de capacitao da organizao.
Taxa de efetividade dos treinamentos
A efetividade dos treinamentos deve ser avaliada periodicamente. Em geral, essa avaliao
feita com base na execuo de tarefas onde o que foi ensinado durante o treinamento pode ser
aplicado. Outra forma de avaliao atravs de provas ou exames.
De qualquer forma, esta medida pode indicar, em termos gerais, se os colaboradores da
organizao esto tirando proveito dos treinamentos. ndices muito baixos podem levar a
organizao a reavaliar a estratgia de treinamento adotada.
Essa medida pode ser estratificada, por exemplo, por treinamento realizado ou perodo.
A Tabela 7.15 apresenta medidas relacionadas gerncia de conhecimento.

Um dos pontos crticos desse aspecto da Gerncia de Recursos Humanos a
capacidade de a organizao implantar uma estratgia de gerncia de
conhecimento que seja efetiva, difundida entre os colaboradores e que traga
benefcios de fato.
Tabela 7.15 Medidas associadas a Gerncia de Recursos Humanos gerncia de conhecimento.
1
Nmero de itens de conhecimento

Analisar o nmero de itens de conhecimento existentes pode ser til para a organizao
avaliar a tendncia de evoluo do contedo da base de conhecimento em uso. Um nmero
pequeno pode ser esperado nos momentos iniciais de implantao do processo Gerncia de
179
Recursos Humanos. Espera-se que, com o tempo, a tendncia seja de crescimento.

Uma alternativa a esta medida avaliar a taxa de evoluo da base de conhecimento, que pode
ser calculada atravs da diviso do nmero de itens de conhecimento identificados no perodo
pelo nmero total de itens de conhecimento.
Nmero de utilizaes registrado por cada item de conhecimento
Um nmero baixo de utilizaes deve ser investigado para avaliar, por exemplo, se h falta de
institucionalizao de fato dos mecanismos associados com a gerncia de conhecimento, ou,
at mesmo, se alguns dos itens de conhecimento deveriam ser excludos da base.
Uma dificuldade para o clculo desta medida pode ser a identificao de quando e se um item
de conhecimento foi utilizado.
Uma variao desta medida pode levar em considerao a taxa de utilizaes, dividindo-se o
valor obtido pelo nmero total de itens de conhecimento existentes.
Outra variao desta medida pode ser avaliar o grau de utilidade percebido pelos usurios da
base de conhecimento de cada um dos itens cadastrados. Itens associados com valores baixos
podem ser reavaliados em relao pertinncia de permanecerem na base.
Esforo do programa de gerncia de conhecimento
Nmero de horas gastas pela equipe para realizar as atividades relacionadas gerncia de
conhecimento
A gerncia e execuo de um programa de gerncia de conhecimento em uma organizao no
uma tarefa trivial e, provavelmente, demandar esforo e dedicao. A anlise desta medida
para identificar potencial risco de no se cumprir o cronograma planejado.
O custo do programa de gerncia de conhecimento pode ser derivado de uma variao desta
medida. Essa medida, no entanto, pode no ser trivial de ser coletada.
7.4.5 - Medidas relacionadas a Gerncia de Reutilizao

O processo Gerncia de Reutilizao tem por propsito gerenciar o ciclo de
vida dos ativos reutilizveis [SOFTEX, 2011a]. O aspecto crtico relacionado a esse
processo a institucionalizao de mecanismos eficientes para a identificao,
avaliao, classificao e gerncia de ativos considerados reutilizveis pela
organizao. Tradicionalmente, a reutilizao de software esteve associada a
componentes de software e cdigo fonte, no entanto, o escopo desse processo
abrange quaisquer produtos de trabalho que a organizao classifique como
candidatos reutilizao.
Para que um ativo seja includo na base de ativos reutilizveis preciso que
ele atenda a critrios de aceitao e de certificao preestabelecidos. Um critrio
de aceitao est relacionado a um conjunto de atributos de qualidade desejveis
que credencie um ativoa fazer parte da biblioteca de ativos reutilizveis, por
exemplo, se o seu propsito est condizente com as necessidades da organizao.
Um critrio de certificao, por sua vez, atende ao que ele se prope realizar, por
exemplo, se o ativo no possui defeitos ou foi testado, no caso de componentes de
software.
A Tabela 7.16 apresenta medidas relacionadas reutilizao de software.
180
Tabela 7.16 Medidas associadas a Gerncia de Reutilizao.

1
Nmero de ativos reutilizveis

Nmero de ativos reutilizveis atualmente existentes na biblioteca de ativos reutilizveis
Analisar o nmero de ativos reutilizveis existentes pode ser til para a organizao avaliar a
tendncia de evoluo do contedo da biblioteca de ativos reutilizveis. Um nmero pequeno
pode ser esperado nos momentos iniciais de implantao do processo Gerncia de
Reutilizao, no entanto, espera-se que haja uma tendncia crescimento e, possivelmente,
mais tarde, se estabilize.
Uma alternativa a esta medida avaliar a taxa de evoluo da biblioteca de ativos
reutilizveis, que pode ser calculada atravs da diviso do nmero de ativos reutilizveis
identificados no perodo pelo nmero total de ativos reutilizveis.
Nmero de reutilizaes por ativo reutilizvel
Um nmero baixo de reutilizaes deve ser investigado para avaliar, por exemplo, se h falta
de institucionalizao de fato dos mecanismos de reutilizao, se as reutilizaes continuam
acontecendo indevidamente de maneira ad hoc ou, at mesmo, se alguns dos ativos
considerados reutilizveis deveriam ser descontinuados como tal.
Uma variao desta medida pode levar em considerao a taxa de reutilizaes, dividindo-se o
valor obtido pelo nmero total de ativos reutilizveis existentes.
Taxa de ativos submetidos, mas no aceitos
Nmero de ativos reutilizveis no aceitos / Nmero total de ativos submetidos biblioteca
de ativos reutilizveis
Um grande nmero de ativos candidatos submetidos base de ativos reutilizveis e no
aceitos pode indicar um desconhecimento dos colaboradores do tipo de ativo reutilizvel
desejado e/ou esperado na organizao. Devido a isso pode ser necessrio reforar o
treinamento dos colaboradores ou reavaliar os tipos de ativos reutilizveis de interesse da
organizao.
Um nmero baixo de ativos submetidos pode indicar falta de interesse dos colaboradores ou
uma saturao da biblioteca de ativos reutilizveis (o que deve ser confirmado a partir da
anlise do contedo atual e taxa de evoluo da biblioteca de ativos reutilizveis).
Taxa de ativos aceitos, mas no certificados
Nmero de ativos reutilizveis no certificados / Nmero total de ativos aceitos na
biblioteca de ativos reutilizveis
Um grande nmero de ativos aceitos na biblioteca, porm no certificados, pode indicar um
grau baixo de qualidade dos candidatos a ativos submetidos. Devido a isso, pode ser
necessrio reavaliar os critrios de qualidade (nem sempre o melhor o que vivel para
organizao) ou investir mais esforo na adequao dos ativos candidatos s caractersticas
de qualidade desejveis e/ou esperadas pela organizao.
7.5 Medio no Nvel D do MR-MPS

O nvel D do MR-MPS no acrescenta nenhum novo requisito ou
interpretao ao processo Medio, no entanto, esse nvel proporciona
organizao a possibilidade de definio de um conjunto de medidas relacionadas
engenharia do software, representada pelos processos Desenvolvimento de
Requisitos, Integrao do Produto, Projeto e Construo do Produto, Validao e
Verificao.
At esse nvel o modelo no prev explicitamente que atividades bsicas
presentes em qualquer ciclo de vida de desenvolvimento de software, como
codificao e testes, sejam executadas. Obviamente, para que um produto de
181
software seja considerado pronto e, portanto, possa ser entregue ao cliente de

forma adequada, essas atividades precisam ser executadas. Logo, de se imaginar
que, mesmo em nveis anteriores de maturidade, a organizao j utilize algumas
das medidas listadas nas prximas subsees. Variaes de algumas das medidas
aqui apresentadas j foram discutidas anteriormente relacionadas ao processo
Gerncia de Requisitos. Dessa forma, recomenda-se a leitura da Seo 7.2.
De forma geral, as medidas apresentadas esto preocupadas em identificar
a qualidade dos produtos intermedirios e finais de cada um dos processos do
nvel, alm do produto de software final, antes, durante e aps a homologao com
o cliente. Associadas a essas medidas esto medidas de retrabalho para avaliar o
esforo (e, indiretamente, o custo) de no se gerar uma primeira verso dos
produtos com qualidade. Apesar de as tabelas inclurem apenas uma verso da
medida de qualidade e outra para a medida de retrabalho, elas podem ser
analisadas de vrias formas, por exemplo: (i) de forma nica e isolada no contexto
de cada processo;(ii) de forma nica e isolada no contexto de cada projeto; (iii)
relacionando uma medida com outras (por exemplo, o efeito causado pela adoo
de inspees de requisitos nos testes de homologao interna e externa ou o efeito
da adoo de testes de software nas manutenes no perodo de garantia do
software); (iv) por meio de uma srie histrica entre um grupo de projetos na
organizao; (v) por meio da anlise de diferentes rodadas de testes e inspees
dentro de um mesmo projeto (para, por exemplo, avaliar quantos defeitos so
detectados e/ou inseridos em cada uma das etapas).
As medidas relativas a esse nvel tm um papel importante na
implementao dos nveis B e A do modelo, pois, certamente, estaro no caminho
crtico do desenvolvimento de software e, portanto, sero utilizadas para o
controle estatstico dos processos e gerncia quantitativa dos projetos. Desse
modo, uma definio deficiente das medidas para monitorao dos processos do
nvel D do MR-MPS, seja pela granularidade ou periodicidade inadequadas ou por
medidas que no capturem elementos importantes desses processos, pode ter
impacto negativo no programa de melhoria de processos das organizaes que
queiram alcanar a alta maturidade no desenvolvimento de software.
182
7.5.1 - Medidas relacionadas a Desenvolvimento de Requisitos

O processo Desenvolvimento de Requisitos tem por propsito definir os
requisitos do cliente, do produto e dos componentes do produto [SOFTEX, 2011a].
O ponto crtico associado a esse processo a capacidade de os projetos
conseguirem fazer boas anlises de requisitos. Diferentemente do processo
Gerncia de Requisitos, o foco no a gerncia da evoluo dos requisitos, mas sua
identificao e evoluo a ponto de garantir que tenham sido bem especificados e
estejam prontos e adequados para serem transformados em elementos de projeto
(design). Os requisitos precisam ser avaliados tanto internamente quanto
externamente para sua adequao aos propsitos dos projetos e aos anseios dos
clientes. Ento, de alguma forma, alguns dos elementos importantes deste
processo tambm tm interseo com os processos Verificao e Validao.
Para simplificao, nesta seo utilizado de forma genrica o termo
especificao de requisitos. Os requisitos podem abranger um conjunto extenso
de nomenclaturas e produtos de trabalho, como, por exemplo, documento de viso,
modelo de anlise, requisitos funcionais etc.
A importncia dos requisitos para a boa execuo do projeto foi brevemente
discutida na Seo 7.2, logo recomenda-se a sua leitura. A Tabela 7.17 apresenta
medidas relacionadas ao desenvolvimento de requisitos.
Tabela 7.17 Medidas associadas a Desenvolvimento de Requisitos.
1
Densidade de defeitos na especificao de requisitos

Nmero de defeitos identificados na especificao de requisitos / Tamanho do projeto
deve ter suas causas e efeitos para o projeto investigados.
Valores baixos associados com medidas de densidade de defeitos nem sempre so indicativos
de boa qualidade do produto de trabalho avaliado. Estas medidas devem ser correlacionadas
com outras para avaliar se os defeitos esto de fato sendo identificados ou se os
procedimentos adotados so incapazes captur-los e efeitos colaterais so gerados em outras
etapas do desenvolvimento de software e/ou produtos de trabalho.
projetos com caractersticas e funcionalidades diferentes..
Esforo de retrabalho para correo de defeitos na especificao de requisitos
de requisitos
para avaliar o impacto na conduo do projeto. Valores altos para o ndice de retrabalho
possvel indicativo de m qualidade da especificao e, consequentemente, desperdcio de
tempo e dinheiro.
183
requisitos (que foi avaliada). As anlises tambm devem ser adaptadas a estes cenrios.
retrabalho.
7.5.2 - Medidas relacionadas a Integrao do Produto

O processo Integrao do produto tem por propsito compor os
componentes do produto, produzindo um produto integrado consistente com seu
projeto, e demonstrar que os requisitos funcionais e na o-funcionais sa o satisfeitos
para o ambiente alvo ou equivalente [SOFTEX, 2011a].
Muitas organizaes confundem teste integrado com os procedimentos
necessrios para se fazer a integrao do software, que so os procedimentos, de
fato, requeridos pelo conjunto de resultados esperados desse processo. Para que
um teste de integrao seja bem sucedido, importante que todas as unidades que
sero integradas sejam adequadamente construdas de acordo com as
especificaes tcnicas e tenham tido as interfaces bem projetadas e codificadas,
de forma que os problemas identificados durante os procedimentos de integrao
tenham origem, de fato, na integrao e no nas unidades de cdigo construdas.
A Tabela 7.18 apresenta medidas relacionadas construo e integrao
dos elementos de cdigo. Algumas das medidas apresentadas podem no ser
facilmente coletadas e/ou analisadas em diferentes contextos, como nos quais o
software construdo simples ou h procedimentos automatizados para a
realizao das integraes.
Tabela 7.18 Medidas associadas a Integrao do Produto.
1
Densidade de defeitos identificados nos testes de integrao

Nmero de defeitos identificados no teste de integrao / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas na construo das unidades de
cdigo e suas interfaces necessrias para a integrao. As causas e efeitos desses problemas
para o projeto devem ser investigados.
Caso os testes de integrao sejam superficiais ou os projetos comumente executados na
organizao no necessitem, na prtica, de procedimentos elaborados de integrao, os
valores coletados para esta medida provavelmente no apresentaro insumos suficientes para
anlises adequadas.
184
Esforo de retrabalho para correo de defeitos em testes de integrao

Nmero de horas gastas pela equipe para corrigir os defeitos identificados durante a
execuo dos testes de integrao
Os gastos com os acertos decorrentes dos testes de integrao deveriam ser relatados e
analisados para avaliar o impacto na conduo do projeto. Valores altos para o ndice de
retrabalho possvel indicativo de m qualidade da codificao e do projeto de interfaces e,
consequentemente, desperdcio de tempo e dinheiro.
total do projeto ou o esforo gasto para construo da primeira verso do cdigo de unidades.
As anlises tambm devem ser adaptadas a esses contextos.
retrabalho.
7.5.3 - Medidas relacionadas a Projeto e Construo do Produto

O processo Projeto e Construo do Produto tem por propsito projetar,
desenvolver e implementar solues para atender aos requisitos [SOFTEX, 2011a].
Muitas vezes, principalmente em projetos que utilizam modelagem orientada a
objetos (leia-se, na prtica, uso de diagramas da UML), as atividades de anlise e
projeto (design) se confundem em algum momento, pois vrios dos diagramas
utilizados podem servir tanto para um propsito quanto para outro. De uma forma
geral, deve-se ter em mente que, tipicamente, as atividades de anlise (de cujo foco
o processo Desenvolvimento de Requisitos) esto preocupadas em descrever 'o
que precisa ser feito', enquanto que as atividades de projeto (de cujo foco o
processo Projeto e Construo do Produto) esto preocupadas em descrever 'como
deve ser feito'. Esse processo tambm prev a codificao e o teste do software,
tendo integrao, dessa forma, com o processo Integrao do Produto. Essas
atividades tendem a ser mais bem sucedidas quanto melhor for o detalhamento
tcnico do projeto (design) do software.
Para simplificao, nesta seo os elementos de projeto so mencionados de
forma genrica como 'especificao tcnica' e podem abranger um conjunto
extenso de nomenclaturas e produtos de trabalho, como detalhamento tcnico,
algoritmos estruturados, modelos de classes, modelos de entidade relacionamento
de projeto ou fsico, diagramas de sequncia, diagramas de componentes e de
implantao etc.
A Tabela 7.19 apresenta medidas relacionadas s atividades de projeto
(design) e construo do produto.
185
Tabela 7.19 Medidas associadas a Projeto e Construo do Produto.

1
Densidade de defeitos identificados na especificao tcnica

Nmero de defeitos identificados na especificao tcnica / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas na especificao tcnica e deve
ter suas causas e efeitos para o projeto investigados.
Variaes dessa medida, em geral, incluem classificao dos defeitos por origem (por
exemplo, falha na especificao de requisitos, inserido durante a construo da especificao
tcnica etc.), complexidade/impacto para o projeto (simples, mdio, alto) ou elemento de
projeto afetado (por exemplo, diagrama de casos de uso, diagrama de sequencia, modelo
entidade-relacionamento etc.). A estratificao da informao pode possibilitar anlises mais
detalhadas e aes mais efetivas.
Esforo de retrabalho para correo de defeitos na especificao tcnica
tcnica
Os gastos com os acertos na especificao tcnica deveriam ser relatados e analisados para
avaliar o impacto na conduo do projeto. Valores altos para o ndice de retrabalho possvel
indicativo de m qualidade da especificao e, consequentemente, desperdcio de tempo e
dinheiro.
total do projeto ou o esforo gasto para elaborao da primeira verso da especificao
tcnica avaliada. As anlises tambm devem ser adaptadas e esses contextos.
retrabalho.
Grau de cobertura da especificao tcnica em relao especificao de requisitos
Nmero de requisitos para os quais foram feitas especificaes tcnicas / Nmero total de
requisitos do projeto
O objetivo desta medida avaliar a taxa de requisitos para os quais foi elaborada uma
especificao tcnica. comum(mas no quer dizer que seja adequado) que, para alguns
requisitos mais simples, alguns projetos no elaborem especificaes tcnicas detalhadas,
visando economia de recursos. No entanto, a consequncia dessa deciso pode ser excesso
de defeitos e retrabalho nas etapas posteriores do de desenvolvimento de software.
Dessa forma, essa medida pode ser til para correlacionar com outras medidas associadas ao
nmero de defeitos encontrados nos diferentes tipos de testes realizados (em geral, mas no
somente, caso a origem deles seja decorrente de falhas na especificao tcnica ou de
requisitos).
Densidade de defeitos identificados nos testes de unidade
Nmero de defeitos identificados no teste de unidade / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas na construo das unidades de
cdigo e deve ter suas causas e efeitos para o projeto investigados.
Nem sempre comum ou prtico o registro dos problemas ocorridos durante a execuo dos
testes de unidade devido forma como so executados. Por exemplo, rotinas de testes
automatizados executados automaticamente durante o commit do cdigo fonte ou
obrigatoriedade de os desenvolvedores executarem um roteiro simplificado de testes antes de
186
dar a tarefa de codificao finalizada. Nesses casos, os resultados das atividades executadas
podem no fornecer resultados suficientes e/ou confiveis para que as anlises sejam
adequadas.
Esforo de retrabalho para correo de defeitos identificados em testes de unidade
execuo dos testes de unidade
Os gastos com os acertos decorrentes dos testes de unidade deveriam ser relatados e
retrabalho possvel indicativo de m qualidade da codificao realizada e,
consequentemente, desperdcio de tempo e dinheiro.
total do projeto ou o esforo gasto para construo da primeira verso do cdigo de unidades.
As anlises tambm devem ser adaptadas e esses contextos.
retrabalho.
7.5.4 - Medidas relacionadas a Validao

O processo Validao tem por propsito confirmar que um produto ou
componente do produto atendera a seu uso pretendido quando colocado no
ambiente para o qual foi desenvolvido [SOFTEX, 2011a]. A validao est
associada com a garantia de que os requisitos do software atendem, de fato, ao que
desejado pelos clientes finais. Apesar de o modelo no especificar explicitamente
em que momentos os procedimentos de validao devam ser executados, no
uma boa prtica fazer essa avaliao apenas ao final do projeto. Sabe-se que
quanto mais cedo dentro do ciclo de desenvolvimento do software problemas nos
requisitos forem identificados, menos custosas sero as atividades para removlos.
A Tabela 7.20 apresenta medidas relacionadas validao de software.
Tabela 7.20 Medidas associadas a Validao.
1
Densidade de defeitos identificados em avaliao de requisitos

Nmero de defeitos identificados pelo cliente na especificao de requisitos / Tamanho do
projeto
deve ter suas causas e efeitos para o projeto investigados.
187
Esforo de retrabalho para correo de defeitos nos requisitos

de requisitos
para avaliar o impacto na conduo do projeto. Valores altos para o ndice de retrabalho
possvel indicativo de m qualidade dos produtos de trabalho das atividades anteriores aos
testes e, consequentemente, desperdcio de tempo e dinheiro.
requisitos (que foi avaliada). As anlises tambm devem ser adaptadas a esses cenrios.
retrabalho.
Densidade de defeitos identificados nos testes de homologao
Nmero de defeitos identificados no teste de homologao / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas nas etapas anteriores do
desenvolvimento de software e deve ter suas causas e efeitos para o projeto investigados.
exemplo, item originado por problema de algoritmo, nos requisitos, no projeto, por teste mal
realizado etc.), complexidade/impacto para o projeto (simples, mdio, alto) ou por mdulo
onde o problema foi identificado. A estratificao da informao pode possibilitar anlises
mais detalhadas e aes mais efetivas.
Esta medida pode ser adaptada para se referir homologao interna ou homologao
externa. De fato, no parece adequado associar os dois eventos a uma nica medida.
Esforo de retrabalho para correo de defeitos em testes de homologao
execuo dos testes de homologao
Os gastos com os acertos decorrentes dos testes de homologao deveriam ser relatados e
retrabalho possvel indicativo de m qualidade da especificao e, consequentemente,
desperdcio de tempo e dinheiro.
total do projeto ou o esforo gasto nas atividades de testes anteriores. As anlises tambm
devem ser adaptadas e esses contextos.
retrabalho.
Esta medida pode ser adaptada para se referir homologao interna ou homologao
externa. De fato, no parece adequado associar os dois eventos a uma nica medida.
Densidade de defeitos identificados durante a homologao
Nmero de defeitos identificados durante a homologao / Tamanho do projeto
A ocorrncia de defeitos durante a homologao deveria ser baixa, pois espera-se que os
problemas sejam identificados ainda em ambiente de testes. Uma ocorrncia alta de defeitos
durante a homologao provavelmente trar custos elevados associados ao retrabalho e,
tambm, pode ser causa de insatisfao do cliente.
Alm disso, a anlise desta medida segue o mesmo padro associado com a medida Densidade
de defeitos identificados nos testes de homologao.
188
Esforo de retrabalho para correo de defeitos identificados durante a homologao

homologao
A anlise desta medida segue o mesmo padro associado com a medida Esforo de retrabalho
para correo de defeitos em testes de homologao.
7.5.5 - Medidas relacionadas a Verificao

O processo Verificao tem por propsito confirmar que cada servio e/ou
produto de trabalho do processo ou do projeto atende apropriadamente os
requisitos especificados [SOFTEX, 2011a]. A verificao est associada com os
procedimentos necessrios para garantir que, a cada etapa do desenvolvimento de
software, os produtos de uma etapa do desenvolvimento de software sejam
adequadamente transformados em outros de forma ordenada, preservando as
informaes importantes, evoluindo-as de acordo com as necessidades do
processo de software em uso, sem deturp-las ou inserindo defeitos. Em teoria,
qualquer produto de trabalho pode ser verificado, porm, em geral, a execuo
desse processo est associada ao documento de requisitos (por exemplo, por meio
de inspees ou revises por pares). Alm disso, espera-se que sejam realizados
testes de forma a avaliar a incidncia de defeitos na codificao.
A Tabela 7.21 apresenta medidas relacionadas verificao de software.
Tabela 7.21 Medidas associadas a Verificao.
1
Densidade de defeitos identificados em revises por pares

Nmero de defeitos identificados nas revises por pares / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas nos documentos produzidos e
deve ter suas causas e efeitos para o projeto investigados. Em teoria todos os documentos
produzidos (sejam no escopo de projetos de desenvolvimento ou decorrente de atividades no
mbito organizacional) podem ser alvo de revises por pares, no entanto, mais comum que
estas atividades se refiram ao documento de requisitos em suas mais diferentes formas, como
especificao de requisitos, documento de viso ou casos de uso.
Variaes dessa medida, em geral, incluem classificao dos defeitos por tipo de documento
avaliado, tipo de defeito (por exemplo, para o documento de requisitos: omisso, ambiguidade
etc.) ou complexidade/impacto para o projeto (simples, mdio, alto). A estratificao da
informao pode possibilitar anlises mais detalhadas e aes mais efetivas.
Esforo para realizao de revises por pares
Nmero de horas gastas pela equipe para executar as revises por pares
Esta medida pode ser til para se correlacionar com a densidade de defeitos identificados e
m qualidade da documentao pode ser a insuficincia de informaes obtidas para a sua
189
elaborao, atrasos no cronograma que levam as atividades a serem executadas de forma mais
rpida e com menos qualidade, falta de treinamento dos profissionais etc.
Densidade de defeitos identificados nos testes de software
Nmero de defeitos identificados nos testes de software / Tamanho do projeto
Um nmero alto de defeitos indicativo claro de problemas na elaborao do software. As
causas e efeitos destes problemas para o projeto devem ser investigados.
exemplo, item originado por problema de algoritmo, nos requisitos, no projeto, por casos de
testes mal especificados etc.), complexidade/impacto para o projeto (simples, mdio, alto) ou
por mdulo onde o problema foi identificado. A estratificao da informao pode possibilitar
anlises mais detalhadas e aes mais efetivas.
Muitas vezes os problemas identificados nos testes de software so decorrentes de problemas
em etapas anteriores do processo de desenvolvimento, por isso as anlises devem ser feitas
com cuidado e utilizao boas informaes de contexto e, talvez, correlacionando com outras
medidas coletadas.
Esforo para realizao de testes
Nmero de horas gastas pela equipe para executar os testes
Esta medida pode ser til para se correlacionar com a densidade de defeitos identificados e
m qualidade da verso obtida para testes, atrasos no cronograma que levam as atividades a
serem executadas de forma mais rpida e com menos qualidade, falta de treinamento dos
profissionais etc.
Esforo de retrabalho para correo de defeitos
Nmero de horas gastas pela equipe para corrigir os defeitos identificados
Os gastos com os acertos dos defeitos identificados deveriam ser relatados e analisados para
avaliar o impacto na conduo do projeto. Valores altos para o ndice de retrabalho possvel
indicativo de m qualidade dos documentos avaliados (no caso de inspees) ou do cdigo
produzido (no caso dos testes) e, consequentemente, desperdcio de tempo e dinheiro.
total do projeto ou o esforo gasto nas atividades anteriores que produziram os produtos de
trabalho avaliados. As anlises tambm devem ser adaptadas e esses contextos.
retrabalho.
Esta medida pode ser adaptada para se referir a revises por pares ou testes. De fato, no
parece adequado associar os dois eventos a uma nica medida.
Taxa de defeitos corrigidos
Nmero de defeitos identificados nos testes que foram corrigidos / Nmero total de defeitos
identificados nos testes
Nem sempre possvel ou desejvel corrigir todos os problemas identificados sejam nos
testes ou nas inspees. Os motivos podem ser devido, por exemplo, criticidade baixa dos
problemas ou baixo risco representado pela existncia do problema para o desenvolvimento
de software ou o software em operao.
A existncia desta medida, no entanto, pode ser til para dar visibilidade a estes valores e, se
for o caso, tomar as aes pertinentes.
A estratificao desta medida pode ser a mesma utilizada para o registro dos defeitos
analisados.
Taxa de cobertura de testes
Nmero de funcionalidades para os quais foram executados testes / Nmero total de
funcionalidades
Muitas vezes, algumas funcionalidades do software no so completamente testadas. Essa
medida tem por finalidade dar visibilidade a esse fato. Muitos problemas podem decorrer da
190
10
falta de testes apropriados. Dessa forma, esta medida pode ser til de ser correlacionada a
outras de forma a possibilitar uma anlise abrangente do cenrio na organizao.
Densidade de defeitos identificados aps o software entrar em produo
Nmero de defeitos identificados aps o software entrar em produo / Tamanho do projeto
A ocorrncia de defeitos durante a homologao deveria ser baixa, pois espera-se que os
problemas sejam identificados ainda em ambiente de testes, no mximo ainda durante a
homologao. Uma ocorrncia alta de defeitos durante aps o software entrar em produo
provavelmente trar custos elevados associados ao retrabalho e, tambm, pode ser causa de
insatisfao do cliente.
Os valores obtidos para esta medida deveriam ser avaliados em conjunto com a densidade de
defeitos detectados no teste do software.:
Uma alta taxa de defeitos identificados no teste do software e baixa taxa de defeitos
identificados aps o software entrar em produo pode significar que os testes esto
bons.
Uma baixa taxa de defeitos identificados no teste do software e baixa taxa de defeitos
identificados aps o software entrar em produo pode significar que os testes esto bons
e, alm disso, que o produto foi produzido com poucos defeitos.
Uma baixa taxa de defeitos identificados no teste do software e alta taxa de defeitos
identificados aps o software entrar em produo pode significar que os testes no esto
bons.
Uma alta taxa de defeitos identificados no teste de software e uma alta taxa de defeitos
identificados aps o software entrar em produo pode significar que o produto est
sendo produzido com muitos defeitos.
Alm disso, a anlise desta medida segue o mesmo padro associado com a medida Densidade
de defeitos identificados nos testes de software.
Esforo de retrabalho para correo de defeitos identificados aps o software entrar em
produo
Nmero de horas gastas pela equipe para corrigir os defeitos identificados aps o software
entrar em produo
A anlise desta medida segue o mesmo padro associado com a medida Esforo de retrabalho
para correo de defeitos.
retrabalho. Esse custo, muitas vezes, representa uma despesa no prevista pela equipe de
desenvolvimento e pode se tornar crtico para a organizao se no estiver adequadamente
coberto por um perodo de garantia contratual.
Tempo mdio entre falhas do software
Intervalo de tempo entre duas ocorrncias sucessivas de falhas aps o software entrar em
produo
As falhas podem ser ocasionadas por um defeito do software ou algum outro fator externo.
Em geral, os problemas do primeiro tipo so mais crticos para a equipe de desenvolvimento,
pois provavelmente foram inseridos (ou no identificados) ainda nessa etapa. Os problemas
do segundo tipo podem ter causas variadas (por exemplo, falhas na infraestrutura de
telecomunicaes ou alterao de interface com outros sistemas), apesar do impacto para o
usurio. As organizaes devem ser capazes de identificar os tipos de problemas mais comuns
a ocorrer e, se for o caso, estratificar esta medida.
O tempo entre duas ocorrncias sucessivas de falhas pode ser til para indicar o quo
frequente so as falhas de um sistema e pode ser um indicador do quanto de disponibilidade
deve ser alocada s equipes de manuteno do software. Em geral, espera-se que, ao longo do
tempo, com o software se tornando mais maduro, os intervalos entre falhas fiquem mais
espaados.
Tambm pode ser interessante analisar a evoluo desta medida ao longo do tempo para a
identificao de uma tendncia. Se o intervalo de tempo entre falhas passar a ser bastante
reduzido ao longo do tempo, pode ser sinal de que o software est em um perodo de
decaimento e que pode ser o caso de substitu-lo por outro ou investir em uma nova verso.
Esta medida pode ser importante para organizaes que desenvolvem produto, onde os
custos relacionados manuteno no so pagos diretamente pelos clientes, ou em que a
identificao de um erro crtico deva gerar verses de manuteno emergenciais/urgentes.
191
11
Tempo mdio para correo de um defeito

Tempo gasto para a correo dos defeitos identificados aps o software entrar em produo
Essa medida pode ser til para avaliar o intervalo de tempo entre sucessivas verses de
manuteno de um produto de software. Valores altos podem indicar a incapacidade de a
organizao atualizar o software em uso pelo cliente de maneira adequada, tambm podem
ser um indicativo que a complexidade dos defeitos e das correes alta (possivelmente com
alto custo e risco associados).
7.6 Medio no Nvel C do MR-MPS

Os processos do nvel C do MR-MPS complementam os requisitos do modelo
em relao gerncia de projetos (por meio do processo Gerncia de Riscos),
engenharia (por meio do processo Desenvolvimento para Reutilizao) e, tambm,
processos de apoio (por meio do processo Gerncia de Decises).
Nenhuma caracterstica especfica esperada de organizaes que
implementam esse nvel em relao ao anterior. No entanto, ele importante
porque prepara a organizao para os desafios presentes na alta maturidade em
dois aspectos principais: a exigncia de uma gerncia mais proativa e menos
reativa, que uma diferena bem importante da gerncia de riscos exigida no nvel
G daquela exigida no nvel C e a exigncia de se documentar decises importantes e
detalhar o raciocnio por trs delas. Essas caractersticas so importantes porque a
gerncia proativa um aspecto relevante da Gerncia de Projetos no nvel B e
porque, sem o registro de informaes de contexto relevante sobre os projetos, a
anlise das medidas, conforme requerida nos nveis B e A, pode ser impactada
negativamente.
7.6.1 - Medidas relacionadas a Desenvolvimento para Reutilizao

O processo Desenvolvimento para Reutilizao tem por propsito
identificar oportunidades de reutilizao sistemtica de ativos na organizao e,
se possvel, estabelecer um programa de reutilizao para desenvolver ativos a
partir de engenharia de domnios de aplicao [SOFTEX, 2011a]. O objetivo desse
processo a conduo do programa de reutilizao sistemtica da organizao por
meio de tcnicas de engenharia de domnio. Um programa desse tipo custoso e
no necessariamente aplicvel a qualquer organizao. Dessa forma, o esforo
associado execuo do programa e efetiva reutilizao dos ativos de domnio
adquiridos ou construdos so fatores crticos a serem considerados. A Tabela 7.22
apresenta medidas relacionadas ao desenvolvimento para reutilizao.
192
Tabela 7.22 Medidas associadas a Desenvolvimento para Reutilizao.

1
Esforo associado ao programa de reutilizao sistemtica

Nmero de horas gastas para a execuo das atividades do programa de reutilizao
sistemtica
Como um programa de reutilizao sistemtica custoso para a organizao, os valores
apurados para esta medida devem ser analisados com cuidado e comparados com os
oramentos disponveis.
Valores altos podem indicar estouro dos valores aprovados. Valores baixos podem indicar
problemas ou lentido na execuo das atividades necessrias para a criao da infraestrutura
necessria para a conduo do programa ou execuo das atividades de construo dos
ativos de domnio.
Taxa de propostas de ativos de domnio avaliadas e aprovadas
Nmero de propostas de reutilizao de domnio aprovadas / Nmero de propostas de
reutilizao de ativos de domnio avaliadas
Um valor baixo para esta medida pode indicar um nmero excessivo de propostas de
reutilizao, por exemplo, devido falta de foco dos colaboradores da organizao. Outra
razo pode estar relacionada ao foco escolhido e incapacidade do programa de reutilizao
sistemtica atender s necessidades dos colaboradores da organizao.
Taxa de ativos de domnio adquiridos ou desenvolvidos em relao s propostas
aprovadas
Nmero de ativos de domnio adquiridos ou desenvolvidos / Nmero total de propostas de
reutilizao de domnio aprovadas
Um valor baixo para esta medida pode indicar baixo investimento da organizao no
povoamento da sua base de ativos de domnio.
Nmero de reutilizaes por ativo de domnio
Um valor baixo para esta medida pode indicar que os ativos de domnio no esto sendo
reutilizados de forma sistemtica, apesar do esforo e custo necessrios para adquiri-los ou
desenvolv-los. Os valores obtidos devem ser analisados com cuidado para identificar se o
programa de reutilizao sistemtica da organizao precisa ser revisto em relao
pertinncia, escopo ou prioridade na escolha dos ativos de domnio que sero adquiridos ou
construdos.
7.6.2 - Medidas relacionadas a Gerncia de Decises

O processo Gerncia de Decises tem por propsito analisar possveis
decises crticas usando um processo formal, com critrios estabelecidos, para
avaliao das alternativas identificadas [SOFTEX, 2011a]. Um aspecto importante
relacionado a esse processo o registro do raciocnio por trs da tomada de
decises que sejam crticas para um projeto ou em algum contexto organizacional,
a partir da avaliao de solues alternativas por meio de critrios objetivos
estabelecidos. A Tabela 7.23 apresenta medidas relacionadas gerncia de
decises.
Tabela 7.23 Medidas associadas a Gerncia de Decises.
1
Taxa de decises tomadas que no seguiram os critrios objetivos estabelecidos

Nmero de decises que no seguiram os critrios objetivos definidos / Nmero total de
decises que utilizaram o processo formal
Um valor elevado para esta medida pode indicar que os critrios definidos para a escolha das
alternativas de soluo no so totalmente adequados ou que decises polticas esto sendo
tomadas em detrimento a decises tcnicas.
193
Taxa de decises tomadas com base nos critrios estabelecidos consideradas adequadas
Nmero de decises que utilizaram o processo formal e foram consideradas adequadas /
Nmero total de decises que utilizaram o processo formal
Por mais que os critrios para a escolha das alternativas de soluo tenham sido bem
formulados e avaliados, nada garante que a deciso tomada tenha sido adequada. Um valor
baixo para esta medida pode indicar a necessidade de reviso nos critrios utilizados ou no
rigor da avaliao realizada em relao a esses critrios.
7.6.3 - Medidas relacionadas a Gerncia de Riscos

O processo Gerncia de Riscos tem por propsito identificar, analisar,
tratar, monitorar e reduzir continuamente os riscos em nvel organizacional e de
projeto [SOFTEX, 2011a]. A gerncia de riscos um importante mecanismo para o
controle do projeto ao tentar identificar e quantificar o impacto de determinados
eventos no projeto. Para que a gerncia de riscos seja efetiva, espera-se a definio
de um plano de respostas aos riscos objetivando a identificao de aes que
tenham objetivo de evit-los (as aes de mitigao) e, na impossibilidade disso, de
minimizar os efeitos de sua ocorrncia (as aes de contingncia). A Tabela 7.24
apresenta medidas relacionadas gerncia de riscos em projetos de software.
Tabela 7.24 Medidas associadas a Gerncia de Riscos.
1
Evoluo no grau de exposio a riscos

Srie histrica com o valor mdio de exposio a riscos do projeto
A exposio aos riscos geralmente calculada pela multiplicao do seu impacto pela sua
probabilidade de ocorrncia.
O ideal seria que ao longo do projeto a exposio aos riscos fosse diminuda ou, pelo menos, se
mantivesse estvel. Mudanas abruptas na exposio a riscos podem indicar a necessidade de
uma maior ateno por parte da gerncia do projeto.
Taxa de aes de mitigao tomadas que surtiram efeito desejado
Quantidade de aes de mitigao que, depois de tomadas, surtiram o efeito desejado de
reduzir o impacto do risco / Quantidade total de aes de mitigao tomadas
Um nmero excessivo de aes de mitigao tomadas que no surtiram efeito pode indicar
uma inadequao dessas aes ou de sua conduo de forma efetiva.
Taxa de aes de contingncia tomadas que surtiram efeito desejado
Quantidade de aes de contingncia que, depois de tomadas, surtiram o efeito desejado ao
evitar que o risco acontecesse /Quantidade total de aes de contingncia tomadas
Um nmero excessivo de aes de contingncia tomadas que no surtiram efeito pode indicar
uma inadequao destas aes ou da de sua conduo de forma efetiva.
Taxa de riscos no previstos que ocorreram
Quantidade de riscos que s foram identificados aps sua ocorrncia / Quantidade total de
riscos identificados
Um nmero grande de riscos que acontecem sem serem previstos pode ser um indicativo de
planejamento ineficiente ou, at mesmo, de caos durante a execuo do projeto com a possvel
perda de controle por parte do gerente do projeto.
Esforo gasto na gerncia de riscos
Nmero de horas gastas pelo gerente do projeto realizando atividades relacionadas
gerncia de riscos
Um esforo pequeno empregado na gerncia de riscos pode ser um indicativo de falta de
dedicao mnima necessria para uma gerncia proativa dos riscos do projeto. Um valor alto
para a medida pode indicar a existncia de muitos problemas nos projetos a serem tratados, o
que pode ter efeitos sobre viabilidade geral do projeto.
194
7.7 Medio no Nvel B do MR-MPS

O objetivo final do nvel B do MR-MPS a implantao na organizao do
controle estatstico de processos e da gerncia quantitativa dos projetos de
software. Diferentemente dos nveis anteriores do modelo, no h a definio de
novos processos. As caractersticas deste nvel sa o atendidas pela implementaa o
dos atributos de processo AP 4.1 (O processo e medido) e AP 4.2 (O processo
controlado) e da evoluo do processo Gerncia de Projetos.
O ponto de partida para a implantao do controle estatstico de processos
na organizao a identificao dos subprocessos crticos que possam apoiar a
organizao a atender os seus objetivos quantitativos de qualidade e de
desempenho que, por sua vez, apoiam os objetivos de negcio relevantes da
organizao. A partir disso, a medio adaptada e evoluda para possibilitar a
anlise do comportamento dos subprocessos selecionados de forma a evidenciar
que so estveis e capazes e, se pertinente, a efetuar as modificaes necessrias
para que os demais se tornem estveis e capazes. Em paralelo a isso, modelos de
desempenho devem ser gerados para possibilitar que os projetos tenham uma
gerncia proativa baseada no uso de mtodos e tcnicas de gerncia quantitativa.
Apesar de a descrio dos resultados esperados poder indicar que a
implementao do nvel B simples, isso no verdade. Muitas vezes, as anlises
necessrias para caracterizar o desempenho dos processos so bastante
elaboradas e no triviais. Tambm comum que as medidas em uso na
organizao no permitam tais anlises, o que faz com que seja necessrio
reavaliar e modificar a infraestrutura de medio da organizao, o que pode levar
muito tempo e consumir muito esforo.
Procedimentos associados com o controle estatstico de processos e a
gerncia quantitativa dos projetos foram discutidos nos Captulos 4, 5 e 6 deste
livro. As subsees a seguir descrevem medidas que podem ser utilizadas para a
monitorao dos elementos crticos deste nvel do MR-MPS.
7.7.1 - Medidas relacionadas ao Controle Estatstico de Processos

No h um processo especfico no MR-MPS que preveja a implementao do
controle estatstico de processos. Essas atividades esto associadas com o nvel B
195
(Gerenciado Quantitativamente) e so exigidas pelo modelo pela implementao

dos atributos de processo AP 4.1 (O processo e medido) e AP 4.2 (O processo e
controlado).
O AP 4.1 evidencia o quanto os resultados de medio so usados para
assegurar que a execuo do processo atinge os seus objetivos de desempenho e
apoia o alcance dos objetivos de negcio definidos [SOFTEX, 2011a], enquanto o
AP 4.2 evidencia o quanto o processo controlado estatisticamente para produzir
um processo estvel, capaz e previsvel dentro de limites estabelecidos [SOFTEX,
2011a]. Dessa forma, o aspecto crtico relacionado ao conjunto desses atributos de
processo o quanto a organizao consegue implementar o controle estatstico de
seus processo crticos, tema discutido nos Captulos 4, 5 e 6 deste livro. A
Tabela7.25 apresenta medidas relacionadas monitorao da capacidade da
organizao de implementar o controle estatstico de processos.
Tabela 7.25 Medidas associadas a Controle Estatstico de Processos.
1
Taxa de subprocessos considerados crticos que so estveis

Nmero de subprocessos considerados crticos que so estveis / Nmero total de
subprocessos considerados crticos
Esta medida pode permitir organizao avaliar o quanto os subprocessos considerados
crticos j conseguiram ser analisados sob a tica do controle estatstico de processos e foram
considerados estveis.
Valores baixos desta medida podem no invalidar os esforos por trs do controle estatstico
de processos, porm podem indicar um ponto de ateno de que preciso maior esforo para
anlise das medidas existentes, redefinio de algumas medidas em anlise ou uma
reavaliao dos subprocessos considerados crticos para a organizao.
Taxa de subprocessos considerados crticos que so capazes
Nmero de subprocessos considerados crticos que so capazes / Nmero total de
subprocessos estveis
No basta um subprocesso considerado crtico para a organizao ser considerado estvel, ele
tambm deve ser capaz de atender a objetivos de qualidade e de desempenho definidos pela
organizao de forma a apoiar os objetivos organizacionais.
Esta medida tem por objetivo monitorar quantos dos processos estveis j atendem aos
objetivos de negcio da organizao. Valores baixos podem fazer com que a organizao
reveja os objetivos ou reavalie os subprocessos considerados pertinentes para atend-los.
Taxa de subprocessos considerados crticos para os quais h modelo de desempenho
estabelecido
Nmero de subprocessos considerados crticos associados com um modelo de desempenho
/Nmero total de subprocessos considerados crticos
Para que a gerncia quantitativa possa ser posta em prtica na organizao, necessrio no
apenas que os subprocessos considerados crticos estejam estveis e capazes, mas tambm
que tenham sido definidos modelos de desempenho que correlacionem a execuo dos
subprocessos ao longo do ciclo de vida do desenvolvimento de software de forma a
possibilitar a gerenciamento do projeto com base no uso de tcnicas estatsticas e
quantitativas. Esta medida, portanto, pode auxiliar a organizao a avaliar a definio de
modelos de desempenho que correlacionem os subprocessos considerados crticos.
Valores baixos desta medida podem indicar a necessidade de se rever os as medidas adotadas
e/ou subprocessos considerados crticos na organizao.
196
Esforo das atividades relacionadas a controle estatstico de processos

Nmero de horas gastas pela equipe para realizar as atividades relacionadas ao controle
estatstico dos processos
A execuo das atividades necessrias para analisar as medidas e processos da organizao
sob a luz do controle estatstico de processos grande e envolve trabalho bastante
especializado. Dessa forma, por no ser uma tarefa trivial, provavelmente, demandar
bastante esforo e dedicao.
A anlise desta medida pode ser til para controlar a alocao da equipe s atividades
relacionadas e tambm para identificar potencial risco de no se cumprir o cronograma do
programa de melhoria de processos em curso.
Variao do desempenho dos subprocessos considerados para controle estatstico de
processos
Diferena dos valores dos limites de controle de duas baselines sucessivas de um subprocesso
O desempenho de um subprocesso caracterizado pelos valores dos limites de controle de
sua baseline de desempenho. Esta medida mede o quanto o desempenho de um subprocesso
variou, considerando sucessivas baselines.
Esta medida pode ser utilizada em conjunto com as duas anteriores de forma a avaliar se h
ou no uma tendncia que indique que as distribuies dos subprocessos considerados
crticos estejam se tornando estveis e/ou capazes.
Por exemplo, o fato de um subprocesso estvel e ainda no capaz ter ao longo do tempo o seu
desempenho melhorado em baselines sucessivas pode indicar maiores chances de ele atingir o
nvel de capacidade desejado pela organizao.
7.7.2 - Medidas relacionadas evoluo de Gerncia de Projetos no

nvel B
projeto [SOFTEX, 2011a].
A partir do nvel B, alm dos resultados j previstos at o nvel E do MRMPS, o processo Gerncia de Projetos evolui para considerar a gerncia do projeto
com um enfoque quantitativo. Devido a esse enfoque, os modelos de desempenho
criados pela execuo dos resultados esperados de atributos de processo que
compo em os AP 4.1 (O processo e medido) e AP 4.2 (O processo e controlado)
devem ser utilizados em conjunto com te cnicas estatsticas e outras te cnicas
quantitativas de modo a atender os objetivos de qualidade e de desempenho do
processo definidos para o projeto em questo.
A Tabela 7.26 apresenta medidas relacionadas gerncia quantitativa de
projetos.
197
Tabela 7.26 Medidas associadas a Gerncia de Projetos nvel B.

1
Taxa de projetos na organizao que utilizam gerncia quantitativa

Nmero de projetos que utilizam gerncia quantitativa / Nmero total de projetos em
execuo na organizao
Esta medida pode ser til para a organizao avaliar o quanto tcnicas estatsticas e outras
tcnicas quantitativas so de fato utilizadas pelos projetos.
O valor baixo desta medida pode indicar que os projetos no esto se beneficiando dos
esforos da organizao para a implantao do controle estatstico de processos ou a
incapacidade dos modelos de desempenho gerados em atender as necessidades reais dos
projetos em execuo.
Uma variao desta medida pode ser considerar os dados coletados de forma acumulativa. Por
exemplo, aps ter sido implantado o Controle Estatstico de Processos, avaliar quantos
projetos foram desenvolvidos at o momento e quantos usaram gerncia quantitativa.
Taxa de projetos sob gerncia quantitativa que atenderam aos objetivos de qualidade e
desempenho definidos
Nmero de projetos sob gerncia quantitativa que atenderam aos objetivos de qualidade e
desempenho definidos / Nmero total de projetos sob gerncia quantitativa na organizao
Um nmero baixo associado a esta medida pode indicar problemas na definio dos modelos
de desempenho na organizao (que no se mostrariam adequados aos projetos atuais) ou a
incapacidade dos projetos de controlar riscos e eventos no previstos durante a elaborao
dos modelos de desempenho que fazem com que o comportamento dos indicadores de
qualidade e de desempenho dos projetos no sejam os esperados pela organizao.
Da mesma forma que para a medida anterior, pode-se tambm considerar uma variao
acumulativa para esta medida. Por exemplo, aps ter sido implantado o Controle Estatstico
de Processos, avaliar quantos projetos foram desenvolvidos at o momento que atenderam
aos objetivos de qualidade e desempenho definidos.
7.8 Medio no Nvel A do MR-MPS

O objetivo final do nvel A do MR-MPS a implantao controlada na
organizao da melhoria contnua dos processos, utilizando o controle estatstico
dos processos como meio. Da mesma forma que no nvel B, no h no nvel A a
definio de novos processos. As caractersticas desse nvel sa o atendidas pela
implementaa o dos atributos de processo AP 5.1 (O processo e objeto de melhorias
incrementais e inovao es) e AP 5.2 (O processo e otimizado continuamente).
O ponto de partida para a melhoria contnua dos processos como prevista
no nvel A o entendimento do relacionamento entre o comportamento dos
processos da organizao e os objetivos de negcio definidos. A partir da anlise
que permita avaliar que esses objetivos de negcio so atingveis, as causas
comuns de variao dos processos devem ser avaliadas para a identificao das
suas causas raiz e, a partir da, identificar melhorias ou incorporar melhores
prticas e inovaes nos processos de forma a melhorar o desempenho dos
subprocessos relacionados.
Assim como no nvel anterior, apesar de a descrio dos resultados
esperados poder indicar que a implementao desse nvel simples, isso no
198
verdade. As anlises das causas raiz associadas com as causas comuns de variao
no desempenho do processo podem ser bastante elaboradas e no triviais. Outro
complicador a implantao das melhorias de forma realmente controlada, de
modo a no desestabilizar os subprocessos relacionados, o que faria com que a
organizao deixasse de atender aos requisitos do modelo do nvel anterior (o
nvel B).
As subsees a seguir descrevem medidas que podem ser utilizadas para a
monitorao dos elementos crticos do nvel A do MR-MPS.
7.8.1 - Medidas relacionadas a Anlise de Causas

No h um processo no MR-MPS destinado anlise de causas raiz, no
entanto, parte dos resultados esperados dos atributos de processo AP 5.1 (O
processo objeto de melhorias incrementais e inovaes) e AP 5.2 (O processo
otimizado continuamente) so referentes a isso. O objetivo desses resultados
esperados que dados selecionados sejam analisados para identificar causas raiz e
propor solues aceitveis para evitar ocorrncias futuras de resultados similares
ou incorporar melhores prticas no processo e para que se possa identificar
causas comuns de variao no desempenho do processo [SOFTEX, 2011a]. Como
esses resultados fazem parte de um atributo de processo, espera-se que sejam
aplicados a pelo menos um dos processos que tiveram subprocessos selecionados
para a anlise de desempenho. A Tabela 7.27 apresenta medidas relacionadas
anlise de causas raiz.
Tabela 7.27 Medidas associadas a Anlise de Causas.
1
Taxa de solues aceitveis indicadas pela anlise de causas que trouxeram o resultado
esperado para evitar ocorrncias futuras de uma causa comum
Nmero de solues indicadas pela anlise de causas que trouxeram o resultado esperado /
Nmero total de solues indicadas pela anlise de causas que foram adotadas
O objetivo desta medida avaliar o quo efetivas foram as solues aceitveis derivadas das
anlises de causas raiz executadas na organizao para identificar causas comuns de variao
no desempenho dos subprocessos.
Se as solues identificadas no esto produzindo os efeitos esperados no desempenho dos
subprocessos pode ser necessrio rever os procedimentos adotados pela organizao tanto
para a identificao das causas raiz quanto para a escolha das solues mais adequadas para
trat-las.
Esforo das atividades relacionadas anlise de causas raiz
Nmero de horas gastas pela equipe para realizar as atividades relacionadas anlise de
causas raiz na organizao
A execuo das atividades necessrias para executar as atividades associadas anlise de
causas raiz grande e envolve trabalho bastante especializado. Dessa forma, por no ser uma
tarefa trivial, provavelmente, demandar bastante esforo e dedicao. A anlise desta medida
199
para identificar potencial risco de no se cumprir o cronograma do programa de melhoria de

processos em curso.
O custo dessas atividades pode ser derivado de uma variao desta medida.
7.8.2 - Medidas relacionadas Melhoria Contnua dos Processos

O conjunto de medidas apresentadas na Tabela 7.28 no est associado a
nenhum dos processos do MR-MPS, mas ao ponto central do nvel A do MR-MPS
que a melhoria contnua dos processos com base na aplicao de controle
estatstico de processos e implantao de melhorias incrementais e inovaes. Essa
melhoria contnua garantida pela aplicao dos resultados esperados dos
atributos de processo AP 5.1 (O processo objeto de melhorias incrementais e
inovaes) e AP 5.2 (O processo otimizado continuamente). Espera-se que
mudanas no processo sejam identificadas a partir da anlise de defeitos,
problemas, causas comuns de variao do desempenho e da investigao de
enfoques inovadores para a definio e implementao do processo e que
mudanas efetuadas na definio, gerncia e desempenho do processo tenham
impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo
[SOFTEX, 2011a].
Apesar do texto do atributo de processo e de seus resultados esperados se
referirem a melhores prticas e inovaes, o foco das medidas apresentadas a
seguir so inovaes, pois constituem um dos grandes diferenciais da implantao
de melhoria de processos em organizaes de alta maturidade em comparao ao
que esperado nos nveis anteriores do modelo.
Tabela 7.28 Medidas associadas a Melhoria Contnua dos Processos.
1
Taxa de identificao de melhorias originadas de inovaes com impacto nos objetivos de

negcio
Nmero de melhorias originadas de inovaes com impacto nos objetivos de negcio /
Nmero total de melhorias identificadas na organizao
Esta medida possibilita que a organizao avalie quantas das melhorias identificadas so
derivadas de inovaes, conforme requerido pelo nvel A do MR-MPS.
No h um nmero mnimo ou mximo esperado para essas melhorias, mas os valores obtidos
devem ser analisados para garantir que haja melhorias suficientes identificadas na
organizao, de modo a permitir que causas comuns de variao no processo possam ser
eliminadas e que o desempenho e a qualidade dos processos sejam adequados aos objetivos
de negcio da organizao.
Taxa de implantao de melhorias originadas de inovaes com impacto nos objetivos de
negcio
Nmero de melhorias originadas de inovaes com impacto nos objetivos de negcio
implantadas / Nmero total de melhorias originadas de inovaes com impacto nos
objetivos de negcio
200
Esta medida possibilita uma anlise do quanto as melhorias originadas de inovaes com
impacto nos objetivos de negcio esto sendo implantadas na organizao.
No h valor mnimo padro associado a esta medida, no entanto valores baixos podem
indicar uma incapacidade de a organizao colocar em prtica as melhorias identificadas ou a
incapacidade de essas aes trazerem, de fato, melhorias no desempenho dos subprocessos
relacionados.
Esta medida pode ser analisada em conjunto com outra que analise o tempo e esforo
associados com as atividades necessrias para o controle estatstico de processos na
organizao.
Taxa de subprocessos estveis que tiveram seu desempenho melhorado pela ao de
melhorias originadas de inovaes
Nmero de subprocessos considerados estveis que tiveram seu desempenho melhorado pela
ao de melhorias originadas de inovaes / Nmero total de subprocessos considerados
crticos afetados por melhorias originadas de inovaes
Esta medida pode permitir organizao avaliar o quanto os subprocessos considerados
crticos j tiveram seu desempenho melhorado pela ao de melhorias originadas de
inovaes.
Valores baixos desta medida podem no invalidar os esforos por trs da aplicao da
melhoria contnua como prevista no nvel A do MR-MPS, porm podem indicar um ponto de
ateno de que preciso maior esforo para anlise dos comportamentos dos subprocessos
sob controle estatstico ou a busca por novas melhorias baseadas em inovaes.
Variao do desempenho dos subprocessos ocasionada pela implantao de uma
inovao
Diferena dos valores dos limites de controle de duas baselines sucessivas de um subprocesso
ocasionada pela implantao de uma inovao
O desempenho de um subprocesso caracterizado pelos valores dos limites de controle de
sua baseline de desempenho. Esta medida mede o quanto o desempenho de um subprocesso
variou, considerando sucessivas baselines.
Esta medida tem por objetivo avaliar o efeito dos resultados obtidos com a implantao de
melhorias originadas de inovaes para o desempenho geral dos subprocessos considerados
para o controle estatstico. Dessa forma, pode ser analisada em conjunto com as medidas
anteriores para avaliar se as mudanas no comportamento dos subprocessos esto ou no
relacionadas implantao de melhorias originadas de novas tecnologias e conceitos de
processo com impacto no alcance dos objetivos de negcio.
Esforo das atividades relacionadas melhoria contnua dos processos na organizao
Nmero de horas gastas pela equipe para realizar as atividades relacionadas melhoria
contnua dos processos na organizao
A execuo das atividades necessrias para executar as atividades associadas melhoria
contnua dos processos na organizao grande e envolve trabalho bastante especializado.
Dessa forma, por no ser uma tarefa trivial, provavelmente, demandar bastante esforo e
dedicao. A anlise desta medida pode ser til para controlar a alocao da equipe s
atividades relacionadas como tambm para identificar potencial risco de no se cumprir o
cronograma do programa de melhoria de processos em curso.
O custo dessas atividades pode ser derivado de uma variao desta medida.

Este captulo apresentou um conjunto de medidas associadas com a
implementao de todos os processos e nveis do MR-MPS. Esse conjunto de
medidas no exaustivo nem completo, portanto, tanto as medidas em si quanto as
suas interpretaes devem ser adaptadas a cada contexto organizacional e podem
ser utilizadas para monitorar a execuo de cada um dos processos em questo.
201
De acordo com o aumento do nvel de maturidade da organizao, tambm

aumenta o nvel esperado de capacidade de seus processos. O processo Medio do
MR-MPS, apesar de no ganhar novos resultados esperados, deve ter sua execuo
evoluda para atender aos novos requisitos incorporados ao modelo relacionados
ao aumento do nvel de capacidade dos processos. Um dos efeitos prticos dessa
evoluo est associado ao tipo de anlise e interpretao que pode e deve ser feita
em relao s medidas consideradas e as medies realizadas.
Dessa forma, o captulo seguinte apresenta uma discusso de como a
medio se insere na determinao de capacidade dos processos da organizao e
como ela evolui ao longo do tempo, passando da fase de conhecimento e controle
para a fase de melhoria dos processos. Tambm discutido como a medio
interfere nos procedimentos associados ao controle estatstico de processos e
melhoria contnua do desempenho dos processos.
202
Captulo 8
Medio no MR-MPS
8.1 Introduo
O uso de um modelo de maturidade por uma organizao por si s no
garante que ela adquira automaticamente a maturidade adequada para o seu
desenvolvimento de software. A adoo dos processos que compem cada nvel de
maturidade dos modelos deve ser acompanhada pelo aumento gradual da
capacidade dos processos em atender os requisitos de qualidade esperados para a
execuo e institucionalizao das atividades de melhoria de processos de
software.
A capacidade do processo expressa como o grau de refinamento e
institucionalizao com que o processo executado na organizao/unidade
organizacional
[SOFTEX,
2011a].
Dessa
forma,
medida
que
organizao/unidade organizacional evolui nos nveis de maturidade, um maior

nvel de capacidade para desempenhar o processo deve ser atingido [SOFTEX,
2011a].
Conforme dito anteriormente, o processo Medio um importante
mecanismo associado ao aumento da capacidade dos processos da organizao.
Por isso, importante a discusso de diferentes formas de se adotar as prticas de
medio de software em organizaes que adotam o MR-MPS, de forma a auxililas a terem uma boa interpretao dos requisitos do modelo e tambm direcionar
seus esforos na institucionalizao de uma cultura de medio que seja gradual e
acompanhe o amadurecimento dos processos preconizado pelos diferentes nveis
de maturidade do modelo.
Uma organizao que tenha sido avaliada no nvel F do MR-MPS ter
atingido tambm o nvel 2 de capacidade da ISO/IEC 15504 [ISO/IEC, 2003] para
os processos desse nvel do MR-MPS. O foco desse nvel de capacidade a gerncia
dos processos, em um primeiro momento ainda relacionado execuo de projetos
isolados. Nesse contexto, h dois itens importantes: conhecer como os processos se
comportam e, posteriormente, a partir deste conhecimento, poder control-los
efetivamente.
203
No nvel G do MR-MPS ainda no h obrigatoriedade de implantao do

processo Medio, porm h aspectos importantes da gerncia de projetos que
podem ser beneficiados pela adoo de algumas medidas relacionadas ao
acompanhamento dos projetos executados.
No nvel F do MR-MPS, as atividades de medio nos projetos devem ser
formalizadas. Os Captulos 2 e 3 deste livro, que discutem o planejamento e a
execuo da medio, contm os principais aspectos requeridos pelo modelo,
porm h desafios em se conseguir que essas atividades sejam institucionalizadas
de forma a, realmente, conseguir trazer valor para a organizao e para os
projetos.
Uma organizao que tenha sido avaliada nos nveis E, D ou C do MR-MPS
ter atingido tambm o nvel 3 de capacidade da ISO/IEC 15504 para os processos
desse nvel do MR-MPS. Os controles obtidos pela adoo do processo Medio
devem ser ajustados para fornecer indicadores e analisar informaes que
favoream a identificao de pontos de melhoria dos processos.
No nvel E do MR-MPS, deve ser criado um repositrio organizacional de
medidas. As coletas e anlises, que antes poderiam ser especficas de cada projeto,
passam a ter que ser consolidadas para apoiar a institucionalizao e melhoria do
conjunto de processos padro, obrigatrios a partir deste nvel.
Nos nveis D e C do MR-MPS, nenhum novo requisito referente medio
includo no modelo, porm, os processos referentes a Engenharia do Software
adicionados nesse nvel (Verificao, Validao, Projeto e Construo do Produto,
Integrao do Produto e Desenvolvimento de Requisitos) tm diversos produtos
de trabalho que podem fornecer informaes valiosas sobre a qualidade dos
produtos desenvolvidos pela organizao e sero utilizadas pelo controle
estatstico dos nveis B e A.
Por fim, o controle estatstico (discutido com mais detalhes nos Captulos 4,
5 e 6) caracterstico dos nveis B e A do modelo e s alcanado com medies
precisas e criteriosas e dados histricos confiveis. Dessa forma, se as medies
obtidas nos nveis anteriores no forem adequadas, as organizaes precisaro
despender grande esforo e gastar muito tempo, o que poderia ter sido
minimizado ao longo do tempo. Organizaes aderentes ao nvel B do MR-MPS tm
204
seus processos com capacidade equivalente ao do nvel 4 da ISO/IEC 15504, pois j

implementam o controle estatstico de processos.
Por fim, no ltimo dos nveis de capacidade da ISO/IEC 15504, o 5, o
controle obtido evoludo para que se consiga aplicar a melhoria contnua dos
processos com base em dados estatsticos e anlises estatsticas e quantitativas.
Esse nvel equivalente ao nvel A do MR-MPS. A partir desse momento, a adoo
de melhores prticas e inovaes na organizao feita de modo ordenado,
visando manuteno do controle estatstico dos processos e aumento da
capacidade de atender aos requisitos de qualidade e de desempenho alinhados s
necessidades da organizao. Os requisitos de medio para esses dois nveis so
equivalentes, referentes ao controle estatstico de processos e melhoria contnua
de processos.
Este captulo discute a implementao de prticas de medio de software
em diferentes nveis de maturidade do MR-MPS. A Seo 8.2 apresenta melhores
prticas e observaes sobre a implementao de medio em organizaes de
software que adotaram o MR-MPS. A Seo 8.3 apresenta como a medio pode ser
utilizada para conhecimento e monitorao dos processos de software, conforme
esperado nvel F do MR-MPS. A Seo 8.4 apresenta como as informaes que
possibilitam a monitorao dos processos podem ser utilizadas para a melhoria
dos processos, conforme esperado pelos nveis E, D e C do MR-MPS.
Exemplos de medidas que podem ser utilizadas para o conhecimento do
comportamento dos processos e posterior controle da execuo dos projetos e
melhoria desses processos foram discutidas no Captulo 7 deste livro. Os exemplos
apresentados nas Sees 8.3 e 8.4 utilizam variaes destas medidas. Os
procedimentos associados anlise das medidas de acordo com os preceitos do
controle estatstico de processos foram discutidos nos Captulos4, 5 e 6 e no sero
repetidos.
8.2 Observaes sobre a Implementao de Medio nas

Organizaes
O conjunto de observaes e melhores prticas relacionadas
implementao de medio apresentado nesta seo foi coletado a partir de
situaes vivenciadas em organizaes de software que implementaram ou foram
205
avaliadas no MPS17 e foi publicado, inicialmente, nos Anais do Simpsio Brasileiro

de Engenharia de Software SBQS 2011 [SANTOS, 2011].
A implantao de um Programa de Medio no trivial e, em geral, pode
ser trabalhosa. Bons programas de medio comeam a partir da derivao dos
objetivos estratgicos da organizao para a definio de objetivos de medio. De
forma geral, essa associao possibilita que o esforo seja concentrado em reas
que contenham aspectos importantes para a tomada de deciso na organizao
como um todo e na rea responsvel pelo desenvolvimento de software em
particular.
Assim, um dos principais problemas associados ao resultado esperado MED
1 (Objetivos de medio so estabelecidos e mantidos a partir dos objetivos de
negcio da organizao e das necessidades de informao de processos tcnicos e
gerenciais) do MR-MPS a falta de um plano estratgico na organizao a partir do
qual possam ser derivados os objetivos de medio. Por causa de uma definio
falha e ambgua desse plano, o relacionamento entre os objetivos estratgicos da
organizao e os objetivos de medio superficial e insuficiente para explicar
completamente a associao entre eles. Desta forma, no existe garantia de que as
medidas identificadas atendam adequadamente s necessidades de informao
dos diferentes nveis de gerncia.
Algumas organizaes (principalmente aquelas em estgios iniciais do
programa de melhoria) ainda confundem Medio (como previsto pelo MR-MPS)
com o clculo associado ao uso da tcnica de Anlise de Pontos por Funo (APF)
para determinar o tamanho de um produto. O clculo do tamanho de um produto
apenas uma das medidas que podem ser utilizadas em uma organizao e est
associado principalmente gerncia de projetos e realizao de estimativas. O
tamanho de um produto deve ser associado a outras medidas para formar
indicadores como a produtividade mdia de uma equipe ou a densidade de
defeitos.
O GQM (Goal-Question-Metric) [BASILI et al., 1994; SOLINGEN e BERGHOUT,
1999], descrito na Seo 3.3.1, um mtodo bastante utilizado para a definio de
17
Dada a compatibilidade entre o MR-MPS e o CMMI-DEV, acredita-se que essas observaes

tambm sejam vlidas e teis para organizaes que implementam o CMMI-DEV.
206
um Plano de Medio devido sua simplicidade de uso. Nem sempre, no entanto,

esse mtodo utilizado adequadamente, produzindo um conjunto de medidas que
no so diretamente relacionveis s questes e objetivos de medio, fato que
prejudicar mais tarde a anlise e a tomada de deciso.
Uma questo muitas vezes formulada pelas organizaes est relacionada a
quantas medidas so necessrias para a implantao de um programa de
medio. Esta uma pergunta equivocada, pois o que importa, na verdade, quais
medidas podem auxiliar a organizao no conhecimento do comportamento de
seus processos de software e na tomada de deciso. Em geral, a maior parte das
medidas a serem utilizadas pode ser obtida pela combinao de cinco medidas
essenciais (tamanho, produtividade, tempo, esforo e confiabilidade), conforme
descrito na Seo 3.4 [PUTNAM E MYERS, 2003].
Muitas vezes, a preocupao com o nmero de medidas decorrente da
necessidade de os processos serem monitorados a partir da coleta e anlise de
medidas, conforme requerido no RAP 4 (Medidas so planejadas e coletadas para
monitorao da execuo do processo e ajustes so realizados), a partir do nvel F.
Uma organizao pode definir um programa de medio com poucas medidas e
elas serem efetivas para a monitorao de seus processos. Entretanto,
relativamente comum a definio de muitas medidas o que, na prtica, aumenta o
esforo para a coleta e anlise de dados, sem produzir resultados teis em termos
de tomada de deciso e melhoria de processos.
Muitos questionam o custo e o esforo relacionados a se ter medidas
especficas para monitorao de cada um dos 17 processos do Nvel C do MR-MPS
(de forma a atender ao RAP 4). Uma soluo s vezes adotada associar a
monitorao de alguns processos execuo de alguns processos de apoio, como,
por exemplo, Garantia da Qualidade. Uma medida como nmero de no
conformidades em avaliaes de qualidade do processo X pode ser simples de
coletar, mas no necessariamente apresenta dados suficientes para avaliar se o
processo X est sendo efetivamente seguido ou adequado para a organizao. Em
alguns casos, pode indicar apenas se a implementao do processo Garantia de
Qualidade est proporcionando que se encontre ou no defeitos nos documentos
avaliados. Um problema ainda maior, neste caso especfico, acontece quando os
207
critrios de garantia da qualidade no asseguram de fato que aspectos relevantes

dos documentos produzidos sejam avaliados. Por exemplo, para monitorar os
processos Verificao e Validao ter laudos de qualidade inadequados avaliando
formato de ttulos ou preenchimento de cabealhos, sendo, assim, incapazes de
identificar problemas relevantes. Para surtir o efeito desejado, os critrios dos
laudos de qualidade devem estar mais prximos de critrios de verificao (ou
seja, observando o contedo dos documentos) do que critrios de garantia da
qualidade simples (ou seja, observando apenas a forma do documento). Alm
disso, se uma medida utilizada para monitorar mais de um processo, deve-se
garantir ter uma viso independente de elementos de cada processo. No caso do
exemplo anterior, por exemplo, seria mais adequado analisar o nmero e tipos de
defeitos encontrados em inspees ou em testes de aceitao.
De qualquer forma, as medidas de monitorao dos processos tambm
devem estar alinhadas aos objetivos de negcio da organizao. Isto pode ser feito
a partir, por exemplo, de um objetivo de medio que signifique a monitorao da
qualidade dos processos de software (o que , ou deveria ser, um dos focos de
programas de melhoria de processos baseados na adoo de modelos de
maturidade).
O esforo associado implantao de um programa de medio grande,
assim, importante que no sejam definidas muitas medidas para no se correr o
risco de poucas serem realmente efetivas e de muitas no medirem nada relevante
ou que, pelo seu alto custo de coleta e anlise, sejam abandonadas ou ignoradas.
Por outro lado, a definio de poucas medidas pode fazer com que aspectos
realmente relevantes da execuo dos processos sejam negligenciados e que as
medidas sejam simples demais para a tomada de deciso. Deve-se cuidar para
solues simples no se transformem em solues simplrias.
Uma vez identificadas as medidas necessrias para responder os objetivos
de medio, cada uma delas deve ser totalmente definida, incluindo os
procedimentos de coleta, armazenamento e anlise de dados.
Os procedimentos de coleta devem ser definidos de tal forma que qualquer
pessoa possa execut-los. Nem sempre utilizado um formalismo adequado para
isto. Uma boa forma de estruturao encontrada na descrio operacional das
208
medidas, conforme descrito na Seo 3.7. comum, por exemplo, a indicao que o
valor de uma medida pode ser encontrado em uma ferramenta (por exemplo, o
MS-Project), mas no informado como identificar de forma inequvoca a
informao (por exemplo, que coluna do cronograma criado) ou quando a medida
j pode ser coletada (por exemplo, s coletar o tempo esforo real da atividade se
ela estiver 100% concluda).
Outro problema comum no descrever as medidas bsicas (utilizadas para
compor outras) isoladamente nem informar matemtica e claramente as frmulas
a serem utilizadas para clculo das medidas derivadas.
Os procedimentos de armazenamento devem indicar o local exato onde as
informaes devem ser registradas. Isso inclui no somente onde os valores
coletados sero transcritos (por exemplo, em que clula da planilha de coleta a
quantidade de defeitos registrados em uma rodada de testes deve ser preenchida),
mas tambm onde o instrumento de coleta (por exemplo, a planilha de coleta) deve
ser salvo.
Em relao aos procedimentos de anlise das medidas importante que
eles realmente auxiliem a anlise das informaes, por exemplo, informando em
que momentos e por quem as medidas so analisadas e com que frequncia. Outro
item relevante indicar como combinar diferentes medidas para compreender o
comportamento dos processos (por exemplo, relacionar o esforo despendido nas
avaliaes de qualidade com o nmero de no conformidades encontradas e o
ndice de retrabalho dos projetos).
Uma omisso comum dos procedimentos de anlise a falha em indicar a
necessidade de se separar: dado da medida, informao de contexto, a anlise de
fato e as aes decorrentes das anlises realizadas.
A falta de metas (apesar de no obrigatrias) para as medidas , tambm,
uma caracterstica que pode dificultar anlises. Mesmo organizaes que esto
iniciando o seu programa de medio (e que, portanto, no tm uma base
histrica) podem se beneficiar da definio de metas. Com o tempo, se as metas
forem consideradas inadequadas, podem ser revistas. Mas a existncia de metas e
valores esperados possibilita ter-se uma viso crtica dos valores obtidos.
209
Quando uma organizao est iniciando o seu programa de melhoria

comum que no haja uma base histrica, portanto, a comparao de valores
passados pode no ser eficiente. Por outro lado, em organizaes com maior
maturidade, a comparao com valores passados um importante mecanismo
para a tomada de decises, por exemplo, a partir da anlise de tendncias do
nmero de defeitos nos testes ou evoluo da produtividade nos projetos. No
entanto, anlises mais elaboradas muitas vezes so negligenciadas, o que crtico,
principalmente, a partir do Nvel E do MR-MPS, onde a existncia de processos
padro possibilita tais comparaes.
A partir do Nvel E, como descrito no Captulo 2, um requisito do modelo a
existncia de um repositrio organizacional de medidas. Um repositrio
organizacional de medidas deve ser capaz de registrar todas as medidas definidas
e coletadas na organizao e possibilitar o seu uso futuro. Considerando a adoo
do MR-MPS de forma evolutiva em uma organizao, isso importante
principalmente para os nveis de alta maturidade (A e B) que requerem tratamento
diferenciado para os dados de medio e o controle estatstico dos processos. Para
o efetivo controle estatstico dos processos, os dados analisados no podem conter
erros e devem ser armazenados de forma a conservar informaes de contexto,
relacionamentos entre medidas e serem manipulveis (por exemplo, com a
derivao de outras medidas compostas) adequadamente. Isto no ser
conseguido facilmente em organizaes cujos repositrios de medidas sejam
armazenados em planilhas Excel ou em apresentaes do PowerPoint (o que
mais comum do que se imagina). Os requisitos para repositrios de medidas
adequados ao controle estatstico foram discutidos, em detalhes, no Captulo 4.
O documento resultante do planejamento de medies um importante
ativo da organizao e, como tal, deve ser gerenciado adequadamente, o que inclui
controle de acesso e mecanismos de gerncia de configurao. Nem sempre isso
adequadamente implementado pelas organizaes, algumas vezes se encontram
organizaes que definem suas medidas apenas em atas de reunio sem a devida
formalizao em um documento especfico.
O programa de medio deve ser posto em prtica atravs da coleta e
anlise das medidas planejadas de acordo com a frequncia definida. Todas as
210
medidas devem ser coletadas e analisadas de acordo com o planejado (se os

procedimentos definidos no forem adequados, devem ser revistos, no
ignorados). Algumas anlises podem ser mais frequentes que outras e isto deve ser
definido caso a caso. Por exemplo, na maior parte das vezes no se justifica
analisar o percentual de atraso de um projeto apenas aps ele ter sido concludo,
por outro lado, analisar a satisfao dos clientes quinzenalmente pode no ser
razovel.
importante que se utilizem grficos adequados para a visualizao dos
valores das medidas. Um problema comum o uso de histograma para dados que
no so sries histricas (por exemplo, para comparao do nmero de defeitos de
cada projeto em execuo em um ms melhor utilizar um grfico de barras do
que grfico de linhas). Os procedimentos de anlise devem informar quais grficos
devem ser gerados e como devem ser interpretados. Deve-se, tambm, procurar
evitar anlises pouco profundas, que apenas repitam o que o grfico diz sem
acrescentar nada alm.
Outros cuidados que devem ser adotados incluem a ordenao adequada
dos valores (dados histricos, por exemplo, devem estar em ordem cronolgica e
no em ordem alfabtica) e a implementao de procedimentos de garantia de
qualidade para assegurar que os dados coletados estejam corretos e representem
os valores associados s propriedades das entidades medidas. Da mesma forma,
importante que as anlises realizadas sejam auditadas pela Garantia da Qualidade
para assegurar que o que foi planejado o que est sendo executado. comum em
algumas organizaes que as anlises fiquem registradas apenas em atas de
reunio e que no sejam avaliadas pelos responsveis pela garantia da qualidade.
Desta forma, negligencia-se um importante aspecto do processo Medio e
prejudica-se, tambm, a adequada institucionalizao do processo Garantia da
Qualidade.
O armazenamento das anlises importante como fonte histrica da
evoluo do programa de medio e tambm para registrar as decises tomadas.
Como todo documento importante, os registros de medio devem ser
armazenados sob algum nvel de controle de gerncia de configurao. Um item
importante das anlises das medidas so as informaes de contexto, que devem
211
possuir o mximo de detalhes para possibilitar comparaes mais efetivas no

futuro e, tambm, identificar medidas com vis. Por exemplo, se as informaes de
contexto forem perdidas, com o tempo a anlise de uma longa srie histrica das
medidas ser comprometida porque dificilmente as pessoas se lembraro de fatos
ocorridos h muito tempo, inclusive porque muitas das pessoas envolvidas
naquele perodo j no estaro na organizao.
Se uma medida coletada, em geral, ela ou deve ser utilizada para compor
outra medida ou, ento, ser analisada e divulgada para os envolvidos por meio
eletrnico ou presencial. Quanto mais frequentemente as medidas forem
analisadas, mais rpida e efetiva poder ser a tomada de deciso. A falha em tomar
decises rpidas pode fazer com que o esforo do programa de medio seja em
vo e prejudicar seu apoio pelos envolvidos. Alm disso, reunies de discusso de
medidas com periodicidade grande (por exemplo, superior a 4 meses) podem ser
improdutivas, principalmente em organizaes em estgios iniciais do programa
de melhoria de processos.
Deve-se evitar, tambm, a discusso de todas as medidas com todos os
envolvidos indistintamente. Deve-se procurar discutir apenas medidas pertinentes
a cada perfil de profissional seno corre-se o risco de desinteresse. Por exemplo,
diferenciar medidas de interesse da alta gerncia (por exemplo, lucratividade
mdia dos projetos) daquelas mais prximas dos profissionais envolvidos na
execuo dos projetos (por exemplo, nmero de defeitos encontrados nos testes de
integrao).
Como as medidas so originadas dos objetivos de medio, as anlises
tambm devem relacionar tais objetivos com os valores obtidos. O apoio da alta
gerncia pode ser enfraquecido em caso de falha na identificao desse
relacionamento, o que pode colocar em risco todo o programa de medio,
causando at o seu abandono. As reunies de discusso dos resultados das
medies tambm podem ser bons momentos para apresentar alta gerncia
resultados da iniciativa de melhoria de processos e avaliar a institucionalizao
dos processos. Os produtos gerados em decorrncia da execuo do processo
Medio tambm permitem constituir uma base para o entendimento do
212
comportamento dos processos e podem auxiliar a direcionar os esforos do

programa de melhoria de processos da organizao.
De pouco adianta a coleta e anlise das medidas se no h tomada de
deciso associada a elas. As aes decorrentes das medidas devem ser gerenciadas
at a concluso e a falha em cumprir tais determinaes pode ser um indicativo da
perda de prioridade e de importncia do programa de medio.
O processo Medio, como um processo de apoio, tambm pode auxiliar a
implementao de outros processos na organizao, como, por exemplo,
contribuindo para a coleta de informaes e medidas necessrias definio de uma
base de estimativas e sua calibrao para a realidade da organizao. So
necessrios alguns cuidados para evitar distores e tomada de decises com base
em dados incorretos. Dentre eles: (i) utilizar medidas coletadas adequadamente a
partir dos dados dos projetos (por exemplo, durao das atividades e tamanho do
projeto); (ii) no consolidar dados de projetos muito diferentes (por exemplo,
pequenos e grandes, de diferentes linguagens, utilizando verses diferentes dos
processos padro ou, ento, projetos muito antigos com novos); (iii) calcular
corretamente o tamanho do produto (por exemplo, seguir o formalismo associado
a uma contagem de pontos por funo); (iv) calcular o tamanho real do produto ao
final do projeto e no utilizar o valor estimado no incio do projeto; (v) ter
claramente definidas as atividades do processo de desenvolvimento da
organizao (evitando que o cronograma dos projetos no seja fielmente baseado
no processo padro da organizao); e (vi) garantir que as medidas presentes na
base de dados sejam confiveis (por exemplo, atravs da adoo de mecanismos de
garantia da qualidade para avali-las).
8.3 Medio como Meio para Conhecimento e Monitorao dos

Processos de Software no nvel F do MR-MPS
O exemplo a seguir mostra como algumas das medidas apresentadas no
Captulo 7 podem ser utilizadas no contexto da monitorao de projetos de
software.
Considere uma organizao em processo de implantao do nvel F do MRMPS que tenha definido as seguintes medidas para a monitorao dos seus
213
processos de Gerncia de Projetos e de Garantia da Qualidade (para simplificao,

outras possveis medidas para monitorao do projeto foram ignoradas):
Preciso da estimativa de tamanho - calculada, para cada fase do projeto,

pela diviso da estimativa de tamanho do projeto medido a partir da
especificao de requisitos pelo tamanho real do projeto medido aps a
construo;
Preciso da estimativa de tempo calculada, para cada fase do projeto, a

partir da diviso da estimativa do nmero de dias a serem gastos pelo
tempo real em dias efetivamente gastos na fase;
Preciso da estimativa de esforo - calculada, para cada fase do projeto, a

partir da diviso da estimativa inicial do nmero de horas a serem gastas
pelo nmero de horas real gastas na fase;
Taxa de no conformidade em avaliaes de qualidade - calculada, para

cada fase do projeto e para cada produto de trabalho avaliado, pela diviso
do nmero de no conformidades identificadas em avaliaes de qualidade
pelo nmero total de critrios observados.
Para efeito do exemplo, considere as seguintes informaes:
essas medidas so coletadas e analisadas durante as revises nos quatro

marcos do projeto(representados pelas letras A, B, C e D na Tabela 8.1);
o tamanho do projeto medido em pontos por funo (PF);
o esforo do projeto medido em quantidade de horas (h);
o tempo do projeto medido em quantidade de dias teis (d);
as avaliaes de qualidade so realizadas ao final de cada marco;
as atividades executadas at o Marco A compreendem o planejamento do

projeto e levantamento de requisitos;
as atividades executadas at os Marcos B e C compreendem as atividades de

codificao, planejamento de testes e execuo de testes;
as atividades executadas at o Marco D compreendem a finalizao da

execuo de testes e a entrega do produto;
214
at a ocorrncia do marco A, devem ser gerados os documentos Plano do

Projeto e Especificao de Requisitos;
em cada um dos demais marcos o gerente de projeto deve produzir um

Relatrio de Monitorao do Projeto;
o cliente do projeto em questo conhecido por demorar a registrar o

aceite final do projeto.
Note que: (i) todos os grficos que sero apresentados utilizam a mesma
escala para que no se corra o risco de as anlises sofrerem desvios devido a

comparaes equivocadas; (ii) para auxiliar e complementar as anlises, todos os
valores utilizados para a gerao dos grficos tambm so apresentados; e (iii) a
ausncia de coleta de medidas representada por - e no pelo valor 0 (zero).
A Tabela 8.1 apresenta os valores coletados inicialmente para as medidas
relacionadas Gerncia de Projetos. Em cada um dos marcos, as medidas
selecionadas mostram o que est acontecendo no projeto em relao aos
parmetros monitorados.
Tabela 8.1 Medidas relacionadas a gerncia de projetos para a monitorao do projeto.
Medidas de GPR
Tamanho
(em PF)
Esforo
(em horas)
Tempo
(em dias
teis)
Marco A
Marco B
Marco C
Marco D
Estimado
100
100
120
120
Real
100
100
100
130
Preciso
1,00
1,00
1,20
0,92
Estimado
40
160
160
60
Real
30
100
200
80
Preciso
1,33
1,60
0,80
0,75
Estimado
10
12
Real
20
1,00
1,25
1,00
0,60
Preciso
Em relao medida referente ao tamanho do projeto em pontos por

funo (PF), pode-se perceber que o tamanho foi inicialmente estimado em 100 PF
e no Marco C essa estimativa foi alterada para 120 PF. A anlise da preciso de
estimativas de tamanho ao longo dos marcos apresenta um possvel problema
relacionado dificuldade de se calcular o tamanho real sem ter ainda o software
construdo, o que s se consegue no Marco D. No entanto, a alterao da medida no
Marco C indica, indiretamente, uma alterao de requisitos. Ao final do projeto, a
contagem do tamanho real do projeto indicou 130 PF. Dessa forma, a preciso da
215
estimativa, conforme frmula de clculo original, foi de 77%. Uma melhor forma de
utilizar essas informaes para a monitorao do projeto seria a anlise de duas
medidas:
Volatilidade de requisitos em Pontos por Funo, como sendo a variao do

tamanho estimado do projeto considerando possveis alteraes de
requisitos ao longo do tempo.
Preciso de estimativas de tamanho ao final do projeto, calculada a partir da

diviso da estimativa de tamanho do projeto pelo tamanho real do projeto
medido aps o final do projeto (e considerando possveis alteraes de
requisitos).
A Tabela 8.2 apresenta os valores coletados para essas medidas. A medida de

volatilidade de requisitos til para a monitorao do processo Gerncia de
Requisitos e permite ao gerente avaliar o impacto das alteraes de requisitos ao
longo do projeto (como pode ser visto adiante, na anlise das demais medidas). A
medida de preciso de estimativa de tamanho, possivelmente, no permite
nenhuma ao dentro do contexto do projeto em si, mas til para a organizao
definir sua base histrica de estimativas.
Tabela 8.2 Medidas relacionadas a tamanho para a monitorao do projeto.
Medidas de GPR
Volatilidade
de Requisitos
(em PF)
Preciso de
Estimativa de
Tamanho
Marco A
Marco B
Marco C
Marco D
Estimado
100
100
120
120
Variao
20
20
Estimado
100
100
120
120
Real
130
Preciso
0,92
O acompanhamento dos indicadores do projeto no Marco A, conforme

mostra a Figura 8.1,indica que o esforo gasto no projeto est aqum do estimado
(o que, a princpio, pode ser bom), apesar do tempo estimado para a realizao das
atividades ter sido cumprido. Um ponto de ateno poderia ser levantado pelo
gerente para confirmar a razo pela qual as duas medidas no apresentaram
resultados semelhantes.
216
Preciso de Estimativas
1,50
1,33
1,00
1,00
1,00
Marco A
0,50
0,00
Tamanho
Esforo
Tempo
Figura 8.1 Preciso de estimativas para o Marco A.
No Marco B, conforme mostra a Figura 8.2, novamente gastou-se menos

esforo para a realizao das atividades. Porm, dessa vez, o nmero de dias
efetivos tambm foi menor. Um novo ponto de ateno pode ser levantado pelo
gerente para averiguar se, de fato, os produtos de trabalho previstos para serem
construdos at este momento foram realmente construdos, pois houve uma
diferena de 60 horas entre o estimado e o real. Caso os produtos de trabalho no
tenham sido construdos, ajustes deveriam ser realizados, pois pode haver impacto
para os compromissos assumidos no escopo do projeto e um replanejamento se
faria necessrio. Caso a equipe tenha conseguido produzir os itens necessrios em
menos tempo, talvez seja necessrio calibrar as estimativas para novos projetos. A
reduo no nmero de dias gasto para desempenhar as atividades relativamente
condizente com a diminuio do esforo gasto (a relao no linear devido ao
tamanho da equipe e diferentes papis envolvidos na construo do produto).
2,00
1,60
1,33
1,50
1,00
1,25
1,00 1,00
1,00
Marco A
Marco B
0,50
0,00
Tamanho
Esforo
Tempo
Figura 8.2 Preciso de estimativas para o Marco B.
No Marco C, como mostra a Figura 8.3, houve um gasto maior de horas do

que o estimado para o projeto naquele momento (200h em vez de 160h), porm
217
no houve desvios em relao ao nmero de dias. Dessa forma, uma anlise que
pode ser feita em relao a esses valores que, apesar de um aumento no esforo,
os prazos foram cumpridos.
No entanto, possvel observar que: (i) o esforo total do projeto at o
momento ainda inferior ao estimado para tal (330h gastas para 360h previstas);
e (ii) apesar de o prazo da fase ter sido cumprido, isso pode ter acontecido com o
uso de horas extras, o que pode ter aumentado o custo total do projeto. Devido a
isso, o gerente poderia sugerir o uso de uma medida referente a custo do projeto
para auxiliar a monitorao dos projetos e a derivao de duas novas medidas s
de esforo e prazo j utilizadas, mostrando os valores acumulados do projeto at o
momento.
2,00
1,60
1,50
1,33
1,20
1,001,00
1,00
1,00
1,25
1,00
Marco A
0,80
Marco B
0,50
Marco C
0,00
Tamanho
Esforo
Tempo
Figura 8.3 Preciso de estimativas para o Marco C.
Tambm importante destacar outro fato ocorrido no projeto. Conforme

mostra o grfico, houve uma mudana de requisitos no projeto entre os Marcos B e
C, o que pode estar por trs dos desvios nas medidas dessa fase, pois as
estimativas, aparentemente, no foram reavaliadas devido alterao do escopo.
Ao final do projeto, conforme mostra a Figura 8.4, referente ao Marco D,
tambm gastou-se mais horas que o previsto para a fase e o nmero de dias teve
um desvio bastante acentuado. Apesar do desvio nas estimativas de esforo, no
acumulado geral do projeto gastou-se 10 horas menos que as 420 horas
originalmente estimadas. O desvio de dias nessa fase final se deveu no ao atraso
da concluso da execuo das atividades pela equipe, mas ao no registro da
aprovao do projeto pelo cliente. Dessa forma, mais uma vez, se fez necessria a
avaliao das medidas de esforo e nmero de dias acumulados do projeto para
218
poder fazer uma anlise mais completa dos resultados obtidos. Uma alterao
decorrente dos dados obtidos nesse momento poderia considerar o final do
projeto, para efeitos da medida de preciso de estimativa de tempo, como sendo a
entrega do produto final e no o registro de aceite pelo cliente.
Figura 8.4 Preciso de estimativas para o Marco D.
A Tabela 8.3 apresenta os valores para as seguintes novas medidas

sugeridas, relacionadas ao acumulado obtido no projeto:
Preciso (acumulada) da estimativa de tempo - calculada a cada fase do

projeto a partir da diviso da estimativa do nmero de dias a serem gastos
at o momento pelo tempo
empo real em dias efetivamente gastos
gasto at o
momento;
Preciso (acumulada) da estimativa de esforo do projeto - calculada

c
a cada
fase do projeto a partir da diviso da estimativa inicial do nmero de horas
a serem gastas at o momento pelo
elo nmero de horas real gastas at o
momento.
Tabela 8.3 Medidas relacionadas a tamanho para a monitorao do projeto.
Medidas de GPR
Marco A
Marco B
Marco C
Marco D
Esforo
Acumulado
(em horas)
Estimado
40
200
360
420
Real
30
230
330
410
Preciso
1,33
0,87
1,09
1,02
Tempo
Acumulado
(em dias
teis)
Estimado
15
23
35
Real
13
21
41
1,00
1,15
1,10
0,85
Preciso
A Figura 8.5 exibe o grfico para essas novas medidas.
219
Figura 8.5 Preciso de Estimativas (acumulado) para o projeto.
Para finalizar a anlise, tambm preciso avaliar as medidas relacionadas a

Garantia da Qualidade, sumarizadas na Tabela 8.4.
O laudo de qualidade
dade utilizado na organizao contm critrios que avaliam
tanto a qualidade do produto quanto a do processo. H 20 critrios referentes
avaliao do Plano do Projeto e s atividades necessrias para produzi-lo.
produzi
H 20
critrios referentes avaliao da Especificao de Requisitos e s atividades
necessrias para produzi--la, sendo que dois desses
es critrios s se aplicam no caso
de haver mudanas de requisitos. H 12 critrios referentes avaliao do
Relatrio de Monitorao do projeto e s atividades necessrias
necessrias para produzi-lo.
produzi
Tabela 8.4 Medidas relacionadas a garantia da qualidade para a monitorao do projeto
Taxa de No
Conformidades
Marco A # NC
Plano do
Projeto
5
Especificao
Requisitos
2
Relatrio de
Monitorao
-
20
18
0,25
0,11
# NC
# Crit.
12
Taxa NC
0,08
# NC
0,00
# Crit.
20
12,00
Taxa NC
0,35
0,00
# NC
# Crit.
12
Taxa NC
0,25
# Crit.
Taxa NC
Marco B
Marco C
Marco D
Alm do relato bvio do nmero de no conformidades obtidos em cada um

dos marcos, importante destacar em especial a taxa associada com a segunda
220
avaliao da Especificao de Requisitos no Marco C (onde houve uma alterao no

escopo do projeto), como pode ser vista na Figura 8.6.
Figura 8.6 Taxa de no conformidade em avaliaes de qualidade de produto e processo.
comum a tomada de alguma ao especfica pelos responsveis pelas

atividades de garantia da qualidade quando a taxa de no conformidades atinge
valores altos. Nessa organizao, caso fosse adotado um limite de 10% de no
conformidades, aes deveriam ser tomadas em todos marcos, exceto no B. No
entanto, importante destacar os problemas encontrados, pois podem se tornar
pontos de ateno no futuro. Note que a no ocorrncia de um alarme em um
momento no elimina a sua necessidade posteriormente: a qualidade do Relatrio
de Monitorao variou bastante ao longo do projeto e o ltimo resultado obtido foi
bastante discrepante dos demais.
No entanto, o ponto de maior ateno nos valores apresentados est
associado ao nmero de problemas encontrados na avaliao da Especificao de
Requisitos (25% dos critrios no foram atendidos completamente) no Marco C.
Isso pode ser uma das causas do estouro nas estimativas de esforo identificadas
nesse marco. Como plano de ao, os responsveis pela rea de Qualidade
poderiam ficar mais atentos a mudanas de requisitos e tentar garantir que as
alteraes nos documentos de requisitos e demais impactados por eles (como os
planos do projeto) fossem feitas de forma adequada e controlada.
221
8.4 Medio para a Melhoria dos Processos de Software nos

nveis E, D e C do MR-MPS
Diferentemente do que ocorre at o nvel F do MR-MPS, a partir do nvel E,
espera-se que a medio auxilie no s a monitorao dos processos como,
tambm, seja mais um mecanismo possvel para identificao de melhoria nos
processos da organizao. Isso possvel devido padronizao dos processos na
organizao e criao de um repositrio de medidas que possibilitam observar o
comportamento dos processos ao longo do tempo.
O exemplo18 a seguir mostra como as informaes obtidas com a medio
podem ser utilizadas para a identificao de possveis pontos de melhoria nos
processos e nos procedimentos adotados pelos projetos.
Considere que a organizao em questo, ao elaborar seu Plano de Medio,
tenha identificado como objetivo organizacional a reduo dos custos dos projetos e
a reduo dos defeitos encontrados durante a manuteno do produto e tenha a
medida descrita na Tabela 8.5 em seu Plano de Medio. Em um plano baseado no
GQM, esta medida estaria associada ao objetivo Diminuir o nmero de defeitos por
caso de uso e questo Qual a densidade de defeitos ocorridos nos testes?.
Tabela 8.5 Medida referente densidade de defeitos.
Nome da Medida
Definio
Mnemnico
Tipo de Medida
Entidade
Propriedade
Unidade de medida
Tipo de Escala
Valores da Escala
Intervalo Esperado
dos Dados
Frmula de Clculo
de Medida
Procedimento de
Medio
Densidade de defeitos em testes de software (DDTS)

Medida que quantifica a densidade de defeitos encontrados nos testes de
software na homologao interna.
DDTS
Medida Derivada
Processo de Testes
Deteco de defeitos
Defeitos/KSLOC
Absoluta
Nmeros reais positivos com preciso de duas casas decimais
[0,00; 0,15]
DDTS = NDTS/TP, onde:
NDTS = Nmero de defeitos detectados nos testes de software, e
TP = Tamanho do Produto
Calcular a densidade de defeitos utilizando a frmula de clculo da medida.
A coleta da mtrica NDTS feita manualmente a partir do Bugzilla (sistema
para registros de defeitos identificados). Deve ser realizada uma busca dos
defeitos com base no nome do projeto referentes a testes de software no
ms de referncia. O valor da medida o nmero de itens retornados nessa
busca. Caso o projeto no tenha executado testes no perodo, no se deve
coletar a medida. Caso nenhum erro tenha sido encontrado, o valor coletado
18
Este exemplo foi criado tendo como base questo da Prova de Conhecimento para Consultores de
Implementao MPS.BR aplicada em 13/02/2009, disponvel em www.softex.br/mpsbr.
222
deve ser 0 (zero).
Momento da
Medio
Periodicidade de
Medio
Responsvel pela
Medio
Procedimento de
Anlise
A coleta da mtrica TP feita a partir da planilha de estimativas do projeto.

O valor da medida o valor da clula 'Total de PF'.
Atividade Registrar Dados dos Testes
Uma vez em cada ocorrncia da atividade
Ferramenta de apoio medio, utilizando dados fornecidos para as
medidas base pelo desenvolvedor que realizou os testes.
Representar em um grfico de barras os dados coletados para a medida nos
projetos da organizao. Mensalmente analisada a densidade de defeitos
ocorridos no teste de software no ms de referncia atual e comparado com
os resultados dos meses anteriores.
Analisar se h projetos cuja densidade de defeitos destoa significativamente
das demais, dos valores praticados nos meses anteriores ou dos valores
esperados. Em caso afirmativo, conduzir investigao de causas para que,
identificadas as causas, sejam determinadas as aes corretivas necessrias.
Momento da Anlise
Periodicidade de
Medio
Responsvel pela
Medio
Se a densidade de defeitos ocorridos no teste de software for maior que o

valor base, as causas devem ser observadas e possveis medidas para
corrigir o problema devem ser identificadas.
Atividade Analisar Dados de Monitoramento dos Projetos
Mensal
Gerente de Qualidade
O perodo em anlise na organizao compreende quatro meses, de

fevereiro a maio, em que foram desenvolvidos cinco projetos (representados pelas
letras A, B, C, D e E). O projeto A foi o primeiro na organizao a adotar o novo
processo compatvel com o nvel C do MR-MPS, em fevereiro.
Em maro foi gerado um relatrio de medio contendo as informaes
apresentadas na Tabela 8.6.
Tabela 8.6 Medidas relacionadas a densidade de defeitos em fevereiro e maro.
Tamanho
(em PF)
Nmero de defeitos
Densidade de defeitos
Fevereiro
Fevereiro
Projeto A
200
50
Projeto B
100
Projeto C
100
Projeto
Maro
-
0,25
30
20
Maro
-
0,3
0,2
A partir dessas informaes, a organizao foi capaz de perceber a

quantidade excessiva de defeitos detectados nos testes de software, todas as
coletas apontam valores acima do limite tolervel pela organizao. Como o
problema no parecia isolado em apenas um projeto e afetava diferentes equipes,
foi investigada a causa e descobriu-se que parte dos problemas era decorrente da
223
falta de qualidade dos requisitos e das informaes tcnicas passadas s equipes

do projeto. Tambm foi informado que todos os projetos estavam com atraso no
cronograma, fato que foi atribudo pelo gerente do projeto incapacidade da
equipe entregar uma verso executvel do software sendo construdo com
qualidade considerada adequada.
De posse dessas informaes, a organizao decidiu reorganizar a agenda
de capacitao dos colaboradores e realizar, no incio de abril, treinamentos
focados em Verificao, Validao e Testes com o objetivo de ensinar tcnicas que
possibilitassem a criao de documentos de requisitos com maior qualidade e a
criao de casos de testes mais completos e abrangentes. Ao mesmo tempo, os
modelos (templates) de documentao referentes especificao de requisitos,
modelo de anlise e projeto, inspeo de requisitos, plano e casos de testes foram
revistos, assim como foi melhorado o detalhamento das atividades referentes a
validao de requisitos com os usurios.
Aps dois meses, a organizao voltou a analisar os dados obtidos no
relatrio de medio para comprovar os efeitos das melhorias implantadas. As
medidas coletadas podem ser vistas na Tabela 8.7. Todos os valores obtidos esto
abaixo dos limites tolerveis pela organizao, porm, preciso analisar tambm o
conjunto de valores obtidos e no apenas cada um individualmente.
Tabela 8.7 Medidas relacionadas a densidade de defeitos (2).
Projeto
Tamanho do
Projeto (em PF)
Nmero de defeitos
Abril
Densidade de defeitos
Maio
Abril
10
Maio
Projeto B
100
Projeto D
200
0,1
0,025
Projeto E
150
0,00667
Os Projetos A e C no tiveram mais execues de testes no perodo, porm

foi possvel coletar a medida em relao aos projetos B, D e E. As Figura 8.7 e 8.8
apresentam os valores obtidos na forma de um grfico de barras com os mesmos
dados agrupados por projeto e por ms, respectivamente. Observando os valores
apurados pode-se perceber que a densidade de defeitos nos projetos foi reduzida
em comparao com os projetos anteriores. Uma informao importante para
corroborar o efeito do treinamento realizado que a equipe do projeto E (que
obteve os menores ndices de densidade de defeitos) foi a mesma do projeto C.
224
Dessa forma, pode-se assumir que a melhora no desempenho dos projetos foi
influenciada pela ocorrncia dos treinamentos realizados.
Densidade de Defeitos (por projeto)
0,35
0,30
0,25
0,20
0,15
0,10
0,05
0,00
0,3
fev
0,25
0,2
mar
abr
0,1
mai
0,025
0,0067
Projeto A Projeto B Projeto C Projeto D Projeto E
Figura 8.7 Densidade de defeitos nos testes de software (em agrupamento por projetos).
Densidade de Defeitos (por ms)

0,35
0,30
0,25
0,20
0,15
0,10
0,05
0,00
0,3
0,25
0,2
C
0,1
D
0,025
E
0,0067
fev
mar
abr
mai
Figura 8.8 Densidade de defeitos nos testes de software (em agrupamento por ms).
Duas outras informaes de contexto relacionadas a essa medida foram

obtidas: (i) todos os trs projetos analisados no perodo estavam em dia com o
cronograma, e (ii) os custos dos projetos D e E estavam muito elevados. A primeira
informao corrobora com a percepo do efeito da qualidade dos requisitos para
o atraso do cronograma dos projetos. A segunda um ponto de ateno que
merece uma anlise mais aprofundada do grupo de processos.
Conversando com os gerentes dos projetos D e E, foi percebido que o
aumento dos custos estava associado durao excessiva das atividades
relacionadas a testes na organizao.
Apenas com as atuais medidas coletadas pela organizao no possvel
analisar o custo dos projetos e das atividades de testes. Para tratar isso da maneira
adequada, o grupo de processos pode gerar uma ao corretiva que envolva a
225
definio de duas medidas para: (i) analisar os custos associados com todas as
atividades dos projetos, e (ii) mensurar os custos para manuteno dos projetos
entregues aos clientes. Essa ltima, apesar de estar relacionada com os objetivos
organizacionais descritos anteriormente, ainda no havia sido coletada.
A primeira medida necessria para confirmar quais atividades esto
contribuindo, de fato, para o aumento dos custos dos projetos; pode ser que as
responsveis no sejam aquelas envolvidas na elaborao e execuo de testes. A
segunda medida til para se avaliar se o investimento feito em testes durante a
execuo dos projetos vale pena se comparado com a reduo dos custos de
manuteno dos produtos.
Se possvel, essas medidas deveriam ser coletadas retroativamente para
aumentar a base histrica de comparaes e, tambm, melhor analisar o efeito que
o treinamento realizado em maro teve nesse cenrio.

Uma das dificuldades quando se inicia a implantao de um programa de
medio de software em uma organizao est em, a partir do entendimento dos
conceitos tericos envolvidos, identificar como os requisitos propostos pelo
modelo de maturidade em uso podem ser utilizados em benefcio da organizao,
seja no contexto dos projetos de software seja no auxlio na melhoria dos
processos existentes.
Dessa forma, este captulo apresentou dois exemplos, representando
situaes prticas, de como o processo de medio pode ser utilizado nesse
contexto. No primeiro exemplo as informaes so utilizadas para a monitorao
do projeto, a interpretao do que est ocorrendo no momento e uma anlise do
andamento geral do projeto e aes que podem ser tomadas em decorrncia desta
anlise. No segundo exemplo foi mostrado como a anlise de uma srie histrica,
ainda que pequena, pode dar insumos para aes de melhoria em uma
organizao. E, tambm, como os efeitos dessas aes de melhoria podem ser
analisados tambm com base nos registros de medio.
Alm disso, tambm foi apresentado um conjunto de observaes da
implementao de medio em organizaes que adotaram o MR-MPS. Essas
observaes no pretendem ser completas nem substituir outras fontes de
226
informao sobre medio de software. Entretanto, por estarem baseadas na

experincia dos autores com vrias organizaes, espera-se que possam ser teis
s organizaes na estruturao e conduo de seu programa de medio, de
forma a otimizar os esforos e evitar os erros e falhas mais comumente cometidos.
227
Referncias Bibliogrficas
ALBUQUERQUE, A. 2008, Avaliao e Melhoria de Ativos de Processos Organizacionais em
Ambientes de Desenvolvimento de Software, Tese de Doutorado, Universidade
Federal do Rio de Janeiro.
ALLEN,J.H., DAVIS,N., 2010, Measuring Operational Resilience Using the CERT Resiliense
Management Model, Carnegie Mellon University, Software Engineering Institute,
Technical Note CMU/SEI-2010-TN-030.
AMCHAM, 2012, Somente 14% das empresas esto plenamente satisfeitas com
mensurao de resultados de TI, disponvel em http://www.amcham.com.br
BALDASSARE, M. T., CAIVANO, D., VISAGGIO, C. A., 2006, Non Invasive Monitoring of a
Distributed Maintenance Process, In: Proceedings of the Instrumentation and
Measurement Technology Conference, Sorrento, pp. 1098-1103.
BARCELLOS, M. P., FALBO, R. A., ROCHA, A. R., 2010, Establishing a Well-founded
Conceptualization about Software Measurement in High Maturity Levels, In:
Proceedings of the 7th International Conference on the Quality of Information and
Communications Technology (QUATIC 2010), Oporto - Portugal, pp. 467-472.
BARCELLOS, M. P., 2009a, Uma Estratgia para Medio de Software e Avaliao de Bases
de Medidas para Controle Estatstico de Processos de Software em Organizaes
de Alta Maturidade, Tese de Doutorado, Universidade Federal do Rio de Janeiro.
BARCELLOS, M. P., 2009b, Controle Estatstico de Processos Aplicado a Processos de
Software Do Cho de Fbrica para as Organizaes de Software, Engenharia de
Software Magazine, 11 Edio, pp.56-61.
BARCELLOS, M. P., 2009c, Utilizao do Controle Estatstico de Processos na Melhoria de
Processos
de
Software
Conhecendo
Ferramentas
para
Anlise
do
Comportamento dos Processos, Engenharia de Software Magazine, 12 Edio, pp.

24-32.
BARRETO, A.S., 2011, Definio e Gerncia de Objetivos de Software Alinhados ao
Planejamento Estratgico, Tese de Doutorado, Universidade Federal do Rio de
Janeiro.
BARRETO, A., 2011, Uma Abordagem para Definio de Processos Baseada em
Reutilizao Visando Alta Maturidade em Processos, Tese de Doutorado,
Universidade Federal do Rio de Janeiro.
BARRETO, A.S., ROCHA, A. R., 2010, Defining and Monitoring Strategically Aligned
Software Improvement Goals, In: 11th International Conference on Product
Focused Software Process Improvement, Lecture Notes in Computer Science, vol
6156/2010, pp380-394.
228
BASILI. V., ROMBACH, H., 1994, Measurement, In: Encyclopedia of Software Engineering,
v.1,
BASILI,V., HEIDRICH, J., LINDVALL, M., MNCH, J., REGARDIE, M., TRENDOWICZ, A., 2007,
GQM+Strategies - Aligning Business Strategies with Software Measurement, In: 1st
International Symposium on Empirical Software Engineering and Measurement.
BASILI. V.; CALDIERA, G.; ROMBACH, H., 1994, Goal Question Metric Paradigm, In:
Encyclopedia of Software Engineering, v.2, pp: 527 532.
BASS,L., BELADY,L.BROWN,A., FREEMAN,P. ISENSEE,S., KAZMAN,R., KRANSNER,H.,
MUSA,J. PFEEGER,S, VREDENBURG,K., WASSERMAN,T., 1999, Constructing
Superior Software, Software Quality Institute Series, Macmillan Technical
Publishing.
BENNEYAN, J. C., LLOYD, R., PSELK, P. E., 2003, Statistical Process Control as a Tool for
Research and Healthcare Improvement, British Medical Journal - Quality and
Safety Health Care, vol. 12, pp. 458-464.
BUSSAB, W. O., MORETTIN, P. A., 2006, Estatstica Bsica: 5. Edio, Editora Saraiva, So
Paulo SP, In FVERO, L. P., BELFIORE, P., SILVA, F. L., CHAN, B. L., 2009, Anlise
de Dados: Modelagem Multivariada para Tomada de Decises, Editora Elsevier,
Campus, Rio de Janeiro RJ.
CAIVANO, D., 2005, Continuous Process Improvement Through Statistical Process Control,
In: Proceedings of the Ninth European Conference on Software Maintenance and
Reengineering, pp. 288-293.
CAMPOS, F. B., CONTE, T. U., KATSURAYAMA, A. E., ROCHA, A. R., 2007 Gerncia
Quantitativa para o Processo Desenvolvimento de Requisitos, VI Simpsio
Brasileiro de Qualidade de Software - SBQS 2007, Porto de Galinhas PE.
CARD, D. N., DOMZALSKI, K., DAVIES, G., 2008, Making Statistics Part of Decision Making in
an Engineering Organization, IEEE Software, 25(3), pp. 37-47.
CURTIS,B., REIFER,D. SESHAGIRI,G.V., HIRMANPOUR, T., KEENI,G., 2008 The Case for
Quantitative Process Management, IEEE Software, v. 25, n. 3, pp 24-28.
DEMING, W. E., 1986, Out of the Crises, Massachusetts Institute of Technology, Center of
Advanced Engineering, Cambridge.
DUMKE, R., EBERT, C., 2010, Software Measurement: Establish - Extract - Evaluate Execute: Springer-Verlag Berlin Heidelberg.
FALBO, R. A., 2005, Notas de Aula de Engenharia de Software, Departamento de
Informtica, Universidade Federal do Esprito Santo.
FENTON, N.E., NEIL,M., 2000, Software Metrics: a Roadmap, in: Proceedings of the 22nd
International Conference on Software Engineering, San Francisco, USA pp 359-370.
229
FENTON, N.E e PFLEEGER, S.L., 1997, Software Metrics: a Rigorous and Practical
Approach, PWS Publishing Company, 2nd Edition,
FERREIRA, A. I. F., 2009, Seleo de Processos de Software para Controle Estatstico,
Dissertao de Mestrado, Universidade Federal do Rio de Janeiro.
FLORAC, W. A., CARLETON, A. D., BARNARD, J. R., 2000, Statistical Process Control:
Analyzing a Space Shuttle Onboard Software Process, IEEE Software, 17(4), pp. 97106.
FLORAC, W. A., CARLETON, A. D., 1999, Measuring the Software Process, Addison-Wesley.
GARCIA,F. BERTOA,M.F., CALERO,C. VALLECILLO,A., RUIZ,F., PLATTINI,M., GENERO,M.,
2006, Towards a Consistent Terminology for Software Measurement Information
and Software Technology, Information and Software Technology, v.48, n. 8, pp 631644.
GOETHERT, W., FISHER, M., 2003, Deriving Enterprise-Based Measures Using the Balanced
Scorecard and Goal-Driven Measurement Techniques, Carnegie Mellon University,
Software Engineering Institute, Technical Note CMU/SEI-2003-TN-024.
GOH, T.N., XIE, M., XIE, W., 1998, Prioritizing Process in Initial Implementation of
Statistical Process Control, IEEE Transactions on Engineering Management, v.45,
n.1, pp 66-72.
GOPAL, A., KRISHNAN, M.S., MUKHOPADHYAY, T. GOLDENSON, D.R., 2002, Measurement
Programs in Software Development: Determinants of Success, IEEE Transactions
on Software Engineering, v.28, n.9, pp 863-875.
ISO/IEC, 2002, ISO/IEC 15939 - Software Engineering Software Measurement Process,
The International Organization for Standardization and the International
Electrotechnical Commission.
ISO/IEC, 2003, ISO/IEC 15504 - Software Engineering - Process Assessment, The
International
Organization
for
Standardization
and
the
International
ISO/IEC, 2008, ISO/IEC 12207 Systems and Software Engineering Software Life Cycle
Process, The International Organization for Standardization and the International
KAPLAN, R.S., NORTON, D.P. The Balanced Scorecard Translating Strategy into Action,
Harvard Business School Press.
KITCHENHAM, B., HUGHES, R. T., LINKMAN, S. G., 2001, Modeling Software Measurement
Data, IEEE Transactions on Software Engineering, 27(9), pp. 788-804.
KITCHENHAM, B., JEFFERY, D. R., CONNAUGHTON, C., 2007, Misleading Metrics and
Unsound Analyses, IEEE Software, 24(2), pp. 73-78.
230
KITCHENHAM, B., KUTAY, C., JEFFERY, D. R,, CONNAUGHTON, C., 2006, Lessons Learnt
from the analysis of large-scale corporate databases, International Conference on
Software Engineering, pp 439-444.
LUECKE, R.,2010,Estratgia, Harvard Business Essentials, Editora Record.
LANTZY, M. A., 1992, Application of Statistical Process Control to the Software Process, In:
Proceedings of the 9th Washington Ada Symposium on Empowering Software
Users and Developers, ACM Press, pp. 113-123.
McGARRY, J, CARD, D., JONES, C., LAYMAN, B., CLARK, E., DEAN, J., HALL, F, 2002, Pratical
Software Measurement: Objetive Information for Decision Makers, Assison Wesley.
NEUBAUER, D., 2011, Understanding Process Capability: The Difference Between
Capability and Control, ASTM Standardization News, May/June.
NIESSINK, F., VLIET, H., 2001, Measurement Program Success Factors Revisited,
Information and Software Technology, v.43, n.10, pp 617-628
PARK,R.E, GOETHERT, W.B., FLORAC, W.A., 1996, Goal-Driven Software Measurement A
Guidebook, Carnegie Mellon University, Pittsburgh, PA, CMU/SEI-96-HB-002.
PMI, 2008, Project Management Institute, A Guide to the Project Management Body of
Knowledge, 4. ed., Newton Square: PMI Publications.
PUTNAM, L. H. e MYERS, W., 2003, Five Core Metrics: The Intelligence Behind Successful
Software Management, Dorset House Publishing Company.
RACKZINSKI, B., CURTIS, B., 2008, Software data Violate SPCs Underlying Assumptions,
IEEE Software, v. 25,n. 3, pp 49-50.
SARGUT, K. U., DEMIRORS, O., 2006, Utilization of Statistical Process Control (SPC) in
Emergent Software Organizations: Pitfalls and Suggestions, Software quality
Journal, v. 14, n. 5, pp 135-157
SEI, 2010, Capability Maturity Model Integration (CMMI) for Development, version 1.3,
Carnegie Mellon University, Software Engineering Institute, Technical Report
CMU/SEI-2010-TR-033.
SHEWART, W. A., 1939, Statistical Method from the Viewpoint of Quality Control,
Washington, D.C.: Graduate School of the Department of Agriculture (Reprinted in
Mineola, N.Y.: Dover D. Publications, Inc., 1986).
SIVIY, J., PENN, M. L., HARPER, E., 2005, Relationship Between CMMI and Six Sigma.
Technical Note, CMU/SEI-2005-TN-005.
SOFTEX, 2011a, MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral.
Disponvel em: http://www.softex.br/mpsbr.
SOFTEX, 2011b, MPS.BR Melhoria de Processo do Software Brasileiro Guia de
Implementao Parte 2. Disponvel em: http:www.softex.br/mpsbr.
231
SOFTEX, 2011c, MPS.BR Melhoria de Processo do Software Brasileiro Guia de

Implementao Parte 6. Disponvel em: http://www.softex.br/mpsbr.
SOLINGEN, R.; BERGHOUT, E., 1999, The Goal/Question/Metric Method: a Practical Guide
for Quality Improvement of Software Development, McGraw-Hill.
TARHAN, A., DEMIRORS, O., 2006, Investigating Suitability of Software Process and
Metrics for Statistical Process Control, Lecture Notes in Computer Science, 4257,
pp. 88-99.
WANG, Q., LI, M., 2005, Measuring and Improving Software Process in China, In:
Proceedings of International Symposium on Empirical Software Engineering, pp
183-192.
WHEELER, D. J., 1997, Good Limits from Bad Data, Quality Digest, April, 53, In WELLER, E.
F., CARD, D., 2008, Appling SPC to Software Development: Where and Why, IEEE
Software, 25(3), pp. 48-50
WHEELER, D. J., POLING, R. S. , 1998, Building Continual Improvement: A Guide for
Business, SPC Press.
WHEELER, D. J., 2000, Understanding Variation: The Key to Managing Chaos, Second
Revised Edition, SPC Press, Knoxville Tennessee.
WHEELER, D. J., CHAMBERS, D. S., 2010, Understanding Statistical Process Control, Third
Edition, SPC Press, Knoxville - Tennessee.
232

Medição de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Medição de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Medio de Software e Controle Estatstico de Processos

MEDIO DE SOFTWARE E CONTROLE

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

Ana Regina Cavalcanti da Rocha

MEDIO DE SOFTWARE E CONTROLE

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

Ana Regina Cavalcanti da Rocha

COPPE/Universidade Federal do Rio de Janeiro (UFRJ). Membro da Equipe

Gleison dos Santos Souza

Monalessa Perini Barcellos

Medio de Software e Controle Estatstico de Processos

A Julia, Rafael e Joo

A minha famlia e amigos que me possibilitaram chegar a esse momento, em

Medio de Software e Controle Estatstico de Processos

Aos alunos e colegas que passaram pelo grupo de Qualidade de Software da

Diniz de Souza, Carlos Simes e Rodrigo Magalhes que

contriburam na reviso do livro.

Medio de Software e Controle Estatstico de Processos

tanto o apoio a iniciativas, tais como o Simpsio Brasileiro de

quanto iniciativas da Secretaria de Poltica de Informtica (SEPIN),

Medio de Software e Controle Estatstico de Processos

dos seus oito captulos: 1 Introduo; 2 Medio de Software; 3 Planejamento

tanto na Academia, onde, daqui em diante, ser uma referncia

quanto no aprimoramento do conhecimento de Implementadores e

como na evoluo da baixa para alta maturidade nas organizaes

O livro 'Medio de Software e Controle Estatstico de Processos' tambm

o Controle Estatstico de Processos (nvel B do modelo de referncia

as organizaes que adotam o modelo MPS carecem destas boas

Enfim, trata-se de um candidato a caso de sucesso na rea de Qualidade de

Medio de Software e Controle Estatstico de Processos

PARTE I - Medio de Software................................................................. 17

PARTE II - Controle Estatstico de Processos ....................................... 56

Medio de Software e Controle Estatstico de Processos

4.3 O Comportamento dos Processos.............................................................................................. 62

PARTE III - Medio e Melhoria de Processos de Software ......... 153

Medio de Software e Controle Estatstico de Processos

7.3.4 - Medidas relacionadas a Gerncia de Portflio de Projetos ............................ 170

Captulo 8 - Medio no MR-MPS................................................................................. 203

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

gerentes de projeto interessados em medir e controlar projetos de

implementadores de melhoria de processos de software que

Medio de Software e Controle Estatstico de Processos

estatstico de processos para implant-las em organizaes de

professores de graduao em Computao;

estudantes de graduao em Computao;

professores de ps-graduao em Engenharia de Software;

estudantes de ps-graduao em Engenharia de Software.

Nos prximos captulos este livro fornecer:

os conceitos relacionados medio, a importncia da medio

conhecimento e orientaes para planejamento e execuo de

conhecimento sobre controle estatstico de processos de software

conhecimento sobre a evoluo da medio nos nveis de

conhecimento sobre medio e evoluo da capacidade no MPS

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

Medio de Software e Controle Estatstico de Processos

2.2 Conceitos da Medio de Software

Medida: quantificao de atributos de entidades. Pode ser medida base

Elemento Mensurvel: propriedade de uma entidade que pode ser

Entidade Mensurvel: entidade que pode ser caracterizada pela