Métricas/thresholds

1. Comparação com outras distribuições
   1. T. Filó. Identificação de valores referência para métricas de softwares orientados por objetos. 2014.

      Annotations:

      • Solução: O autor identificou valores de referência de várias métricas OO usando apenas análise estatísticas de 11 projetos. Para ecnontrar os valores de referência ele analisou medições de diferentes softwares encontrando distribuições que os melhor representa. Após isso, ele pegou o 70º e 90º quartis, divindo a disstribuição em 3 partes(bom, normal, ruim). Validação: Na validação, ele definiu cenários de testes, comparando os valores das métricas com bad smell informados pelos desenvolvedores.Pontos importantes:1. Não é levado em consideração aspectos próprios do desenvolvimento, tal como a maturidade da equipe;2. Os valores são apenas uma referência de o que é mais usado.
   2. R. Shatnawi. Deriving metrics thresholds using log transformation. 2015.

      Annotations:

      • Problema: Não consegui entender qual o problema de negócio que ele ataca, mais como problema técnico ele pretende testar se realmente a transformação de log melhora a definição de thresholds. Solução proposta: O autor propões a transformações em log para identificar valores de thresholds, para isso ele utiliza a média e o desvio padrão das métricas de CK. Validação: Usaram a ferramenta BugInfor para analisar os dados dos repositórios e identificar classes em que bugs foram encontrados e corrigidos. Fazendo posteriormente uma comparação com os dados coletados das métricas.
   3. K. Ferreira. Identifying thresholds for object-oriented software metrics. 2012.

      Annotations:

      • Problema: Apesar da importância de métricas de software e do grande número de métricas propostas, elas não têm sido amplamente aplicada na indústria. Uma das razões, pode ser que para a maioria das métricas os valores de referência não são conhecidos. Solução: Apresenta um método para encontrar thresholds usando análise estatística. Basicamente, compara os valores das métricas com distribuições conhecidas. Encontrada a distribuição, é derivado os thresholds desta. Validação: Realizaram dois experimentos. No primeiro, foi avalido se os limiares identificam classes problemáticas. No segundo estudo, foi avaliadado se os limiares identificam classes bem desenhados. A comparação foi feita entre o resultado do limitar e uma inspeção manual da classe estudada. Limitações: 1. Não é possível assegurar que os softwares usados para análise estatísticas teem boas práticas; 2. Só foi considerados softwares feitos em JAVA. Pontos importantes: 1. Poucos estudos empíricos têm sido realizados a fim de obter estes valores de referência(Lanza and Marinescu, 2006); 2. Os valores encontrados, não expressam as melhores práticas de engenharia de software necessariamente. No entanto, eles expõem um padrão da maioria dos sistemas de software; 3. Eles se preoculpam com o contexto, nos seguintes quesitos: domínio de aplicativo, tipos de software e tamanho do sistema.
2. Baseado no contexto
   1. M. Foucault. Computing contextual metric thresholds. 2014.

      Annotations:

      •   Contexto/Problema: O objetivo é aumetar a qualidade de softwares. Para isso é usado métricas, tais como (Número de atributos por class)NOA e Número de métodos por classe(NOM). Para uma métrica existe limiares(thresholds), eles dão a definição de bom e ruim. Muitos trabalhos apresentam valores de thresholds, mais poucos introduzem o conceito de contexto na sua definição.Objetivo: Definir uma abordagem que calcule os thresholds levando em consideração o contexto de cada projeto.Solução: A solução foi baseado em dois métodos estatísticos: Double sampling, que seleciona aleatoriamente amostras de projetos, e Bootstrap, que estima os thesholds baseados em quartis. Validação: Como os dois métodos estatíticos são amplamente usados, o processo de validação foi apenas um teste para identificar a melhor configuração. Pontos importantes:1. A definição de contexto é bem abrangente. O contexto em si é apenas o domínios dos projetos que são usados para gerar os thresholds. Vale lembrar que eles apresentam apenas uma abordagem. 2. Os thresholds represetam apenas a moda, não representando necessariamente bons números.
   2. K. Ferreira. Identifying thresholds for object-oriented software metrics. 2012.

      Annotations:

      • Problema: Apesar da importância de métricas de software e do grande número de métricas propostas, elas não têm sido amplamente aplicada na indústria. Uma das razões, pode ser que para a maioria das métricas os valores de referência não são conhecidos. Solução: Apresenta um método para encontrar thresholds usando análise estatística. Basicamente, compara os valores das métricas com distribuições conhecidas. Encontrada a distribuição, é derivado os thresholds desta. Validação: Realizaram dois experimentos. No primeiro, foi avalido se os limiares identificam classes problemáticas. No segundo estudo, foi avaliadado se os limiares identificam classes bem desenhados. A comparação foi feita entre o resultado do limitar e uma inspeção manual da classe estudada. Limitações: 1. Não é possível assegurar que os softwares usados para análise estatísticas teem boas práticas; 2. Só foi considerados softwares feitos em JAVA. Pontos importantes: 1. Poucos estudos empíricos têm sido realizados a fim de obter estes valores de referência(Lanza and Marinescu, 2006); 2. Os valores encontrados, não expressam as melhores práticas de engenharia de software necessariamente. No entanto, eles expõem um padrão da maioria dos sistemas de software; 3. Eles se preoculpam com o contexto, nos seguintes quesitos: domínio de aplicativo, tipos de software e tamanho do sistema.
   3. F. Zhang. How Does Context Affect the Distribution of Software Maintainability Metrics? 2013.

      Annotations:

      • Problema: O contexto pode influenciar nas métricas de softwares? Solução: O artigo faz uma comparação entre 20 métricas retiradas de 320 softwares de contextos diferentes, para analizar se o contexto influencia nessas métricas. Os fatores usados são: Domínio, Linguagem de programação, número de alterações, idade, tempo de vida e número de downloads. Validação: Não consta. Pontos Importantes: 1. Os fatores, ano, tempo de vida e número de download não infuenciaram nenhuma métrica.
