View
5.525
Download
4
Category
Preview:
DESCRIPTION
Apresentação realizada no Developer's World 2004.
Citation preview
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
Recommended