Medição 1 - Confiabilidade

Objetivo de Medição 1: Confiabilidade

Analisar	o i-Educar
Para o propósito de	Avaliar
Com respeito a	Confiabilidade
Do ponto de vista da	Comunidade de desenvolvedores
No contexto da	Disciplina de Qualidade de Software 1 (FCTE - UnB)

Tabela 1: Objetivo de Medição: Confiabilidade

Perguntas e Hipóteses de Medição

Para decompor o objetivo de análise da Confiabilidade, foram formuladas as seguintes perguntas e hipóteses. As hipóteses tornam explícito o conhecimento atual sobre o sistema, que será validado pelas métricas.

Questão 1: Maturidade

Qual é a estabilidade do código em relação à ocorrência de defeitos?

Hipótese 1.1 (H1.1): A densidade de defeitos (bugs por KLOC) geral do sistema será superior a 3 bugs/KLOC, indicando um passivo de manutenção que afeta a estabilidade.
Hipótese 1.2 (H1.2): O percentual de commits de correção no histórico do projeto será superior a 15%, indicando que uma parcela significativa do esforço de desenvolvimento é reativa, focada na correção de falhas existentes.

Questão 2: Tolerância a Falhas

Qual é o nível de robustez do código contra falhas em tempo de execução?

Hipótese 2.1 (H2.1): Menos de 50% das operações críticas de entrada/saída (I/O), como conexões com banco de dados e manipulação de arquivos, possuirão um mecanismo adequado de tratamento de exceções (try-catch).

Questão 3: Recuperabilidade

Qual é a eficácia dos mecanismos de recuperação de dados do sistema?

Hipóteso 3.1 (H3.1): A análise qualitativa das rotinas de backup revelará uma baixa pontuação de manutenibilidade (inferior a 5 em 10), devido à falta de documentação clara e à complexidade do código, representando um risco para a manutenção desses mecanismos.

Seleção das Métricas

Questão 1: Maturidade

Métrica 1.1: Densidade de Defeitos no Código
- Definição: Número de issues com a label bug no repositório GitHub, normalizado por mil linhas de código (KLOC).
- Fórmula: (Número total de issues "bug") / (Total de linhas de código / 1000)
- Coleta: 1. Listar todas as issues com a label bug via API do GitHub ou busca manual.
  1. Contar o total de linhas de código PHP (.php) de todo o projeto, utilizando a ferramenta cloc.
  2. Aplicar a fórmula para o escopo global do projeto para validar a H1.1.
- Pontuação de Julgamento:
Excelente Bom Regular Insatisfatório

≤ 1 bug/KLOC >1 e ≤3 bugs/KLOC >3 e ≤6 bugs/KLOC >6 bugs/KLOC
- Propósito: Identificar a densidade geral de defeitos reportados no sistema em relação ao seu tamanho.
Métrica 1.2: Percentual de Commits de Correção
- Definição: Percentual de commits cuja mensagem contém palavras-chave como "fix", "corrige" ou "bugfix".
- Fórmula: (Número de commits de correção / Número total de commits) * 100
- Coleta:
  1. Definir um período de análise (ex: últimos 24 meses).
  2. Contar o número total de commits com git log --oneline --no-merges | wc -l
  3. Contar o número de commits de correção com git log --grep="..." --regexp-ignore-case --oneline --no-merges | wc -l
  4. Aplicar a fórmula para validar a H1.2.
- Pontuação de Julgamento:
Excelente Bom Regular Insatisfatório

≤ 10% >10% e ≤20% >20% e ≤35% >35%
- Propósito: Avaliar se o esforço de desenvolvimento é mais reativo (corrigindo falhas) do que proativo (desenvolvendo novas funcionalidades).

Questão 2: Tolerância a Falhas

