Métricas de software

 

Introdução às métricas de software

 

  • Visão geral
    • mensura e dimensiona o software por fatores relevantes que agregam valor ao projeto;
    • a medição deve ser feita a fim de responder a um problema de negócio (há esforço em medir);
    • a medição determina a linha de base (dados históricos) de um conjunto de métricas;
    • a linha de base contém informações históricas coletadas e armazenadas (produtividade, custo, tamanho funcional);
  • Objetivos
    • fazer inferências sobre a qualidade do software (do produto ou do processo) – SOMMERVILLE;
    • melhoria contínua e avaliação da qualidade do software quando aplicada ao processo de software;
    • estimar o esforço de desenvolvimento dos requisitos;
    • estimar o custo de sustentação;
    • analisar a viabilidade do projeto em relação ao escopo, cronograma e orçamentos disponíveis;
    • acompanhar o progresso do projeto (no cronograma, no orçamento, etc);
    • rastrear riscos;
    • embasar decisões de ajuste de fluxo de trabalho (recursos, produtividade, etc);
    • medir desempenho da equipe para subsidiar decisão de desenvolvimento ou compra;
    • prever número de erros de componentes ou de linhas de código;
    • medir habilidades da equipe e identificar áreas problemáticas;
    • subsidiar contratos de remuneração por resultado;
  • Conceitos
    • Medida
      • unidade de contagem, um número associado a um valor relativo;
      • tempo (hora, dia, etc), custo, ponto de função, esforço;
    • Medição
      • a coleta de dados quantitativos em determinada medida;
      • medição do produto (software) ou do processo de desenvolvimento de software – SOMMERVILLE;
    • Métrica
      • associação/relacionamento entre duas ou mais medidas quantitativas
      • ponto de função por hora, defeitos por ponto de função, etc;
  • Princípios específicos (Pressman,1995; RIEDER,2003):
    • coletar dados para avaliação de desempenho atribuindo essas responsabilidades a toda equipe envolvida no projeto.
    • reunir dados de desempenho relativos à complementação do software.
    • analisar os históricos de projetos anteriores para determinar o efeito desses fatores, prevenindo erros para projetos futuros.
  • Principais benefícios (Pressman,1995; RIEDER,2003):
    • constatar a qualidade do produto.
    • avaliar a produtividade das pessoas.
    • ter uma base de estimativas (baseline).
    • justificar pedidos de recursos e treinamento adicional, entre outros.
  • Classificação de métricas

    • Métricas diretas
      • pessoas, orçamento, trabalho, velocidade de execução (desempenho da equipe);
      • memória utilizada, número de defeitos, linhas de código (LoC), pontos de casos de uso, pontos de função;
    • Métricas indiretas
      • qualidade, complexidade, eficiência, confiabilidade;
      • manutenabilidade das funcionalidades, tempo entre falhas, incidentes, problemas;
  • Tipos de métricas
    • Métricas orientadas a tamanho
      • a partir da quantidade de linhas de código (LoC);
      • não tem significado de negócio;
      • difícil de estimar nas fases iniciais do projeto;
      • depende da linguagem de programação;
      • não há padronização em contagem;
    • Métricas orientadas a função
      • a partir da quantidade de funcionalidades (tamanho funcional);
      • a partir do ponto de vista do usuário;
      • independe de linguagem de programação ou tecnologia;
      • pode omitir complexidade não visível;
    • Métricas orientadas a objetos
      • a partir de quantidade de cenários, classes-chave, classes de apoio;
      • ou média de classes de apoio para cada classe-chave e subsistemas;

 

