métricas em fabricas de software

Tudo o que você sempre quis saber sobre o seu projeto...

Luiz Borba (borba@cesar.org.br)

mas tinha medo de perguntar.

Introdução

• C.E.S.A.R (Centro de Estudos e Sistemas Avançados do Recife)• Cenário do C.E.S.A.R

– Perto de 400 empregados– Vários Projetos diferentes

• Não trabalha exclusivamente em mercados verticais– Arquiteturas diferentes– Tecnologias diferentes– Qual a taxa de sucesso dos nossos projetos ?– “Para mudar seu destino, primeiro você tem mudar sua atitude”

• Grupo de Engenharia– Criar mecanismos para melhoria da produtividade

• Problema: Como saber se as iniciativas para melhoria deram resultado ?– A PRODUTIVIDADE DEVE SER MEDIDA !

Produtividade

• O que é produtividade ?– Várias definições– Razão entre o que é produzido pelo custo

• PROBLEMA: Subprodutos (modelos, documentos de requisitos, documentos de arquitetura, por exemplo) devem ser contabilizados ?– Servem para facilitar o desenvolvimento– O produto principal é o código (software)– E o código de teste ?– É isso mesmo ?

O que afeta a Produtividade ?

• Estudos apontam entre 18 e 100 variáveis– Fatores Humanos (motivação, capacitação, ...)

• “Eu só tenho uma regra: todo vocês lutam e ninguém desiste ou então eu mesmo mato vocês” (Sargento Rsczak, Tropas Estelares)

– Fatores Organizacionais (espaço físico, nível de ruído, faixas salariais, ...)• “Reuniões são indispensáveis quando se quer não fazer nada”

(john kenneth galbraith)– Fatores Técnicos (processo, ferramentas, linguagem de programação, ...)

• “Quando tudo o que você tem é um martelo, todo o resto parece prego”

• “Usabilidade é como oxigênio, você nunca percebe, até a hora que falta”

• PROBLEMA: Qual o peso de cada uma delas ?– Os pesos podem ser diferentes em cada instituição

• Medidas de produtividade devem ser específicas para a organização

O que afeta a Produtividade ?

• PROBLEMA: O que medir ?– Que fatores podem ser medidos e como ?

• PROBLEMA: Qual o escopo ?– Individual– Time– Organizacional

• Mais problemas ???– “O difícil a gente faz de uma vez, o impossível leva um pouco mais

de tempo” (American SeaBees)

O que afeta a Produtividade ?

• Processo (cascata x iterativo) ?– [Thomas01] 1027 projetos (13% não falharam)

• 82% apontaram a cascata como a causa principal– [Jones95] 6700 projetos

• 4 dos 5 causas de falha, eram relacionados com cascata– [Jonhson02] Levantamento completo de requisitos no início

• 45% features NUNCA SÃO USADAS• 19% RARAMENTE SÃO USADAS

– [Solon02] 43700 projetos• Iterativo – 570 FP por full-time developer• Cascata – 480 (BUUUUU)

O que afeta a Produtividade ?

O que afeta a Produtividade ?

• “Você só deve usar desenvolvimento iterativo nos projetos que você quer que dê certo” (Martin Fowler)

O que afeta a Produtividade ?

• Tamanho

Premissas da nossa solução

• Lei de Gilbs: “Anything you need to quantify can be measured in some way that is superior to not measuring it at all”– Não procure indefinidamente pela MÉTRICA PERFEITA !– Não existe MÉTRICA PERFEITA !

• Premissas para a solução:– Simplicidade

• “É fácil ter uma idéia complicada, mas é muito, muito difícil ter uma idéia simples” (Carver Mead)

– Medição no escopo dos times (projetos)– Concentração nos fatores técnicos

• Métricas de Produtividade• Métricas de Qualidade

– CESAR está crescendo rapidamente• Métricas de Reuso

– Grupo de Engenharia está investindo em Reuso

Métrica de Produtividade

• ESFORÇO / FP (Esforço em horas por Ponto de Função)• Esforço

– Total de horas por projeto

• Ponto de Função– É uma medida de complexidade

• PROBLEMAS:– Todas as horas tem o mesmo custo ?– A reportagem de horas está correta ?– FP usada é correta ? (FP venda x FP estimada x FP real)– Utilizada no mercado

