Pular para conteúdo

Fase 4 - Execução da Medição

Sumário

Organização da Equipe

Dividimos os trabalhos em duplas para a realização das tarefas, conforme pode ser observado na Tabela 1 a seguir:

Tabela 1: Divisão de Tarefas por Dupla

Característica de Qualidade Dupla Responsável
Adequação Funcional Felipe das Neves e Mylena Mendonça
Confiabilidade Ana Luiza Komatsu e Gustavo Gontijo
Manutenibilidade Pedro Barbosa e Marcos Bittar

1. Execução da Medição Para a Adequação Funcional

1.1 Execução Etapa 1 - Realização da Entrevista Para o Levantamento dos Requisitos

Nessa primeira etapa fizemos a entrevista com os desenvolvedores para elaborarmos os requisitos funcionais da aplicação, segue as perguntas que utilizamos:

Atenção!

Para visualizar as perguntas basta clicar na barra azul abaixo com o texto: "Perguntas utilizadas para a entrevista" nele também está disponível o link para visualizar em uma nova aba e fazer o download do pdf.

Perguntas utilizadas para a entrevista

Clique aqui para visualizar as perguntas em uma nova aba e fazer o download .pdf

No que consiste a aplicação mepa?

Há a necessidade de cadastrar distribuidoras? Quem as faz?

Sobre Gestão de Universidades e Usuários

Qual é a diferença prática de permissão entre um 'Administrador da Universidade' e um 'Técnico'? Existe alguma tela ou botão que o Admin vê e o Técnico não?

Um usuário pode estar vinculado a múltiplas universidades simultaneamente ou o vínculo é exclusivo (1 para 1)?

A remoção de um usuário é 'lógica' (apenas desativa o login, mantendo o histórico) ou 'física' (apaga os dados do banco)? Se apagarmos uma instituição ece com as faturas que ele cadastrou?

Quais são os campos obrigatórios para cadastrar uma Universidade? O sistema deve validar o formato do CNPJ automaticamente e impedir duplicatas?

Sobre Unidades Consumidoras

Qual dado garante que uma UC é única no sistema? É o 'Código da Unidade Consumidora' presente na conta de luz? O sistema deve bloquear se tentarem cadastrar o mesmo código duas vezes?

Além do nome e endereço, precisamos cadastrar dados técnicos como 'Grupo Tarifário' (A ou B), 'Subgrupo', 'Tensão de Fornecimento' e 'Tipo de Medição'? Esses dados influenciam nos cálculos futuros?

Se uma UC mudar de endereço ou de medidor, o sistema cria uma nova ou atualiza a existente mantendo o histórico de consumo?

Sobre Contratos e Renovação

Todo contrato tem obrigatoriamente uma 'Data de Início' e 'Data de Fim'? O sistema deve mudar o status do contrato para 'Expirado' automaticamente quando chegar a data final?

Ao clicar em 'Renovar Contrato', o sistema deve criar um novo registro copiando os dados do contrato anterior (ex: Demanda Contratada) para agilizar o preenchimento? O sistema deve manter o histórico de todas as renovações passadas?

Um contrato pertence a uma única UC ou pode ser um contrato 'guarda-chuva' que cobre várias unidades?

Sobre Faturas

A entrada da fatura é manual campo a campo? Se sim, quais campos são críticos para os relatórios? (Ex: Consumo Ponta, Fora de Ponta, Demanda Medida, Demanda Faturada, Energia Reativa, Multas).

O sistema deve alertar o usuário se ele digitar um consumo absurdamente alto ou negativo (validação de range)? O sistema deve impedir o cadastro de duas faturas para o mesmo mês de referência na mesma UC?

Qual é a regra exata para o sistema marcar uma fatura como 'Pendente'? É quando passa do dia X do mês e a fatura ainda não foi cadastrada no sistema?

Sobre Distribuidoras e Tarifas

As tarifas de energia mudam anualmente. O sistema permite cadastrar a vigência da tarifa (De: Jan/2024 Até: Dez/2024)? Isso é essencial para que faturas antigas não tenham seus valores alterados quando a tarifa nova for cadastrada?

