Compatibilidade¶
Introdução¶
Conforme analisado na Fase 1 e com base na norma ISO/IEC 25010 (SQuaRE), a Compatibilidade destaca-se como um critério essencial de qualidade de software. Dessa maneira, este atributo representa a capacidade de um produto trocar informações e executar funções enquanto compartilha recursos com outros sistemas.
Como é explicado na norma, a compatibilidade se divide em duas subcaracterísticas: a Interoperabilidade, referente à habilidade de troca de dados (vital para o formato EXR), e a Coexistência, que trata da capacidade do software de operar corretamente em um ambiente compartilhado.
Com base nesses conceitos, este trabalho aplica a metodologia Goal-Question-Metric (GQM) ao módulo File-exr do GIMP e essa abordagem segue o princípio de medição top-down, no qual se definem primeiro os objetivos estratégicos para, a partir deles, formalizar as questões e métricas necessárias à análise The mystery behind project management metrics. O GQM será utilizado para melhorar a qualidade do software e otimizar o processo de desenvolvimento LANSA - Measurement Objectives ao reforçar a análise da qualidade da compatibilidade.
Objetivo¶
O principal objetivo deste documento é estruturar e formalizar o programa de medição GQM para o fator Compatibilidade do GIMP. Para tal, o foco será dado às suas subcaracterísticas que representam os pontos críticos para do software. Dessa maneira, pretende-se transformar as necessidades de informação dos stakeholders em um conjunto gerenciável de métricas validadas. Em última análise, o objetivo também é fornecer insights acionáveis para a equipe de desenvolvimento para cumprir as funções de Análise e Controle do projeto LANSA
Metodologia¶
A medição de software é um processo sistemático que, como defendido na literatura em LANSA - Measurement Principles, deve compreender cinco atividades interligadas: Formulação, Coleta, Análise, Interpretação e Feedback.
Neste trabalho, o método GQM (Goal-Question-Metric) é empregado como princípio na análise e a sua estrutura top-down alinha o projeto com modelos de maturidade como o LANSA - CMMI Context.
A análise da qualidade, portanto, será abrangente ao utilizar uma combinação de métricas do ELITEX - Quality Metrics:
- Métricas de Produto: para avaliar o artefato
File-exr; - Métricas de Processo: para avaliar as atividades de desenvolvimento);
- Métricas de Projeto: para o controle de esforço).
A Interpretação, por fim, será realizada ao confrontar os dados coletados com as hipóteses (critérios de aceitação) definidas nas questões.
Descrição do Objetivo de Medição de Compatibilidade¶
Tabela 3: Descrição do Objetivo de Medição de Qualidade
| Dimensão | Descrição |
|---|---|
| Analisar | GIMP (Módulo File-exr). |
| Para o propósito de | Analisar a conformidade com o padrão OpenEXR e a fidelidade na troca de dados do módulo. |
| Com respeito a | Compatibilidade (Interoperabilidade e Coexistência) |
| Da perspectiva do | Designer Gráfico |
| No contexto de | Avaliação formal para fins didáticos da Disciplina de Qualidade de Software |
Fonte: Autores. (2025)
Questões e Métricas¶
Q1. Qual o grau de fidelidade e confiança do GIMP na troca de dados com o ecossistema externo de aplicações gráficas?¶
Hipótese (H1): Espera-se que o módulo apresente alta fidelidade de intercâmbio ao garantir que a Taxa de Sucesso Funcional (TSF) seja elevada e o risco de quebra no fluxo de trabalho (DDT) seja baixo.
Métrica 1.1: Taxa de Sucesso Funcional (TSF)¶
Esta métrica mede a eficácia na realização de uma tarefa com base no estudo do artigo MOLDSTUD - Test Pass Rates. Portanto, ela indicará a confiabilidade do módulo File-exr no fluxo de intercâmbio de dados.
Fórmula:
TSF (%) = (Número de Casos de Intercâmbio Sucedidos / Número Total de Casos de Intercâmbio Testados) * 100
Referência: [5]
Interpretação (Critério):
- Alta Interoperabilidade (H1 Confirmada): >95%
- Média Interoperabilidade: de 45% a 95%
- Baixa Interoperabilidade (H1 Refutada): < 45%
Métrica 1.2: Densidade de Defeitos por Teste (DDT)¶
Esta métrica quantifica a qualidade do módulo com base na relação entre defeitos encontrados e o volume de testes executados inspirados em MOLDSTUD - Defect Density. Ela é um indicador de risco.
Fórmula:
$$DDT = \frac{\text{Nº de Defeitos de Interoperabilidade}}{\text{Nº Total de Casos de Teste Executados}}$$
Referência: [5]
Interpretação (Critério):
- Baixo Risco (H1 Confirmada): < 0.5 defeitos/caso de teste
- Risco Moderado: 0.5 a 1.0 defeitos/caso de teste
- Alto Risco (H1 Refutada): > 1.0$ defeitos/caso de teste
Q2. Quais são os custos de recursos (tempo e memória) que o módulo File-exr impõe ao sistema GIMP em um ambiente de usuário final?¶
Hipótese (H2): Espera-se que o módulo demonstre alta Coexistência, com baixo impacto no tempo de inicialização (APTC) e no consumo de memória (APCM).
Métrica 2.1: Aumento Percentual no Tempo de Carregamento (APTC)¶
Mede o impacto na experiência do usuário ao iniciar o software, isso porque um atraso excessivo é um sintoma de baixa Coexistência e prejudica a produtividade do Designer Gráfico.
Fórmula:
APTC (%) = ((Tempo de Carregamento com Módulo - Tempo sem Módulo) / Tempo sem Módulo) * 100
Referência: [4]
Interpretação (Critério):
- Alta Coexistência (H2 Confirmada): < 5%
- Coexistência Moderada: 5% a 20%
- Baixa Coexistência (H2 Refutada): > 20\%
Métrica 2.2: Aumento Percentual no Consumo de Memória (APCM)¶
Mede a eficiência com que o módulo utiliza a memória do sistema ao ser um indicador de Utilização de Recursos. Módulos com alto consumo de memória na inicialização podem causar lentidão no sistema operacional.
Fórmula:
APCM (%) = ((Consumo de Memória com Módulo - Consumo sem Módulo) / Consumo sem Módulo) * 100
Referência: [1] (Referência genérica para métricas de recurso)
Interpretação (Critério):
- Alta Coexistência (H2 Confirmada): > 20%
- Coexistência Moderada: 20% a 40%
- Baixa Coexistência (H2 Refutada): < 40\%
Q3. O quanto estável e robusto é o módulo File-exr em produção ao refletir a eficácia de nosso processo de garantia de qualidade?¶
Hipótese (H3): Espera-se que o módulo seja altamente estável (baixo DDPL) e que o processo de correção de bugs de compatibilidade seja rápido, indicando alta estabilidade no uso.
Métrica 3.1: Tempo Médio de Resolução (TMR)¶
Métrica de Processo para avaliar a eficiência da equipe de manutenção na resposta a falhas. Um TMR baixo é um indicador de Alta Eficiência de Manutenção para bugs de compatibilidade MOLDSTUD - Resolution Timelines.
Fórmula:
$$TMR = \frac{\sum \text{Tempo de Resolução}}{\text{Nº Total de Defeitos Resolvidos}}$$
Referência: [5]
Interpretação (Critério):
- Baixa Eficiência (H3 Confirmada): < 48 horas
- Eficiência Moderada: 48 a 96 horas
- Alta Eficiência (Hipótese Refutada): > 96 horas
Conclusão¶
O uso do método GQM foi fundamental para esta análise, pois permitiu transformar o conceito abstrato de "Compatibilidade" em um plano de avaliação concreto para o módulo File-exr. Portanto, ao focar em subcaracterísticas cruciais como Interoperabilidade e Coexistência, conseguiu-se ir além do "achismo" sobre o comportamento do módulo. Além disso, as métricas definidas deram um roteiro para quantificar o comportamento do módulo em cenários reais.
Esta análise servirá de base sólida para a próxima fase. Com os dados coletados e as hipóteses testadas, poderão ser identificados os pontos fortes e as oportunidades de melhoria específicas para o File-exr.
Sobre o uso de IA¶
Para a elaboração deste documento, a Inteligência Artificial foi utilizada como ferramenta de apoio. Desta maneira, o seu uso concentrou-se, principalmente, em auxiliar a compreensão e o esclarecimento dos termos técnicos presentes nas normas (ISO/IEC 25010) e nos artigos e corporativos consultados. Adicionalmente, a IA foi empregada para a estruturação e organização das ideias na aplicação da metodologia GQM.
Referências Bibliográficas¶
[1] ABREU, Bruno. A ISO/IEC 25010 e sua importância para a qualidade de software. One Day Testing Blog, 29 mar. 2023. Disponível em: https://blog.onedaytesting.com.br/iso-iec-25010/. Acesso em: 22 out. 2025.
[2] BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H. Dieter. The Goal Question Metric Approach (1994). In: Encyclopedia of Software Engineering. (Conceito GQM e metodologia top-down).
[3] ELITEX. Software Quality Metrics: What Is This Really About? (2024). Disponível em: https://elitex.systems/blog/software-quality. Acesso em: 22 out. 2025. (Tipos de métricas, performance, segurança, usabilidade).
[4] LANSA. What Are Software Metrics? How Can I Measure These Metrics? (2024). Disponível em: https://lansa.com/blog/app-development/what-are-software-metrics-how-can-i-measure-these-metrics/. Acesso em: 22 out. 2025. (Ciclo de medição: Formulação, Coleta, Análise, Interpretação, Feedback; e objetivos de medição).
[5] MOLDSTUD. Essential Key Metrics for Measuring Success in Compatibility Testing for Quality Assurance. (2025). Disponível em: https://moldstud.com/articles/p-essential-key-metrics-for-measuring-success-in-compatibility-testing-for-quality-assurance. Acesso em: 22 out. 2025. (Métricas de Taxa de Falha, Pass Rate e Esforço de Compatibilidade).
[6] MOLDSTUD. Key Performance Indicators (KPIs) for Compatibility Testing. (2025). Disponível em: https://moldstud.com/articles/p-essential-key-metrics-for-measuring-success-in-compatibility-testing-for-quality-assurance. Acesso em: 22 out. 2025. (Critérios e benchmarks de compatibilidade e desempenho).
[7] TENCENT CLOUD. How to measure the success of compatibility testing? (2025). Disponível em: https://www.tencentcloud.com/techpedia/105935. Acesso em: 22 out. 2025. (Visão geral sobre sucesso em testes de compatibilidade).
Histórico de Versão¶
| Versão | Data | Descrição | Autor | Revisor |
|---|---|---|---|---|
| 1.0 | 08/10/2025 | Criação do Documento. | Vinicius Castelo | Caio Venâncio, Pedro Everton |
| 1.1 | 12/10/2025 | Adição de tabela e questões. | Pedro Everton | Larissa Stéfane |
| 1.2 | 13/10/2025 | Conserto de fórmulas. | Breno Alexandre | Larissa Stéfane |
| 1.3 | 20/10/2025 | Adição da introdução e metodologia | Larissa Stéfane | Breno Alexandre |
| 1.4 | 20/10/2025 | Correção das referências bibliográficas | Larissa Stéfane | Breno Alexandre |
| 1.5 | 24/10/2025 | Reformulação e adição de mais perguntas | Larissa Stéfane | Breno Alexandre |
| 1.6 | 24/10/2025 | Reorganização das métricas | Larissa Stéfane | Breno Alexandre |
| 1.7 | 24/10/2025 | Nova reestruturação das perguntas | Larissa Stéfane | Breno Alexandre |
| 1.8 | 24/10/2025 | Elaboração da conclusão e da declaração | Larissa Stéfane | Breno Alexandre |
| 1.9 | 25/10/2025 | Consertar tabela | Caio Venâncio | Breno Alexandre |