Medição de Software

Medição de Software

1. Motivação

   • Usabilidade: estética da interface do usuário
     • "O grau que a interface do usuário permite interação agradável e satisfatória para o usuário" (ISO, 2011, p.12)
   • Como especificar um requisito não funcional?
     • "A interface deve ser muito agradável para o usuário"
     • Qual é o grau de atendimento disto no software?
       • Como avaliar?
       • Como dizer que esse software é "agradável" o suficiente?
   • Importância de se medir
     • Produto, processo e projeto
   • Motivos para medir
     • Para avaliar a qualidade do software
     • Para descobrir e corrigir problemas potenciais
     • Para ajudar a estimar o esforço
     • Para controlar o andamento do processo
   • Uso de métricas

2. Medição e Métricas de Software

   • Medição
     • Extrair valores numéricos para um atributo de qualidade
     • Usada para avaliação de qualidade
   • Métrica de software
     • Qualquer medição referente ao sistema Ex.: linhas de código, # de métodos etc

3. Medição, Métricas e Indicadores

   • Medida
     • Fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo
   • Métrica
     • É uma medida quantitativa do grau em que um sistema, componente ou processo possui um determinado atributo
   • Indicador
     • É uma métrica ou combinação de métricas que fornece informações sobre o processo de software, um projeto de software ou o próprio produto

4. Atributos e Métricas de Software efetivas

   • Simples e computável
     • Deve ser relativamente fácil aprender como derivar a métrica
   • Empiricamente e intuitivamente persuasiva
     • Satisfaz as noções intuitivas do engenheiro sobre o atributo do produto
   • Consistente e objetiva
     • A métrica deve produzir resultados inequívocos
   • Consistente no uso de unidades e dimensões
     • O cálculo da métrica não deve levar a combinações bizarras de unidades
   • Independente de Linguagem de programação
     • As métricas devem ser baseadas no modelo de análise, no modelo de design ou na estrutura do próprio programa.
   • Mecanismo eficaz para feedback de qualidade
     • Deve fornecer ao engenheiro de software informações que possam levar a um produto final de maior qualidade.

5. Métricas

   • São comumente divididas em:
     • Métricas de produto
       • Ajudam a prever características de qualidade do produto
         • (Métricas de previsão)
       • Nem sempre é possível fazer medições diretas de uma característica de qualidade
         • Exemplo:
           • Eficiência de execução – comportamento no tempo
           • Mas como medir a manutenibilidade ou a usabilidade
       • Necessidade de relacionar propriedades de qualidade que possam ser medidas
         • Exemplo:
           • Manutenibilidade – analisabilidade
           • Número de linhas de código
           • Número de filhos de uma classe
       • Existem dois tipos de métricas de produto
         • Dinamicas
           • Coletadas por meio de medições do programa em execução
             • Exemplo: tempo de carregamento de uma página
         • Estáticas
           • Coletadas por meio de uma representação do sistema
             • Exemplo: número de linhas de código (LOC)
     • Métricas de projeto
       • Usadas pelo gerente para adaptar o fluxo de trabalho de projeto e atividades técnicas
     • Métricas de processo
       • Provêm indicadores para ajudar a melhoria do processo

6. Linhas de código

   • Vantagens
     • Fácil de medir
     • Muitos trabalhos sobre o assunto
   • Algumas métricas são normalizadas por LOC
     • Exemplo: erros por KLOC (mil linhas de código), custo por KLOC
   • Alguns problemas
     • Dependente da linguagem de programação
     • Produtividade com LOC penaliza bons designs
     • O uso é discutível

7. Pontos de função

   • É uma medida do tamanho funcional do software
     • Permite estimar o software antes da sua implementação
     • Uso:
       • Apoiar análises de produtividade e qualidade
       • Estimar custos e recursos necessários
       • Predizer o número de erros encontrados em testes
       • Predizer o número de componentes ou linhas de código
   • Baseado na medição de:
     • Transações (funções transacionais)
     • Dados necessários (funções de dados)
   • O manual da IFPUG detalha como contar
     • Busca evitar ao máximo decisões subjetivas
   • Problemas e críticas
     • Apesar das regras, existe alguma subjetividade
     • Fórmula empírica
     • O número não tem um significado real
       • Necessário mapear linhas de código ou pessoas/mês
   • Conclusão
     • Apesar dos problemas, é bastante útil
     • Usado em editais
   • Existem algumas variações
     • Pontos de caso de uso
       • Considera atores e casos de uso
       • Também é empírica

