PG_C03_Conclusiones

Conclusiones intervalos de medidas y valores anómalos

Analizar los valores de las medidas (umbrales y anómalos) desglosando por autor/tipo de entidad y por tipo de característica de la entidad de código (tamaño complejidad, herencia...)

Métricas de paquetes

Estas métricas analizan los atributos de los paquetes a nivel general.

NA (Número de atributos): Todos los participantes presentan un intervalo de 0-0, lo que indica que no se han detectado atributos a nivel de paquete.

NCL (Número de clases): Hay cierta variabilidad, con valores que van desde 1 hasta 18.5. Alejandro destaca por tener un número máximo más alto (18.5), lo que sugiere una mayor modularización.

NM (Número de métodos): Intervalos amplios, especialmente en el caso de Andrés (7.75-81.25), lo que puede indicar una mayor complejidad o un sistema con más funcionalidad.

TLOC (Tamaño del paquete): Los valores varían bastante, desde 133344 hasta más de 2 millones, lo cual refleja grandes diferencias en el tamaño del código procesado. Mario y Sofía tienen los paquetes más grandes.

Métricas de clases (Chidamber y Kemerer)

Estas métricas ayudan a evaluar el diseño orientado a objetos.

WMC (Complejidad): Intervalos bajos en general. Andrés muestra el mayor rango (2-15), lo cual puede reflejar una mayor variedad en la complejidad de sus clases.

RFC, CBO: Valores bajos en todos los casos, indicando bajo acoplamiento y menor complejidad en la interacción entre clases.

LCOM5 (Falta de cohesión): Muy bajo (0-2), lo que sugiere buena cohesión interna en las clases.

DIT, NOC: Valores entre 0 y 2 como máximo, lo que refleja jerarquías de herencia poco profundas.

TLOC (Tamaño): Mario y Sofía trabajan con clases significativamente más grandes que los demás.

Tamaño por clases (Lorenz y Kidd)

Se analiza el tamaño estructural de las clases.

NA (Número de atributos): Todos tienen 0-0, lo que concuerda con lo observado en paquetes.

NM (Número de métodos): Intervalos más amplios para Sofía (2-15), indicando que algunas clases pueden tener mayor funcionalidad.

NOS (Número de sentencias): Los valores varían de forma moderada. Andrés tiene el rango más alto (2-39), lo que puede indicar clases más densas o con mayor lógica.

TLOC: Mario y Sofía repiten con los valores más altos, reflejando clases más extensas.

Métricas de métodos

Estas métricas reflejan la complejidad de los métodos individuales.

McCC (Complejidad ciclomática): Sorprendentemente todos tienen 0-0, lo cual puede indicar que los métodos analizados están extremadamente simplificados o que no se ha detectado bien esta métrica.

TLOC: Mario y Sofía tienen los métodos más grandes por líneas de código, lo que puede asociarse a mayor complejidad o funcionalidad por método.

Conclusión de general convergencia

• ¿Convergen los estadísticos Q1 y Q3 en los diferentes proyectos seleccionados? ¿Ocurre lo mismo con la media aritmética y la mediana?

No necesariamente. Aunque los intervalos de Q1 y Q3 pueden mostrar cierta similitud en algunas métricas (como en CBO o DIT, que presentan rangos pequeños), en otras como NM (número de métodos) o TLOC (tamaño del código) hay una gran dispersión entre proyectos, lo que indica diferencias significativas en estructura y complejidad.

Con respecto a la media y la mediana, pueden diferir considerablemente cuando hay valores atípicos. Por ejemplo, si un proyecto tiene una clase o método mucho más grande que los demás, la media se verá más afectada que la mediana. Por tanto, la mediana suele ser más robusta en este tipo de análisis, especialmente cuando hay mucha variabilidad entre proyectos.

• ¿Es posible la evaluación automatizada de un proyecto a través de valores estadísticos de sus métricas?

Sí, es posible una evaluación automatizada basada en métricas estadísticas, especialmente si se establecen umbrales o patrones típicos de calidad. Herramientas de análisis estático pueden recoger estas métricas automáticamente, y comparar los resultados con valores de referencia (como los percentiles) permite identificar proyectos con posibles problemas (clases muy grandes, alta complejidad, acoplamiento excesivo...).

Sin embargo, la evaluación automatizada debe complementarse con juicio humano, ya que métricas similares pueden tener significados distintos según el contexto del proyecto o del dominio.

• ¿Los valores de las métricas pueden depender de los tipos de software?

Totalmente. El tipo de software (web, embebido, empresarial, móvil...) condiciona su arquitectura y, por tanto, sus métricas:

Un software modular y extensible puede tener muchas clases pero con bajo acoplamiento.

En cambio, un programa embebido puede concentrar mucha funcionalidad en pocas clases o métodos.

Los frameworks también afectan: por ejemplo, usar Spring o Django puede implicar muchas anotaciones y estructuras predefinidas.

Por tanto, no es adecuado aplicar los mismos umbrales a todo tipo de proyectos sin contextualizarlos.

• ¿El proceso puede influir en la calidad del producto? ¿Crees que sería interesante añadir al estudio métricas de proceso? ¿Cuáles?

Sí, el proceso de desarrollo tiene un impacto directo en la calidad del software. Un proceso ágil con revisiones frecuentes, integración continua y pruebas automatizadas suele producir software más robusto y mantenible.

Sería muy interesante incluir métricas de proceso como:

Número de commits por desarrollador (actividad).

Frecuencia de commits (flujo de trabajo).

Número de issues abiertos/cerrados (gestión de tareas).

Cobertura de tests automatizados.

Tiempo medio de resolución de bugs.

Historial de revisiones por archivo/clase (podría correlacionar con complejidad o deuda técnica).

Estas métricas ayudarían a correlacionar la calidad del producto con el comportamiento del equipo de desarrollo.