Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Métricas Em Fabricas De Software

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

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>

×