Métricas Em Fabricas De Software

4,621 views

Published on

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

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,621
On SlideShare
0
From Embeds
0
Number of Embeds
776
Actions
Shares
0
Downloads
32
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Métricas Em Fabricas De Software

  1. 1. Tudo o que você sempre quis saber sobre o seu projeto... Luiz Borba (borba@cesar.org.br) mas tinha medo de perguntar.
  2. 2. Introdução <ul><li>C.E.S.A.R (Centro de Estudos e Sistemas Avançados do Recife) </li></ul><ul><li>Cenário do C.E.S.A.R </li></ul><ul><ul><li>Perto de 400 empregados </li></ul></ul><ul><ul><li>Vários Projetos diferentes </li></ul></ul><ul><ul><ul><li>Não trabalha exclusivamente em mercados verticais </li></ul></ul></ul><ul><ul><li>Arquiteturas diferentes </li></ul></ul><ul><ul><li>Tecnologias diferentes </li></ul></ul><ul><ul><li>Qual a taxa de sucesso dos nossos projetos ? </li></ul></ul><ul><ul><li>“ Para mudar seu destino, primeiro você tem mudar sua atitude” </li></ul></ul><ul><li>Grupo de Engenharia </li></ul><ul><ul><li>Criar mecanismos para melhoria da produtividade </li></ul></ul><ul><li>Problema: Como saber se as iniciativas para melhoria deram resultado ? </li></ul><ul><ul><li>A PRODUTIVIDADE DEVE SER MEDIDA ! </li></ul></ul>
  3. 3. Produtividade <ul><li>O que é produtividade ? </li></ul><ul><ul><li>Várias definições </li></ul></ul><ul><ul><li>Razão entre o que é produzido pelo custo </li></ul></ul><ul><li>PROBLEMA: Subprodutos (modelos, documentos de requisitos, documentos de arquitetura, por exemplo) devem ser contabilizados ? </li></ul><ul><ul><li>Servem para facilitar o desenvolvimento </li></ul></ul><ul><ul><li>O produto principal é o código (software) </li></ul></ul><ul><ul><li>E o código de teste ? </li></ul></ul><ul><ul><li>É isso mesmo ? </li></ul></ul>
  4. 4. O que afeta a Produtividade ? <ul><li>Estudos apontam entre 18 e 100 variáveis </li></ul><ul><ul><li>Fatores Humanos (motivação, capacitação, ...) </li></ul></ul><ul><ul><ul><li>“ 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) </li></ul></ul></ul><ul><ul><li>Fatores Organizacionais (espaço físico, nível de ruído, faixas salariais, ...) </li></ul></ul><ul><ul><ul><li>“ Reuniões são indispensáveis quando se quer não fazer nada” (john kenneth galbraith) </li></ul></ul></ul><ul><ul><li>Fatores Técnicos (processo, ferramentas, linguagem de programação, ...) </li></ul></ul><ul><ul><ul><li>“ Quando tudo o que você tem é um martelo, todo o resto parece prego” </li></ul></ul></ul><ul><ul><ul><li>“ Usabilidade é como oxigênio, você nunca percebe, até a hora que falta” </li></ul></ul></ul><ul><li>PROBLEMA: Qual o peso de cada uma delas ? </li></ul><ul><ul><li>Os pesos podem ser diferentes em cada instituição </li></ul></ul><ul><li>Medidas de produtividade devem ser específicas para a organização </li></ul>
  5. 5. O que afeta a Produtividade ? <ul><li>PROBLEMA: O que medir ? </li></ul><ul><ul><li>Que fatores podem ser medidos e como ? </li></ul></ul><ul><li>PROBLEMA: Qual o escopo ? </li></ul><ul><ul><li>Individual </li></ul></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Organizacional </li></ul></ul><ul><li>Mais problemas ??? </li></ul><ul><ul><li>“ O difícil a gente faz de uma vez, o impossível leva um pouco mais de tempo” (American SeaBees) </li></ul></ul>
  6. 6. O que afeta a Produtividade ? <ul><li>Processo (cascata x iterativo) ? </li></ul><ul><ul><li>[Thomas01] 1027 projetos (13% não falharam) </li></ul></ul><ul><ul><ul><li>82% apontaram a cascata como a causa principal </li></ul></ul></ul><ul><ul><li>[Jones95] 6700 projetos </li></ul></ul><ul><ul><ul><li>4 dos 5 causas de falha, eram relacionados com cascata </li></ul></ul></ul><ul><ul><li>[Jonhson02] Levantamento completo de requisitos no início </li></ul></ul><ul><ul><ul><li>45% features NUNCA SÃO USADAS </li></ul></ul></ul><ul><ul><ul><li>19% RARAMENTE SÃO USADAS </li></ul></ul></ul><ul><ul><li>[Solon02] 43700 projetos </li></ul></ul><ul><ul><ul><li>Iterativo – 570 FP por full-time developer </li></ul></ul></ul><ul><ul><ul><li>Cascata – 480 (BUUUUU) </li></ul></ul></ul>
  7. 7. O que afeta a Produtividade ?
  8. 8. O que afeta a Produtividade ? <ul><li>“ Você só deve usar desenvolvimento iterativo nos projetos que você quer que dê certo” (Martin Fowler) </li></ul>
  9. 9. O que afeta a Produtividade ? <ul><li>Tamanho </li></ul>
  10. 10. Premissas da nossa solução <ul><li>Lei de Gilbs: “ Anything you need to quantify can be measured in some way that is superior to not measuring it at all ” </li></ul><ul><ul><li>Não procure indefinidamente pela MÉTRICA PERFEITA ! </li></ul></ul><ul><ul><li>Não existe MÉTRICA PERFEITA ! </li></ul></ul><ul><li>Premissas para a solução: </li></ul><ul><ul><li>Simplicidade </li></ul></ul><ul><ul><ul><li>“ É fácil ter uma idéia complicada, mas é muito, muito difícil ter uma idéia simples” (Carver Mead) </li></ul></ul></ul><ul><ul><li>Medição no escopo dos times (projetos) </li></ul></ul><ul><ul><li>Concentração nos fatores técnicos </li></ul></ul><ul><ul><ul><li>Métricas de Produtividade </li></ul></ul></ul><ul><ul><ul><li>Métricas de Qualidade </li></ul></ul></ul><ul><ul><ul><ul><li>CESAR está crescendo rapidamente </li></ul></ul></ul></ul><ul><ul><ul><li>Métricas de Reuso </li></ul></ul></ul><ul><ul><ul><ul><li>Grupo de Engenharia está investindo em Reuso </li></ul></ul></ul></ul>
  11. 11. Métrica de Produtividade <ul><li>ESFORÇO / FP (Esforço em horas por Ponto de Função) </li></ul><ul><li>Esforço </li></ul><ul><ul><li>Total de horas por projeto </li></ul></ul><ul><li>Ponto de Função </li></ul><ul><ul><li>É uma medida de complexidade </li></ul></ul><ul><li>PROBLEMAS: </li></ul><ul><ul><li>Todas as horas tem o mesmo custo ? </li></ul></ul><ul><ul><li>A reportagem de horas está correta ? </li></ul></ul><ul><ul><li>FP usada é correta ? (FP venda x FP estimada x FP real ) </li></ul></ul><ul><ul><li>Utilizada no mercado </li></ul></ul><ul><ul><ul><li>É possível comparações externas ? </li></ul></ul></ul><ul><ul><li>FP leva em consideração a documentação produzida ? </li></ul></ul><ul><ul><ul><li>Opção por considerar apenas o software como produto ! </li></ul></ul></ul>
  12. 12. ESFORÇO / FP <ul><li>Interpretação diferente dependendo do processo </li></ul><ul><ul><li>Cascata </li></ul></ul><ul><ul><ul><li>Número correto ao final do projeto </li></ul></ul></ul><ul><ul><li>Iterativo </li></ul></ul><ul><ul><ul><li>Implementação mais cedo </li></ul></ul></ul><ul><ul><ul><li>Realimentação entre iterações (velocidade) </li></ul></ul></ul>
  13. 13. ESFORÇO / FP (mais problemas) <ul><li>FP ainda não é usado largamente no CESAR </li></ul><ul><ul><li>UCP (Pontos de Caso de Uso) pode ser usado </li></ul></ul><ul><ul><li>CESAR tem planos para padronizar o uso de FP </li></ul></ul><ul><li>Outra Alternativa: ESFORÇO / KLOC (Esforço em horas por Mil Linhas de Código) </li></ul><ul><ul><li>Existe relação entre LOC e Complexidade ? </li></ul></ul><ul><ul><ul><li>Nem sempre </li></ul></ul></ul><ul><ul><ul><li>Projetos com mais QUALIDADE ou R EUSO são penalizados (menos LOC) </li></ul></ul></ul><ul><ul><ul><li>LOC varia com tecnologia, linguagem </li></ul></ul></ul><ul><ul><ul><li>Pode criar ilusão </li></ul></ul></ul><ul><ul><li>Métrica utilizada por aí </li></ul></ul><ul><ul><ul><li>Avaliação individual </li></ul></ul></ul><ul><ul><li>É melhor do que nada ? (não temos FP ainda) </li></ul></ul>
  14. 14. java + flash
  15. 15. java + flash
  16. 16. Métricas de Qualidade (BUGS/KLOC) <ul><li>“ Qualquer bug suficientemente avançado é indistinguível de uma feature ” (Rich Kulawiec) </li></ul><ul><li>BUGS / KLOC (Bugs por Mil Linhas de Código) </li></ul><ul><li>BUGS </li></ul><ul><ul><li>Defeitos encontrados </li></ul></ul><ul><ul><li>Pode ser categorizado (Crítico, Normal, etc) </li></ul></ul><ul><li>KLOC </li></ul><ul><ul><li>Não conta comentários, linhas em branco, etc </li></ul></ul><ul><ul><li>Varia de acordo com a linguagem utilizada </li></ul></ul><ul><li>Amplamente usado no mercado </li></ul><ul><li>Deve ser medido em 3 etapas (Desenvolvimento, Homologação e Produção) </li></ul>
  17. 17. Métricas de Qualidade (BUGS/KLOC) <ul><li>“ Error, no keyboard - press F1 to continue” (early PC BIOS message) </li></ul><ul><li>PROBLEMAS: </li></ul><ul><ul><li>O que é bug (como categorizar) ? </li></ul></ul><ul><ul><ul><li>Devo atribuir pesos ? </li></ul></ul></ul><ul><ul><li>Padrão entre equipes </li></ul></ul><ul><li>“ 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) </li></ul>
  18. 18. java + flash Não possui dados Não possui dados
  19. 19. Métricas de Qualidade (PROBS/KLOC) <ul><li>PROBS / KLOC (Problemas de inspeção de código por Mil Linhas de Código) </li></ul><ul><li>PROBS </li></ul><ul><ul><li>É a quantidade de problemas de qualidade encontrados na execução da ferramenta de inspeção de código (Checkstyle - JAVA) </li></ul></ul><ul><ul><li>Problemas devem estar zerados ao final do projeto </li></ul></ul><ul><ul><li>Decisão de projeto sobre quais regras vão ser avaliadas </li></ul></ul><ul><ul><ul><li>Cada projeto tem pode escolher o nível de qualidade </li></ul></ul></ul><ul><ul><ul><li>Existe um valor mínimo especificado pela instituição (Check - CORE) </li></ul></ul></ul><ul><li>PROBLEMAS: </li></ul><ul><ul><li>Inspeção automática é limitada (análise estrutural) </li></ul></ul><ul><ul><li>Falta mecanismo de exclusão adequado </li></ul></ul>
  20. 20. java
  21. 21. Métricas de Qualidade (LOC/FP) <ul><li>LOC / FP (Linhas de Código por Ponto de Função) </li></ul><ul><li>Linhas de Código </li></ul><ul><ul><li>Quanto menos linhas de código for necessária para realizar um FP, melhor </li></ul></ul><ul><ul><li>Esforço x LOC </li></ul></ul><ul><li>Influências: </li></ul><ul><ul><li>Reuso </li></ul></ul><ul><ul><li>Arquitetura (+tecnologias +linguagem) </li></ul></ul><ul><ul><li>Qualidade </li></ul></ul><ul><li>PROBLEMAS: </li></ul><ul><ul><li>FP tem que ser o real (medido após a implementação) </li></ul></ul><ul><ul><li>Será que ter menos linhas é sempre melhor ? </li></ul></ul><ul><ul><li>Ainda não podemos usar (FP ainda não é uma realidade no CESAR) </li></ul></ul>
  22. 22. Métricas de Reuso <ul><li>? </li></ul><ul><li>“ Danger will robinson, danger !” (robbie the robot) </li></ul>
  23. 23. Métricas de Reuso <ul><li>Quanto eu economizei por conta do Reuso ? </li></ul><ul><li>Fatores: </li></ul><ul><ul><li>Reuso Interno X Reuso Externo </li></ul></ul><ul><ul><li>Reuso Caixa Preta X Reuso Caixa Branca </li></ul></ul><ul><li>KLOC Reusado / KLOC Total </li></ul><ul><ul><li>Nem sempre é possível calcular KLOC de binários </li></ul></ul><ul><ul><li>Nem sempre você reusa todos os recursos (ou todos os KLOCS) de um componente </li></ul></ul><ul><ul><li>Nem sempre você está reusando o componente em todos os lugares onde deveria </li></ul></ul><ul><ul><li>Quanto maior o projeto, pior a métrica (injusto ?) </li></ul></ul>
  24. 24. Métricas de Reuso <ul><li>Métrica baseada em acoplamento com pesos </li></ul><ul><ul><li>Pesquisa de mestrado (Jorge Mascena) </li></ul></ul><ul><ul><li>“ Para inventar você precisa de uma boa imaginação e uma pilha de tranqueiras” (Thomas Edison) </li></ul></ul><ul><ul><li>“ Do, or do not. There is no try” (Yoda) </li></ul></ul><ul><li>Enquanto isso... </li></ul><ul><ul><li>PACOTES REUSADOS / PACOTES TOTAL </li></ul></ul><ul><li>PROBLEMAS: </li></ul><ul><ul><li>Exclusivo para Java </li></ul></ul><ul><ul><li>Parecido com a métrica de KLOC </li></ul></ul><ul><ul><li>Pacotes não referenciados diretamente (IoC) devem ser contabilizados ? </li></ul></ul>
  25. 26. Métricas Técnicas (Qualidade) <ul><li>Durante a execução, Arquiteto deve acompanhar a qualidade do que está sendo produzido </li></ul><ul><ul><li>Inspeções de código devem ser feitas (CMMI) </li></ul></ul><ul><li>Métricas devem ser coletadas: </li></ul><ul><ul><li>Acoplamento </li></ul></ul><ul><ul><li>Complexidade </li></ul></ul><ul><li>Inspeções automáticas devem ser realizadas </li></ul>
  26. 27. Métricas Técnicas (Acoplamento) <ul><li>Ferramenta JDepend </li></ul><ul><li>Métricas coletadas por pacote: </li></ul><ul><ul><li>Acoplamento Eferente </li></ul></ul><ul><ul><li>Acoplamento Aferente </li></ul></ul><ul><ul><li>Nível de abstração </li></ul></ul><ul><ul><li>Instabilidade </li></ul></ul><ul><ul><li>Ciclos de dependências </li></ul></ul><ul><li>Interpretação complexa </li></ul><ul><ul><li>Treinamento </li></ul></ul>
  27. 28. Métricas Técnicas (Complexidade) <ul><li>Ferramenta JavaNCSS </li></ul><ul><li>Métricas coletadas: </li></ul><ul><ul><li>Linhas de Código (LOC ou NCSS – Non Commenting Source Statements) por método, classe, pacote e projeto </li></ul></ul><ul><ul><li>Quantidade de Classes por pacote e projeto </li></ul></ul><ul><ul><li>Quantidade de pacotes por projeto </li></ul></ul><ul><ul><li>Quantidade de Métodos por classe, pacote, projeto </li></ul></ul><ul><ul><li>Javadocs por método, classe, pacote e projeto (NÃO SEMÂNTICO) </li></ul></ul><ul><ul><li>Complexidade Ciclomática (CCN) por método </li></ul></ul>
  28. 29. Inspeção Automática <ul><li>Ferramenta Checkstyle </li></ul><ul><li>Analisa Código Fonte </li></ul><ul><li>Regras são aplicadas nas classes </li></ul><ul><ul><li>Relatório de não conformidade é gerado </li></ul></ul><ul><li>Possui regras em várias categorias </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Algumas Regras podem ter limites definidos </li></ul><ul><li>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) </li></ul><ul><ul><li>Faixas limites vão ser definidas e caberá ao projeto decidir os valores absolutos </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  29. 30. Conclusões <ul><li>“ Eu só posso mostrar a porta, você é quem deve atravessa-la” (Morpheus, The Matrix) </li></ul><ul><li>Não existe métrica perfeita </li></ul><ul><li>Nunca confie em uma métrica isoladamente </li></ul><ul><li>Ainda temos muito a aprender... </li></ul><ul><ul><li>Experiência prática é fundamental </li></ul></ul><ul><ul><li>“ O tempo é um ótimo professor, infelizmente, ele mata todos os alunos” (Hector Belioz) </li></ul></ul><ul><li>Estamos prontos para COMEÇAR </li></ul><ul><ul><li>Candidatos ??? </li></ul></ul>
  30. 31. Referências <ul><li>[Ambler02] Ambler, S. 2002. Agile Modeling, John Wiley & Sons. </li></ul><ul><li>[Jones95] Jones, C. 1995. Patterns of Software Failure and Success. International Thompson Press. </li></ul><ul><li>[Jonhson02] Johnson02 Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy. </li></ul><ul><li>[Gibeon04] Aquino, G. 2004. Plano de Doutorado. Word Editor. </li></ul><ul><li>[Larman01] Larman, C. 2001. Applying UML and Patterns: An Introduction to OOA/D and the Unified Process, 2nd edition. Prentice-Hall. </li></ul><ul><li>[Larman03] Larman, C. 2003. Agile and Iterative Development: A Manager's Guide. Addison Wesley. </li></ul><ul><li>[Solon02] Solon02 Solon, R. 2002. &quot;Benchmarking the ROI for Software Process Improvement.&quot; The DoD SoftwareTech News. Nov. 2002, USA DoD. </li></ul><ul><li>[Thomas01] Thomas, M. 2001. &quot;IT Projects Sink or Swim.&quot; British Computer Society Review. </li></ul>
  31. 32. <ul><li>Obrigado </li></ul>

×