3. R.Shatnawi. Finding software metrics threshold values using ROC curves. 2010.

   Annotations:

   • Problema: Encontrar thresholds. Solução: Utilizou de curvas ROC associando a métrica aos erros encontrados, seja presença ou ausência de erros ou o nível do erro(baixo, médio ou alto). Para cada valores da metrica(do mínimo ao máximo) x erro é encontrado um par de valores de sensibilidade e 1-especificidade. Cada par representa o desempenho da classificação do valor limiar que produz este par. A dupla que produz o melhor desempenho da classificação é o melhor valor limite para usar na prática. Validação: Usou apenas o p-value o ROC para verificar a correção entre as métricas testadas e o erro.

1. Variation factors
   1. Lionel C. Briand. Practical Guidelines for Measurement-Based Process Improvement. 1997.

      Annotations:

      • Introduz o conceito de Variation factors, que são fatores que influenciam no valor esperado da métrica. Esse artigo apenas apresenta instruções de como aplicar GQM na prática. Então, não tem validação.

1. P. Oliveira. Validating Metric Thresholds with Developers: An Early Result. 2015.

   Annotations:

   • Problema: Apesar de alguns thresholds serem conhecidos, não sabe-se se eles realmente representam a boa ou mal mantenabilidade de um softwares. Soluções/Contribuições: Extrai thresholds relativos das métricas(NOA, NOM, FAN-OUT e WMC), usando 79 aplicações e valida os thresholds a fim de verificar se eles de fato são capazes de inferir problemas de manutenção e de design. Validação: Foi comparado os resultados das métricas com a avaliação de especialista quanto a boa/mal escrita destes. Pontos importates: 1. O paper não foca na definição de Relative Thresholds, focando apenas na aplicação destes. Relative Thresholds: São representados por um par (p, k), onde p% de classes de uma aplicativo deve ter M ≤ k, onde M é o valor da métrica e p é percentual mínimo que deve estar acima do limite k.
2. P. Oliveira. Extracting relative thresholds for source code metrics. 2014.

   Annotations:

   • Problema: É "natural" que as entidades de código-fonte não sigam os limites propostos por várias razões, incluindo os requisitos complexos, otimizações de desempenho, código gerado automaticamente, etc. Solução: Thresholds absolutos devem ser complementados por um segundo pedaço de informação, o que denota a percentagem de entidades do limite superior deve ser aplicada. Mais especificamente, é proposto o conceito de limites relativos para avaliar métricas de código fonte. Validação: Não entendi o processo de validação.
3. P. Oliveira. RTTool: A Tool for Extracting Relative Thresholds for Source Code Metrics. 2014.

   Annotations:

   • Apresenta a ferramenta RTTool, ela é usada para extrair os Threholds relativos.

Annotations:

• Métricas não está relacionado apenas com o sucesso ou fracasso de softwares, sendo relacionado também o previsões, prazos, necessidades, custos, etc.

1. P. Meirelles. Crab: Uma Ferramenta de Configuração e Interpretação de Métricas de Software para Avaliação de Qualidade de Código. 2009.

   Annotations:

   • Problema: Ferramentas de métricas de softwares apresentam resultados na forma de valores isolados para cada métrica, isso exige que os usuários possuam a capacidade de interpretar esses valores, dificultando a tomada de decisões a respeito da qualidade do software. Solução proposta: Apresenta uma ferramenta denominada Crab, que tem como objetivo lidar com esses problemas existentes em ferramentas de métricas, tornando possível a definição de um contexto para a avaliação dos valores coletados. Validação: Foi feita a integração com a ferramenta JaBUTi, onde foi analisado um sistema com 5751 linhas e 59 classes. Nada mais foi feito!Limitações: Não foi apresentado limitações.
2. M. Schots .ReuseDashboard: Apoiando Stakeholders na Monitoração de Programas de Reutilização de Software. 2013.

   Annotations:

   • Problema: A implementação de programas de reutilização nas organizações pode ser difícil devido a problemas de gestão, falta de compreensão, falta de incentivos financeiros e sobrecarga cognitiva, dentre outros. Solução proposta: Este trabalho apresenta o ReuseDashboard, um mecanismointerativo voltado para programas de reúso, que faz uso de métricas e visual analytics visando estimular o envolvimento dos stakeholders, provendo informações relevantes a cada papel envolvido em tarefas de reúso.Validação: Não foi validado, foi apenas apresentado um cenário de utilização.Limitações: Não foi validado.

Annotations:

• Apresenta as principais métricas de softwares, dando uma visão ampla do assunto.

1. M. Perkusich. A Bayesian network approach to assist on the interpretation of software metrics. 2015.

   Annotations:

   • Problema: Existe muitas métricas, e a maioria das abordagens as interpreta apenas definindo thresholds, sem levar em consideração o risco ou fatoras subjetivos. Solução: Usar Redes Bayesianas para correlacionar riscos e fatores sobjetivos aos resultados das métricas, melhorando a interpretação das métricas. Validação: Foi validado em um estudo de caso em uma empresa no Basil. Onde foi feita uma comparação entre o resultado da rede e a interpretação do ScrumMaster a cada sprint. Observações: Dá uma ideia de como posso usar as Redes Baysianas para definir os Thresholds.