O cadastro de tarifa deve suportar diferenciação por 'Posto Horário' (Ponta e Fora de Ponta) e 'Bandeiras Tarifárias' (Verde, Amarela, Vermelha)?

Sobre Inteligência e Dashboards

Como o sistema gera uma 'Recomendação'? Ele compara a 'Demanda Contratada' com a 'Demanda Medida' dos últimos 12 meses? Essa recomendação aparece automaticamente ou o usuário precisa solicitar a análise?

No dashboard de pendências, o usuário deve conseguir filtrar por 'Tipo de Pendência' (ex: Fatura Atrasada vs. Tarifa não cadastrada)? Deve haver um link direto para resolver o problema (ex: clicar na pendência e ir para a tela de cadastro de fatura)? ```

Clique aqui para visualizar a transcrição em uma nova aba e fazer o download .pdf

Autores: Felipe das Neves e Mylena Mendonça

Após a entrevista modelamos a seguinte lista para os requisitos funcionais para o nosso estudo:

Atenção!

Para visualizar os requisitos basta clicar na barra azul abaixo com o texto: "Lista de Requisitos Funcionais", nele também está disponível o link para visualizar em uma nova aba e fazer o download do pdf.

Lista de Requisitos Funcionais

Clique aqui para visualizar as perguntas em uma nova aba e fazer o download .pdf

RF. Módulo de Gestão de Universidades e Integração

  • RF001 - Cadastro de Universidade via Formulário: O sistema deve permitir o cadastro de novas universidades, processo que é iniciado através do recebimento de um formulário de interesse analisado pela equipe.
  • RF002 - Validação de CNPJ: No ato do cadastro da universidade, o sistema deve validar automaticamente os dígitos verificadores do CNPJ e impedir o cadastro se o número for inválido.
  • RF003 - Bloqueio de Duplicidade de CNPJ: O sistema deve verificar se o CNPJ já existe no banco de dados e impedir a criação de registros duplicados.
  • RF004 - Integração com API da ANEEL: O sistema deve conectar-se automaticamente à API da ANEEL para obter e atualizar a lista de distribuidoras de energia e suas respectivas tarifas em tempo real, eliminando o cadastro manual.
  • RF005 - Lista de Solicitações: O sistema deve possuir uma área administrativa onde a equipe do MEPA possa visualizar a lista de universidades que solicitaram acesso via formulário.

RF. Módulo de Gestão de Usuários e Permissões

  • RF006 - Níveis de Acesso: O sistema deve suportar quatro tipos de perfis de usuário com permissões distintas:
    1. Gestor: Pode gerenciar faturas, contratos e gerenciar outros usuários (adicionar/desativar).
    2. Operacional: Pode apenas adicionar/gerenciar contratos e faturas, sem acesso à gestão de pessoas.
    3. Convidado: Acesso apenas de leitura (visualização) para fins de validação/manutenção.
    4. Demonstração: Acesso público a dados fictícios para conhecer o sistema, sem interagir com dados reais.
  • RF007 - Vínculo Exclusivo: O sistema deve garantir que um usuário esteja vinculado a apenas uma universidade por vez.
  • RF008 - Exclusão Lógica de Usuário: O sistema não deve permitir a exclusão física de usuários do banco de dados. A remoção deve ser lógica (apenas desativação do login), mantendo o histórico de ações e integridade dos dados.

RF. Módulo de Unidades Consumidoras (UCs)

  • RF009 - Unicidade da UC: O sistema deve utilizar o "Código da Unidade Consumidora" (presente na conta de luz) como identificador único, bloqueando o cadastro se o código já existir.
  • RF010 - Dados Técnicos Obrigatórios: O cadastro da UC deve exigir dados essenciais que influenciam no cálculo, incluindo: Grupo Tarifário, Subgrupo, Tensão de Fornecimento e Distribuidora.
  • RF011 - Imutabilidade de Local: O sistema não deve permitir a alteração do endereço de uma UC (regra da ANEEL). Caso o local mude, a UC deve ser desativada e uma nova criada.
  • RF012 - Edição de Dados Cadastrais: O sistema deve permitir a edição de nome e outros dados não-críticos da UC, mantendo o histórico.
  • RF013 - Desativação de UC: O sistema deve permitir desativar uma UC, preservando todo o seu histórico de consumo.

RF. Módulo de Contratos

  • RF014 - Vigência do Contrato: O sistema deve registrar obrigatoriamente a data de início e fim de cada contrato.
  • RF015 - Status de Expiração: O sistema deve alterar automaticamente o status do contrato para "Expirado" quando a data final for atingida e alertar o usuário.
  • RF016 - Renovação de Contrato: O sistema deve possuir uma função de "Renovar" que cria um novo contrato copiando os dados do contrato anterior (preservando o histórico do antigo) e vinculando-o à mesma UC.
  • RF017 - Relacionamento Contrato-UC: O sistema deve restringir cada contrato a uma única Unidade Consumidora (relação 1 para 1).

RF. Módulo de Faturas (Entrada de Dados)

  • RF018 - Métodos de Entrada: O sistema deve permitir o lançamento de faturas de duas formas:
    1. Manual: Preenchimento campo a campo.
    2. Automática (Importação): Leitura de arquivos .CSV ou .XLSX. Nota: Leitura de PDF não é suportada.
  • RF019 - Campos Críticos da Fatura: O sistema deve capturar os seguintes dados para os cálculos:
    • Valor Total.
    • Valor Ponta e Fora Ponta.
    • Demanda Ponta e Fora Ponta (para tarifa Azul) ou Demanda Única (para tarifa Verde).
    • Energia Injetada (Geração Fotovoltaica).
  • RF020 - Validação de Valores: O sistema deve bloquear valores negativos, mas deve aceitar valores altos (variável conforme o tamanho da universidade).
  • RF021 - Bloqueio de Duplicidade de Mês: O sistema deve impedir o cadastro de mais de uma fatura para o mesmo mês de referência na mesma UC.
  • RF022 - Identificação de Pendência: O sistema deve marcar uma fatura como "Pendente" automaticamente a partir do dia 1º do mês subsequente.

RF. Módulo de Inteligência e Recomendação

  • RF023 - Janela de Análise: O sistema deve utilizar uma janela móvel das últimas 12 faturas lançadas para realizar os cálculos de recomendação.
  • RF024 - Aviso de Dados Insuficientes: Caso existam faturas pendentes dentro da janela de 12 meses, o sistema deve exibir um aviso (warning) informando que a recomendação pode estar imprecisa, mas não deve impedir o cálculo.
  • RF025 - Simulação de Cenários: O sistema deve simular cenários comparando o contrato atual com as modalidades Verde e Azul (Ponta/Fora Ponta), considerando a demanda medida.
  • RF026 - Geração Automática: A recomendação deve ser recalculada automaticamente em background sempre que uma nova fatura for lançada ou editada.
  • RF027 - Exibição da Recomendação: O sistema deve exibir uma recomendação apenas se o cenário simulado for mais econômico que o contrato atual.

RF. Módulo de Dashboards e Visualização

  • RF028 - Painel Principal (Visão Geral): O sistema deve exibir um painel com todas as Unidades Consumidoras que possuem pendências (faturas atrasadas ou problemas de contrato).
  • RF029 - Ação Rápida no Painel Principal: No painel principal, deve haver um botão/link direto para resolver o problema (ex: abrir o modal de lançamento da fatura pendente).
  • RF030 - Painel Específico da UC: Ao acessar uma UC específica, o sistema deve listar as pendências em fila (ex: "Lançar Novembro"), mostrando o mês seguinte apenas após a resolução do anterior. ```

