• Like
Métricas Em Fabricas De Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Métricas Em Fabricas De Software

  • 3,632 views
Published

Apresentação realizada no Developer's World 2004.

Apresentação realizada no Developer's World 2004.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,632
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
7
Comments
0
Likes
8

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Tudo o que você sempre quis saber sobre o seu projeto... Luiz Borba (borba@cesar.org.br) mas tinha medo de perguntar.
  • 2. 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 !
  • 3. 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 ?
  • 4. 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
  • 5. 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)
  • 6. 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)
  • 7. O que afeta a Produtividade ?
  • 8. O que afeta a Produtividade ?
    • “ Você só deve usar desenvolvimento iterativo nos projetos que você quer que dê certo” (Martin Fowler)
  • 9. O que afeta a Produtividade ?
    • Tamanho
  • 10. 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
  • 11. 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 !
  • 12. 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)
  • 13. 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 R EUSO 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)
  • 14. java + flash
  • 15. java + flash
  • 16. 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)
  • 17. 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)
  • 18. java + flash Não possui dados Não possui dados
  • 19. 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
  • 20. java
  • 21. 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)
  • 22. Métricas de Reuso
    • ?
    • “ Danger will robinson, danger !” (robbie the robot)
  • 23. 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 ?)
  • 24. 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 ?
  • 25.  
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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.
  • 30. 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 ???
  • 31. 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.
  • 32.
    • Obrigado
  • 33.  
  • 34.