8. Fórmula empírica

   • Existem diversas organizações que definem o método de medição
     • Alguns padrões ISO
       • Exemplo
         • ISO 20926:2009 (IFPUG)
         • ISO 24570:2018 (NESMA)

9. Método

   • Obter documentação disponível
     • Determinar escopo e fronteira do sistema
       • Medir funções de transações
       • Medir funções de dados
         • Calcular tamanho funcional
           • Documentar e reportar

10. Medir funções de dados

    • Identificar grupos lógicos de dados ou informações de controle
      • Arquivo de lógica interna (ILF):
        • Escopo do sistema
      • Arquivo de interface externa (EIF):
        • Referenciado pela aplicação, mas mantido por outra aplicação

11. Medição de funções transacionais

    • Definição de processos elementares
      • A menor unidade de atividade
      • Tipos:
        • Entrada externa:
          • Processa dados ou informação de controle enviada externamente
        • Consulta externa:
          • Envia para fora da fronteira dados ou informação de controle
        • Saída externa:
          • Similar a consulta externa, mas inclui lógica adicional de processamento
          • O cálculo matemático cria dados derivados, mantém arquivo de lógica interna e/ou altera o comportamento do sistema

12. Software Analytics

    • Indicadores chave de desempenho (KPIs) são métricas usadas para monitorar o desempenho e desencadear ações corretivas quando seus valores caem em uma faixa predeterminada.
    • Como você sabe que as métricas são significativas em primeiro lugar?
    • A análise de software é a análise computacional sistemática de dados ou estatísticas de engenharia de software para fornecer aos gerentes e engenheiros de software insights significativos e capacitar suas equipes para tomar melhores decisões
    • A análise de software pode ajudar os desenvolvedores a tomar decisões sobre:
      • Testes direcionados
      • Refatoração direcionada
      • Planejamento de lançamento
      • Entendimento dos clientes
      • Julgamento da estabilidade.
      • Inspeção direcionada

13. Métricas orientadas a objetos

    • Métodos ponderados por classe (WMC)
      • O número de métodos e sua complexidade são indicadores razoáveis da quantidade de esforço necessário para implementar e testar uma classe.
    • Profundidade da árvore de herança (DIT)
      • Uma hierarquia de classes profunda (DIT é grande) leva a uma maior complexidade de design.
    • Número de filhos (NOC)
      • À medida que o NOC aumenta, a quantidade de testes (necessários para exercitar cada filho no seu contexto operacional) também aumentará.
    • Acoplamento entre classes de objetos (CBO)
      • Valores elevados de CBO indicam fraca capacidade de reutilização e tornam os testes de modificações mais complicados.
    • Resposta para uma classe (RFC)
      • O número de métodos que podem ser potencialmente executados em resposta a uma mensagem recebida por um objeto da classe.
    • Falta de coesão nos métodos (LCOM)
      • LCOM é o número de métodos que acessam um ou mais dos mesmos atributos

14. Métricas de Design de interface com usuário

    • Métricas de interface
      • Medidas ergonômicas (por exemplo, carga de memória, esforço de digitação, tempo de reconhecimento, complexidade de layout)
    • Métricas estéticas (design gráfico)
      • O design estético depende de julgamento qualitativo, mas algumas medidas são possíveis (por exemplo, contagem de palavras, porcentagem gráfica, tamanho da página)
    • Métricas de conteúdo
      • Concentre-se na complexidade do conteúdo e em clusters de objetos de conteúdo organizados em páginas
    • Métricas de navegação
      • Abordam a complexidade do fluxo de navegação e são aplicáveis apenas para aplicações Web estáticas.