1.2 Execução Etapa 2

1.2.1 Análise se o sistema possui tudo que foi listado nos requisitos funcionais

Autores: Felipe das Neves e Mylena Mendonça

1.2.2 Resultados da Análise se o sistema possui tudo que foi listado nos requisitos funcionais:
Resultados da Análise da Q1

1. Gestão de Universidades e Integração

  • RF001 — Cadastro de universidade (implementado)
  • RF002 — Validação de CNPJ (testado e funcionando)
  • RF004 — Integração com API da ANEEL (funcionalidade presente e confirmada)
  • RF003 — Bloqueio de duplicidade de CNPJ (testado e funcionando)
  • RF005 — Lista de solicitações (não dava pra saber como eles recebiam a lista)

2. Gestão de Usuários e Permissões

  • RF006 — Níveis de acesso (perfil “SYS Admin” validado no vídeo)
  • RF007 — Vínculo exclusivo (testado e funcionando)
  • RF008 — Exclusão lógica (testado e funcionando)

3. Unidades Consumidoras

  • RF009 — Unicidade da UC (testado e funcionando)
  • RF010 — Campos técnicos obrigatórios (cadastro de UC exige dados, confirmado)
  • RF011 — Imutabilidade de local (testado e funcionando)
  • RF012 — Edição de dados cadastrais (testado e funcionando)
  • RF013 — Desativação (não testado)