• É possível comparações externas ?– FP leva em consideração a documentação produzida ?

• Opção por considerar apenas o software como produto !

ESFORÇO / FP

• Interpretação diferente dependendo do processo – Cascata

• Número correto ao final do projeto– Iterativo

• Implementação mais cedo• Realimentação entre iterações (velocidade)

ESFORÇO / FP (mais problemas)

• FP ainda não é usado largamente no CESAR– UCP (Pontos de Caso de Uso) pode ser usado– CESAR tem planos para padronizar o uso de FP

• Outra Alternativa: ESFORÇO / KLOC (Esforço em horas por Mil Linhas de Código)– Existe relação entre LOC e Complexidade ?

• Nem sempre• Projetos com mais QUALIDADE ou REUSO são penalizados (menos LOC)• LOC varia com tecnologia, linguagem• Pode criar ilusão

– Métrica utilizada por aí• Avaliação individual

– É melhor do que nada ? (não temos FP ainda)

Linhas de Código

1.944

62.144

34960

30.492

37.037

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

A B C D E

Qu

atid

ade

de

linh

as d

e có

dig

o

LOC

java + flash

Horas/KLOC

428,6523

395,5244

240,6894

278,1405

127,0832

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

450,00

500,00

A B C D E

Horas/KLOC

java + flash

Métricas de Qualidade (BUGS/KLOC)

• “Qualquer bug suficientemente avançado é indistinguível de uma feature” (Rich Kulawiec)

• BUGS / KLOC (Bugs por Mil Linhas de Código)• BUGS

– Defeitos encontrados– Pode ser categorizado (Crítico, Normal, etc)

• KLOC– Não conta comentários, linhas em branco, etc– Varia de acordo com a linguagem utilizada

• Amplamente usado no mercado• Deve ser medido em 3 etapas (Desenvolvimento, Homologação e

Produção)

Métricas de Qualidade (BUGS/KLOC)

• “Error, no keyboard - press F1 to continue” (early PC BIOS message)

• PROBLEMAS:– O que é bug (como categorizar) ?

• Devo atribuir pesos ?– Padrão entre equipes

• “Os especialistas concordam que a forma mais provável do mundo ser destruído é por acidente. É por isso que estamos aqui; nós somos profissionais de informática. Nós causamos acidentes” (Nathaniel Borenstein)

Bugs em Desenvolvimento/KLOC

10,80246914

0

14,27345538

6,624688443

00

2

4

6

8

10

12

14

16

A B C D E

Bugs emDesenvolvimento/KLOC

java + flashNão possui dados Não possui dados

Métricas de Qualidade (PROBS/KLOC)

• PROBS / KLOC (Problemas de inspeção de código por Mil Linhas de Código)

• PROBS– É a quantidade de problemas de qualidade encontrados na execução da

ferramenta de inspeção de código (Checkstyle - JAVA)– Problemas devem estar zerados ao final do projeto– Decisão de projeto sobre quais regras vão ser avaliadas

• Cada projeto tem pode escolher o nível de qualidade• Existe um valor mínimo especificado pela instituição (Check - CORE)

• PROBLEMAS:– Inspeção automática é limitada (análise estrutural)– Falta mecanismo de exclusão adequado

Problemas/KLOC

41,2

149,3

174,7

478,3

376,1

0

100

200

300

400

500

600

A B C D E

Pro

ble

ma

s/L

OC

Problem as /KLOC

java

Métricas de Qualidade (LOC/FP)

• LOC / FP (Linhas de Código por Ponto de Função)• Linhas de Código

– Quanto menos linhas de código for necessária para realizar um FP, melhor– Esforço x LOC

• Influências:– Reuso– Arquitetura (+tecnologias +linguagem)– Qualidade

• PROBLEMAS:– FP tem que ser o real (medido após a implementação)– Será que ter menos linhas é sempre melhor ?– Ainda não podemos usar (FP ainda não é uma realidade no CESAR)

Métricas de Reuso

?“Danger will robinson, danger !” (robbie the robot)

Métricas de Reuso

• Quanto eu economizei por conta do Reuso ?• Fatores:

– Reuso Interno X Reuso Externo– Reuso Caixa Preta X Reuso Caixa Branca

• KLOC Reusado / KLOC Total– Nem sempre é possível calcular KLOC de binários– Nem sempre você reusa todos os recursos (ou todos os KLOCS) de um

