Especificação da Avaliação
Critério de Qualidade: Manutenabilidade
Subcaracterística Avaliada: Compreensibilidade
Objetivo: Verificar se o sistema AgroMart (código + documentação) é fácil de entender por novos desenvolvedores
1. Objetivo de Medição (GQM)
| Dimensão |
Descrição |
| Objeto de Análise |
Analisar o sistema AgroMart (código-fonte + documentação) |
| Propósito |
Avaliar sua compreensibilidade técnica |
| Foco |
Estrutura de arquivos, clareza dos nomes, comentários e qualidade dos documentos de apoio |
| Ponto de Vista |
Equipe de desenvolvimento e novos colaboradores |
| Contexto |
Disciplina Qualidade de Software |
1.1 Questões Relacionadas ao Objetivo de Medição
| Questão |
Descrição |
Hipótese |
| Q1 |
O código-fonte do agromart-web está estruturado e nomeado de forma compreensível? |
A estrutura modular e a nomeação de arquivos e funções são suficientemente claras para facilitar a navegação no sistema. |
| Q2 |
A documentação do projeto (docs) ajuda na compreensão da arquitetura e do fluxo de execução? |
Os arquivos de documentação fornecem instruções claras para que novos desenvolvedores entendam como o sistema funciona. |
| Q3 |
Existem comentários e convenções no código que contribuem para o entendimento das funções e responsabilidades? |
As funções e componentes do sistema possuem comentários explicativos e seguem padrões de nomeação consistentes. |
2. Relação entre Objetivo de Medição – Questões – Métricas
Figura 1 - Relação entre questões e métricas
3. Abstraction Sheet – Objetivo de Medição
| Object |
Purpose |
Quality Focus |
Viewpoint |
Código-fonte e documentação do sistema AgroMart (agromart-web + docs) |
Compreensão do sistema por novos colaboradores |
Compreensibilidade técnica: estrutura, nomeação, comentários e documentação de apoio |
Equipe de desenvolvimento e novos contribuidores |
Quality Focus
- Clareza da estrutura de pastas e arquivos
- Nomeação de funções, variáveis e componentes
- Existência de comentários explicativos
- Presença e completude de README, guias e fluxos
Variation Factors
- Qualidade e atualização da documentação
- Grau de padronização entre os contribuidores
- Nível de experiência da equipe de desenvolvimento
Baseline Hypotheses (Estimates)
- A estrutura do projeto segue padrões comuns em projetos React
- Pelo menos 70% das funções relevantes contêm comentários úteis
- Os nomes dos arquivos e componentes refletem suas funções no sistema
- Há README principal e guias suficientes para onboarding básico
Impact of Variation Factors
- Melhor padronização e documentação reduzem o tempo necessário para novos desenvolvedores entenderem o sistema
- Falta de comentários e nomes genéricos aumenta a dificuldade de leitura do código
- Documentação desatualizada ou inexistente compromete a compreensão geral da arquitetura
4. Níveis de Pontuação e Critérios de Julgamento
| Métrica |
Tipo |
Nível Alto (👍) |
Nível Médio (⚠️) |
Nível Baixo (🚨) |
| M1 |
Objetiva |
Estrutura clara, com pastas por função |
Algumas pastas agrupam múltiplas lógicas |
Pastas genéricas, sem divisão clara |
| M2 |
Subjetiva |
Nomes descritivos e padronizados |
Nomes medianos, às vezes genéricos |
Nomes confusos, siglas ou abreviações |
| M3 |
Binária |
README + guia de contribuição + arquitetura |
Apenas README |
Sem documentação funcional |
| M4 |
Escore |
5 – Documentação completa e clara |
3 – Documentação parcial |
1 – Documentação confusa ou ausente |
| M5 |
Objetiva |
≥ 70% das funções têm comentários úteis |
40% a 69% |
< 40% |
| M6 |
Subjetiva |
Código segue padrões consistentes (ex: ESLint) |
Parcialmente padronizado |
Sem padrões visíveis ou confusos |
Tabela de Versionamento
| Data |
Versão |
Descrição |
Autor |
Revisor |
| 11/07/2025 |
1.0 |
Criação da Fase 2, Objetivos e Questões |
Raissa |
Mateus |