4. Contratos

  • RF014 — Vigência do Contrato (testado e funcionando)
  • RF015 — Status de Expiração (testado e funcionando)
  • RF016 — Renovação de Contrato (testado e funcionando)
  • RF017 — Relacionamento Contrato-UC (testado e funcionando)

5. Faturas

  • RF018 — Métodos de Entrada (Manual e Importação) (Confirmado)
  • RF019 — Campos Críticos da Fatura (Valores e Demandas) (Confirmado)
  • RF020 — Validação de Valores (Bloqueio Negativo) (Confirmado)
  • RF021 — Bloqueio de Duplicidade de Mês (Confirmado)
  • RF022 — Identificação de Pendência (Confirmado)

6. Inteligência e Recomendação

  • RF023 — Janela de Análise (Últimas 12 Faturas) (Confirmado)
  • RF024 — Aviso de Dados Insuficientes (Confirmado)
  • RF025 — Simulação de Cenários (Verde e Azul) (Confirmado)
  • RF026 — Geração Automática da Recomendação (Confirmado)
  • RF027 — Exibição da Recomendação (Apenas se Mais Econômico) (Confirmado)

7. Dashboards e Visualização

  • RF028 — Painel geral (foi observado e nas análises tudo está ok)
  • RF029 — Ação rápida (foi observado e nas análises tudo está ok)
  • RF030 — Painel específico da UC (foi observado e nas análises tudo está ok) ```

1.2.3 Análise se as funcionalidades do sistema estão corretas e se são relevantes para o usuário

Autores: Felipe das Neves e Mylena Mendonça

1.2.4 Resultados da Análise se o sistema possui tudo que foi listado nos requisitos funcionais
Resultados da Análise Q2 e Q3

1. Análise de dados inexistentes

  • Ao acessar a unidade Ceilândia, o sistema exibiu corretamente que não há dados lançados para 2025.
  • Na área de Análise, nenhum gráfico foi gerado, como esperado. Cenário correto.

2. Inserção manual de dados e atualização dos gráficos

  • Após inserir valores em Janeiro e Fevereiro de 2025:

  • Os gráficos foram exibidos imediatamente, com valores correspondentes.

  • Tanto o consumo em ponta quanto em fora de ponta foram atualizados.
  • O sistema demonstrou correção nos cálculos e renderização imediata. Cenário correto.

3. Edição de dados da unidade consumidora

  • Alteração do nome “Campo Ceilândia” → “Campo Ceilândia Sul”:

  • Alteração refletiu corretamente.

  • Alteração numérica de campos diversos:

  • Todos foram atualizados corretamente. Cenário correto.

4. Criação de nova unidade consumidora

  • Cadastro com dados válidos funcionou.
  • Cadastro com data futura exibiu corretamente o erro “dados futuros não são permitidos”. Validação correta.

5. Gerenciamento de pessoas

  • Inclusão de usuário gera um bug: o sistema apresenta erro, mas o usuário é criado mesmo assim.
  • Alterações de perfil, bloqueio e redefinição de senha funcionaram.

  • Logando com perfil “SYS Admin”, os usuários cadastrados anteriormente aparecem corretamente. Um bug encontrado (erro durante criação de usuário).

    Figura 1: Bug

bug

Autores: Felipe das Neves e Mylena Mendonça

6. Distribuidoras e API da Neoenergia

  • A tela de distribuidoras exibe dados apenas para consulta, conforme informado:

  • Não permite cadastro manual (dados vêm da API). Comportamento esperado.

7. Grupos tarifários e painel

  • Telas exibem informações de taxa, horários e subgrupos conforme esperado. Cenário correto.

8. Instituições

  • Cadastro requer CNPJ válido, conforme requisitos.
  • Cadastro e edição funcionaram com dados válidos. Cenário correto. ```