componente– Nem sempre você está reusando o componente em todos os lugares onde

deveria– Quanto maior o projeto, pior a métrica (injusto ?)

Métricas de Reuso

• Métrica baseada em acoplamento com pesos– Pesquisa de mestrado (Jorge Mascena)– “Para inventar você precisa de uma boa imaginação e uma pilha

de tranqueiras” (Thomas Edison)– “Do, or do not. There is no try” (Yoda)

• Enquanto isso...– PACOTES REUSADOS / PACOTES TOTAL

• PROBLEMAS:– Exclusivo para Java– Parecido com a métrica de KLOC– Pacotes não referenciados diretamente (IoC) devem ser contabilizados ?

Pacotes Reusados / Pacotes Total

34,62%

74,07%

51,72%

45,83%

76,47%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

A B C D E

Po

rce

nta

ge

m

Métricas Técnicas (Qualidade)

• Durante a execução, Arquiteto deve acompanhar a qualidade do que está sendo produzido

– Inspeções de código devem ser feitas (CMMI)

• Métricas devem ser coletadas:– Acoplamento– Complexidade

• Inspeções automáticas devem ser realizadas

Métricas Técnicas (Acoplamento)

• Ferramenta JDepend• Métricas coletadas por pacote:

– Acoplamento Eferente– Acoplamento Aferente– Nível de abstração– Instabilidade– Ciclos de dependências

• Interpretação complexa– Treinamento

Métricas Técnicas (Complexidade)

• Ferramenta JavaNCSS• Métricas coletadas:

– Linhas de Código (LOC ou NCSS – Non Commenting Source Statements) por método, classe, pacote e projeto

– Quantidade de Classes por pacote e projeto– Quantidade de pacotes por projeto– Quantidade de Métodos por classe, pacote, projeto– Javadocs por método, classe, pacote e projeto (NÃO SEMÂNTICO)– Complexidade Ciclomática (CCN) por método

Inspeção Automática

• Ferramenta Checkstyle• Analisa Código Fonte• Regras são aplicadas nas classes

– Relatório de não conformidade é gerado

• Possui regras em várias categorias– Javadoc, cabeçalhos, imports, violação de tamanho, padrão de codificação,

problemas de codificação, fatores de qualidade, código duplicado, checagem de métricas de acomplamento e complexidade, etc

• Algumas Regras podem ter limites definidos• A idéia é definir um conjunto de regras CORE (será obrigatório) e um conjunto

de regras opcionais (cada projeto decide o que vai ser inspecionado)– Faixas limites vão ser definidas e caberá ao projeto decidir os valores absolutos– Ex.: Máximo Número de Linhas por Classe pode variar de 20-40 (definição da faixa).

Projeto escolherá o seu limite dentro dessa faixa, 30 por exemplo.

Conclusões

• “Eu só posso mostrar a porta, você é quem deve atravessa-la” (Morpheus, The Matrix)

• Não existe métrica perfeita• Nunca confie em uma métrica isoladamente• Ainda temos muito a aprender...

– Experiência prática é fundamental– “O tempo é um ótimo professor, infelizmente, ele mata todos os

alunos” (Hector Belioz)• Estamos prontos para COMEÇAR

– Candidatos ???

Referências

• [Ambler02] Ambler, S. 2002. Agile Modeling, John Wiley & Sons.• [Jones95] Jones, C. 1995. Patterns of Software Failure and Success.

International Thompson Press.• [Jonhson02] Johnson02 Johnson, J. 2002. Keynote speech, XP 2002, Sardinia,

Italy.• [Gibeon04] Aquino, G. 2004. Plano de Doutorado. Word Editor.• [Larman01] Larman, C. 2001. Applying UML and Patterns: An Introduction to

OOA/D and the Unified Process, 2nd edition. Prentice-Hall.• [Larman03] Larman, C. 2003. Agile and Iterative Development: A Manager's

Guide. Addison Wesley.• [Solon02] Solon02 Solon, R. 2002. "Benchmarking the ROI for Software Process

Improvement." The DoD SoftwareTech News. Nov. 2002, USA DoD.• [Thomas01] Thomas, M. 2001. "IT Projects Sink or Swim." British Computer

Society Review.

Obrigado