💻 computer science

Exploring Sustainability in Scientific Software through Code Quality & Test Coverage Metrics

Este estudio analiza las métricas de calidad del código y la cobertura de pruebas en el software científico de código abierto para demostrar que los proyectos sostenibles presentan una cobertura de pruebas más alta y consistente y correlaciones más fuertes entre código y pruebas, al tiempo que destacan que la baja testabilidad general suele estar impulsada por una alta complejidad y acoplamiento.

Autores originales: Sheikh Md. Mushfiqur Rahman, Gregory R. Watson, Nasir U. Eisty

Publicado 2026-05-06

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Sheikh Md. Mushfiqur Rahman, Gregory R. Watson, Nasir U. Eisty

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina el software científico como una enorme cocina personalizada, diseñada por científicos para cocinar nuevos descubrimientos. Algunas de estas cocinas están bien organizadas, con etiquetas claras en cada frasco de especias, un libro de recetas que se actualiza y un equipo que sabe exactamente cómo usar la estufa. Otras son caóticas: las recetas están garabateadas en servilletas, la estufa es un misterio, y si el chef original se va, nadie sabe cómo encenderla.

Este artículo es como un inspector de salud que visitó 14 de estas cocinas científicas para averiguar qué hace que una cocina sea "sostenible" (capaz de seguir cocinando durante años) frente a una que probablemente se desmoronará. No solo miraron cuántas personas había en la cocina; examinaron los planos (el código) y los controles de seguridad (las pruebas).

Esto es lo que encontraron, desglosado de forma sencilla:

1. Las dos formas de juzgar una cocina

Los investigadores tuvieron que decidir qué cocinas estaban "sanas" y cuáles estaban "enfermas". Utilizaron dos métodos diferentes, como dos formas distintas de juzgar un restaurante:

Método A (La prueba del "chef ocupado"): Observaron con qué frecuencia los chefs estaban realmente cocinando. Si una cocina había estado activa durante al menos dos años con un flujo constante de nuevos platos (commits), la calificaron como Sostenible.
Método B (La prueba del "factor camión"): Preguntaron: "¿Si el chef principal se chocara contra un camión (o simplemente renunciara), la cocina colapsaría?". Si había suficientes chefs de respaldo que conocían los secretos, la calificaron como Sostenible.

2. La gran sorpresa: Las pruebas no cuentan toda la historia

Los investigadores esperaban que las cocinas "Sostenibles" siempre tuvieran mejores controles de seguridad (cobertura de pruebas).

Al usar el método del "chef ocupado": ¡Tenían razón! Las cocinas activas tenían controles de seguridad mucho mejores.
Al usar el método del "factor camión": Se equivocaron. Algunas cocinas etiquetadas como "No sostenibles" (porque dependían de solo uno o dos chefs) en realidad tenían mejores controles de seguridad que las "Sostenibles".

La lección: Solo porque una cocina tenga una lista de verificación de seguridad no significa que durará para siempre. Si el equipo es demasiado pequeño o frágil, la cocina podría fallar aún si las pruebas son perfectas.

3. El problema del "plano desordenado"

El estudio examinó la complejidad de los planos (el código).

El hallazgo: En las cocinas que eran verdaderamente sostenibles, existía una conexión clara entre cómo se construyó la cocina y qué tan bien se probó. Si la cocina estaba desordenada (alta complejidad) y las paredes se apoyaban demasiado unas en otras (alto acoplamiento), los controles de seguridad eran más difíciles de realizar.
La analogía: Imagina intentar probar una casa donde la fontanería está enredada con el cableado eléctrico. Es una pesadilla verificar si las luces funcionan sin quemar un fusible. El estudio encontró que el código desordenado y enredado dificulta escribir buenas pruebas.
El resultado: Las cocinas sostenibles tendían a tener planos más limpios, mejores etiquetas (documentación) y una conexión más clara entre cómo se construyeron y cómo se probaron. Las cocinas no sostenibles solían ser desordenadas, y sus controles de seguridad no parecían seguir ningún patrón lógico.

4. La regla del "chef más estricto"

Los investigadores se preguntaron: ¿Qué pasa si exigimos que los chefs estén aún más ocupados para calificar una cocina como "Sostenible"?

Subieron el listón, requiriendo aún más actividad para calificar.
El resultado: A medida que hacían las reglas más estrictas, el patrón se volvía cristalino. Las cocinas verdaderamente activas y bien mantenidas tenían altos controles de seguridad. Las que simplemente "fingían" estar activas (o estaban muriendo) tenían casi ningún control de seguridad en absoluto.
La conclusión: Si quieres saber si una cocina científica está verdaderamente sana, no mires solo la lista de verificación de seguridad. Observa qué tan ocupado y consistente es el equipo. Un alto nivel de actividad es un mejor indicador de salud que las pruebas en sí mismas.

5. El estado general de las cocinas científicas