1.3 Conclusão da Medição da Adequação Funcional

Q1 — Functional Completeness (CR)

Cálculo da Q1 — Functional Completeness (CR)

  • Total de requisitos (RF001–RF030): 30

  • Requisitos confirmados como implementados/funcionando: todos exceto RF005 e RF013. Requisitos confirmados = 28

  • Divisão: (28 ÷ 30)

  • 28 ÷ 30 = 0,9333333333...

  • Multiplicar por 100:

  • (0,9333333333 ÷ 100 = 93,33333333...)

  • Arredondamento para uma casa decimal:

  • CR = 93,3%

Classificação segundo os níveis definidos

  • Desejável: CR ≥ 90%
  • Resultado obtido: 93,3% portanto: Desejável

Q2 — Correctness das Funcionalidades Críticas (SC)

Cálculo da Q2 — Correctness (SC)

  • Total de cenários executados: 14

  • Cenários concluídos corretamente: 13

  • Divisão: (13 ÷ 14)

  • 13 ÷ 14 = 0,9285714286...

  • Multiplicar por 100:

  • 0,9285714286... × 100 = 92,85714286...

  • Arredondamento:

  • SC = 92,8%

Classificação segundo os níveis definidos

  • Aceitável: 85% ≤ SC < 95%
  • Resultado obtido: 92,8%, portanto: Aceitável

Q3 — Functional Conformity (CF)

Evidências de Conformidade

A avaliação se deu pela comparação entre o comportamento observado e o comportamento especificado.

Funcionalidades avaliadas e conformidade:
Funcionalidade Conformidade Observada Observações
Visualização de dados lançados ✔ Conforme Sem divergências
Geração de gráficos ✔ Conforme Atualização imediata
Validação de dados futuros ✔ Conforme Mensagem correta
Edição de unidades consumidoras ✔ Conforme Tudo atualizado
Operar como SYS Admin ✔ Conforme Usuários e instituições exibidos corretamente
Cadastro de instituições com CNPJ válido ✔ Conforme Respeita regra
Exibição de grupos tarifários ✔ Conforme Coerente com requisitos
Tela de distribuidoras com dados da API ✔ Conforme Funcionalidade declaradamente somente leitura
Cadastro de usuários ⚠ Parcial Bug: encontrado, mas usuário é criado

Cálculo da Q3 — Functional Conformity (CF)

  • Total de funcionalidades avaliadas: 9

  • Funcionalidades em conformidade: 8

  • Divisão: (8 ÷ 9)

  • 8 ÷ 9 = 0,8888888889...

  • Multiplicar por 100:

  • 0,8888888889... × 100 = 88,88888889...

  • Arredondamento para uma casa decimal:

  • CF = 88,9%

Classificação segundo os níveis definidos

  • Aceitável: 75% ≤ CF < 90%
  • Resultado obtido: 88,9%, portanto: Aceitável

Tabela 2: Resultado Final

Questão avaliada Resultado (%) Classificação
Q1 — Em que medida as funcionalidades priorizadas do MEPA foram implementadas 93,3% Desejável
Q2 — Os resultados apresentados pelo sistema estão corretos 92,8% Aceitável
Q3 — As funcionalidades implementadas operam em conformidade com o esperado 88,9% Aceitável

Melhorias Analisadas para a Adequação Funcional