15. Métricas de Código Fonte

    • Ciência de software de Halstead: uma coleção abrangente de métricas, todas baseadas no número (contagem e ocorrência) de operadores e operandos dentro de um componente ou programa

16. Métricas de Teste

    • Esforço de teste estimado usando métricas derivadas de medidas

17. Métricas de Manutenção

    • IEEE Std. 982.1-2005 índice de maturidade de software (SMI) que fornece uma indicação da estabilidade do produto de software (com base nas alterações feitas).

18. Métricas de Projeto e Processo

    • Métricas de processo são coletadas em todos os projetos, durante longos períodos de tempo. Sua intenção é fornecer um conjunto de indicadores que levem à melhoria do processo de software a longo prazo.
    • As métricas do projeto permitem que um gerente de projeto de software:
      • 1. avalie o status de um projeto em andamento
      • 2. rastreie riscos potenciais
      • 3. descubra áreas problemáticas antes que se tornem “críticas”
      • 4. ajuste o fluxo de trabalho ou tarefas
      • 5. avalie a capacidade da equipe do projeto de controlar a qualidade dos produtos de trabalho de software

19. Métricas de Processo

    • Medimos a eficácia de um processo de software indiretamente – derivando métricas baseadas nos resultados que podem ser derivados do processo:
      • medidas de erros descobertos antes do lançamento do software
      • defeitos entregues e relatados pelos usuários finais
      • produtos de trabalho entregues (produtividade).
      • esforço humano despendido
      • tempo de calendário gasto
      • conformidade com o cronograma
      • outras medidas
    • Também derivamos métricas de processo medindo as características de tarefas específicas de engenharia de software

20. Etiquetas de Métricas de Processo

    • Use o bom senso e a sensibilidade organizacional ao interpretar dados de metricas.
    • Forneca feedback regular aos individuos e equipes que coletam medidas e metricas
    • Nao use metricas para avaliar individuos
    • Trabalhe com profissionais e equipes para definir metas e metricas claras que serao usadas para alcanca-las.
    • Nunca use metricas para ameacar individuos ou equipes
    • Os dados de metricas que indicam uma area problematica nao devem ser considerados “negativos”. Esses dados sao apenas um indicador de melhoria de processos
    • Não fique obcecado com uma unica metrica excluindo outras métricas importantes

21. Processo de medição

    • Compõe o controle de qualidade
      • Pode-se usar dados históricos de projetos anteriores
    • 5 atividades principais
      • Desde a escolha das medições até a análise de componentes do sistema

22. Modelo de Processo

    • Processo de medição do produto
      • Escolher as medições a serem feitas
        • Selecionar os componentes a serem avaliados
          • Medir as características dos componentes
            • Identificar medições anômalas
              • Analisar componentes anõmalos

23. Escolher Medições

    • Uma abordagem para escolher as medições é o GQM
      • Goal-Question-Metric
        • Modelo de Medição GQM
          • Objetivo
            • O que se deseja melhorar
            • Ex.: produtividade
          • Questões
            • Refinamento do objetivo em perguntas
            • Ex.: pode-se aumentar # de linhas de código (LOC) produzidas?
          • Métricas
            • Seleção de medições apropriadas
            • Ex.: LOC por desenvolvedor
    • Questões são formuladas para atender a um objetivo
    • Métricas são escolhidas para responder às questões

24. Selecionar Componentes

    • Pode não ser necessário (ou desejável) medir todo o sistema
    • Estratégias de escolha
      • Subconjunto representativo de todos os componentes
      • Componentes críticos do sistema

25. Medir Atributos de Qualidade

    • Os componentes selecionados são medidos
    • As medidas são associadas aos atributos de qualidade

26. Analisar Medições

    • Novas medições são comparadas com anteriores
      • Uso de dados históricos
    • Análise procura valores incomuns
      • Valores muito altos/baixos para cada métrica

27. Analisar Componentes

    • Componente com valores anômalos é examinado
      • Inspeção decide se há problema no componente
    • Valor incomum
      • Não indica, necessariamente, componente de baixa qualidade