Cuando miraron todas las cocinas juntas, las noticias no fueron buenas:

Bajos controles de seguridad: En promedio, estas cocinas científicas estaban mal probadas. Muchas tenían casi ningún control de seguridad en sus estufas u hornos.
La complejidad es el enemigo: Cuanto más enredado y complejo era el diseño de la cocina, menos controles de seguridad tenía. Parece que cuando los científicos construyen estas herramientas, se enfocan en lograr que la "cocción" se haga (la ciencia) en lugar de construir una cocina segura y probable.

Resumen

Este artículo nos dice que el software científico sostenible no se trata solo de tener pruebas. Se trata de tener una estructura bien organizada, una buena documentación y un equipo consistente que mantenga el proyecto vivo.

Buenos indicios: Planos limpios, etiquetas claras y un equipo que sigue apareciendo para trabajar.
Malos indicios: Cableado enredado, instrucciones faltantes y depender de solo una o dos personas para mantener las luces encendidas.

Los autores concluyen que para mantener el software científico vivo a largo plazo, debemos dejar de tratar el código como un boceto desordenado y empezar a tratarlo como un edificio bien diseñado, con un enfoque en la estructura y la consistencia, no solo en el resultado final.

Resumen Técnico: Exploración de la Sostenibilidad en el Software Científico a través de Métricas de Calidad del Código y Cobertura de Pruebas

Declaración del Problema

El software científico de código abierto (SciOSS) es fundamental para la investigación y la ingeniería, pero a menudo sufre problemas de sostenibilidad a largo plazo. A diferencia del software industrial, el SciOSS se desarrolla frecuentemente con una adhesión limitada a los estándares de ingeniería de software, lo que resulta en un código mal estructurado, difícil de mantener, carente de documentación y con pruebas automatizadas insuficientes. Estas deficiencias obstaculizan el progreso de la investigación, reducen la eficiencia y dificultan la reproducibilidad. Aunque la investigación existente ha explorado la sostenibilidad a través de métricas sociales (por ejemplo, número de colaboradores, actividad de confirmaciones) o indicadores a nivel de proyecto, existe una brecha significativa en la comprensión de cómo las propiedades estructurales internas del código —tales como la complejidad, la modularidad y la cobertura de pruebas— se correlacionan con la viabilidad a largo plazo del software científico.

Metodología

El estudio emplea un enfoque basado en datos para investigar la relación entre la calidad del código y la sostenibilidad dentro de la Cartera de Software del CASS (Consorcio para el Avance del Software Científico).

Conjunto de datos y selección:
Los autores curaron un conjunto de datos de 14 proyectos de software científico en C/C++. Se aplicaron criterios estrictos de viabilidad para garantizar la reproducibilidad: los proyectos debían estar alojados públicamente, ser compilables con GCC/Clang utilizando banderas de instrumentación de cobertura (-coverage -O0 -g), ser compatibles con la extracción de AST de Clang y contener suites de pruebas ejecutables. Se excluyeron los proyectos que requerían hardware especializado (por ejemplo, controladores de GPU específicos) o que no podían compilarse bajo instrumentación de cobertura.

Etiquetado de sostenibilidad:
Los proyectos se clasificaron como "sostenibles" o "insostenibles" utilizando dos métodos complementarios y establecidos:

Criterio basado en tiempo (t-años): Un proyecto es sostenible si tiene confirmaciones que abarcan más de $t$ años (establecido en 2) con una mediana de confirmaciones mensuales $\ge k$ (establecido en 6).
Criterio del Factor Camión (TF): Un proyecto es sostenible si al menos un desarrollador central del "Factor Camión" (un conjunto mínimo de desarrolladores críticos para el mantenimiento del proyecto) permanece activo o es reemplazado exitosamente.

Recopilación de métricas:
Se extrajo un conjunto integral de métricas estáticas y dinámicas utilizando herramientas como Analizo, Lizard, Cloc, scripts personalizados de AST de Clang y gcovr:

Métricas estructurales: Tamaño (LOC, NOM), Complejidad (WMC, AMC, RFC), Cohesión (LCOM4), Acoplamiento (CBO, ACC) y Documentación (Densidad de Comentarios, Líneas de Comentarios).
Métricas de llamadas a funciones: Llamadas de métodos internas vs. externas (NMC, NMCI, NMCE).
Métricas de calidad de pruebas: Porcentajes de cobertura de líneas, ramas y funciones.

Análisis:
El estudio utilizó métodos estadísticos no paramétricos debido a la distribución no normal de los datos. Se empleó la correlación de rangos de Spearman ( $\rho$ ) para evaluar las relaciones entre las métricas estructurales y la cobertura de pruebas. Se utilizaron pruebas U de Mann–Whitney y tamaños del efecto Delta de Cliff para comparar las distribuciones entre los grupos sostenibles e insostenibles. Se realizaron análisis de sensibilidad variando el umbral de frecuencia de confirmaciones ( $k$ ) para probar la robustez de las clasificaciones de sostenibilidad.