Os resultados da avaliação de Adequação Funcional para o MEPA indicam que o sistema está principalmente saudável, mas precisa de ajustes para atingir a excelência. O projeto tem uma Completude Funcional Desejável (93,3\%). No entanto, a principal correção reside na Conformidade Funcional (88,9\% - Aceitável). O sistema possui um bug no Cadastro de Usuários: ele cria o usuário corretamente no backend, mas exibe um erro visual no front-end. Sendo necessário a correção do único cenário de teste que falhou para garantir que todos os cálculos críticos estejam 100\% precisos.

2. Execução da Medição Para a Confiabilidade

A execução da medição de confiabilidade foi realizada no ambiente de produção do MEPA Energia, utilizando ferramentas de auditoria técnica em tempo real (DevTools). A validação seguiu os procedimentos de Caixa Preta definidos na etapa de descrição.

Vídeo

Autores: Gustavo Gontijo Lima

Resultados da Disponibilidade (Availability)

Objetivo: Aferição técnica da resposta do servidor e renderização da interface.

  • Ferramenta: DevTools > Network Tab.
  • Cenário: Recarregamento forçado da página principal e análise do gráfico de requisições.
Métrica Coletada Valor Obtido Status
Status Code HTTP 200 OK ✅ Sucesso
Tempo de Load (Finish) 1.01 s ✅ Excelente

Análise Técnica: O sistema demonstrou Alta Disponibilidade. O tempo de carregamento de 1.01 segundos é extremamente performático, situando-se em uma faixa ideal de usabilidade (abaixo de 2 segundos). O retorno do código HTTP 200 confirma que a infraestrutura do servidor está saudável e respondendo corretamente às requisições do cliente.

Resultados da Tolerância a Falhas (Fault Tolerance)

Objetivo: Verificar a robustez da validação de dados no Client-Side e estabilidade do código.

  • Ferramenta: DevTools > Console Tab.
  • Cenário: Tentativa de submissão de formulário com campos obrigatórios vazios.
Observação Visual Mensagem Exibida Comportamento do Console
Bloqueio da Ação Ícone de exclamação amarelo seguido de: "Preencha este campo". Limpo (Sem exceções de erro crítico/Vermelho).

Análise Técnica: O sistema possui mecanismos eficazes de Tolerância a Falhas na Camada de Apresentação. 1. Validação: A aplicação utiliza atributos de validação nativos HTML5 ou scripts de verificação prévia, interceptando a ação antes que uma requisição inválida sobrecarregue o servidor. 2. Estabilidade: O console do navegador permaneceu limpo, indicando que o tratamento da exceção foi previsto no código e não gerou falhas de execução (crashes de JavaScript).

Resultados da Recuperabilidade (Recoverability)

Objetivo: Avaliar a persistência de dados não salvos (Rascunhos de Sessão).

  • Ferramenta: DevTools > Application > Local Storage.
  • Cenário: Preenchimento de dados seguido de atualização da página (F5) antes do envio.
Ação Executada Resultado no Local Storage Estado do Formulário Após F5
Digitação de Dados Nenhum registro criado (Tabela vazia). Campos retornaram Vazios.
Submissão (Envio) Registro criado apenas após sucesso. N/A (Ação já concluída).

Métrica CF2 - Taxa de Recuperação de Sessão (TRS): - TRS = 0% (Perda total dos dados não submetidos).

Análise Técnica: O sistema apresenta Baixa Recuperabilidade para dados em rascunho. A auditoria via DevTools confirmou que o Local Storage não é utilizado para persistência temporária durante a digitação (apenas pós-envio). Isso representa um risco de usabilidade: caso o usuário sofra uma instabilidade de rede ou feche a aba acidentalmente durante o preenchimento, todo o progresso será perdido irrecuperavelmente.

Conclusão da Avaliação de Confiabilidade

A avaliação técnica revela um sistema com infraestrutura robusta, mas com pontos de melhoria na experiência de continuidade:

  1. Pontos Fortes: O sistema é altamente disponível e rápido (Load de 1.01s). A Tolerância a Falhas é garantida por validações de interface competentes que previnem erros de uso sem quebrar a aplicação.
  2. Ponto de Atenção: A Recuperabilidade de rascunhos é inexistente no front-end. Recomenda-se a implementação de um padrão de Autosave no localStorage para formulários extensos, aumentando a resiliência contra interrupções acidentais.