Análise por ponto de função – APF

 

  • Visão geral
    • Conceitos
      • APF é um método de medição de tamanho funcional;
      • tem por base os requisitos funcionais do usuário (a partir da visão do usuário);
      • medição de projetos de diferentes linguagens de programação e independente da tecnologia;
      • pode ser associada a um contexto histórico de métricas de produtividade, custo, etc;
    • IFPUG classifica a contagem em projeto de desenvolvimento, melhoria e aplicação;
      • promove o uso da APF;
      • mantém o Manual de Práticas de Contagem (CPM);
      • provê estudos de casos e outras técnicas de medição de software;
    • NESMA classifica a contagem em:
      • detalhada → contagem de funções, entrada, saídas, e determina a complexidade;
      • estimativa → não analisa a complexidade (funções de dados → baixa, funções transacionais → média);
      • indicativa → estimativa de alto nível que conta somente funções de dados (considera 3ee, 2se, 1ce por arquivo lógico);
      • considera o fator de impacto para amortizar a contagem em projetos melhoria de software;
  • Manual de práticas de contagem (FP-CPM) – guia com processo, regras, práticas e exemplos de contagem;
    • Processo de contagem
      • simples o suficiente para minimizar a sobrecarga por medir;
      • consistente dentre vários projetos e organizações;
      • menos subjetivo, inclusive com a utilização de exemplos;
      • mantém conformidade com a norma ISO/IEC 14143-1:2007 (elementos gerais de métodos de contagem);
    • V3.0 – 1990: criação de um documento consensual e coerente a partir das diversas interpretações existentes;
    • V4.0 – 1994: introduziu a contagem das fases iniciais dos projetos, a contagem de GUI e as práticas de contagem;
    • V4.1 – 1999: detalhou as Consultas Externas, Saídas Externas e Dados e Registros Elementares Diferenciados;
    • V4.2 – 2004: reestruturado em 4 partes (Regras, Práticas, Exemplos e Apêndices) e melhorou a interpretação das regras;
    • V4.3 – 2010: nova estrutura com Método e Aplicação do método, novos interpretações e exemplos;
    • V4.3.1 – 2010 (norma ISO 20.926) → incorporou revisões editoriais da ISO e tornou o fator de ajuste opcional;
      • Parte 1 – O método de medição de tamanho funcional do IFPUG contendo o processo e atividades de medição;
      • Parte 2 – Aplicação do método;
      • Parte 3 – Práticas de contagem com orientações a partir de situações comuns;
      • Parte 4 – Exemplos de contagem passo-a-passo para execução do método de contagem;
      • Parte 5 – Apêndices: Tabela de cálculo, Tamanho funcional ajustado (Fator de ajuste);
  • Análise de ponto de função

    • quantifica o tamanho (tarefas e serviços) e a complexidade de um projeto de software;
    • por meio da análise dos requisitos funcionais do projeto lógico da aplicação;
    • funcionalidades implementadas, solicitadas e recebidas pelo usuário;
    • funcionalidades impactadas pelo desenvolvimento, melhoria e manutenção;
    • aplicável a todos os domínios funcionais (áreas de negócio);
    • Usuário → qualquer entidade que interage com o software (pessoas, hardware, dispositivos, outros sistemas, etc);
    • Visão do usuário → representa suas necessidades e descreve as funções do negócio;
  • Limitações
    • não mede requisitos não funcionais (mudanças somente não funcionais tem ponto de função igual a zero);
    • projetos de pontos de função similares podem ter esforços e custos diferentes;
  • Finalidades
    • estimar o tamanho e custo dos requisitos (antes do projeto);
    • acompanhar a evolução do desenvolvimento ou manutenção (durante o projeto);
    • verificar o tamanho e custo das funcionalidades entregues (após o projeto);
    • fator de normalização para comparação de software;
    • mensurar os pacotes de software em aquisição;
    • apoiar a análise da qualidade e da produtividade;
    • reduzir a complexidade da gestão de contratos (tamanho, defeitos, esforço, tempo e custo);
  • Fases do método de medição funcional
    1. Obter a documentação disponível
    2. Determinar o escopo e fronteira da contagem e identificar os requisitos funcionais do usuário
    3. Medir funções de dados
    4. Medir funções de transação
    5. Calcular o tamanho funcional
    6. Documentar e reportar
  • Obter a documentação disponível
    • necessita de documentação suficiente para subsidiar a contagem funcional;
    • documentos de requisitos (iniciais do usuário, técnicos iniciais e funcionais finais);
    • diagrama de entidades e relacionamentos (contagem de função de dados);
    • esquemas de banco de dados;
    • diagramas de classe e sequência;
    • modelos de dados e de objetos;
    • casos de uso;
    • protótipos de tela;
    • exemplos de relatórios gerados pela aplicação;
    • guias, manuais de uso e materiais de treinamento;
    • demonstração da operação da aplicação;
    • especialistas e usuários na aplicação para apoio a medição;
  • Determinar o escopo e fronteira da contagem e identificar os requisitos funcionais do usuário
    • Estabelecer o propósito da contagem
      • estabelece a razão pela qual uma contagem de pontos de função será executada;
      • deve ser feita a fim de responder a um problema de negócio;
      • problemas de negócio → determinar esforço de desenvolvimento, custos de sustentação ou comparação entre dois pacotes;
    • Identificar o tipo da contagem
      • Contagem de projeto de desenvolvimento
        • desenvolvimento da primeira versão do software;
        • contagem estimada que ocorre em diversas fases do desenvolvimento (análise, construção, etc);
        • mede o que será entregue ao usuário;
      • Contagem de projeto de melhoria
        • desenvolvimento de manutenções adaptativas do software;
        • medem-se as funcionalidade incluídas, alteradas ou excluídas;
        • Manutenção adaptativa → mantém o software utilizável em um ambiente alterado ou em vias de alteração;
        • Manutenção corretiva → corrige falhas no software para satisfazer os requisitos;
        • Manutenção perfectiva → corrige falhas engatilhadas (ano 2000), aprimora a usabilidade, o desempenho, a documentação;
      • Contagem de aplicação
        • contagem do tamanho funcional instalado ou linha de base (baseline);
        • contagem precisa das funcionalidades atualmente fornecidas ao usuário;
    • Identificar o escopo da contagem
      • é determinado pelo propósito (problema de negócio a ser respondido);
      • define o conjunto de requisitos funcionais do usuário a ser incluído na contagem;
      • de toda a aplicação ou somente de uma parte;
      • das funções utilizadas por usuário ou das funções específicas de relatórios;
    • Identificar a fronteira de cada aplicação
      • a fronteira é determinada com base na  visão do usuário;
      • fronteira é uma interface conceitual entre o software e seus usuários;
      • define o que é externo à aplicação e interface a passagem (entrada e saída) dos dados;
      • está vinculada a separação dos processos de negócio;
      • independe de implementação;
      • a futura substituição de um módulo da aplicação influência a definição da fronteira como uma aplicação separada;
      • o posicionamento da fronteira impacta os dados que serão incluídos na contagem;
    • Identificar os requisitos funcionais
      • APF considera apenas os requisitos funcionais (funcionalidades e serviços);
      • descartar os requisitos não funcionais (restrições ou qualidades específicas do sistema);
  • Medir funções de dados → sempre dados reconhecidos pelos usuários;
    • Identificar tipo das funções de dados → representa a necessidade de armazenamento de dados ou de informações de controle;
      • Arquivos lógicos internos (ALI)
        • grupo de dados ou informações de controle logicamente relacionados;
        • mantido dentro da fronteira da aplicação medida;
        • um conceito lógico que relaciona-se a visão de negócio;
        • pode representar um ou vários arquivos, registros, tabelas ou objetos em um banco de dados;
        • exemplo → índice de dados não é um ALI, pois não é um dado identificado pelo usuário;
      • Arquivos de interface externas (AIE)
        • grupo de dados ou informações de controle logicamente relacionados;
        • referenciados pela aplicação medida, porém mantido dentro da fronteira de outra aplicação;
        • trata-se de um ALI de outra aplicação;
    • Contar DERs e RLRs para cada função de dados (ALI ou AIE)
      • Dado elementar referenciado (DER)
        • atributo único (nome, cpf, etc), não repetido, não recursivo;
        • menor unidade de dado com nome que tem significado no mundo real;
      • Registro lógico referenciado (RLR)
        • especialização de ALIs em subgrupos¹ de dados relacionados que são tratados como uma unidade;
        • heranças (pessoa, servidor¹, terceirizado¹, estagiário¹);
        • relacionamento entre entidades fracas (pessoa e dependente);
    • Determinar a complexidade funcional de cada função de dados
      • ↓RLRs/→DERs    1–19   20–50   >50
        • 1……………..: baixa   baixa   média
        • 2–5…………..: baixa  média   alta
        • >5……………: média   alta     alta
    • Determinar o tamanho funcional de cada função de dados
      • ↓Complexidade    ALI    AIE
        • baixa…………:  7      5
        • média………..:  10    7
        • alta……………: 15   10
  • Medir funções de transação
    • Identificar cada processo elementar requerido pelo usuário
      • representa a necessidade de processamento de dados ou de informações de controle;
      • processo elementar (componente funcional básico) é a menor unidade de atividade significativa;
      • constitui uma transação completa, autocontida e leva a aplicação a um estado consistente;
    • Classificar cada processo elementar em função de transação
      • Entradas Externas (EE)
        • processo elementar que processa de dados ou informações de controle enviados para fora da fronteira da aplicação;
        • altera o comportamento da aplicação ou mantém um ou mais ALIs;
        • inclusão (create), alteração (update) e exclusões (delete) de dados dos ALI (inclusive em batch);
        • pode apresentar mensagem de confirmação da operação;
      • Consultas Externas (CE) – a partir de ALI ou AIE;
        • processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação;
        • apresentação de informações (read), consulta e imprime, não contém cálculos ou fórmulas matemáticas;
        • não altera o comportamento da aplicação e nenhum ALI é mantido;
        • como consultas de dados persistidos, relatórios, downloads sem cálculos adicionais a formatação;
        • somente formata e apresenta dados armazenados, podendo receber dados como filtro da consulta;
      • Saídas Externas (SE) – a partir de ALI ou AIE;
        • processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação;
        • inclui lógico processamento adicional (sumarização, totalização, agregação, etc), além daquela da consulta externa;
        • secundariamente, pode alterar o comportamento da aplicação (incrementar um contador, etc) ou manter ALIs;
        • apresentação de informações (read), consulta, calcula e imprime, deve conter ao menos um cálculo ou fórmula matemática;
        • como relatórios estatísticos, download com percentual calculado;
    • Contar DERs e ALRs para cada função de transação (EE, CE ou SE)
      • Dado elementar referenciado (DER)
        • cada dado que atravessa a fronteira durante o processamento da transação;
      • Arquivo lógico referenciado (ALR)
        • ALI ou AIE lidos (CE ou SE) ou gravados (EE) por função de transação;
    • Determinar a complexidade funcional de cada função de transação
      • Entradas Externas (EE)
        • ↓ALRs/→DERs    1–4    5–15    >15
          • 0–1…………:  baixa   baixa  média
          • 2…………….:  baixa   média  alta
          • >2………….:   média   alta      alta
      • Consultas Externas (CE) ou Saídas Externas (SE)
        • ↓ALRs/→DERs   1–5    6–19   >19
          • 0–1………..:   baixa baixa  média
          • 2–3………..:   baixa média  alta
          • >3…………:   média  alta    alta
    • Determinar o tamanho funcional de cada função de transação
      • ↓Complexidade     EE  CE  SE
        • baixa…………:   3    3    4
        • média………..:   4    4    5
        • alta……………:   6    6    7
  • Calcular o tamanho funcional (contagem bruta de pontos de função)

    • Unidades de cálculo
      • Tamanho das funções adicionadas ao projeto (ADD);
      • Tamanho das funções alteradas ao projeto (CHGA);
      • Tamanho das funções excluídas (DEL);
      • Tamanho das funções de conversão de dados (CFP) → construídas no momento da implantação e descartadas após a utilização;
    • Cálculo para Projeto de Desenvolvimento (DFP = ADD + CFP)
    • Cálculo para Projeto de Melhoria (EFP = ADD + CHGA + DEL + CFP)
    • Cálculo para Contagem de Aplicação (AFP) → tamanho das funções entregues ao usuário;
    • Resumo do tamanho funcional
      • ↓Complexidade    EE    CE    SE    ALI    AIE
        • baixa…………:    3     3      4         7      5
        • média………..:    4     4      5        10     7
        • alta……………:   6     6      7        15     10
  • Documentar e reportar
    • a documentação da contagem permite sua conferência e auditoria;
    • deve estar adequada ao propósito da contagem;
    • deve preservar a memória de cálculo além do número final da contagem;
    • recomenda-se conter: o propósito, o tipo, o escopo, a fronteira, a data, as funções (tipo e complexidade) e o resultado da contagem;
    • recomenda-se manter um padrão ao reportar os resultados e identificar a técnica utilizada;
      • 170 FP (IFPUG ISO/IEC 20.926)
  • Ajuste de pontos de função
    • Visão geral
      • ajuste nos pontos de função brutos a partir de aspectos técnicos ou não funcionais;
      • refletem a complexidade técnica de desenvolvimento do sistema;
      • fatores subjetivos, podem estar desatualizadas, não contempla todos os fatores técnicos possíveis;
      • não reconhecido pelo padrão ISO;
    • Nível de Influência → relacionamento dos requisitos com o esforço de desenvolvimento (maior peso, maior esforço);
      • peso 0 → nenhum requisito especial foi estabelecido para a característica;
      • peso 1 → influência mínima; menos restrições que uma aplicação típica, nenhum esforço especial é necessário;
      • peso 2 → influência moderada; restrições típicas para a característica;
      • peso 3 → influência média; restrições importantes;
      • peso 4 → influência significativa; requisitos rigorosos que requerem desenvolvimento especializado;
      • peso 5 → influência forte; a característica está ligada a essência dos requisitos;
    • Características gerais do sistema → atribuir peso de 0 a 5 para cada característica;
      1. Comunicação de dados
        • a aplicação se comunica diretamente com o processador?
        • são definidos protocolos específicos para o envio e recebimento de informações?
        • a aplicação é em batch, online, web ou de tempo real?
        • possui entrada de dados, impressão remota, um protocolo ou mais de um protocolo?
      2. Processamento distribuído
        • a aplicação transfere de dados entre seus componentes físicos?
        • a transferência é online, processada pelo usuário, em uma direção ou em ambas?
      3. Performance
        • a aplicação tem desempenho controlado?
        • o desempenho de tempo de resposta e volume de processamento são controlados?
        • os requisitos são rigorosos a ponto da análise de performance ser realizada no projeto?
      4. Utilização do equipamento
        • a aplicação sofre influência da infraestrutura a ser executada?
        • há restrições de execução de recursos computacionais?
        • os recursos estão sujeitos a deadlocks?
      5. Volume de transações
        • a aplicação sofre influência da taxa transações de negócio?
        • a influência tem efeito sobre as fases de projeto, desenvolvimento, instalação e suporte?
      6. Entrada de dados on-line
        • qual percentual das transação são interativas?
        • a aplicação é em batch, online, web ou de tempo real?
      7. Eficiência do usuário final
        • quantos requisitos de eficiência ao usuário final (usabilidade) são considerados?
        • paginação, movimentação automática da tela, menus gerados dinamicamente, janelas pop-up, suporte a idiomas;
      8. Atualização de dados on-line
        • a aplicação fornece atualização online dos dados (ALIs)?
        • há proteção contra perda de dados especialmente projetada?
        • há procedimentos de recuperação altamente automatizados?
      9. Processamento complexo
        • a aplicação sofre influência da lógica de processamento utilizada?
        • há processamento específico de segurança?
        • há processamento lógico ou matemático extensivos?
        • há tratamento de exceções de transações incompletas para gerar novo processamento?
        • há complexo tratamento das possibilidades de entradas e saídas (validações)?
      10. Reusabilidade
        • a aplicação foi projetada para ter seu código reutilizável em outras aplicações?
        • qual percentual do código aplicação foi planejado para ser reutilizável?
        • o código reutilizável está apropriadamente empacotado para esse fim e/ou há documentação?
        • o código reutilizável é configurável por meio de parâmetros pelo usuário?
      11. Facilidade de implantação
        • a facilidade na instalação influenciou o desenvolvimento da aplicação?
        • foi fornecido um pacote de instalação?
        • ferramentas automáticas de instalação foram fornecidas e testadas?
      12. Facilidade operacional
        • a facilidade de operação influenciou o desenvolvimento da aplicação?
        • procedimentos de inicialização, de backup e de recuperação serão/foram fornecidos?
        • os procedimentos dependem de intervenção humana?
      13. Multiplicidade de locais
        • a aplicação foi projetada para operar em hardware e software (SO) diferentes, ou idênticos, ou similares?
        • foi fornecida documentação e plano de suporte e testados para ambientes simulares e diferentes?
      14. Facilidade de mudanças
        • a aplicação foi desenvolvida para que a estrutura de dados e a lógica de processamento sejam facilmente modificados?
        • há dados de controle de negócio que só tem efeito imediato ou no próximo dia?
    • Nível de Influência Geral (TDI)

      • soma da pontuação de todos os 14 itens (máximo de 14×5=70pts);
    • Fator de ajuste (FA) → (TDI * 0,01) + 0,65
      • um por cento do Nível de Influência Geral + Variação pelo tamanho do projeto;
      • máximo [0↔0,7] + 0,65 = [65%↔135%];
    • Pontos de função ajustados (PFa) → PFna * FA;
      • em um projeto padrão (0,65), a obtenção de 35 pontos FA = 1, então PFna = PFa;
      • o fator de ajuste ajusta o tamanho funcional não ajustado em -35% a +35%;
  • Cálculos derivados da linha base (associação da métrica de tamanho funcional com dados históricos de outras métricas)
    • Índice de produtividade hipotético (IP)
      • métrica de produtividade que considera experiência na plataforma;
      • média = 12h/PF
    • Estimativa de esforço (E) → PFa * IP
      • associação com a métrica de produtividade;
      • 180PF*12h/PF = 2160HH (homens hora);
    • Tempo ótimo de desenvolvimento (TD) → PFa^expoente de tipo de projeto (ex: 0,34)
      • associação de métrica de tempo;
      • 150PF^0,34 = 5,5meses
      • 195PF^0,34 = 6meses
      • tempo em que é impossível terminar o trabalho antes de 0,75 * TD;
    • Estimativa da equipe
      • E / TD * 22d * 7h (período de trabalho)
    • Backfiring
      • estimativa de pontos de função a partir do número de linhas de código;
      • baseada em um fator de conversão dependente da linguagem;
      • apresenta erros consideráveis por assumir uma relação linear entre pontos de função e linhas de código;
      • diferentes organizações divulgam fatores de conversão distintos para cada linguagem de programação;
      • útil para sistemas legados em que uma contagem manual de pontos é inviável e a precisão não seja um fator crítico;

 

Análise por ponto de caso de uso (UCP – Use Case Points)

 

  • Visão geral

    • Pontos por caso de uso é um método de contagem similar a APF, porém conta-se atores e casos de uso;
    • Não pode ser utilizada antes de concluída a análise de requisitos;
    • Aplica-se somente a projetos que utilizem casos de uso;
    • Ajustes realizados por complexidade técnica e ambiental (subjetivos);
    • Valor total de pontos do sistema (UCP) = UUCP x TCF x ECF
    • O peso total não ajustado (UUCP) = ∑ pesos de atores não ajustados (UAW) e pesos de casos de uso não ajustados (UUCW);