As Sete Mtricas de Controle do Projeto

Poucos temas provocam tanta discusso na comunidade de desenvolvimento de software como o assunto
mtricas. Existe uma percepo geral de que mtricas so necessrias mas, ao mesmo tempo, so difceis de
se coletar e a recompensa de sua interpretao no imediata. Uma sensao sempre presente a de que o
valor agregado pela coleta e anlise de mtricas ocorreria muito mais tarde. reio que esta sensao est
vinculada ! uma experi"ncia real da comunidade com as mtricas da programao estruturada e com o ciclo
de vida waterfall.
#pesar de acreditar que medir sempre mel$or do que estimar, a prtica %rasileira adota francamente o
feeling e a estimativa & e aqui eu cometo um eufemismo & na verdade as condi'es de um pro(eto plane(ado
de modo tradicional no contri%uem para o uso imediato das mtricas, sendo muito comum uma interpretao
dos n)meros do pro(eto ao final de uma release ou verso. Por consequ"ncia as mtricas de um pro(eto
aca%am por contri%uir para o entendimento do pr*ximo pro(eto e muito pouco para o atual.
+as contri%uir para a quantificao dos processos de desenvolvimento de uma empresa ( seria uma grande
misso para a coleta de mtricas, isto se as diferenas de neg*cio e tecnologia do pr*ximo pro(eto de
software no eliminassem o %ril$o dessa contri%uio. -alve. isto explique, em parte, a relut/ncia em investir
firmemente na medio dos pro(etos. 0o entanto esta situao ( no ocorre quando aplicamos o processo
iterativo&incremental, diferentemente do processo waterfall, o iterativo&incremental utili.a muito rapidamente
toda e qualquer informao de feed%ac1 que as mtricas possam oferecer. Por outro lado, se alm do
processo iterativo, estivermos falando de um desenvolvimento orientado a o%(etos, ento as mtricas gan$am
uma nova e importante dimenso, pois neste paradigma encontramos uma integrao muito maior entre os
modelos que constroem o software, desde o levantamento de requisitos at o momento de teste e li%erao.
Uma das maiores ra.'es porque a industria automo%ilstica, em geral, gera produtos de mais alta qualidade
do que a industria de software, que a medio de seus artefatos mais fortemente integrada ao processo
de pro(eto e construo de carros. 2s loops de feed%ac1 existem em todas as reas do processo de
manufatura, vo desde decis'es de design, medi'es de c$o de f%rica at relat*rios de experimentao de
campo.
0este documento apresentaremos sete mricas que tem por o%(etivo o controle e acompan$amento do
pro(eto. Estas mtricas so usadas na rea c$ave de processo que o modelo do 3E4&++ denomina trac1ing
and oversig$t, so portanto para superviso e no para estimativa de pro(eto.
O que Mtrica?
Podemos definir mtrica como um atri%uto mensurvel de uma entidade. aso a entidade se(a um pro(eto,
uma mtrica seria, por exemplo, o seu taman$o. -aman$o um atri%uto de pro(eto e pode ser medido. 5omo
medi&lo outra questo6.
Podemos perguntar qual o taman$o de um determinado carro e seremos imediatamente compreendidos pela
maioria das pessoas. #lguns porm, antes de responder, perguntaro se entendemos por taman$o o seu
comprimento, sua largura, seu volume ou mesmo sua pot"ncia. 0estes casos as respostas seriam dadas, por
exemplo, em metros, metros c)%icos ou 7Ps. 4sto mostra a necessidade de contextuali.ao e indica os
vrios angulos de a%ordagem de um pro%lema de medio.
2utro exemplo8 se(a um determinado requisito de software, que foi definido durante o processo de
levantamento de requisitos, mas continua, nas fases seguintes, sofrendo altera'es, conforme os usurios
mudam sua concepo ou viso do sistema. 2 atri%uto esta%ilidade pode ser uma mtrica para o requisito e
podemos quantificar esse atri%uto pelo n)mero de ve.es em que o requisito foi alterado. 9 facil o%ter essa
mtrica diretamente da contagem do n)mero de ordens de mudana 5solicita'es de mudana de software6
que se referem a esse requisito.
Usualmente o que coletamos so mtricas que podem ser medidas diretamente, mas que so de pouco
significado numa interpretao isolada. Por exemplo, o n)mero de classes de um modelo de design
encontrado por simples inspeo, mas tem pouca significao por si mesmo. Porm, podemos estimar o
taman$o do sistema se com%inarmos o n)mero de classes com o n)mero de opera'es e atri%utos de cada
classe, alm de medidas so%re a profundidade da rvore de $erana. Estas so as c$amadas mtricas
primitivas, so dados %rutos que com%inados com outros dados %rutos podem levar ! mtricas significativas.
As Mtricas de Projetos OO so Diferentes das Mtricas Waterfall
oletar a mesma informao e interpretar da mesma maneira que os gerentes sempre fi.eram quando
usavam um processo waterfall pode causar pro%lemas quando aplicado a um processo iterativo&incremental.
Por exemplo8 com uma a%ordagem waterfall uma mtrica usada para medir progresso poderia ser8 :a ;<=
dos gastos o documento de requisitos deve estar completo:. 4sto no se aplicaria a uma a%ordagem iterativa,
pois, nesta a%ordagem o documento de requisitos no fica completo at a )ltima iterao. Uma aplicao sem
cuidado dessa mtrica waterfall levaria a interpretar que o pro(eto 22 est atrasado, levando ! preocupa'es
desnecessrias.
#s mtricas so diferentes porque o processo e os produtos so diferentes8 lidamos com o%(etos e no
fun'es, releases executveis e no documentao. Porm a principal questo talve. se(a que o processo
iterativo necessite de uma mudana no foco das mtricas. Precisamos desenfati.ar a import/ncia do valor
a%soluto e enfati.ar a o%teno de um valor inicial, agregado a uma taxa de mudana desse valor. 4sto quer
di.er analisar a tend"ncia.
>ual o pro(eto criar o mel$or sistema? #quele em que o tempo mdio entre fal$as permanece, release ap*s
release, flutuando em torno de uma semana, ou aquele em que o tempo mdio entre fal$as vem caindo
significativamente, apesar de partir de um patamar mais alto, por exemplo dois dias?
0o primeiro caso a mtrica a%soluta aparentemente indica um sistema de mel$or qualidade, com uma menor
frequ"ncia de fal$as que o segundo sistema. +as, o%servando ao longo do tempo, o sistema com frequ"ncia
de fal$as em torno de uma semana se mantm estvel, 5com fal$as a cada semana6, enquanto o segundo
sistema demonstra que est evoluindo. 4sto pode significar que a equipe do segundo sistema est fa.endo a
coisa certa em termos de depurao. Podemos esperar um sistema de mel$or qualidade no segundo caso.
# concluso que a tend"ncia com relao ao tempo mais importante que o valor a%soluto num
determinado instante. om relao ! pergunta acima, se definimos a mtrica :maturidade de software: como
ro%uste. ao uso e %aixa frequ"ncia de erros, verificamos que seu comportamento no tempo claramente
mais importante do que o valor a%soluto do pseudo +-@A 5+ean -ime @etween Aailures6. Este enfoque
recon$ece o carter inerentemente din/mico de um processo de desenvolvimento iterativo e em ve. de se
concentrar no valor, prefere, explicitamente, focali.ar a primeira derivada ou a mudana com respeito ao
tempo. # com%inao do valor corrente com a tend"ncia corrente, capa. de fornecer um indicador muito
mel$or para a tomada de deciso gerencial.
O Que um Projeto Precisa Medir?
+uitas mtricas diferentes podem ser de valor para um processo iterativo&incremental. #presentaremos como
exemplo um con(unto de sete mtricas consideradas c$ave para qualquer pro(eto de software e que
demonstraram ser )teis na prtica. Estes indicadores tem a virtude de serem simples, fceis de coletar, fceis
de interpretar e difceis de mal&interpretar. -r"s so indicadores de gerenciamento e quatro so indicadores
de qualidade.
Indicadores de Gerenciamento
-ra%al$o e Progresso. 5-ra%al$o reali.ado ao longo do tempo6
2ramento e Bespesas. 5Castos ao longo do tempo6
#locao e Dotatividade da Equipe. 5+udana de pessoal ao longo do tempo6
Indicadores de Qualidade
Aluxo de +udanas e Esta%ilidade. 5Aluxo de altera'es ao longo do tempo6
Aragmentao e +odularidade. 5Aragmentao mdia por mudana ao longo do tempo6
Detra%al$o e #dapta%ilidade. 5Detra%al$o mdio por mudana ao longo do tempo6
-empo mdio entre fal$as e +aturidade. 5-axa de defeitos ao longo do tempo6
#o coletar estes indicadores ao longo do tempo devemos escol$er a a%rang"ncia da coleta, isto ,
definir se estaremos coletando por iterao, por m*dulo do sistema, por equipe, etc.
Decomendamos, no mnimo, a coleta por iterao para acompan$amento do pro(eto e a coleta por
m*dulo para exame da qualidade do produto.
Em resumo, a seguinte lista deve fa.er parte de qualquer plano de mtricas de pro(eto8
Progresso -ra%al$o pelo tempo Por 4terao Por Pac1age
Bespesa Casto pelo tempo Por 4terao Por Pac1age
Dotatividade +udana de pessoal pelo tempo Por 4terao Por Pac1age
Esta%ilidade Aluxo de mudanas pelo tempo Por 4terao Por Pac1age
+odularidade Aragmentao pelo tempo Por 4terao Por Pac1age
#dapta%ilidade Detra%al$o por mudana pelo tempo Por 4terao Por Pac1age
+aturidade -axa de defeitos pelo tempo Por 4terao Por Pac1age
2%servao8 0o tratamos neste documento de mtricas para estimativa e mtricas para verificao
da %oa formao de alguns modelos e artefatos. -ais mtricas tam%m devero fa.er parte de um
plano de mtricas de pro(eto.
As Sete Mtricas ! Pro"resso # $ra%al&o reali'ado ao lon"o do tem(o
2 tra%al$o reali.ado ao longo do tempo deve ser confrontado com o tra%al$o plane(ado para a
iterao. Bevemos usar uma medida o%(etiva como, por exemplo, cenrios de casos de uso, classes
ou o%(etos criados e guardados so% a %aseline de um controle de configurao. 2 n)mero de lin$as
de c*digo fonte 53E26, depois de uma ou duas itera'es, torna&se uma %oa medida de tra%al$o,
principalmente do ponto de vista do implementador. 2 n)mero de casos de teste executados com
sucesso, deve ser usado como medida do ponto de vista do testador. -am%m so )teis os n)meros
de 32Fs fec$adas e os critrios de sucesso atingidos no assessment de final de iterao.
2 progresso, portanto, a verificao de quanto o reali.ado se aproxima daquilo que foi plane(ado
para cada iterao e para os pontos intermedirios de verificao 5c$ec1points6. Por exemplo8 se
pensamos em medir o tra%al$o pelo n)mero de Use&ases 5U6 implementados, comparamos o
n)mero de U plane(ados versus U implementados e assim o progresso pode ser indicado como
uma porcentagem 5=6.

Para um acompan$amento de pro(eto mais preciso, devemos usar como medida de progresso no
apenas os Use&ases mas os enrios derivados desses Use&ases. Esta mtrica permite um
refinamento na medida do tra%al$o reali.ado. Uma variao desta metrica o 0)mero de asos de
-este, pois para cada enrio de um Use&ase temos um -est&ase correspondente.
2utras mtricas que devem ser coletadas so8 o n)mero de classes, o n)mero de 32s fec$adas e
o n)mero de o%(etivos 5critrios6 atingidos ao final da iterao.
)! Des(esa # Gastos ao lon"o do tem(o
#s despesas ao longo do tempo devem ser comparadas com o plano de gastos. Para a maioria dos
pro(etos de software, onde intenso o uso de servio intelectual, o perfil de gastos geralmente segue
o perfil de alocao de pessoal. Portanto, a menos de gastos pontuais, possvel criar uma curva de
plane(amento de gastos %aseada na curva de alocao de pessoal. 50o processo iterativo $
$eursticas adequadas para alocao e dimensionamento da equipe6.
*! +otati,idade # Mudan-a de (essoal ao lon"o do tem(o
Em um pro(eto tpico uma equipe pequena ir reali.ar as primeiras itera'es para ela%orao de
prot*tipos e definio de arquitetura e, ap*s isso, o time crescer para uma alocao de construo
a pleno vapor. #lm da alocao variar conforme a fase, outro fator ir contri%uir para a variao da
equipe8 a rotatividade. 2 acompan$amento gerencial verifica o turnover & a variao da equipe, a
adequao dessa equipe ! demanda de tra%al$o na iterao, a sada prematura de mem%ros da
equipe, o clima interno, etc. Um plano de alocao, com perfis e durao, permitir comparar com o
staff realmente alocado.
#lm de examinar a variao do pessoal dentro da equipe, precisamos avaliar em que momentos a
carga de tra%al$o exigir mais ou menos staff. Bada uma determinada alocao de pessoal,
pro(etamos a Ea%or Date 5taxa de tra%al$o6 esperada. >uando ocorre uma variao da equipe,
verificamos o quanto de so%retra%al$o este evento ocasionou.
.! /sta%ilidade # 0lu1o de altera-2es ao lon"o do tem(o
2 fluxo de altera'es 5ou de mudanas6 ao longo do tempo definido como o n)mero de solicita'es
de mudana a%ertos e fec$ados durante o ciclo de vida de desenvolvimento. # esta%ilidade
definida como a relao entre solicita'es a%ertas versus fec$adas. >uanto mais pr*ximas as duas
curvas, mais estvel o processo. Esta informao, associada ao plano de releases, nos permitir
previsi%ilidade de cronograma.
3e(a 0 o n)mero total de solicita'es de mudana. Aluxo de mudanas ser o n)mero total de
solicita'es de mudana a%ertas menos as fec$adas 50a%ertas & 0fec$adas6.
$amemos 32 53oftware $ange 2rder6 uma solicitao de mudana. 3e(a 32tipoG as
mudanas referentes a defeitos crticos. 3e(a 32tipoH as mudanas referentes a defeitos normais.
3e(a 32tipo; as mudanas referentes a mel$orias no sistema. 3e(a 32tipoI as mudanas
referentes a novas caractersticas. Esta%ilidade ser a tend"ncia das solicita'es de mudana no
tempo.
aso um determinado sistema, por exemplo, apresente um alto fluxo de mudanas isto significa um
alto valor de 0a%ertas & 0fec$adas, porm a tend"ncia desse valor ao longo do tempo mais
informativo do que seu valor a%soluto. Essa tend"ncia denominada esta%ilidade. Para representar
essa tend"ncia temos duas alternativas8 efetuar a conta 0a%ertas & 0fec$adas e construir a curva no
tempo com o resultado do fluxo de mudanas 5como no primeiro grfico6, ou simplesmente plotar
duas curvas com os valores diretamente o%tidos de 0a%ertas e 0fec$adas 5como no segundo
grfico6.
#s duas representa'es podem ser )teis para fins diferentes8 # primeira demonstra mais
intuitivamente a esta%ilidade do pro(eto, a segunda nos d detal$es quanto ! intensidade do fluxo de
mudanas.
# esta%ilidade pode ser medida, portanto, como a relao entre 0 em a%erto e 0 fec$ados, mas
tam%m podemos necessitar de indicadores mais detal$ados como8 32tipoG em a%erto e 32tipoG
fec$ados, 32tipoH em a%erto e 32tipoH fec$ados, e assim por diante. Podemos construir curvas
no tempo para os a%ertos e fec$ados e comparar a proximidade ou afastamento entre elas.
onforme nossa preciso de anlise podemos utili.ar apenas 0, deixando de lado as especficas
32s.
3! Modularidade # 0ra"menta-o mdia (or mudan-a ao lon"o do tem(o
# fragmentao definida como a extenso da mudana, isto , a quantidade de software que est
em %aseline e que precisa ser retra%al$ado. +edimos a fragmentao com duas grande.as8 #
fragmentao devida ao retra%al$o em a%erto 5@6, e a fragmentao devida ao retra%al$o ( fec$ado
5A6.
# modularidade definida como a medida da locali.ao da fragmentao, e indica quanto da
fragmentao est locali.ada ou espal$ada. Um aspecto importante da modularidade a indicao
da tend"ncia da fragmentao mdia ao longo do tempo. Em um pro(eto com %om design, a
expectativa que a fragmentao fique estvel ou diminua.
3e(a @ a quantidade estimada, em lin$as de c*digo, do retra%al$o em a%erto devido !s mudanas
32tipoG, 32tipoH e 32tipo;. 3e(a A a quantidade medida, em lin$as de c*digo, do retra%al$o
fec$ado devido !s mudanas 32tipoG, 32tipoH e 32tipo;. Estes valores so a fragmentao
relativa !s mudanas de tipos G, H e ;. 52 efeito das mudanas do tipo I muito variado e deve ser
analisado ! parte. Deflete um novo tra%al$o e no um rewor16.
Aragmentao mdia por 32 ser @J0 ou AJ0 na unidade KE2L. +odularidade ser a tend"ncia de
@J0 e AJ0 ao longo do tempo. Estes indicadores fornecem uma viso do carter da mudana8
positivo ou negativo em relao ! futura manuteni%ilidade.
4! Ada(ta%ilidade # +etra%al&o mdio (or mudan-a ao lon"o do tem(o
Podemos definir retra%al$o como o esforo gasto com mudanas, isto , o esforo ou carga de
tra%al$o para analisar, implementar e retestar as altera'es no c*digo que est em %aseline. #
adapta%ilidade ser, ento, definida como a tend"ncia desse retra%al$o ao longo do tempo. Para um
pro(eto saudvel esperamos uma diminuio do retra%al$o.
3e(a E o esforo, em $omens&$ora, do retra%al$o devido !s mudanas 32tipoG, 32tipoH e
32tipo;. Detra%al$o mdio por 32 ser EJ0 na unidade K7$L. #dapta%ilidade ser a tend"ncia de
EJ0 ao longo do tempo.
# adapta%ilidade nos permite uma viso so%re a facilidade com que o produto pode ser alterado, se a
tend"ncia do retra%al$o aumentar de valor, podemos interpretar como um mau sinal so%re a
manuteni%ilidade futura do sistema.
5! Maturidade # $a1a de defeitos ao lon"o do tem(o
2 tempo mdio entre fal$as uma forma de medir a qualidade de um produto. Deflete a taxa de
desco%erta de defeitos quando certas condi'es de operao esto satisfeitas. +aturidade pode ser
definida como a taxa de defeitos ao longo do tempo e nos fornece um nvel de confiana no produto.
3e(a U- 5Usage -ime6 o n)mero de $oras que certa %aseline vem operando ou vem sendo testada
no exerccio de seus cenrios so% condi'es realistas. +-@A ser U-J532tipoGM32tipoH6 na
unidade K$L. +aturidade ser a tend"ncia do +-@A ao longo do tempo.
Concluso
+tricas de tend"ncia em relao ao tempo fornecem uma viso de como o processo e o produto
esto evoluindo. 2 desenvolvimento iterativo lida com o gerenciamento de mudanas, e medir a
mudana o mais importante aspecto da coleta de mtricas. Nalores a%solutos de produtividade e
mel$oria da qualidade so quest'es secundrias enquanto no se conseguir o o%(etivo primrio de
qualquer gerenciamento8 previsi%ilidade de pra.os e custos.
Referncias: [Royce, Walker, 1998] Royce, Walker E., Software Project Management: A n!f!e" #ramework $A""!%on&We%ley P'(l!%)!ng *om+any, 1998,.
[-ooc), .ra"y, 199/] -ooc), .ra"y, 0(ject Sol't!on%: Manag!ng t)e 0(ject&0r!ente" Project $A""!%on&We%ley P'(l!%)!ng *om+any, 199/,.
[00PM] Rat!onal n!1er%!ty, 0(ject&0r!ente" Project Management 2ra!n!ng *o'r%e $Rat!onal Software *or+orat!on,
Moacyr *ar"o%o "e Mello #!l)o. Eng. El3tr!co +ela E%cola Pol!t3cn!ca "a n!1er%!"a"e "e S4o Pa'lo & SP. *om c'r%o "e a+erfe!5oamento em
.erenc!a "e Projeto% e Em+reen"!mento% +ela #'n"a54o .et6l!o 7arga% & #.7. 2ra(al)o' com meto"olog!a na n!1er%!"a"e "e S4o
Pa'lo e fo! .erente "e 2ecnolog!a "a 8nforma54o na 2ec-an & 2ecnolog!a -anc9r!a S:A, on"e !m+lanto' +roce%%o% !terat!1o% "e
"e%en1ol1!mento "e %oftware. At'almente 3 Software Eng!neer S+ec!al!%t re%+on%91el +ela 9rea "e +roce%%o% e gerenc!a "e re;'!%!to% "a
Rat!onal Software *or+orat!on.