Métrica 2.1: Índice de Tratamento de Exceções
- Definição: Percentual de operações de I/O críticas que estão contidas dentro de um bloco de tratamento de exceções (try-catch).
- Fórmula: (Número de operações críticas com try-catch / Número total de operações críticas) * 100
- Coleta: Revisão manual de código ou uso de scripts de análise estática para buscar padrões de tratamento de exceções.
  1. Definir a lista de "operações críticas": chamadas de função/método para conexão com banco de dados ex:( new PDO(, pg_connect), manipulação de arquivos (ex: fopen, file_put_contents) etc.
  2. Em todo o código-fonte do projeto, executar scripts de busca (grep ou ack) para contar o número total de ocorrências dessas operações.
  3. Executar um segundo script para contar quantas dessas ocorrências estão sintaticamente dentro de um bloco try { ... }.
  4. Aplicar a fórmula para validar a H2.1.
- Observação: a métrica mede a existência do mecanismo, não sua eficácia.
- Pontuação de Julgamento:
Excelente Bom Regular Insatisfatório

≥ 90% 70%–89% 40%–69% < 40%
- Propósito: Medir a robustez do código contra erros em tempo de execução.

Questão 3: Recuperabilidade

Métrica 3.1: Análise Qualitativa de Código de Backup
- Definição: Avaliação qualitativa, baseada em um checklist estruturado, das rotinas de backup para verificar sua compreensibilidade, documentação e aderência a boas práticas.
- Coleta: Inspeção manual do código-fonte das funcionalidades de backup.
  1. Identificar os arquivos/módulos responsáveis pela funcionalidade de backup/restauração no código-fonte.
  2. Realizar uma inspeção manual do código aplicando o checklist abaixo. Cada item recebe uma nota de 0 (ausente) a 2 (excelente).
  3. Checklist de Análise:
    - Documentação (Comentários): O código possui comentários explicando a lóǵica geral e os passos críticos?
    - Clareza do Código: Os nomes de variáveis e funções são intuitivos e seguem um padrão?
    - Tratamento de Erros: O código verifica falhas potenciais (ex: falha de escrita em disco, permissões) e as reporta de forma adequada?
    - Configuração: As configurações críticas (ex: caminhos de backup, credenciais) são externalizadas e não "hard-coded"?
    - Testabilidade: A estrutura do código permite a criação de testes unitários ou de integração?
  4. A pontuação final (0 a 10) será a soma dos pontos do checklist, usada para validar a H3.1.
- Pontuação de Julgamento:
Excelente Bom Regular Insatisfatório

9–10 7–8 4–6 0–3
- Propósito: Avaliar a manutenibilidade e a confiabilidade percebida dos mecanismos de recuperação de dados do ponto de vista de um desenvolvedor.

Critérios para Julgamento

Aceitável: ≥ 70% das métricas classificadas como "Bom" ou "Excelente". O sistema demonstra robustez e previsibilidade.
Parcialmente aceitável: Entre 40% e 69% das métricas com nível "Regular" ou superior. O sistema funciona, mas pode apresentar instabilidades pontuais.
Inaceitável: > 30% das métricas atingindo o nível "Insatisfatório". A estabilidade do sistema é considerada crítica e propensa a falhas.

Relação entre a Confiabilidade, Perguntas e Métricas

Questão	Métricas Simplificadas	Tipo de Coleta
Maturidade Qual é a estabilidade do código em relação a defeitos?	M1.1: Densidade de defeitos (issues "bug" por KLOC) M1.2: Percentual de commits de correção (mensagens com fix/corrige/bugfix)	GitHub issues + contagem de linhas com cloc (ou similar) Histórico de commits via git log com filtros/regex
Tolerância a Falhas Qual é o nível de robustez contra falhas em tempo de execução?	M2.1: Índice de tratamento de exceções (% operações I/O críticas dentro de try-catch)	Análise estática / scripts (grep/ack) para localizar operações críticas e verificar blocos try-catch Revisão manual de trechos críticos quando necessário
Recuperabilidade Qual é a eficácia dos mecanismos de recuperação de dados?	M3.1: Pontuação qualitativa das rotinas de backup (checklist, escala 0–10)	Inspeção manual do código e documentação aplicando checklist de avaliação (documentação, clareza, tratamento de erros, configuração, testabilidade)

Tabela 2: Questões e Métricas Simplificadas

Diagrama GQM - Confiabilidade (Representação Estrutural)

Info

Dê zoom com o scroll do mouse no diagrama para ver melhor. Caso prefira, abra em tela cheia.
Você também mode mover o diagrama com o mouse.


graph TB
  BusinessObjective["Objetivo: Avaliar Confiabilidade do i-Educar"]

  BusinessObjective --> Question1["Q1: Qual é a estabilidade do código em relação à ocorrência de defeitos?"]
  BusinessObjective --> Question2["Q2: Qual é o nível de robustez do código contra falhas em tempo de execução?"]
  BusinessObjective --> Question3["Q3: Qual é a eficácia dos mecanismos de recuperação de dados do sistema?"]

  Question1 --> MetricDefects["M1.1: Densidade de Defeitos no Código"]
  Question1 --> MetricFixCommits["M1.2: Percentual de Commits de Correção"]

  Question2 --> MetricExceptions["M2.1: Índice de Tratamento de Exceções"]

  Question3 --> MetricBackup["M3.1: Análise Qualitativa de Código de Backup"]

Use mouse to pan and zoom

Figura 2: Diagrama GQM - Confiabilidade. Autor: Manuela Valadares