Pages Menu
Categories Menu

Posted by on Oct 9, 2013 in General | 3 comments

Cuantitativamente ¿Qué calidad tiene el software libre? Datos de 51 aplicaciones, que pueden ayudarte como referencia

Corría el mes de marzo del 2013, en Móstoles, asignatura Calidad Software del grado de ingeniería del software de la Universidad Rey Juan Carlos, profesor, el que aquí suscribe, cuando se propuso a los alumnos que lo mejor para aprender a evaluar calidad software era evaluar calidad software, y para ello íbamos a evaluar la de los proyectos Java más vistos por aquellas fechas en Github.

Para ello, los alumnos podían utilizar una o varias herramientas de análisis de código (principalmente análisis estático y de caja blanca) tales como PMD, Checkstyle, Sonar, Code Pro Analytics y obtener distintas métricas de los proyectos antes mencionados, sobre todo aquellas que afectan a la mantenibilidad del código. Concretamente, obtuvieron valores de % código repetido, densidad de la complejidad ciclomática, % de cobertura de pruebas unitarias, y número de líneas de código.

Con todo, dado que el trabajo realizado por los alumnos fue de muy alta calidad, sumado a que las aplicaciones evaluadas son de fuentes abiertas más que las páginas de este blog tienen el objetivo de difundir conocimiento de manera abierta, para mejorar la creación de tecnología… he querido compartir contigo los datos.

Datos que son muy interesantes, ya que una de las cosas que más necesitamos en calidad software es ratios de referencia para las métricas y tener los de 51 aplicaciones… puede ayudarte mucho.

Valores de calidad software de 51 aplicaciones de Github

Una de las métricas destacadas del estudio realizado era densidad de complejidad ciclomática. Y los resultados obtenidos fueron los que se adjuntan en la siguiente tabla, ordenados de mayor a menor densidad de la complejidad ciclomática. También podéis ver el porcentaje de código repetido y, si existía o se podía calcular, la cobertura de pruebas unitarias.

Nombre Aplicación y versión

Líneas de Código

Densidad de

Complejidad Ciclomática

% Código

Repetido

CoberturaPruebas
JSON – java 2823 0.395324123273114 0.6% 0%
yuicompressor 5853 0.330428839911157 2.8%
Rhino 56586 0.328385112925459 2.3%
Config-master 8348 0.319597508385242 0.8%
The MongoDB Java driver 2.12.0 16456 0.31951871657754 0.7% 9.8%
aws-sdk-java 331988 0.314701133 11,02%
DiskLruCache 766 0.304177545691906 0% 85.1%
EssentialsProject 573 0.3037 4.54%
Parboiled 7147 0.300125926962362 1.7%
Clojure 37258 0.287106124859091 4.2% 0%
58.com argo version 1.0. 10544 0.286323975720789 2.2% 3.1%
 Retrofit 1.0.0 2056 0.285992217898833 0.9% 61.9%
SlidingMenu-master 2186 0.2813358 30612%
Jna-master 1859 0.2805 1.54% 4.5%
CraftBukkit-master 64454 0.2712632 4,88%
ActionBarSherlock-master 19547 0.2539 118052%
spring-framework 3.2 197163 0.2529227781 1,7
FBReaderJ 52079 0.2469 7.46%
TeleHash 4185 0.2463 0,71%
Bukkit 29610 0.243161094224924 12% 0
erjang 1.1 44649 0.23449 12.41% 0.5%
jsoup 13192 0.2343 2% 1.6%
storm 45288 0.233836777954425 52% 0%
endlessAdapter 177 0.23 9,03%
argoMaster 11220 0.23 7,86%
BuildCraft 32293 0.22791 13.07% 0%
vert.x 15927 0.2261568 12.6%
Twitter4J 31082 0.225 1.32 %
Facebook_Android_SDK 12223 0.2230221713 4,35%
greenDAO – DaoGenerator 1.3 1304 0.22163 3.44% 21.8%
h2o 38804 0.219534068652716 0.65%
stratego_12-2009 4932 0.2183 11.68% 23,50%
Java-WebSocket 5046 0.216 1.8% 8,60%
acra 4657 0.21387 4.87% 0%
elasticsearch-master 209426 0.212929 4.94%
Jedis 13564 0.2114 4.1 %
Android BillingLibrary 1806 0.2048 5.89%
Mustache 6997 0.197 1.15 %
k9mail 52328 0.19423 5.29%
reddit-is-fun 11350 0.1931 0.09% 14.3%
RxJava 9134 0.17999 12.3%
viewserver 584 0.1777 2.05%
Solandra 8123 0.1755 0.59 %
http-request 3591 0.1743 27.59%
Android Master 17476 0.174 7.77%
Voldemort 125616 0.171021207489492 4.82
junit 22451 0.166771190592847 4.28
disruptor 7450 0.137 9,93%
NewQuickAction 590 0.13179 1.3%
REST LI 74623 0.1232 0.62 %
lazylist 460 0.102 0%

Resultados métricas de proyectos más vistos de Github en Java

A partir de ellos concluimos que aunque un programa esté entre los proyectos más vistos de Java en Github, no lleva implícito que tenga una cierta calidad de software.

Algunos proyectos tienen un % de cobertura de pruebas unitarias bastante aceptable o vimos rastros de haber sido analizados con alguna herramienta de análisis (algunos por ejemplo tenían una carpeta .Sonar), denotando una cierta preocupación por controlar la calidad del código, en otros, como en el del proyecto JSON-java, los desarrolladores no se preocuparon demasiado en la calidad de su software, y en la fecha en la que se analizó el estudio, este no tenía ningún caso de prueba programado y el valor de su densidad de la complejidad ciclomática era el mayor de todos.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

3 Comments

  1. Hola,
    ¿Qué valor se debería tomar como límite para la densidad ciclomática? Nosotros tomamos el de 0,3 (aunque creo que somos demasiado generosos.
    Lo mismo para el porcentaje de líneas duplicadas. Nosotros tomamos mayor o igual al 10% como inaceptable de 5% a 10% como malo y menor del 5% como aceptable.
    Las líneas de código en si no es una métrica de calidad quizás sí el nº medio de líneas por metodo u otras similares.
    ¿Cuales son vuestros valores?
    ¿ faltaría alguna métrica importante?¿cuál?

    Un saludo

    • Hola,

      En el estudio, nosotros no establecimos un valor límite de densidad de complejidad ciclomática (que como tal no hay), sino que usamos esa métrica para poder comparar de forma general la complejidad ciclomática de todos los proyectos, independientemente de su tamaño.

      Si en vez de usar la densidad hubiéramos tomado la complejidad ciclomática total de cada proyecto la comparación entre todos ellos no sería objetiva (ya que es normal que un proyecto más grande tenga más cc que uno pequeño.)

      En mi opinión, para mejorar la calidad del código, en vez de fijar un límite para la densidad de la complejidad ciclomática, me centraría más en la complejidad ciclomática de cada método (según Checkstyle si es más de 11 hay que refactorizar).

      Aún así…tampoco creo que sea recomendable quedarse con un límite fijo de complejidad que nunca debería pasar un métododo, sino revisar cada caso concreto.

      Saludos

  2. Hola, muchas gracias por publicar los resultados, son muy interesantes. Me gustaría saber si alguien puede recomendarme un par de buenos libros sobre calidad del software en los que aprender más sobre métricas como la Densidad de
    Complejidad Ciclomática para entender exactamente cada término y aprender a mejorar mi propio software.

    ¡Gracias!

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This