3. Execução da Medição Para a Manutenibilidade

A execução da medição para a Manutenibilidade concentrou-se na análise estática do código-fonte e na coleta de dados de processo do sistema de gestão de projetos (GitLab Issues), conforme detalhado na Fase 3.

Complexidade Ciclomática (CCM)

A Complexidade Ciclomática (CC) é uma métrica que indica a complexidade estrutural do código, sendo um fator chave para a Analisabilidade e Modificabilidade.

Execução da Medição: A análise estática foi realizada utilizando a ferramenta SonarCloud. O valor total da Complexidade Ciclomática para o projeto foi de 1.295.

Análise Modular e Julgamento:

Para obter a Complexidade Ciclomática Média (CCM), foi realizada uma análise granular por módulo, excluindo os módulos tests e mec_energia (módulo administrativo do framework Django) por não representarem o código de negócio principal.

Video 3: Coleta CCM

Módulo CC (Total) CCM (Média por Módulo)
contracts 132 10,15
users 195 15,00
global_search_recommendation 71 11,83
recommendation 99 9,00
recommendation_commons 49 5,44
scripts 47 5,22
tariffs 155 14,09
universities 101 8,41
utils 102 7,84

O CCM geral a partir dos módulos coletados foi de 9,00.

Conclusão da CCM: O resultado de CCM = 9,00 se enquadra na faixa Desejável (CCM ≤ 10), conforme o critério de julgamento estabelecido no Módulo 2. Isso sugere que, em média, o código do projeto MEPA apresenta uma baixa complexidade estrutural, favorecendo a Analisabilidade e a Modificabilidade.

No entanto, a análise modular revela pontos de atenção: os módulos users (CCM = 15,00) e tariffs (CCM = 14,09) estão no limite superior da faixa Aceitável (10 < CCM ≤ 15), indicando que estes componentes específicos podem exigir maior esforço para manutenção e testes.

Lead Time de Correção (LTC)

O Lead Time de Correção (LTC) mede a agilidade do processo de manutenção, sendo um indicador direto da Modificabilidade do sistema.

Execução da Medição: A coleta de dados foi realizada através de uma consulta estruturada no sistema de Issues do GitLab, utilizando um script em Python [4]. O LTC foi calculado como o tempo decorrido entre a abertura do Issue e o fechamento (correção do bug), o que reflete o tempo total de resolução de defeitos.

Video 4: Coleta LTC

Amostra de Dados Coletados: A tabela abaixo apresenta uma amostra dos dados utilizados no cálculo do LTC:

Tabela 2: Amostra de Lead Time de Correção (LTC)

ID Issue Created Closed LTC_dias
490 Fix campo "Nome da Unidade Consumidora" 2025-05-17 2025-06-01 15
480 Tratamento de erro para plot de gráficos 2025-05-12 2025-05-14 1
479 Refatorar a mensagem para faturas 2025-05-12 2025-05-14 1
477 Relatório detalhado faltando dados 2025-05-09 2025-05-14 5
475 Tarifa vencida mesmo dentro da validade 2025-05-08 2025-05-14 5

| Fonte: Resultados em CSV da Extração Pipeline LTC [5]

Resultado da Medição: O LTC médio encontrado na amostra analisada foi de 64 dias.

Análise e Julgamento: O critério de julgamento estabelecido no Módulo 2 para o LTC é: * Desejável: LTC ≤ 3 dias * Aceitável: 4 ≤ LTC ≤ 7 dias * Inaceitável: LTC > 7 dias

Com um LTC médio de 64 dias, o resultado se enquadra na faixa Inaceitável. Este valor é significativamente superior ao limite de 7 dias, indicando um processo de manutenção lento.