28. Medição de software

    • Medicoes de previsao e controle
    • Relacionamentos entre atributos de software internos e externos
    • Medidas diretas
      • As medidas diretas do processo de software incluem custo e esforço aplicado.
        • As medidas diretas do produto incluem linhas de código (LOC) produzidas, velocidade de execução, tamanho da memória e defeitos relatados durante um determinado período de tempo
    • Medidas indiretas
      • As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, facilidade de manutenção e muitas outras.
        • As medidas diretas são relativamente fáceis de recolher, a qualidade e a funcionalidade do software são mais difíceis de avaliar e só podem ser medidas indiretamente.

29. Métricas Normalizadas Orientadas à Tamanho

    • erros por KLOC (mil linhas de codigo)
    • defeitos por KLOC
    • $ por LOC
    • paginas de documentacao por KLOC
    • erros por pessoa-mes
    • erros por hora de revisao
    • LOC por pessoa-mes
    • $ por pagina de documentação

30. Métricas Normalizadas Orientadas à Função

    • erros por FP (mil linhas de codigo)
    • defeitos por FP
    • $ por FP
    • paginas de documentacao por FP
    • FP por pessoa-mes

31. Por que optar por métricas orientadas a funções?

    • Linguagem de programação independente
    • Usa características facilmente contáveis que são determinadas no início do processo de software
    • Não “penaliza” implementações inventivas (curtas) que usam menos LOC do que outras versões mais desajeitadas
    • Torna mais fácil medir o impacto de componentes reutilizáveis

32. Métricas de Qualidade de Software

    • Corretude. grau em que o software executa a função exigida (por exemplo, defeitos por KLOC).
    • Integridade. grau em que um programa é imune a ataques externos
    • Manutenibilidade. grau em que um programa é passível de mudança (por exemplo, MTTC - tempo médio para mudança).
    • Usabilidade. Quantifica a facilidade de uso (ex., taxa de erro).

33. Eficiência de remoção de um defeito (DRE)

    • DRE é uma medida da capacidade de filtragem das ações de garantia e controle de qualidade à medida que são aplicadas em todas as atividades da estrutura do processo.
    • O valor ideal para DRE é 1. Nenhum defeito (D = 0) é encontrado nos consumidores de um produto de trabalho após a entrega.
    • O valor de DRE começa a se aproximar à medida que E aumenta e a equipe detecta seus próprios erros.

34. Programa de Métricas Orientadas a Metas

    • 1. Identifique seus objetivos de negócios
      • 2. Identifique o que você deseja saber ou aprender
        • 3. Identifique seus subobjetivos.
          • 4. Identifique as entidades e atributos relacionados aos seus subobjetivos.
            • 5. Formalize seus objetivos de medição
              • 6. Identifique questões quantificáveis e os indicadores relacionados que você usará para ajudá-lo a atingir suas metas de medição.
                • 7. Identifique os elementos de dados que irá recolher para construir os indicadores
                  • 8. Identifique as medidas a serem utilizadas e torne essas definições operacionais
                    • 9. Identifique as ações que você executará para implementar as medidas.
                      • 10. Preparar um plano para implementar as medidas.

35. Métricas de processo

    • Métricas de processo podem ser usadas para avaliar a capacidade de manutenção
      • Número de solicitações de manutenção corretiva
      • Tempo médio necessário para a análise de impacto
      • Tempo médio necessário para implementar uma solicitação de mudança
      • Número de solicitações de mudança pendentes
    • Se algum ou todos esses estão aumentando, isso pode indicar um declínio na manutenibilidade

36. Pontos importantes

    • As análises permitem que gerentes e profissionais melhorem o processo de software
    • Métricas de processo permitem visão estratégica da organização
    • Métricas de software permitem avaliar quantitativamente a qualidade dos atributos internos do produto
    • Métricas de qualidade de software focam no processo, no projeto e no produto
    • Uma boa métrica de software deve ser simples, calculável, persuasiva, consistente e objetiva