Contribuciones y Resultados Clave

1. Hallazgos divergentes basados en el método de clasificación (PQ1)
El estudio encontró que la definición de sostenibilidad impacta significativamente la relación observada entre la calidad del código y las pruebas:

Bajo el criterio t-años: Los proyectos sostenibles exhibieron una cobertura de pruebas significativamente mayor (línea, rama y función) en comparación con los insostenibles. Esto sugiere que el mantenimiento a largo plazo se correlaciona con una inversión constante en la infraestructura de pruebas.
Bajo el criterio TF: La tendencia se invirtió; los proyectos etiquetados como "insostenibles" (debido a la pérdida de desarrolladores clave) mostraron una cobertura de pruebas mediana mayor que los sostenibles. Los autores interpretan esto como un escenario donde un grupo pequeño y concentrado de desarrolladores construyó y probó inicialmente el software exhaustivamente, pero el proyecto carecía del apoyo comunitario más amplio necesario para la evolución a largo plazo.
Patrones de correlación: Los proyectos sostenibles demostraron correlaciones más fuertes y consistentes entre las métricas estructurales y la cobertura de pruebas. Por ejemplo, una mayor complejidad (NMC, NMCE) y una menor cohesión se correlacionaron negativamente con la cobertura en proyectos sostenibles, indicando un claro compromiso. Los proyectos insostenibles mostraron correlaciones débiles o erráticas, lo que sugiere una falta de prácticas de ingeniería disciplinadas.

2. Impacto de umbrales más estrictos (PQ2)
El estudio investigó si refinar la definición de sostenibilidad mejora la fiabilidad de los indicadores de calidad. Al aumentar el umbral de frecuencia de confirmaciones ( $k$ ) desde valores bajos (2–4) hasta valores altos (8–32):

En umbrales más bajos, la distinción entre proyectos sostenibles e insostenibles en cuanto a la cobertura de pruebas fue inconsistente.
A medida que el umbral se volvió más estricto, el patrón se estabilizó: los proyectos verdaderamente activos (alta $k$ ) mostraron consistentemente una cobertura de pruebas mediana más alta, mientras que los proyectos menos activos cayeron a una cobertura cercana a cero.
Esto confirma que las definiciones basadas en actividad más estrictas reducen el ruido en las etiquetas y capturan mejor la disciplina de ingeniería asociada con la sostenibilidad a largo plazo.

3. Relación general entre métricas de código y cobertura de pruebas (PQ3)
En todo el conjunto de datos, la cobertura de pruebas fue generalmente baja (cobertura de líneas mediana ~21%, ramas ~14%).

Complejidad y acoplamiento: Existe una correlación negativa moderada entre la complejidad/acoplamiento estructural (por ejemplo, NMCE, NMC, WMC) y la cobertura de pruebas. Las dependencias externas más altas y la complejidad parecen obstaculizar la capacidad de prueba.
Documentación: Métricas como la Densidad de Comentarios (CD) mostraron ligeras correlaciones positivas con la cobertura, lo que sugiere que una mejor documentación puede facilitar las pruebas, aunque la relación es débil.

Significado y Afirmaciones

El artículo afirma ofrecer un marco práctico y basado en datos para evaluar la sostenibilidad del software científico vinculando la calidad interna del código con la viabilidad a largo plazo. Su significado principal radica en desplazar el enfoque desde indicadores puramente sociales o basados en actividad hacia propiedades estructurales de ingeniería.

Los autores concluyen que:

La cobertura de pruebas por sí sola es insuficiente: Una alta cobertura no garantiza la sostenibilidad si la base de desarrolladores es frágil (como se observa en los resultados de la clasificación TF).
La integridad estructural importa: Los proyectos sostenibles se caracterizan por una relación coherente entre la estructura del código y las pruebas. Tienden a tener mejor documentación, diseños más modulares y prácticas de ingeniería consistentes.
Son necesarias definiciones refinadas: El uso de umbrales más estrictos para la "actividad sostenida" produce distinciones más fiables en la calidad del software, ayudando a identificar proyectos que son genuinamente saludables frente a aquellos que son meramente activos a corto plazo.
Perspectivas accionables: Los hallazgos sugieren que los desarrolladores y las partes interesadas deben monitorear las métricas estructurales (complejidad, acoplamiento) y la documentación como señales de advertencia temprana de una sostenibilidad en declive, en lugar de depender únicamente de los recuentos de confirmaciones o los porcentajes de cobertura.

El estudio reconoce limitaciones, incluido el tamaño pequeño de la muestra (14 proyectos) y la exclusión de proyectos complejos dependientes de hardware, lo cual puede introducir un sesgo de supervivencia. Sin embargo, la instrumentación rigurosa y la pipeline de análisis estandarizada proporcionan una base reproducible para futuras investigaciones sobre las características de ingeniería del software científico sostenible.