Implicações: O alto LTC sugere que a Modificabilidade do sistema está comprometida. As causas podem estar relacionadas a: 1. Complexidade do Código: O alto LTC pode ser uma consequência da alta Complexidade Ciclomática em módulos críticos (como visto na CCM). 2. Processo de Desenvolvimento: Gargalos no processo de review, testes ou deploy que atrasam a entrega da correção.

Este resultado é um ponto crítico que deve ser destacado na conclusão da avaliação de Manutenibilidade.

Cobertura de testes de Regressão (CTR)

Para calcular o CTR, como descrito na etapa 3, fizemos manualmente o cálculo dos últimos 3 Merge Requests aceitos, seguindo a fórmula descrita na etapa 2. a tabela a baixa mostra os resultados. |MR|Linhas cobertas por Testes|Linhas Alteradas|CTR| |:------:|------------------|------------|:----------------:| |!435|50|60|83%| |!433|236|264|89%| |!432|569|572|99%| |!431|437|493|88%| |!430|574|583|98%|

Assim, como todos os CTRs foram maiores ou iguais à 80% concluimos, conforme estabelecido na etapa 2, que o CTR é desejável.

Uso de IA

Para a elaboração deste documento e de outros artefatos do projeto, foram utilizadas ferramentas de Inteligência Artificial, como o ChatGPT (OpenAI) e o Gemini (Google). O uso dessas tecnologias teve como principais objetivos:

  • Aprimoramento da Escrita: Melhorar a clareza, coesão e correção gramatical dos textos, garantindo uma comunicação mais eficaz.
  • Geração de Estruturas: Auxiliar na criação de estruturas iniciais para seções e tabelas, otimizando o tempo de desenvolvimento.
  • Refinamento de Ideias: Servir como ferramenta de brainstorming para refinar conceitos e justificativas apresentadas no documento.
  • Consistência Terminológica: Ajudar a manter a consistência dos termos técnicos utilizados ao longo da documentação.

Ressaltamos que todo o conteúdo gerado por IA foi cuidadosamente revisado, editado e validado pelos membros da equipe para assegurar sua precisão, relevância e alinhamento com os objetivos da avaliação de qualidade. As ferramentas foram empregadas como um suporte ao processo de criação, e a responsabilidade final pelo conteúdo permanece com os autores do projeto.

Referências Bibliográfica

[1] REQUISITOS NÃO FUNCIONAIS. Canal Fatto Consultoria e Sistemas. Publicado em 06 de ago. de 2015. Disponível em: https://www.youtube.com/watch?v=Gv5H9XgWOJ0. Acesso em: 17 de nov. de 2025.

[2] RODRIGUES, Renato. ISO/IEC 25010: Functional Suitability. LinkedIn, 2 de fev. de 2024. Disponível em: https://pt.linkedin.com/pulse/isoiec-25010-functional-suitability-renato-rodrigues. Acesso em: 17 de nov. de 2025.

[3] Notas de aula da disciplina de Qualidade de Software: Conceitos GQM (introdução, planejamento, definição, coleta e interpretação).

[4] Script Implementação da Pipeline LTC. Disponível em: Script - Extrator de LTC - Issues GitLab

[5] Resultados em CSV da Extração Pipeline LTC. Disponível em: Dados de Saída - Extrator de LTC - Issues GitLab

Histórico de Versões

Versão Descrição Autor(es) Data de Produção Revisor(es) Data de Revisão Observações / Incrementos
1.0 Desenvolvimento dos objetivos do GQM. Felipe das Neves 17/11/2025 — — Versão inicial do documento.
1.1 Inserção do que executamos para o artefato da adequação funcional. Felipe das Neves 17/11/2025 Mylena Mendonça 17/11/2025 Revisão da ideação do artefato.
1.2 Inserção do que executamos para o artefato da confiabilidade. Gustavo Gontijo Lima 18/11/2025 Ana Luiza Komatsu 18/11/2025 Revisão da ideação do artefato.
1.3 Inserção do CTR. Marcos Bittar 23/11/2025
1.4 Inserção do que executamos para o artefato da Manuntenabilidade Pedro Barbosa 23/11/2025
1.5 Inserção dos videos para o artefato da Manuntenabilidade Pedro Barbosa 28/11/2025