Métricas de Legibilidad Del Software

Métricas de legibilidad del software:
Una revisión sistemática de literatura
Ingrid Sofia Echavarría Flórez
Universidad Nacional de Colombia

Facultad de Ingeniería, Maestría en Ingeniería -Ingeniería de Sistemas y Computación -
Convenio Unillanos
Bogotá, Colombia
2020
2 Métricas de legibilidad del software: una revisión sistemática de literatura
Métricas de legibilidad del software:

una revisión sistemática de literatura
Ingrid Sofía Echavarría Flórez
Trabajo final de maestría presentado como requisito para optar al título de:
Magíster en Ingeniería - Ingeniería de Sistemas y Computación
Director:
Felipe Restrepo Calle, PhD.
Línea de Investigación:
Ingeniería de Software
Grupo de Investigación:
PLaS - Programming Languages and Systems
Universidad Nacional de Colombia

Facultad de Ingeniería
Maestría en Ingeniería - Ingeniería de Sistemas y Computación
Bogotá, Colombia
2020
Dedicatoria 3
Dedicatoria
Dedico este trabajo a mi hija Julieta, quien

inspira y alegra mis días, y a quien deseo inculcar con
mi ejemplo la importancia de continuar el proceso de
educación.
A mi mamá Yolanda y a mi tía Ruth por

brindarme siempre su apoyo incondicional, lo cual me
permitió culminar exitosamente mi maestría.
Agradecimientos
Hago un especial agradecimiento a mi director del trabajo de grado, el ingeniero PhD Felipe
Restrepo, docente de la Universidad Nacional de Colombia, quien me acompañó y guio en
todo el proceso de desarrollo de la propuesta y el trabajo final.
Gracias a la Doctora en Ingeniería Diana Marcela Cardona, quien me brindó asesoría y

acompañamiento en el desarrollo de mi propuesta y trabajo final de maestría.
A mis compañeros de curso y los docentes, con los cuales, no sólo compartí estos dos años
de estudio, sino de quienes aprendí muchas cosas, que me servirán en mi vida profesional
y personal.
Resumen 5
Resumen
La calidad del software es un aspecto importante, principalmente por su relación con los
costos futuros asociados al mantenimiento del producto. Para poder cuantificar la calidad,
se utilizan las métricas de calidad de software, las cuales son un conjunto de medidas
utilizadas para estimar la calidad de un proyecto de software. Teniendo en cuenta que la
calidad del software debe evaluar varios aspectos, y que debe ser medida de la misma
forma para todos, se han creado normas que brindan una guía del proceso a realizar. Al
año 2019, la norma que se encuentra en vigencia es la familia de normas ISO/IEC 25000,
cuyo objetivo es crear un marco de trabajo común para evaluar la calidad de un producto
de software teniendo en cuenta 8 características: adecuación funcional, rendimiento,
compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. La
característica de mantenibilidad, tiene un alto impacto sobre los costos totales de los
proyectos de software, consumiendo entre 40% y 80% del costo total del ciclo de vida de
un producto de software. Adicionalmente, dentro de la labor de mantenimiento, los
desarrolladores gastan aproximadamente 70% del tiempo tratando de comprender el código
fuente, por lo que poder medir la legibilidad de un fragmento de código, podría ayudar a
estimar el esfuerzo requerido para una actividad de mantenimiento. La legibilidad
(readability en inglés) del software, es definida como el grado de facilidad con la que una
persona puede leer y comprender un fragmento de código fuente, escrito por otra persona.
A pesar de los esfuerzos e investigaciones en el área de legibilidad del software, aún no se

tiene un modelo definitivo que permita evaluar el nivel de legibilidad de un fragmento de
código fuente en tiempo real. Por ello, es indispensable dar continuidad a las
investigaciones en el área, pero para ello, es necesario conocer los estudios que existen
hasta la fecha sobre la legibilidad del software, identificando las características y métricas
propuestas para medirla, los modelos que permiten la evaluación automática, las
aplicaciones que tienen en el área del software y los retos que deben afrontar los futuros
investigadores.
Este trabajo final de maestría presenta una síntesis y análisis de las métricas de legibilidad
de software. Para esto, se realizó una revisión sistemática de la literatura de trabajos
relacionados con la legibilidad del código fuente, presentando una recopilación de las
características principales y los métodos utilizados para su medición. El resultado de este
trabajo pretende servir como base para que otros investigadores puedan proponer nuevas
métricas de legibilidad, y posteriormente, puedan desarrollar estrategias que sean
integradas a los entornos integrados de desarrollo (IDEs) para medir y alertar sobre la
legibilidad del código fuente en tiempo de desarrollo.
Palabras clave: Métrica; Legibilidad; Código fuente; Software; Calidad; Clasificación;

Revisión sistemática de literatura.
Abstract 7
Abstract
The quality of the software is an important aspect, mainly due to its relation to the future
costs associated with the maintenance of the product. In order to quantify the quality,
software quality metrics are used, which are a set of measures used to estimate the quality
of a software project. Taking into account that the quality of the software must evaluate
several aspects, and that it must be measured in the same way for all, standards have been
created that provide a guide to the process to be carried out. As of 2019, the standard that
is the family of ISO/IEC 25000 standards, whose objective is to create a common framework
to assess the quality of a software product considering 8 characteristics: functional
adequacy, performance, compatibility, usability, reliability, security, maintainability, and
portability. The maintainability feature has a high impact on the total costs of software
projects, consuming between 40% and 80% of the total cost of the life cycle of a software
product. Additionally, within the Maintenance work, developers spend approximately 70% of
the time trying to understand the source code, so being able to measure the readability of a
code snippet could help estimate the effort required for a maintenance activity. The
readability of software is defined as the degree of ease with which a person can read and
understand a piece of source code, written by another person.
Despite the efforts and research in the area of readability of the software, there is still no
definitive model to assess the level of readability of a fragment of source code in real time.
Therefore, it is essential to continue research in the area, but for this, it is necessary to know
the studies that exist to date on the legibility of software, identifying the characteristics and
metrics proposed to measure it, the models that allow automatic evaluation, the applications
they have in the area of software and the challenges that future researchers must face.
This final master's work presents a synthesis and analysis of software readability metrics.
For this, a systematic review of the literature of works related to the readability of the source
code was carried out, presenting a compilation of the main characteristics and the methods
used for its measurement. The result of this work aims to serve as a basis for other
researchers to propose new readability metrics, and subsequently, to develop strategies that
are integrated into integrated development environments (IDEs) to measure and alert on the
readability of the source code in time developmental.
Keywords:
Metric; Readability; Source code; Software; Quality; Classification; Systematic review of
literature.
Contenido 9
Contenido
Pág.
Lista de figuras ................................................................................................................ 12
Lista de tablas ................................................................................................................. 13
1. Capítulo 1. Introducción............................................................................................ 15
1.1. Motivación .......................................................................................................... 15
1.2. Definición del problema ...................................................................................... 17
1.3. Pregunta de investigación .................................................................................. 18
1.4. Objetivos ............................................................................................................ 18
1.4.1. Objetivo general............................................................................................. 18
1.4.2. Objetivos específicos ..................................................................................... 19
1.5. Metodología ....................................................................................................... 19
1.5.1. Tipo de investigación ..................................................................................... 19
1.5.2. Estrategia de investigación ............................................................................ 19
1.5.3. Diseño de investigación ................................................................................. 20
1.5.4. Métodos de investigación .............................................................................. 20
1.6. Alcance del trabajo ............................................................................................. 20
1.7. Estructura del trabajo final .................................................................................. 21
2. Capítulo 2. Contexto: calidad y legibilidad del software ............................................ 22

2.1 Calidad del software ........................................................................................... 22
2.2 Mantenibilidad del software ................................................................................ 23
2.3 Métricas de calidad en productos de software .................................................... 24
Figura 1: Clasificación de las métricas de software. ............................................... 25
Figura 2. Clasificación de las métricas de calidad de un producto de software. ..... 26
Figura 3. Pasos para realizar la medición de una métrica de calidad de software. . 27
2.4 Legibilidad del software ...................................................................................... 28
2.5 Estándares de calidad del software .................................................................... 29
Figura 4. Línea de tiempo de los modelos y estándares de calidad aplicados a
productos de software. Fuente: ilustración propia elaborada con los datos de la
fuente [15].............................................................................................................. 31
2.6 Resumen del capítulo ......................................................................................... 34
3. Capítulo 3. Revisión sistemática de literatura de métricas de legibilidad del software36

3.1 Revisión sistemática de literatura ....................................................................... 36
Figura 5. Fases de trabajo de la RSL para las métricas de legibilidad. .................. 37
3.1.1 Fase 1: Estrategia de búsqueda .................................................................... 37
3.1.2 Fase 2: Recolección de documentos ............................................................. 38
3.1.3 Fase 3: Revisión de resultados de la búsqueda ............................................. 39
3.1.4 Fase 4: Análisis y presentación de resultados ............................................... 39
3.1.5 Fase 5: Monitoreo .......................................................................................... 40
3.2 Palabras clave .................................................................................................... 40
3.3 Fuentes bibliográficas ........................................................................................ 41
3.4 Ecuaciones de búsqueda ................................................................................... 42
3.5 Criterios de inclusión .......................................................................................... 43
3.6 Criterios de exclusión ......................................................................................... 43

3.7 Lista de chequeo ................................................................................................ 44
Figura 6. Formato de evaluación de la calidad del estudio. .................................... 45
3.8 Gestión bibliográfica ........................................................................................... 46
Figura 7. Imagen de la herramienta de gestión bibliográfica Mendeley con las
carpetas. ................................................................................................................ 47
3.9 Preguntas orientadoras ...................................................................................... 48
3.10 Formulario de extracción de datos ..................................................................... 48
Figura 8. Hoja de cálculo utilizada para la extracción de datos de todos los
documentos. .......................................................................................................... 49
Figura 9. Archivo de texto utilizado para la extracción de datos de cada documento.
.............................................................................................................................. 52
3.11 Resumen del proceso de la RSL ........................................................................ 53
Figura 10. Documentos finales clasificados por año de publicación. ...................... 59
Figura 11. Nube de palabras representando la frecuencia de los autores en los
estudios seleccionados. Fuente: Herramienta SASR ............................................. 60
Figura 12. Nube que representa la frecuencia de las palabras clave en los estudios
seleccionados. Fuente: herramienta SASR. ........................................................... 61
4. Capítulo 4. Características y métricas de legibilidad del software ............................. 66

4.1 Características para medir la legibilidad del código fuente ................................. 66
4.2 Métricas de legibilidad del software .................................................................... 74
5 Capítulo 5. Modelos de legibilidad del software ........................................................ 84

5.1 Evolución de la legibilidad del software .............................................................. 84
5.2 Modelos de legibilidad del software .................................................................... 88
Figura 13. Evolución de los modelos de legibilidad del software. ........................... 89
Figura 14. Descripción del proceso realizado para desarrollar un modelo de
legibilidad enfocado a las características. .............................................................. 95
Figura 15. Descripción del proceso realizado en el modelo de legibilidad de Choi et
al............................................................................................................................ 96
Figura 16. Descripción del proceso realizado en el modelo de legibilidad DeepCRM
con ConvNets de Mi et al. ...................................................................................... 97
5.3 Métodos y técnicas utilizadas en los modelos .................................................... 99
5.4 Lenguajes de programación evaluados y participantes .................................... 101
5.5 Características y métricas propuestas .............................................................. 104
5.6 Recursos disponibles ....................................................................................... 107
5.6.1 Datasets: Fragmentos de código fuente ....................................................... 108
5.6.2 Herramientas ................................................................................................ 108
5.6.3 Documentación ............................................................................................. 109
5.7 Resumen del capítulo ....................................................................................... 110
6 Capítulo 6. Retos y aplicaciones de la legibilidad del software ............................... 113

6.1 Aplicaciones de interés .................................................................................... 113
6.1.1 Enseñanza de la legibilidad del software desde las instituciones de educación
superior ..................................................................................................................... 115
Figura 17. Proceso de aprendizaje iterativo de Chen. .......................................... 117
6.1.2 Buenas prácticas de la legibilidad del software ............................................. 117
Contenido 11
6.2 Retos................................................................................................................ 121

6.3 Resumen del capítulo ....................................................................................... 123
7 Capítulo 7. Conclusiones y recomendaciones ........................................................ 125

7.1 Conclusiones.................................................................................................... 125
7.2 Recomendaciones............................................................................................ 126
Referencias 128
Lista de figuras
Pág.
Figura 1: Clasificación de las métricas de software. ........................................................ 25
Figura 2. Clasificación de las métricas de calidad de un producto de software. ............... 26
Figura 3. Pasos para realizar la medición de una métrica de calidad de software. .......... 27
Figura 4. Línea de tiempo de los modelos y estándares de calidad aplicados a productos

de software. Fuente: ilustración propia elaborada con los datos de la fuente [15]. .......... 31
Figura 5. Fases de trabajo de la RSL para las métricas de legibilidad. ............................ 37
Figura 6. Formato de evaluación de la calidad del estudio. ............................................. 45
Figura 7. Imagen de la herramienta de gestión bibliográfica Mendeley con las carpetas. 47
Figura 8. Hoja de cálculo utilizada para la extracción de datos de todos los documentos.49
Figura 9. Archivo de texto utilizado para la extracción de datos de cada documento. ..... 52
Figura 10. Documentos finales clasificados por año de publicación. ............................... 59
Figura 11. Nube de palabras representando la frecuencia de los autores en los estudios
seleccionados. Fuente: Herramienta SASR..................................................................... 60
seleccionados. Fuente: herramienta SASR. .................................................................... 61
Figura 13. Evolución de los modelos de legibilidad del software. .................................... 89
Figura 14. Descripción del proceso realizado para desarrollar un modelo de legibilidad
enfocado a las características. ........................................................................................ 95
Figura 15. Descripción del proceso realizado en el modelo de legibilidad de Choi et al... 96
Figura 16. Descripción del proceso realizado en el modelo de legibilidad DeepCRM con
ConvNets de Mi et al. ...................................................................................................... 97
Figura 17. Proceso de aprendizaje iterativo de Chen. ................................................... 117

Lista de tablas 13
Lista de tablas
Pág.
Tabla 1. Definición de modelos y estándares de calidad de software. ............................. 30
Tabla 2. Descripción de los modelos/estándares de calidad de software. ....................... 31
Tabla 3. Listado de palabras clave. ................................................................................. 40
Tabla 4. Listado de palabras clave descartadas. ............................................................. 41
Tabla 5. Factores evaluados en la lista de chequeo. ....................................................... 45
Tabla 6. Detalle del formato de extracción de datos. ....................................................... 49
Tabla 7. Ecuaciones de búsqueda utilizadas para la recolección. ................................... 53
Tabla 8. Parametrización adicional realizada en las fuentes bibliográficas. ..................... 53
Tabla 9. Resultados cuantitativos de la RSL. .................................................................. 54
Tabla 10. Resultados cuantitativos de la RSL. Parte 2. ................................................... 55
Tabla 11. Cantidad total de documentos seleccionados. ................................................. 55
Tabla 12. Listado de estudios seleccionados en la RSL. ................................................. 56
Tabla 13. Clasificación de los aportes encontrados en los estudios. ............................... 61
Tabla 14. Listado general ordenado de características de legibilidad del software. ......... 67
Tabla 15. Lenguajes de programación recomendados de acuerdo al dominio de la

aplicación (de acuerdo a Akour et al [14] en 2016). ......................................................... 73
Tabla 16. Listado de métricas simples en Java. .............................................................. 74
Tabla 17. Listado de métricas en C y C++, de la fuente [37]............................................ 74
Tabla 18. Listado de métricas compuestas...................................................................... 75
Tabla 19. Aportes a los estudios de legibilidad del software en el tiempo. ....................... 85
Tabla 20: Modelos de legibilidad del software. ................................................................ 90
Tabla 21. Técnicas utilizadas en las investigaciones para medir la legibilidad en el

software. ................................................................................................................... 99
Tabla 22. Detalle de los fragmentos de código fuente utilizados en los modelos de
legibilidad del software. ................................................................................................. 101
Tabla 23. Lenguajes de programación utilizados en otros experimentos de legibilidad del

software. ................................................................................................................. 103
Tabla 24. Representación de la importancia de cada característica. ............................. 104
Tabla 25. Características que permiten medir la legibilidad del software. ...................... 105
Tabla 26. Repositorios que contienen fragmentos de código fuente. ............................. 108
Tabla 27. Repositorios que contienen herramientas libres o propias utilizadas en los
estudios. ................................................................................................................. 108
Tabla 28. Repositorios que contienen documentos de interés. ...................................... 110
Tabla 29. Aplicaciones identificadas en la literatura para la legibilidad del software. ..... 113
Tabla 30. Lista compilada de buenas prácticas en la escritura de código fuente. Fuente
principal: Sampaio y Barbosa (2016) [43]. ..................................................................... 118
Tabla 31. Buenas prácticas para el lenguaje WSDL. Obtenido de la fuente [29]. .......... 120
Tabla 32. Lista compilada de malas prácticas en la escritura de código fuente. Fuente
principal: Sampaio y Barbosa (2016) [43]. ..................................................................... 120
Tabla 33. Guía de estilo recomendada para los identificadores. Obtenida de la fuente [20].
................................................................................................................. 121
Tabla 34. Retos identificados para los trabajos futuros de legibilidad del software. ....... 122
Capítulo 1. Introducción 15
1. Capítulo 1. Introducción
En este capítulo se presenta la motivación general del proyecto. Posteriormente, se expone
el problema identificado en el área de métricas de legibilidad del código fuente, lo que llevó
a realizar una revisión sistemática de literatura. También, se presentan los objetivos del
proyecto y las preguntas de investigación planteadas en la propuesta. Por último, se
presenta la descripción de la metodología utilizada en la investigación.
1.1. Motivación
La calidad en los productos de software es de gran importancia para los desarrolladores y
empresarios de esa industria, principalmente por los altos costos que implica modificar un
programa si es de baja calidad [1]. Pese a que algunos programadores desarrollan software
mediante un método ordenado y eficiente conseguido gracias a años de experiencia,
muchos otros desarrollan malos hábitos que dan como resultado una pobre calidad y
mantenibilidad del software [2].
Entre las características implícitas de la calidad del software se encuentra la mantenibilidad

[2], la cual se define como la facilidad con la que se modifica, mejora y/o adapta un producto
de software [3]. La mantenibilidad es de gran interés para las personas y empresas
involucradas con la industria de software, tales como clientes, desarrolladores, instituciones
académicas y organizaciones dedicadas a la estandarización, quienes aseguran que es uno
de los aspectos determinantes de la calidad de un producto de software, debido al fuerte
impacto que tiene sobre los costos totales de los proyectos de software [4]. Los costos en
la fase de mantenimiento pueden consumir entre 40% y 80% del costo total del ciclo de vida
de un producto de software [5][1], y por ello se dice que los desarrolladores gastan más
tiempo manteniendo y arreglando software existente que escribiendo nuevo código [6].
Adicionalmente, dentro de la labor de mantenimiento, según estudios, los desarrolladores

gastan aproximadamente 70% del tiempo tratando de comprender el código fuente, por lo
que poder medir la legibilidad de un fragmento de código, podría ser útil a la hora de estimar
el esfuerzo requerido para una actividad de mantenimiento [7].
A la fecha del presente documento, se encuentra en vigencia la familia de normas ISO/IEC

25000, cuyo objetivo es crear un marco de trabajo común para evaluar la calidad de un
producto de software teniendo en cuenta 8 características: adecuación funcional,
rendimiento, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad
[8]. Para la característica de mantenibilidad, se tienen en cuenta a su vez varios aspectos,
entre los cuales se encuentran las métricas de legibilidad de código fuente.
Barrio [9] definió la legibilidad, en general, como el conjunto de características tipográficas

y lingüísticas del texto escrito que permiten leerlo y comprenderlo con facilidad. La
legibilidad tipográfica es la que considera el diseño y disposición espacial de los caracteres
gráficos del texto; mientras que la legibilidad lingüística es la que viene condicionada por la
estructura lingüística del propio texto [9]. En el campo de la ingeniería del software, Knuth
en 1984 [6] vio la legibilidad como esencial para su noción de "Literate Programming",
argumentando que un programa debería ser visto como "una pieza de literatura, dirigida a
los seres humanos" y que un programa legible es "más robusto, más portable y más fácil
de mantener". La legibilidad (readability, en inglés) del software se entiende como la
facilidad en la que su código fuente es comprendido; es un factor de la mantenibilidad, y a
la vez, tiene un papel fundamental en la calidad del producto de software. El código que
sea legible hoy, probablemente podrá leerse, comprenderse y mantenerse más fácilmente
en el futuro [10].
La legibilidad puede cuantificarse mediante las métricas de legibilidad, las cuales están bien
establecidas en el dominio del lenguaje natural, mientras que, en el dominio del software,
están bien establecidas en dominios particulares como el hipertexto [6]. Resulta importante
poder identificar con precisión las métricas determinantes en la legibilidad del software para
poder automatizar el proceso de medición [1]. Para los gerentes de proyectos de software,
conocer estas métricas les ayudaría a monitorear y mantener la legibilidad, contribuyendo
así a que el producto final sea de alta calidad [1]. Asimismo, los programadores podrían
tener una cuantificación de la legibilidad del código fuente en tiempo real, de la misma
forma, como hoy en día los IDE1 informan los errores de sintaxis [10], lo que les permitiría
realizar los ajustes de forma temprana. No obstante, la legibilidad es una propiedad
subjetiva [10], y aunque se han logrado avances significativos, aún no se tiene un modelo
definitivo que permita una medida 100% precisa. Adicionalmente, algunos autores como
Mannan et al. (2018), argumentan que los modelos de legibilidad propuestos presentan
deficiencias y por ello es necesario continuar con las investigaciones para identificar
mejores métricas para evaluar la legibilidad del software [11].
Este trabajo final de maestría consistió en realizar una revisión sistemática de literatura
sobre los trabajos relacionados con métricas de legibilidad de código fuente, con el objetivo
de presentar una recopilación de los modelos, métricas y algoritmos existentes. El resultado
de este trabajo pretende servir de base para otros trabajos de investigación en el área, y
así, posteriormente se puedan proponer estrategias y desarrollar herramientas que
permitan medir la legibilidad del código fuente de forma automática y efectiva durante la
etapa del desarrollo del software. Esto permitiría que los programadores puedan tomar
correctivos a tiempo, lo que en el futuro permitirá la reducción de los costos asociados al
ciclo de vida del software.
1.2. Definición del problema

A pesar de los esfuerzos e investigaciones en el área de legibilidad del software, aún no se
cuenta con un modelo definitivo que permita determinar el nivel de legibilidad de un
fragmento de código fuente, como lo manifiestan los autores de los estudios
[1][7][10][6][11][3] quienes consideran necesario continuar con las investigaciones en el
área, buscando mejores métricas que permitan medir la legibilidad del software. En otras
palabras, es necesario determinar las características que permiten a un desarrollador de
software, decidir si un código fuente es o no legible [7]. Algunos de estos factores están
relacionados a las construcciones semánticas y sintácticas del programa, además de otros
factores externos posiblemente como, por ejemplo: la experiencia previa del desarrollador
1IDE significa entorno de desarrollo integrado, por sus siglas en inglés IDE de Integrated
Development Environment.
en el lenguaje de programación, conocimientos previos, costumbres, cultura y preferencias

[12].
Por otra parte, hasta donde sabemos, no existe una única fuente que recopile los estudios
asociados a las métricas de legibilidad del software, abarcando los conceptos
fundamentales, los modelos automatizados propuestos para su medición, las
características y las métricas. Por lo anterior, es necesario identificar este tipo de
características mediante un análisis detallado y sistemático de los trabajos relacionados
con la medición de la legibilidad en el software, brindando así un documento que sirva como
base para futuras investigaciones sobre el tema.
1.3. Pregunta de investigación

¿Cuáles son las características de las métricas que existen en la literatura para medir la
legibilidad del software y cómo pueden ser aplicadas? En particular, resulta pertinente
conocer los siguientes aspectos acerca de las métricas:
RQ1. ¿Cuáles son las características que permiten medir la legibilidad del código fuente de
un software?
RQ2. ¿Qué métodos son utilizados para obtener el valor de medida de cada una de esas
métricas de forma automática?
RQ3. ¿Cuáles son los principales retos y aplicaciones de interés en las investigaciones
relacionadas con la legibilidad del software?
1.4. Objetivos
1.4.1. Objetivo general

Analizar las métricas utilizadas en la medición de la legibilidad del software estableciendo
su evolución, las características utilizadas para su medición, los métodos automáticos de
medición, los retos actuales y las aplicaciones de interés en las investigaciones
relacionadas, a través de una revisión sistemática de la literatura.
1.4.2. Objetivos específicos

1) Definir la estrategia de búsqueda acerca de las métricas de legibilidad del software.
2) Sintetizar los resultados en términos de la evolución de las métricas de legibilidad
del software, las características utilizadas para su medición y los métodos automáticos de
medición.
3) Identificar los retos actuales y las aplicaciones de interés para la comunidad
científica en el área.
1.5. Metodología
1.5.1. Tipo de investigación

El tipo de investigación utilizado fue el descriptivo, el cual describe los hechos como son
observados. Para el caso de esta propuesta, la observación se realizó sobre la literatura
disponible en las bases de datos bibliográficas Scopus, IEEE Explore, ACM, Google Scholar
y Web of Science, mediante una revisión sistemática de la literatura (RSL2), buscando los
trabajos relacionados con la legibilidad del software para extraer los datos de interés.
1.5.2. Estrategia de investigación

La estrategia de investigación que se utilizó fue la cuantitativa, porque se buscó en la
literatura los trabajos relacionados con la legibilidad del código fuente, para posteriormente
analizar los datos, interpretarlos y sintetizarlos. La investigación se realizó utilizando la
revisión sistemática literatura [13], porque ésta permite desarrollar una síntesis de la
evidencia disponible. En el capítulo 3, sección 3.1 se explica en detalle en que consiste la
revisión sistemática de literatura y cómo fue aplicada a este trabajo.
2 RSL significa revisión sistemática de literatura, por sus siglas.

1.5.3. Diseño de investigación

El diseño de investigación utilizado fue el no experimental, porque se observaron los
trabajos relacionados con la legibilidad del código fuente y mediante la aplicación de una
RSL se analizaron los datos obtenidos, sin manipular ningún tipo de variable.
1.5.4. Métodos de investigación

Se usaron los siguientes métodos cuantitativos:
▪ Recolección de datos: mediante una revisión sistemática de literatura se obtuvieron los
trabajos relacionados al tema de estudio, que contenían información sobre los modelos
propuestos de legibilidad, los fragmentos de código fuente usados para el
entrenamiento y prueba de los modelos, información sobre las características
propuestas y los métodos implementados.
▪ Análisis de datos: se realizó un análisis de texto y de contenido, para clasificar los datos
de interés.
▪ Interpretación de los datos.
▪ Escritura: Se realizó el procedimiento de sintetizar la información para presentarla de
forma adecuada a los lectores.
1.6. Alcance del trabajo

Este trabajo final de maestría realizó una revisión sistemática de literatura, siguiendo los
lineamientos de Kitchenham et al. (2008) [13], buscando y recopilando trabajos de
investigación relacionados con las métricas de legibilidad del código fuente, entre el 1 de
enero del año 2015 y el 23 de abril del año 2019, los cuales, permitieron responder las
preguntas de investigación planteadas. El resultado final de la revisión sistemática de
literatura fue este documento, donde se sintetizaron de forma cualitativa y cuantitativa, la
información extraída de los documentos, presentando las características evaluadas en la
legibilidad del código fuente, los modelos propuestos para su medición, las métricas, las
aplicaciones y los retos planteados por los autores.
1.7. Estructura del trabajo final

En este documento se presentan los resultados de una revisión sistemática de literatura
desarrollada en el tema de las métricas de legibilidad del código fuente, con un total de 7
capítulos organizados de la siguiente forma: en el capítulo 1 se presenta la importancia del
trabajo, la definición del problema, las preguntas de investigación y los objetivos planteados
al inicio de la investigación; en el capítulo 2 se presenta el contexto de la investigación,
mostrando la descripción de los diferentes conceptos involucrados en el tema de las
métricas de legibilidad del código fuente; en el capítulo 3 se detalla la estrategia de
búsqueda desarrollada, la cual sigue los lineamientos de Kitchenham et al. (2008) [13] para
la revisión sistemática de literatura, presentando los resultados obtenidos en cada una de
las fases; el capítulo 4, expone los modelos de legibilidad del software, los aportes sobre el
tema que se han realizado a lo largo del tiempo, así como los datos y herramientas
disponibles para su replicación; el capítulo 5 reúne las características y las métricas
propuestas en la literatura para medir la legibilidad del software; el capítulo 6 presenta los
retos que deben afrontar los investigadores para continuar avanzando en la búsqueda y
definición de las métricas de legibilidad del software, así como las diversas aplicaciones en
las que se está utilizando; finalmente, en el capítulo 7 se exponen las conclusiones
generales y las recomendaciones para trabajos futuros.
2. Capítulo 2. Contexto: calidad y legibilidad

del software
En este capítulo se presentan los conceptos relacionados con la legibilidad del código
fuente. Para ello, se organizan los temas desde lo general hasta lo particular, iniciando con
la calidad del software, pasando por la mantenibilidad, las métricas de calidad, hasta llegar
a la legibilidad del código fuente. Adicionalmente, se presenta una sección con los
estándares que rigen a la calidad del software.
2.1 Calidad del software

Pressman (1977) definió la calidad de software como la “concordancia con los requisitos
funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente" [2]. De acuerdo con esa definición se identifican
tres puntos:
1. Los requisitos funcionales del software son la base de las medidas de la calidad y por
ello deben estar reflejados en el producto [2].
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían
la forma en que se aplica la ingeniería de software. Si no se siguen esos criterios, casi
siempre habrá falta de calidad [2].
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por
ejemplo, el deseo de un buen mantenimiento). Si el software se ajusta a sus requisitos
explícitos, pero falla en alcanzar los requisitos implícitos, su calidad queda en duda [2].
La calidad de un producto de software se puede ver afectada por algunos factores, los
cuales fueron clasificados en 1977 por McCall [2] teniendo en cuenta tres aspectos
Capítulo 2. Contexto 23
importantes en la calidad de un producto de software, tales como sus características

operativas, su capacidad de soportar los cambios y su adaptabilidad de nuevos entornos.
McCall definió las siguientes dos categorías de factores que afectan la calidad de un
producto de software [2]:
1) Factores que pueden ser medidos directamente: como los errores, LOC (Líneas de
código) y las unidades de tiempo.
2) Factores que sólo pueden ser medidos indirectamente: como la facilidad de uso o de
mantenimiento.
La calidad de un producto de software evalúa el grado de cumplimiento y satisfacción en

el cual el producto cumple con los requisitos de los usuarios. La familia de normas ISO/IEC
250003, define que el modelo de calidad de un producto de software se encuentra
compuesto por 8 características, que representan los requisitos de los usuarios, las cuales
son: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad,
seguridad, portabilidad y mantenibilidad.
En el 2014, Ming-Chang investigó los factores de la calidad del software y las métricas de
calidad del software que permiten mejorar la calidad del software [14]. Su trabajo demostró
que la legibilidad del software, la cual es un factor importante de la mantenibilidad,
desempeña un papel crucial en el aumento de la calidad del software [14].
2.2 Mantenibilidad del software

El mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las
adaptaciones requeridas por la evolución del entorno del software y a las modificaciones
debidas a los cambios de los requisitos del cliente dirigidos a reforzar o ampliar el sistema
[2]. En la familia de normas ISO/IEC 25000, las cuales crean un marco de trabajo para
evaluar la calidad de un producto de software, definen la mantenibilidad, como la capacidad
que tiene un producto de software para ser modificado efectiva y eficientemente, debido a
necesidades evolutivas, correctivas o perfectivas [3]. De acuerdo a lo anterior, se
identifican tres tipos o razones para realizar un mantenimiento:
3
https://iso25000.com/index.php/normas-iso-25000
1) Corrección: Es muy probable que el cliente descubra defectos en el software,

aunque se hayan llevado a cabo las mejores actividades de aseguramiento de la
calidad. El mantenimiento correctivo cambia el software para corregir los defectos
[2][3].
2) Adaptación: Con el paso del tiempo es probable que cambie el entorno original
(por ejemplo, los requisitos de la aplicación, el CPU, el sistema operativo, los
periféricos) para el cual se desarrolló el software. El mantenimiento adaptativo
consiste en modificar el software para acomodarlo a los cambios de su entorno
externo [2][3].
3) Mejora. Conforme utilice el software, el cliente/usuario puede descubrir

funciones adicionales que pudieran interesarle que estuvieran incorporadas en el
software. El mantenimiento perfectivo amplía el software más allá de sus requisitos
funcionales originales [2][3].
La familia de normas ISO/IEC 25000, define que el modelo de calidad de un producto de

software se encuentra compuesto por 8 características, entre las cuales se encuentra la
mantenibilidad. La mantenibilidad a su vez está compuesta de las siguientes sub-
características: modularidad, reusabilidad, analizabilidad, capacidad para ser modificado y
capacidad para ser probado. Para las anteriores sub categorías, y más para la
analizabilidad y la capacidad para ser modificado, es muy importante la legibilidad porque
permitirá que las tareas de mantenimiento consuman menos tiempo, lo cual se traduce en
menor costo para el producto de software.
2.3 Métricas de calidad en productos de software

Una métrica en la calidad del software es un indicador que permite dar una medida para
determinar el nivel de cumplimiento de una característica operativa, de la capacidad de
soportar cambios o de la adaptabilidad a un nuevo entorno [2]. Las métricas pueden ser
recopiladas o tomadas de un proceso de desarrollo de software, de la gestión de un
proyecto, o del producto como tal [15].
Hay varias razones para medir el software, como lo son [2]:
1) Para indicar la calidad del producto.

2) Para evaluar la productividad de la gente que desarrolla el producto.
3) Para evaluar los beneficios (en términos de productividad y calidad) que se

derivan del uso de nuevos métodos y herramientas de la ingeniería de software.
4) Para establecer una línea de base para la estimación.
5) Para ayudar a justificar el uso de nuevas herramientas o la formación adicional

de otras herramientas.
Las mediciones de software pueden clasificarse en dos categorías [2]:
1) Medidas directas: como el costo y el esfuerzo requerido para construir el

software, el número de líneas de código, etc.
2) Medidas indirectas: como la calidad y funcionalidad del software, la eficiencia

y facilidad de mantenimiento.
De acuerdo con Martínez [2], las métricas de software se pueden clasificar en dos
dimensiones, como se ilustra en la Figura 1.
Figura 1: Clasificación de las métricas de software.

Como se muestra en la Figura 1, la dimensión 1 está compuesta por las métricas de

productividad, las métricas técnicas y las métricas de calidad. Por otra parte, la dimensión
2 está compuesta por las métricas orientadas al tamaño, orientadas a la función y
orientadas a la persona.
Las métricas de calidad se clasifican a su vez en dos tipos: cualitativas y cuantitativas [2].
En la Figura 2 se presenta una breve descripción de las métricas cualitativas y las métricas
cuantitativas, las cuales hacen parte de las métricas de calidad.
Figura 2. Clasificación de las métricas de calidad de un producto de software.
Como se observa en la Figura 2, las métricas se clasifican en cualitativas y cuantitativas,

las cuales a su vez están compuestas por otras métricas. Las métricas correspondientes
a la legibilidad del software, en muchos casos, están ubicadas dentro del grupo de las
métricas cualitativas, por ser un aspecto subjetivo.
Una vez comprendido el tipo de métricas de calidad que existen para los productos de
software, se puede proceder a realizar la medición. Para esto se sugiere seguir los pasos
ilustrados en la Figura 3 [16]:
Figura 3. Pasos para realizar la medición de una métrica de calidad de software.
A continuación, se explica en detalle en qué consiste cada uno de los pasos que aparecen
en la Figura 3:
 Paso 1. Identificar los requisitos de calidad: Seleccionar e indicar las características

que se desean medir y asignar un peso a cada una de ellas, de acuerdo a la importancia
que tendrán en la evaluación.
 Paso 2. Especificar la evaluación: Para cada una de las características
seleccionadas en el paso anterior, definir las métricas que se medirán. Para cada una
de las métricas establecer el nivel requerido, es decir, el valor mínimo con el que se
considera bueno.
 Paso 3. Diseñar la evaluación: Indicar para cada una de las características
seleccionadas en el paso 1 en qué entregables o secciones del software se van a
aplicar. Indicar también para cada una de esas secciones cuáles métricas serán
usadas.
 Paso 4. Ejecutar la evaluación: Implementar la evaluación diseñada en el paso 3 y
anotar el valor para cada una de las métricas.
 Paso 5. Retroalimentación: Informar a los interesados (organización o dueño de
producto de software) sobre los resultados de la evaluación.
Los resultados finales de un proceso de medición, es decir, la aplicación de las métricas

de código fuente, pueden llegar a ser muy útiles para una empresa o el dueño de un
producto de software, ya que pueden conducir o indicar la necesidad de realizar desde un
pequeño ajuste al código, hasta una completa refactorización del código fuente. La
refactorización se define como una técnica para mejorar la estructura interna de los
sistemas de software [17]. Cuando un fragmento de código fuente es sometido a una
refactorización, su mantenimiento disminuye significativamente comparado con el código
fuente original (antes de la refactorización), demostrando la fuerte relación que tiene la
refactorización con la mantenibilidad en un producto de software [17]. Las métricas tenidas
en cuenta para el proceso de selección de funciones o partes del código candidatas a la
refactorización son el tamaño del código, la complejidad y el acoplamiento [17].
2.4 Legibilidad del software

La legibilidad (readability en inglés) del software es definida como el grado de facilidad con
la que una persona puede leer y comprender un fragmento de código fuente [1][10]. La
legibilidad del código fuente juega un papel muy importante en la mantenibilidad de un
producto de software, por el alto impacto que tiene sobre los costos finales de un proyecto
[1]. Si un producto de software es poco legible, su calidad se considera baja o mala, y por
consiguiente, el costo de su mantenimiento será mayor [1], porque los desarrolladores
gastarán más tiempo tratando de leer y entender el código [14]. Aggarwal et al. (2012)
afirmaron que la legibilidad del código fuente y la legibilidad de la documentación son
cruciales para la mantenibilidad de un software [5]. Los investigadores Raymond (1991),
Deimel (1985) y Rugaber 2000), identificaron a la lectura del código como una actividad
clave en el mantenimiento del software, y también reconocieron que es la actividad que
consume más tiempo entre todas las actividades de mantenimiento [5].
Se identifican dos conceptos en la lectura de un código fuente (texto): “legibilidad” y

“comprensibilidad”. La primera, según Scalabrino et al. (2017), se refiere al aspecto
sintáctico y la segunda al aspecto semántico, que es más complejo [7], mientras que
Borstler et al. (2015), consideraron a la legibilidad como una propiedad del código y a la
comprensión como una característica del lector [18]. La relación entre legibilidad y
comprensibilidad se puede definir mediante la siguiente afirmación: “Todo fragmento de
código que sea considerado como comprensible, es considerado también como legible,
pero si un fragmento de código es considerado legible, no significa que sea comprensible”

[7].
DuBay (2004) definió a la legibilidad (readability en inglés) como lo que hace más fácil leer
un texto que otros. Se confunde con legibilidad (legibility en inglés), que se refiere al tipo
de letra y diseño [18]. Hargis (2000) indicó que “la legibilidad depende de las cosas que
afectan los ojos y la mente del lector. Tamaño, estilo y la guía afectan al ojo. La estructura
y longitud de las oraciones, el vocabulario y la organización afectan la mente" [18].
La legibilidad del software es comparada como una barrera para comprender lo que el
programador sintió cuando lo construyó, así entre más legible es un fragmento de código
fuente, más débil es esa barrera [10]. En este sentido, la legibilidad del código fuente es
muy subjetiva [14], y las medidas de percepción subjetivas son difíciles de realizar porque
requieren de estudios humanos, los cuales involucran muchos factores [10]. Los niveles
de los lectores dependen principalmente de su capacidad cognitiva para procesar
información textual [14]. La rapidez también contribuye a esta subjetividad, ya que cuando
una persona trata de leer un programa, el código debe escribirse de tal manera que le tome
menos tiempo leer y entender las líneas [14]. Sin embargo, en el año 2010 Buse y Weimer
[10] mediante su trabajo de investigación titulado “Learning a Metric for Code Readability”
realizaron una gran contribución en el área de la medición de la legibilidad de software,
creando el primer modelo de clasificación automática para predecir este aspecto subjetivo,
el cual consistía en un clasificador entrenado con juicios humanos, abriendo así las puertas
a nuevas investigaciones y avances en el tema.
2.5 Estándares de calidad del software

Las métricas de calidad de software, se encuentran enmarcadas dentro de modelos /
estándares de calidad de software que han ido evolucionando a través de los años,
adaptándose a las necesidades de la industria [15].
En la Tabla 1 se presenta una breve descripción de los conceptos individuales de modelos

y estándares de calidad en el software, así como la función que desempeñan juntos.
Tabla 1. Definición de modelos y estándares de calidad de software.
Modelos de Calidad Estándares de Calidad Modelos y Estándares de

Calidad
Son aquellos documentos Son aquellos que permiten Los modelos y estándares
que integran la mayor parte definir un conjunto de permiten que las empresas
de las mejores prácticas, criterios de desarrollo que de software realicen sus
proponen temas de guían la forma en que se tareas y funciones teniendo
administración en los que aplica la ingeniería del en cuenta la calidad. La
cada organización debe software. Los estándares calidad desempeña un rol
hacer énfasis, integran suministran los medios para determinante para la
diferentes prácticas que todos los procesos se competitividad de la
dirigidas a los procesos realicen de la misma forma empresa [19].
clave y permiten medir los y son una guía para lograr la
avances en calidad [19]. productividad y la calidad
[19].
Como se observa en la Tabla 1, los modelos y los estándares de calidad de software

brindan un marco para evaluar un software desde dos perspectivas: una perspectiva mide
la calidad del producto en sí, mientras la otra perspectiva mide la calidad del proceso que
se utilizó para la obtención o construcción del producto. La mayoría de modelos y
estándares de calidad, se han centrado en la evaluación y mejora en el nivel de los
procesos, que se refiere a cómo se desarrolla un producto de software, por lo que hoy en
día se puede considerar que este nivel está bien establecido [8]. En contraste, la calidad
de software a nivel del producto, aunque tiene varias normas que permiten su evaluación
y certificación, aún se considera muy joven, poco madura [8].
Cuando una empresa está funcionando y decide implantar un modelo o estándar de calidad
del software, es señal que la empresa tiene el propósito de permanecer y crecer en el
mercado, ser competitiva, proteger los intereses de los accionistas, cuidar la fuente de
trabajo y mejorar la calidad de vida de su personal [20]. La calidad es algo que debe
inyectarse en un proyecto desde el inicio, desde su construcción y para esa tarea las
personas y empresas se apoyan en los modelos y estándares de calidad del software [15].
Como se mencionó al inicio de esta sección, los modelos y estándares de calidad de

software han ido cambiando y evolucionado a través de los años. En la Figura 4 se
presenta una línea de tiempo con algunos de los modelos y estándares de Calidad
aplicados a los productos de software, que tienen en cuenta el concepto de la
mantenibilidad del producto [15].
Figura 4. Línea de tiempo de los modelos y estándares de calidad aplicados a productos

de software. Fuente: ilustración propia elaborada con los datos de la fuente [15].
Para complementar la información de la Figura 4, se presenta en la Tabla 2 una breve

descripción de cada uno de los modelos y estándares de calidad de software presentados
en la línea de tiempo.
Tabla 2. Descripción de los modelos/estándares de calidad de software.
Modelo/Estándar Descripción Referencia

Año de Calidad de
Software
1977 Modelo de McCall El modelo de McCall define y organiza los factores de [19]
calidad en tres ejes o puntos de vista desde los cuales
el usuario puede contemplar la calidad de un producto
(1) Operación del producto, (2) Revisión del producto
y (3) Transición del producto.

Año de Calidad de
Software
1987 Modelo FURPS Propuesto por Robert Grady y Heweltt Packard Co [19]
(HP) cuenta con 5 características de calidad del
software: (1) Funcionalidad, (2) Facilidad de uso, (3)
Confiabilidad, (4) Performance y (5) Facilidad de
soporte. Además, plantea 2 categorías de
requerimientos, las cuales son funcionales y no
funcionales.
1987 - Normas ISO 9000 Consta de 4 normas básicas: [19]

1994  ISO 9000:2000: Fundamentos y vocabulario.
 ISO 9001:2000: Requerimientos
 ISO 9004:2000: Directrices para la mejora del
desempeño.
 ISO 19011: Directrices sobre auditorías de
sistemas de gestión de la calidad y/o ambiental.
1996 Modelo Dromey El modelo tiene el propósito de trabajar con una [19]
estructura que permite construir y utilizar un modelo
de calidad práctico para evaluar las etapas de
Determinación de los requerimientos, Diseño e
Implementación. Plantea la calidad del producto por
medio de la definición de subcaracterísticas que
pueden ser medidas y evaluadas como
características.
1999 Normas ISO/IEC 14598 Evaluación de un producto de software. [19]
2001 Normas ISO/IEC 9126 Está conformada por cuatro partes: Modelo de calidad, [19]
(2001) métricas externas, métricas internas y calidad en uso.

Año de Calidad de
Software
2002 Modelo MOSCA El modelo sistémico de calidad, tiene como propósito [21]
estimar la calidad sistémica dentro de una
organización desarrolladora de software. Está
constituido por dos submodelos: uno del producto y
otro del proceso. El modelo está conformado por 4
niveles:
 Nivel 0: Dimensiones: Eficiencia y Efectividad del
proceso, Eficiencia y Efectividad del producto.
 Nivel 1: Categorías: contempla 11 categorías de
las cuales 6 pertenecen al Producto y 5 al Proceso
de desarrollo.
 Nivel 2: Características: Cada categoría tiene
asociada un conjunto de características, las
cuales definen las áreas claves que se deben
satisfacer para lograr asegurar y controlar la
calidad del Producto o el Proceso.
 Nivel 3: Métricas. Cada característica posee una
serie de métricas que están relacionadas con las
cualidades que se desean evaluar del software
y/o del proceso de su desarrollo.
2006 Modelo QSOS Permite la cuantificación y calificación de software [15]

Open Source. El modelo está orientado
exclusivamente al producto de software.
2005 Normas ISO/IEC 25000 Se basa y sustituye a las normas ISO/IEC 9126 e [19]
ISO/IEC 14598 y es conocida también con el nombre
(Norma Vigente) SQuaRE. Uno de los principales objetivos de la serie
SQuaRE es la coordinación y armonización del
contenido de ISO 9126 y de ISO 15939:2002.
El modelo y estándar de Calidad de Software que se encuentra actualmente vigente, es la

familia de normas ISO/IEC 25000, también conocida como SQuaRE por sus siglas en
inglés que significan “System and Software Quality Requirements and Evaluation
(SQuaRE)”. Permite crear un marco de trabajo común para evaluar la calidad de un
producto de software, para lo cual hace uso de las siguientes divisiones [8]:
 25010: define varios modelos de calidad y determina las características de calidad del
producto que se pueden evaluar. Son 8: adecuación funcional, rendimiento,
compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad (modularidad,
analizabilidad, capacidad de reusado, capacidad de ser modificado, capacidad de ser
probado), portabilidad [8].
 25040: define el proceso de evaluación. 5 actividades: establecer requisitos, especificar

la evaluación, diseñar la evaluación, ejecutar la evaluación y concluir la evaluación [8].
 25020: define las métricas de calidad del producto de software [8].
Una de las características de calidad del producto en la división 25010 del estándar
ISO/IEC 25000, está enfocada en la “Mantenibilidad”, la cual describe la capacidad que
tiene un producto de software para ser modificado efectiva y eficientemente, debido a
necesidades evolutivas, correctivas o perfectivas [3]. La norma ISO/IEC 25010 enuncia
que la característica de mantenibilidad, se divide a su vez en las sub características:
modularidad, reusabilidad, capacidad para analizarse, capacidad para modificarse y
capacidad de probarse [3].
2.6 Resumen del capítulo

La calidad de un producto de software evalúa el grado de cumplimiento y satisfacción en
el cual el producto cumple con los requisitos de los usuarios. La familia de normas ISO/IEC
25000, define que el modelo de calidad de un producto de software se encuentra
compuesto por 8 características, que representan los requisitos de los usuarios, las cuales
son: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad,
seguridad, portabilidad y mantenibilidad. La mantenibilidad se define como la capacidad
que tiene un producto de software para ser modificado efectiva y eficientemente, debido a
necesidades evolutivas, correctivas o perfectivas [3]. De acuerdo a lo anterior, se
identifican tres tipos de mantenimiento: correctivo, adaptativo y de mejora.
Una métrica en la calidad del software es un indicador que permite dar una medida para
determinar el nivel de cumplimiento de una característica operativa, de la capacidad de
soportar cambios o de la adaptabilidad a un nuevo entorno [2]. Las métricas de calidad de
software se clasifican a su vez en dos tipos: cualitativas y cuantitativas. Las métricas
correspondientes a la legibilidad del software están ubicadas dentro del grupo de las
métricas cualitativas, por ser un aspecto subjetivo [2].
La legibilidad del código fuente juega un papel muy importante en la mantenibilidad de un

producto de software, por el alto impacto que tiene sobre los costos finales de un proyecto
[1]. Si un producto de software es poco legible, su calidad se considera baja o mala, y por
consiguiente, el costo de su mantenimiento será mayor [1], porque los desarrolladores

gastaran más tiempo tratando de leer y entender el código [14].
El modelo y estándar de calidad de software que se encuentra actualmente vigente, es la

familia de normas ISO/IEC 25000, también conocida como SQuaRE por sus siglas en
inglés que significan “System and Software Quality Requirements and Evaluation”.
SQuaRE permite crear un marco de trabajo común para evaluar la calidad de un producto
de software [8]. La división 25010 del estándar ISO/IEC 25000, está enfocada en la
mantenibilidad, la cual describe la capacidad que tiene un producto de software para ser
modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o
perfectivas [3].
3. Capítulo 3. Revisión sistemática de

literatura de métricas de legibilidad del
software
En este capítulo se describe todo el proceso de revisión sistemática de literatura
implementado en la investigación. Se describen las fases, actividades y cada uno de los
entregables que fueron diseñados e implementados en cada fase, siguiendo los
lineamientos de Kitchenham [13], así como los resultados obtenidos en el proceso de
investigación.
3.1 Revisión sistemática de literatura

Kitchenham (2018) [13] sugirió que los investigadores de ingeniería de software deberían
adoptar la "Ingeniería de Software basada en evidencia” (EBSE por sus siglas en inglés).
La meta principal de la EBSE es proporcionar los medios por los cuales la mejor evidencia
actual de la investigación se puede integrar con la experiencia práctica y los valores
humanos en el proceso de toma de decisiones con respecto al desarrollo y mantenimiento
del software [13]. El concepto evidencia es definido como una síntesis de los mejores
estudios científicos de calidad sobre un tema específico o pregunta de investigación. El
principal método de la síntesis es la revisión sistemática de literatura, abreviado como RSL
o SLR por sus siglas en inglés [13].
Siguiendo los pasos para llevar a cabo una RSL [13][22][23], este trabajo se organizó en
cinco fases. Las cuatro primeras corresponden a las actividades misionales de la
propuesta, mientras la quinta fase corresponde al proceso transversal de monitoreo y
revisión de las actividades. Las fases se presentan en la Figura 5.
Capítulo 3. Revisión sistemática de literatura de métricas de legibilidad del 37
software
Figura 5. Fases de trabajo de la RSL para las métricas de legibilidad.
3.1.1 Fase 1: Estrategia de búsqueda

El objetivo principal de la revisión sistemática de literatura fue encontrar tantos estudios
relacionados con las preguntas orientadoras como fuera posible, por ello fue necesario
plantear una estrategia de búsqueda sistemática. La estrategia de búsqueda permitió que
el proceso fuera guiado de forma objetiva, identificando la bibliografía relevante de forma
imparcial [22]. La estrategia de búsqueda contiene [22][23]:
 Las preguntas orientadoras.

 Los objetivos de la RSL.
 Selección de las bases bibliográficas dónde se realizó la búsqueda.
 Los tipos de estudios recolectados: actas de congreso, artículos de revista, capítulos
de libros.
 Los términos usados: palabras clave y ecuaciones de búsqueda.
 Para la gestión bibliográfica se utilizó la herramienta Mendeley4, la cual permite
coleccionar y organizar la literatura.
4
https://www.mendeley.com/
 Documentar la búsqueda: teniendo en cuenta que una RSL debe ser transparente y
replicable, se documentó la estrategia de búsqueda para que otros investigadores
puedan evaluar su rigor, exhaustividad y puedan incluso realizar una repetición del
proceso. Se incluyeron datos como la fuente bibliográfica en la que se realizó la
búsqueda, la ecuación usada, la estrategia para cada base de datos, la fecha de la
búsqueda y los años contemplados.
 Criterios de inclusión y exclusión explícitos, que se usaron para evaluar la pertinencia
de los estudios primarios y cómo fueron aplicados. Por ejemplo, uno de los criterios de
exclusión fue que, al encontrar múltiples publicaciones de un mismo autor sobre un
mismo estudio, es decir, con los mismos datos, se tomó el estudio más reciente.
 Diseño y aplicación de la lista de chequeo con la cual se evaluó la calidad de cada
estudio primario recolectado.
 Diseño y aplicación de los formularios de extracción de datos, que permitieron registrar
la información de los estudios primarios que daba respuesta a las preguntas de
investigación. En el formulario se incluyeron campos como la fecha de la extracción,
título del estudio, autores del estudio, revista o institución que lo publicó, otros detalles
de la publicación y un espacio para notas adicionales.
 Definición del plan de revisión del proyecto.
3.1.2 Fase 2: Recolección de documentos

En esta fase se realizó el proceso de recolección de documentos, utilizando como guía la
estrategia de búsqueda definida en la fase 1. Todo el proceso de recolección se documentó
de forma rigurosa, actualizando las listas de documentos incluidos y los excluidos
indicando la razón de exclusión, así como las cantidades de artículos encontrados y
filtrados con los criterios [22].
Para el proceso de gestión se utilizó el administrador de referencias Mendeley, que

permitió almacenar y organizar los documentos encontrados, tomar notas de cada uno y
tener los datos completos de la referencia. Para cada unidad de literatura seleccionada, se
almacenó la referencia completa, clasificación del tipo de estudio, área principal de la
investigación, autores e institución, y el resumen del estudio [22].
software
3.1.3 Fase 3: Revisión de resultados de la búsqueda

Se revisaron los trabajos recolectados en la fase 2 utilizando los criterios de inclusión y
exclusión establecidos anteriormente, evaluando las contribuciones de cada uno de los
artículos y determinando cuales pasaban a formar parte del corpus del trabajo final [22].
Se realizaron en total 3 filtros: el primero leyendo sólo el título y el resumen del documento;
el segundo filtro se realizó leyendo la sección de resultados y conclusiones; el tercer filtro
se realizó con la lectura completa de los documentos. Adicionalmente, se evaluó la calidad
de cada estudio de acuerdo a los umbrales de calidad definidos en la lista de chequeo [22].
Con la lectura completa de cada documento se realizó también la extracción de los datos
de interés, guiada por las preguntas y los objetivos de la RSL, registrando algunos datos
de todos los documentos en una hoja de cálculo, para posteriormente realizar la tarea de
comparación, y en un archivo de texto por cada documento para la toma detallada de
información. La calidad de cada documento fue evaluada usando la lista de chequeo de
calidad, y de acuerdo al puntaje el estudio fue incluido o excluido en el trabajo final.
3.1.4 Fase 4: Análisis y presentación de resultados

Se realizó una síntesis de los datos, lo que implicó resumir los resultados recopilados en
los estudios primarios [22]. Se realizó una síntesis descriptiva y se complementó con un
resumen cuantitativo. Para la síntesis descriptiva, se utilizaron tablas y figuras que
permitieron resaltar similitudes y diferencias entre los estudios, así como presentar la
evolución en el tiempo de la legibilidad del código fuente.
Se intentó presentar los resultados de la revisión sistemática de literatura de una forma

adecuada, según los objetivos de la RSL, usando la síntesis y el análisis. La síntesis se
refiere a la representación sintética de cada trabajo en base a la extracción de las
características de cada artículo recolectado y el análisis se refiere a la descripción y
valoración global de los resultados encontrados [22]. Con este trabajo se pretende entregar
la información organizada, brindando las respuestas a las preguntas orientadoras y
cumpliendo con los objetivos planteados al inicio de la RSL.
3.1.5 Fase 5: Monitoreo

Utilizando el plan de revisión establecido en la fase 1, se mantuvo la comunicación con el
director de trabajo final y con la monitora de la maestría la ingeniera Marcela Cardona,
dando a conocer los avances, correcciones, inquietudes e inconvenientes.
Los mecanismos de comunicación utilizados fueron: correo electrónico, video llamada por
Hangouts5, carpetas de archivos compartidas en Google Drive, reuniones personales y
llamadas telefónicas.
3.2 Palabras clave

Las palabras clave son los términos que permiten identificar los estudios que pueden
contener información clave sobre el tema de investigación. En la Tabla 3, se presentan las
palabras clave utilizadas en el proceso de búsqueda, las cuales fueron elegidas teniendo
en cuenta los objetivos del trabajo y las preguntas de investigación, así como las palabras
clave de los documentos relevantes recolectados en la etapa de la elaboración de la
propuesta del trabajo.
Tabla 3. Listado de palabras clave.
No. Inglés Español

1 Software Software
2 Source code Código fuente
3 Metric Métrica
4 Model Modelo
5 Readability Legibilidad
6 Classification Clasificación
La Tabla 3 muestra el listado de palabras clave en español e inglés utilizadas en las

ecuaciones de búsqueda finales que lograron recolectar documentos relevantes. Estas
formaban parte de un grupo más grande de palabras, entre las cuales había otras que
finalmente fueron descartadas porque al utilizarlas en las ecuaciones de búsqueda no
lograron los resultados que se esperaban, trayendo muchos resultados que no estaban
relacionados con las preguntas orientadoras. A continuación, en la Tabla 4 se mencionan
5
https://hangouts.google.com/
software
las palabras clave que se utilizaron para versiones preliminares de la ecuación de

búsqueda, pero que fueron descartadas de la versión final.
Tabla 4. Listado de palabras clave descartadas.
No. Inglés Español

1 Fragment of code Fragmento de código
2 Software Engineering Ingeniería de software
3 Product of software Producto de software
4 Program Programa
5 Algorithm Algoritmo
6 Feature Características
7 Factor Factores
8 Criteria Criterios
9 Understandability Comprensibilidad
10 Reading Lectura
11 Maintenance Mantenimiento
12 Developing Desarrollo
13 Measurement Medición
14 Programming Programación
15 Write Escritura
16 Quality Calidad
17 Standards / rules Estándares / normas
18 Good practices Buenas prácticas
3.3 Fuentes bibliográficas

Las fuentes bibliográficas seleccionadas para realizar la búsqueda de los documentos
fueron:
 WoS - Web of Science
 Scopus
 Google Scholar
 IEEExplore
 ACM Digital Library
Las fuentes WoS, Scopus, fueron seleccionadas porque se consideran fuentes confiables
e importantes para obtener artículos de revistas y conferencias científicas, y además
porque la Universidad Nacional tiene subscripción a las mismas. Además, se incluyeron
IEEExplore y ACM Digital Library porque los artículos recientemente publicados por IEEE
y ACM son indexados primero en estas bases de datos, antes que en WoS o Scopus. Por
último, se utilizó también el buscador Google Scholar ya que al ser una base de datos no
estructurada permitía obtener documentos de investigaciones que aún están en proceso,
y no sólo los finalizados y publicados, lo cual permitió obtener un número mayor de
resultados.
3.4 Ecuaciones de búsqueda

Utilizando las palabras clave identificadas en pasos anteriores, se definieron las siguientes
ecuaciones de búsqueda, cuyos resultados satisfacen los objetivos de la RSL.
 readability AND (software OR code) AND (metric* OR classification OR model*)

 metric + readability + software + classification + "source code"
Es importante mencionar que, al momento de realizar la búsqueda en cada una de las

fuentes bibliográficas, se configuró de forma manual el filtro por año, para que los
resultados correspondieran a publicaciones desde el año 2015 hasta el 2019.
Adicionalmente, a continuación, se presentan otras 2 ecuaciones que fueron parte de las
pruebas iniciales, y aunque fueron finalmente descartadas porque los resultados no
satisfacían los objetivos de la RSL, permitieron la obtención de 5 documentos que fueron
incluidos en el trabajo final.
 readab* AND software

 (metric* OR feature* OR factor* OR criteri* OR model*) AND (software OR "code
source" OR program* OR algorithm) AND (readability)
La definición y selección de las ecuaciones de búsqueda finales, se obtuvo luego de un

proceso cuidadoso de construir y probar diferentes ecuaciones. A continuación, se
mencionan las ecuaciones de búsqueda descartadas por no traer resultados relevantes
para el tema de investigación.
 metric* AND code AND source

software
 (quality OR standar* OR rule*) AND (software OR "code source" OR program OR

algorithm) AND (read* OR maint*)
 (metric* OR featur* OR factor* OR criteria* OR model*) AND (software OR "code
source" OR program* OR algorithm) AND (understand* OR maint* OR read*)
 "good practice" AND (program* OR software OR "code source" OR algorithm)
 program* AND (read* OR maint*)
 (writ*) AND (software OR "code source" OR program* OR algorithm)
 metric* AND code AND source AND readability
 readability AND (software OR code) AND (metric*)
3.5 Criterios de inclusión

Los criterios de inclusión fueron los parámetros definidos para limitar el alcance de la
investigación, es decir, lo que tenían que cumplir los documentos para ser incluidos en el
trabajo. Para la búsqueda de documentos relacionados con las métricas de legibilidad del
código fuente, se definieron los siguientes criterios de inclusión:
 Idioma: español o inglés.

 Publicado desde el año 2015 hasta 2019.
 El tipo de estudio corresponde a: actas de congreso, artículo de revista y capítulo de
libro.
 El documento contenía información de alguno de los siguientes temas de métricas de
legibilidad de software: métricas de la legibilidad de software; características evaluadas
al medir la legibilidad del software; modelos automáticos para medir la legibilidad del
software; técnicas o métodos aplicados para medir la legibilidad del código fuente.
3.6 Criterios de exclusión

Los criterios de exclusión fueron los parámetros que permitieron definir los documentos
que no serían incluidos en el trabajo final. Para la búsqueda de documentos relacionados
con las métricas de legibilidad del código fuente, se definieron los siguientes criterios de
exclusión:
 No cumplía con alguno de los criterios de inclusión.

 En los casos donde se encontraron dos o más versiones de un mismo estudio de un
autor, se descartó las versiones anteriores, tomando en cuenta únicamente la más
reciente.
 El documento no se pudo obtener.
 Al recolectar documentos desde varias fuentes, se encontraron varios registros
duplicados, por lo que se unificaron mediante la función “Merge” de la herramienta
Mendeley6.
3.7 Lista de chequeo

La lista de chequeo comprende un conjunto de factores que se evaluaron en los
documentos, con el objetivo de realizar una evaluación de la calidad de los documentos
recolectados. La evaluación de cada parámetro se realizó mediante una calificación
numérica, correspondiente a las respuestas sí, parcialmente o no, con valores de 2, 1 y 0,
respectivamente. Adicionalmente, se usó la calificación NA, que significa “No aplica”, para
omitir el parámetro evaluado en alguno de los estudios. Al finalizar, se realizó una
sumatoria de los puntajes del documento, donde los documentos que obtuvieron una
calificación igual o superior al 80% de la nota máxima, quedaron seleccionados para
incluirlos en el trabajo final. Por el contrario, los que obtuvieron un puntaje inferior al 80%,
fueron excluidos.
La lista de chequeo de calidad definida, se aplicó a cada uno de los 33 documentos de la

fase 3 y fue registrada en una misma hoja de cálculo para efectos de comparación entre
estudios. En la Figura 6 se muestra una imagen correspondiente a la evaluación de calidad
de varios estudios, donde cada fila representa un documento.
6
https://www.mendeley.com/
software
Figura 6. Formato de evaluación de la calidad del estudio.
En la Figura 6 se observa en la parte superior el encabezado de cada columna, la cual

empieza, de izquierda a derecha con el puntaje total obtenido, denominado “CHK
CALIDAD” bajo la fila de color azul. Luego, bajo la fila de color violeta se encuentran varias
columnas numeradas de 1 a 11, las cuales representan cada uno de los factores de calidad
evaluados, lo cuales se exponen en la Tabla 5. Cada factor tiene su calificación la cual es
2 para los que cumplen, 1 para los que cumplen parcialmente, 0 para los que no cumplen
y NA para que no sea tomada en cuenta, para los casos en los que el factor evaluado no
puede ser aplicado al estudio. La última columna, denominada “TOTAL” que es de color
verde, contiene la fórmula matemática para calcular el puntaje total de acuerdo a las
calificaciones, la cual consiste en sumar los valores asignados en la calificación de cada
factor, y utilizando una regla de tres, teniendo en cuenta el valor máximo que podría ser
asignado, se obtuvo un valor de 0 a 100. Los factores de calidad evaluados se listan a
continuación en la Tabla 5, presentando el número del factor y su respectiva descripción.
Tabla 5. Factores evaluados en la lista de chequeo.
# Factor evaluado
1 Plantea un objetivo de estudio
2 Es clara la descripción del contexto del problema
3 Tiene sección de resultados
4 La metodología de investigación utilizada en el estudio es clara
5 El estudio es reproducible
6 Las secciones del documento tienen relación con el objetivo principal

7 Describe al menos 1 métrica, 1 método o 1 característica
8 Referencias actualizadas (al menos 2) de máximo 1 año antes a la fecha de
elaboración del estudio
9 Describe el conjunto de datos (dataset) utilizado
10 Tiene preguntas de investigación
11 El documento responde sus propias preguntas de investigación
En el listado anterior no se tuvo en cuenta el número de citaciones por año, porque debido
a lo reciente de las investigaciones, teniendo en cuenta que la búsqueda se limitó a las
publicaciones desde 2015, algunos de los artículos tienen 0 o máximo 2 citaciones. Lo que
si se observó en común con los artículos, es que en su bibliografía mencionaban el trabajo
de Buse y Weimer [1], el cual fue el que abrió las puertas a los demás al encontrar una
forma para medir algo tan subjetivo como lo es la legibilidad del software.
El formato de lista de chequeo utilizado y diligenciado en el proceso de extracción de datos

está disponible en el repositorio público de GitHub
https://github.com/sofi876/MetricasLegibilidadSW.
3.8 Gestión bibliográfica

Para realizar la gestión bibliográfica de los documentos recolectados y su posterior revisión
y clasificación, se utilizó la herramienta de gestión bibliográfica Mendeley. Utilizando la
opción “Groups”, se creó un grupo público, agregando inicialmente como participante al
director de la propuesta, para que pudiera realizar el seguimiento correspondiente al
desarrollo del trabajo final. Al ser un grupo público, cualquier persona podrá acceder, para
consultar y verificar el proceso de gestión bibliográfica desarrollado en la RSL. El enlace
del grupo es: https://www.mendeley.com/community/legibilidadsw_isef/
La carpeta principal está compuesta por dos carpetas, que corresponden a la fase 2 de
recolección, denominada “F2- Recolección”, y a la fase 3, denominada “F3- Filtrado
completo”. La carpeta de la fase 2 contiene a su vez 6 carpetas; cada una corresponde a
una fuente bibliográfica y dentro de ella contiene a su vez otras dos carpetas denominadas
software
“Excluidos” e “Incluidos”, donde se encuentran los archivos correspondientes al proceso

realizado en el filtro 2.
Al terminar la fase 2, se tomaron los archivos de todas las fuentes bibliográficas

clasificados como “Incluidos” y se copiaron a la carpeta “F3- Filtrado completo” de la fase
3. Posteriormente, se revisaron y fusionaron los archivos duplicados. Una vez se obtuvo la
lista de documentos finales, se realizó la lectura completa de los mismos, aplicando los
criterios de inclusión, los criterios de exclusión, la lista de chequeo de calidad y extrayendo
los datos en los formatos correspondientes.
Al terminar la lectura completa de los documentos, los que no cumplieron con los criterios
de inclusión o la calidad mínima requerida, fueron excluidos y pasaron a la “F3-2 -
Excluidos”. Los demás documentos que, si cumplieron, pasaron a la carpeta final
denominada “F3-3 Cumplen criterios Inc, Exc y Cal”. En la Figura 7, se muestra una imagen
que corresponde a la vista de la herramienta Mendeley.
Figura 7. Imagen de la herramienta de gestión bibliográfica Mendeley con las carpetas.

En la Figura 7, se puede apreciar la organización del proceso en las fases 2 y 3, mediante

el uso de carpetas que permiten registrar la trazabilidad de las actividades realizadas.
Adicionalmente, se exportó y compartió la bibliografía de Mendeley correspondiente a los

estudios seleccionados para la extracción de datos, y se encuentra disponible en el
repositorio público de GitHub https://github.com/sofi876/MetricasLegibilidadSW.
3.9 Preguntas orientadoras

Las preguntas orientadoras son aquellas formuladas al inicio de la RSL, y que permitieron
guiar la búsqueda y recolección de estudios relacionados al tema de las métricas de
legibilidad del software, así como el proceso de extracción de datos de interés. Las
preguntas orientadoras fueron las siguientes:
RQ1. ¿Cuáles son las características que permiten medir la legibilidad del código fuente
de un software?
RQ2. ¿Qué métodos son utilizados para obtener el valor de medida de cada una de esas
métricas de forma automática?
RQ3. ¿Cuáles son los principales retos y aplicaciones de interés en las investigaciones
relacionadas con la legibilidad del software?
3.10 Formulario de extracción de datos

En la fase 3, mientras los documentos fueron leídos completamente, se utilizó un formulario
de extracción de datos, que permitió clasificar, analizar y sintetizar los datos encontrados
para dar respuesta a las preguntas de investigación de la RSL.
El formulario de extracción de datos es un conjunto de parámetros que permitieron guiar

el proceso de extracción de forma objetiva y, al igual que la lista de chequeo, se aplicó a
cada uno de los documentos leídos. Se utilizaron 2 formatos para la extracción de los
datos: un archivo de tipo hoja de cálculo, que se muestra en la Figura 8, donde cada
documento está representado en una fila, y cada dato solicitado se registró en la columna
correspondiente; el segundo archivo es un archivo de texto por cada documento leído, que
software
se muestra en la Figura 9, donde se registró de forma detallada la información de interés

extraída para posteriormente ser usada en el trabajo final.
Figura 8. Hoja de cálculo utilizada para la extracción de datos de todos los documentos.
En la Figura 8 se puede observar una parte del formato de extracción de datos, donde la
fila 2 tiene los nombres de los grupos en las cuales se clasifican los datos solicitados. Los
grupos en los cuales se clasifican los datos son: Documento, Extracción de datos, Chequeo
de calidad, Preguntas de investigación, Objetivos y TAGS. A continuación, en la Tabla 6
se explica en detalle los datos que se solicitan en cada una de las categorías.
Tabla 6. Detalle del formato de extracción de datos.
Grupo Nombre Descripción

# Número de identificación asignado al documento
Fecha de recolección Fecha en la cual se recolectó el documento desde la
fuente bibliográfica
Fuente Base de datos bibliográfica desde la cual se obtuvo
el documento
Ecuación Número de la ecuación usada para obtener el
documento
Documento
Autor Autor(es) del documento
Titulo Título del documento
Citación Citación de texto obtenida por la herramienta
Mendeley
Año Año en el cual se publicó el documento
País País al cual pertenecen los autores del documento
Institución Institución a la que pertenecen los autores
Documento Tipo de estudio Tipo de documento

Revista / Conferencia Revista o conferencia donde se publicó el
documento
Fecha de inicio Fecha de control interna, en la cual se inició la
lectura completa del documento
Fecha de fin Fecha de control interna, en la cual se finalizó la
lectura completa del documento
Chk calidad Puntaje total de la evaluación de calidad. Es la copia
de la columna “Total”, pero sólo con el valor, no con
la formula.
1 Plantea un objetivo de estudio.
2 Es clara la descripción del contexto del problema
3 Tiene sección de resultados
4 La metodología de investigación utilizada en el
estudio es clara
5 El estudio es reproducible
6 Las secciones del documento tienen relación con el
CHK Calidad objetivo principal
7 Describe al menos 1 métrica, 1 método o 1
característica
8 Referencias actualizadas (al menos 2) de máximo 1
año antes a la fecha de elaboración del estudio
9 Describe el conjunto de datos (Data set) utilizado
10 Tiene preguntas de investigación
11 El documento responde sus propias preguntas de
investigación
Total Puntaje total de la evaluación de calidad. Contiene la
formula con la cual se calculó el valor
1 ¿Cuáles son las características que permiten medir
la legibilidad del código fuente de un software?
2 ¿Qué métodos son utilizados para obtener el valor
Preguntas de de medida de cada una de esas métricas de forma
investigación automática?
3 ¿Cuáles son los principales retos y aplicaciones de
interés en las investigaciones relacionadas con la
legibilidad del software?
1 Definir la estrategia de búsqueda acerca de las
métricas de legibilidad del software
2 Sintetizar los resultados en términos de la evolución
de las métricas de legibilidad del software, las
Objetivos
características utilizadas para su medición y los
métodos automáticos de medición.
3 Identificar los retos actuales y las aplicaciones de
interés para la comunidad científica en el área
Lenguajes de Lenguajes de programación utilizados o evaluados
programación en el documento para el estudio de la legibilidad del
software
Tema Temática de la cual trata el documento
Conceptos Definiciones que se pueden encontrar en el
documento sobre términos, para adicionar en el
trabajo final
TAGS
Factores / Características Las características que proponen o mencionan en
los documentos para evaluar la legibilidad del
software
Métricas Las métricas que proponen o mencionan en los
documentos para medir la legibilidad del software
Mejores prácticas Los temas del documento que tratan sobre las
mejores prácticas para la legibilidad del software
software

Modelos Modelos que proponen o mencionan en los
documentos para evaluar automáticamente la
legibilidad en el código fuente
Tipo de modelo Si el modelo es especializado en un lenguaje de
programación o general
Otros modelos Si el documento habla de un modelo, pero no es
para medir automáticamente la legibilidad del
software
Dataset Vínculos web obtenidos del documento para ver y
descargar los fragmentos de código fuente utilizados
en las investigaciones
Herramientas Vínculos web obtenidos del documento para ver y
descargar las herramientas utilizadas en las
investigaciones
Documentación Vínculos web obtenidos del documento para ver y
descargar las herramientas utilizadas en las
investigaciones
Nota 1: Para los factores evaluados en el chequeo de calidad los valores posibles son:
Puntaje 2 si lo cumple, 1 si lo cumple parcialmente, 0 si no lo cumple, y NA si el factor no
puede ser evaluado en el documento.
Nota 2: Para las preguntas de investigación, la forma de diligenciarlos fue ingresar los
datos que daban respuesta a esa pregunta (si aplica). Para los objetivos se realizó el
mismo procedimiento.
Adicional al formato de extracción de datos explicado anteriormente en la Figura 8 y la

Tabla 6, donde se registran los datos extraídos de los documentos, también se usó un
archivo de texto por cada uno de los documentos, lo cual permitió registrar un mayor
volumen de información que posteriormente fue usado en este trabajo final. En la Figura 9
se presenta el formato en blanco del archivo de texto.
Figura 9. Archivo de texto utilizado para la extracción de datos de cada documento.
En la Figura 9 se muestran el formato básico para el registro de información de cada uno

de los documentos recolectados que fueron seleccionados para la lectura completa. En el
campo de “TÍTULO” se registró el nombre del documento en español, teniendo en cuenta
que todos los estudios recolectados estaban en inglés. En el campo “TAGS” se registraron
las palabras clave, en idioma español, que fueron asignadas de acuerdo a los aportes que
el estudio brindó para dar respuesta a las preguntas de investigación planteadas en este
trabajo final, y que posteriormente, también fueron registrados en la herramienta de
Mendeley para facilitar la búsqueda y la clasificación de los estudios.
Los formatos diseñados y utilizados en el proceso de extracción de datos están disponibles

en el repositorio público de GitHub https://github.com/sofi876/MetricasLegibilidadSW.
software
3.11 Resumen del proceso de la RSL

A continuación, en la Tabla 7, se presentan nuevamente las ecuaciones de búsqueda
utilizadas en el proceso de recolección.
Tabla 7. Ecuaciones de búsqueda utilizadas para la recolección.
Número Ecuación de búsqueda

1 readability AND ( software OR code ) AND ( metric* OR classification OR model*)
2 metric + readability + software + classification + "source code"
3 readab* AND software
4 (metric* OR feature* OR factor* OR criteri* OR model*) AND (software OR "code
source" OR program* OR algorithm) AND (readability)
Adicionalmente, para limitar los resultados de la búsqueda, se utilizaron algunos

parámetros de configuración que se describen en la Tabla 8.
Tabla 8. Parametrización adicional realizada en las fuentes bibliográficas.
Ecuación Fuente Filtros adicionales

1 WoS AND IDIOMA: (English OR Spanish)
Refinado por: CATEGORÍAS DE WEB OF SCIENCE: (
COMPUTER SCIENCE SOFTWARE ENGINEERING OR
COMPUTER SCIENCE INFORMATION SYSTEMS OR
COMPUTER SCIENCE ARTIFICIAL INTELLIGENCE OR
COMPUTER SCIENCE THEORY METHODS OR COMPUTER
SCIENCE INTERDISCIPLINARY APPLICATIONS OR
ENGINEERING MULTIDISCIPLINARY )
Período de tiempo: 2015-2019.Índices: SCI-EXPANDED, SSCI,
A&HCI, ESCI.
2 Google >2014
Scholar
1 IEEE >2014
1 ACM >2014
3 Scopus AND PUBYEAR > 2014 AND ( LIMIT-TO ( SUBJAREA ,
"COMP" ) OR LIMIT-TO ( SUBJAREA , "ENGI" ) )
4 WoS AND IDIOMA: (English OR Spanish)
Refinado por: CATEGORÍAS DE WEB OF SCIENCE: (
COMPUTER SCIENCE SOFTWARE ENGINEERING OR
COMPUTER SCIENCE INFORMATION SYSTEMS OR
COMPUTER SCIENCE ARTIFICIAL INTELLIGENCE OR
COMPUTER SCIENCE THEORY METHODS OR COMPUTER
SCIENCE INTERDISCIPLINARY APPLICATIONS OR
ENGINEERING MULTIDISCIPLINARY )
Período de tiempo: 2015-2019.Índices: SCI-EXPANDED, SSCI,

A&HCI, ESCI.
3 ACM >2014
En la Tabla 8, se puede apreciar que la configuración adicional implementada en la

búsqueda para acotar los resultados, corresponde al año de publicación del estudio, el
idioma y las áreas relacionadas con el software y las ciencias de la computación.
Luego de aplicar la parametrización adicional en las ecuaciones de búsqueda, se inició el

proceso de recolección, cuyos resultados cuantitativos se describen en la Tabla 9.
Tabla 9. Resultados cuantitativos de la RSL.
Fuente Ecuación Resultados Recolectados Excluidos Incluidos

(F1) (F2) (F2)
WoS 1 66 13 8 5
Scopus 1 53 49 31 18
Google 2 3870 (60 27 9 18
Scholar
hasta
página 6)
IEEE 1 65 19 9 10
ACM 1 60 18 10 8
Otras 3y4 4 4 1 3
fuentes
En la Tabla 9, se puede observar la cantidad de resultados que fueron obtenidos al realizar

la búsqueda en cada una de las fuentes bibliográficas. La columna “Recolectados F1”, se
refiere a los documentos seleccionados de los primeros resultados, leyendo sólo el título y
el resumen. Los “Excluidos F2”, son los que no cumplieron con los criterios, luego de leer
la sección de los resultados de cada documento, mientras que “Incluidos F2” si los
cumplieron. El siguiente paso que se realizó, fue tomar los estudios “Incluidos F2” y realizar
una fusión de aquellos repetidos, teniendo en cuenta que fueron recolectados desde varias
fuentes bibliográficas. Los resultados del proceso realizado se describen en la Tabla 10.
software
Tabla 10. Resultados cuantitativos de la RSL. Parte 2.
Inician (F3) Luego de fusionar duplicados (F3) Excluidos Definitivos

(F3)
62 33 9 24
El campo “Inician F3” de la Tabla 10, corresponde a la suma de los estudios que resultaron
seleccionados en el filtro 2 (F2). La segunda columna de la Tabla 10, corresponde a los 33
documentos únicos, sin repetir, a los cuales se les realizó la lectura completa, y se
evaluaron con los criterios y la evaluación de calidad. Los documentos que cumplieron
satisfactoriamente con la evaluación de criterios y de calidad, fueron utilizados para la
extracción de datos, mediante el uso de los formatos diseñados para ello, que fueron
explicados anteriormente en la sección 3.10.
Adicionalmente, ya se tenían algunos estudios importantes relacionados con la legibilidad

del código fuente, que fueron usados en la elaboración de la propuesta, y corresponden a
años anteriores al 2015, pero debido a la importancia de sus aportes en el estudio, se
adicionaron a la muestra de documentos seleccionados. En la Tabla 11, se detallan la
cantidad de documentos adicionales y totales que fueron seleccionados para hacer parte
de este trabajo final.
Tabla 11. Cantidad total de documentos seleccionados.
Obtenidos por la RSL Obtenidos en la propuesta Cantidad total

24 6 30
Como lo indicó la Tabla 11, adicionando los 6 documentos que se tenían desde la
propuesta, se logró un total de 30 estudios que permitieron dar respuesta a las preguntas
de investigación. Su discusión se presenta en los capítulos 4, 5 y 6.
A continuación, en la Tabla 12, se presenta la información correspondiente a los 30

estudios que fueron finalmente seleccionados, para responder a las preguntas de
investigación planteadas en este trabajo final.
Tabla 12. Listado de estudios seleccionados en la RSL.
# REF AÑO AUTOR TITULO REVISTA / TIPO DE PAIS

CONFERENCIA ESTUDIO
1 [14] 2016 Akour, Mohammed; Application domain 2016 7th Conference Jordania;
Falah, Bouchaib and programming International proceedings Marruecos
language readability Conference on
yardsticks Computer Science
and Information
Technology (CSIT)
2 [5] 2018 Alawad, Duaa; An Empirical Study Working Estados

Panta, Manisha; of the Relationships paper Unidos
Zibran, Minhaz; between Code
Islam, Rakibul Readability and
Software Complexity
3 [24] 2015 Allamanis, Miltiadis; Suggesting accurate ESEC/FSE’15 Conference Estados
Barr, Earl T.;Bird, method and class proceedings Unidos;
Christian;Sutton, names Inglaterra
Charles
4 [25] 2015 AMAN, Hirohisa; Lines of Comments IEICE TRANS. INF. & Working Japón
AMASAKI, as a Noteworthy SYST VOL E98-D paper
Sousuke; SASAKI, Metric for Analyzing No. 12
Takashi; Fault-Proneness in
KAWAHARA, Methods
Minoru
5 [18] 2016 Borstler, Jurgen; The Role of Method TRANSACTIONS Journal Suecia;
Paech, Barbara; Chains and ON SOFTWARE Article Alemania
Comments in ENGINEERING
Software Readability
and Comprehension
– An Experiment
6 [26] 2018 Chen, Hsi Min; An automated Journal of Journal Taiwán

Chen, Wei Han; assessment system Information Science Article
Lee, Chi Chen; for analysis of coding and Engineering
convention
violations in Java
programming
assignments*
7 [27] 2018 Choi, Sangchul; Measuring the Springer International Book Corea del
Kim, Suntae; Lee, Extent of Source Publishing AG, part of Section sur
Jeong-Hyu; Kim, Code Readability Springer Nature 2018
JeongAh; Choi, Using Regression
Jae-Young Analysis
8 [28] 2018 Coleman, Ron Aesthetics Versus International Journal Journal Estados
Readability of of Advanced Article Unidos
Source Code Computer Science
and Applications
9 [29] 2017 De Renzis, Alan; A domain Computer Standards Journal Argentina

Garriga, Martin; independent & Interfaces Article
Flores, Andres; readability metric for
Cechich, Alejandra; web service
Mateos, Cristian; descriptions
Zunino, Alejandro;
10 [30] 2018 dos Santos, Impacts of coding International Conference Brasil;

Rodrigo Magalhães; practices on Conference on proceedings Estados
Gerosa, Marco readability Program Unidos
Aurélio; Comprehension
software

CONFERENCIA ESTUDIO
11 [31] 2018 Fakhoury, Sarah; The effect of poor 2018 ACM/IEEE 26th Conference Estados
Ma, Yuzhan; source code lexicon International proceedings Unidos
Arnaoudova, and readability on Conference on
Venera; Adesope, developers' Program
Olusola; cognitive load Comprehension
12 [32] 2018 Frunzio, Luigi; Lin, RETICULA: Real- 2018 IEEE 25th Suiza
Bin; Lanza, Michele; time code quality International
Bavota, Gabriele; assessment Conference on
Software Analysis,
Evolution and
Reengineering
(SANER)
13 [33] 2015 Liu, Yangchao; Sun, Analyzing program Proceedings of the Conference China
Xiaobing; Duan, readability based on 19th International Proceedings
Yucong; WordNet Conference on
Evaluation and
Assessment in
Software Engineering
- EASE '15
14 [11] 2018 Mannan, Umme Towards Proceedings of the Conference Estados

Ayda; Ahmed, understanding code 4th ACM SIGSOFT Proceedings Unidos
Iftekhar; Sarma, readability and its International
Anita; impact on design Workshop on NLP for
quality Software Engineering
- NL4SE 2018
15 [34] 2018 Mi, Qing; Keung, A Gamification 2018 International Conference Hong Kong
Jacky; Mei, Xiupei; Technique for Symposium on Proceedings
Xiao, Yan; Chan, W. Motivating Students Educational
K; to Learn Code Technology
Readability in
Software
Engineering
16 [35] 2018 Mi, Qing; Keung, Improving code Information and Journal Hong Kong;
Jacky; Xiao, Yan; readability Software Technology Article China
Mensah, Solomon; classification using
Gao, Yujin; convolutional neural
networks
17 [36] 2018 Mi, Qing; Keung, An Inception Proceedings of the Conference Hong Kong
Jacky; Xiao, Yan; Architecture-Based 22nd International Proceedings
Mensah, Solomon; Model for Improving Conference on
Mei, Xiupei; Code Readability Evaluation and
Classification Assessment in
2018 - EASE'18
18 [37] 2016 Mi, Qing; Keung, Measuring the Proceedings of the Conference Hong Kong;
Jacky; Yu, Yang; Stylistic The 12th Proceedings China
Inconsistency in International
Software Projects Conference on
using Hierarchical Predictive Models
Agglomerative and Data Analytics in
Clustering Software Engineering
- PROMISE 2016

CONFERENCIA ESTUDIO
19 [12] 2017 Novais, Daniel José Program analysis for Proceedings of the Conference Portugal
Ferreira; Pereira, Clustering Federated Proceedings
Maria João Programmers' Conference on
Varanda; Profile Computer Science
Henriques, Pedro and Information
Rangel; Systems
20 [38] 2017 Pahal, Ankit; Chillar, Code Readability: A International Journal Journal India
Rajender S; Review of Metrics for of Computer Trends Article
Software Quality and Technology
21 [39] 2018 Scalabrino, Simone; A comprehensive Journal of Software: Journal Estados

Linares-Vásquez, model for code Evolution and Article Unidos;
Mario; Oliveto, readability Process Colombia;
Rocco; Italia
Poshyvanyk,
Denys;
22 [40] 2016 Sedano, Todd Code Readability 2016 IEEE 29th Conference Estados
Testing, an Empirical International Proceedings Unidos
Study Conference on
Education and
Training (CSEET)
23 [41] 2019 Wulff-Jensen, Gaze Strategies Can Springer International Working Dinamarca
Andreas; Ruder, Reveal the Impact of Publishing AG, part of Paper
Kevin; Triantafyllou, Source Code Springer Nature 2019
Evangelia; Bruni, Features on the
Luis Emilio; Cognitive Load of
Novice
Programmers
24 [42] 2017 Xu, Weifeng; Xu, Measurement of 2017 IEEE 41st Conference Estados
Dianxiang; Deng, Source Code Annual Computer Proceedings Unidos
Lin; Readability Using Software and
Word Concreteness Applications
and Memory Conference
Retention of (COMPSAC)
Variable Names
25 [1] 2010 Buse, Raymond P Learning a Metric for 558 IEEE Journal Estados
L; Weimer, Westley Code Readability TRANSACTIONS Article Unidos
R; ON SOFTWARE
ENGINEERING,
VOL. 36, NO. 4
26 [20] 2010 Butler, S; Exploring the 2010 14th European Conference Reino
Wermelinger, M; Influence of Identifier Conference on Proceedings Unido
Yijun Yu; Sharp, H; Names on Code Software
Quality: An Empirical Maintenance and
Study Reengineering
27 [6] 2012 Dorn, Jonathan A General Software Working Estados
Readability Model Paper Unidos
28 [10] 2011 Posnett, Daryl; A simpler model of MSR’11 Conference Estados

Hindle, Abram; software readability Proceedings Unidos
Devanbu,
Premkumar;
29 [43] 2016 Sampaio, Isabel Software readability 2016 7th Conference Portugal
Braga; Barbosa, practices and the International Proceedings
Luis; importance of their Conference on
teaching Information and
Communication
Systems (ICICS)
software

CONFERENCIA ESTUDIO
30 [44] 2017 Scalabrino, Simone; Automatically 2017 32nd Conference Italia;

Bavota, Gabriele; assessing code IEEE/ACM Proceedings Suiza;
Vendome, understandability: International Estados
Christopher; How far are we? Conference on Unidos;
Linares-Vasquez, Automated Software Colombia
Mario; Poshyvanyk, Engineering (ASE)
Denys; Oliveto,
Rocco;
En la Tabla 12, se presentan los 24 documentos que fueron seleccionados con la RSL,
junto con los 6 documentos que se tenían de la propuesta, que se presentan al final de la
tabla, desde el documento número 25 hasta el 30, en color gris. En la tabla, se detallan los
nombres de los autores, título del estudio, la revista o conferencia que lo publicó, el tipo de
estudio y el país al que corresponden las instituciones a las que pertenecieron los autores
que participaron en el estudio.
En la Figura 10, se presentan los 24 estudios seleccionados en la RSL, más los 6 estudios
obtenidos en la propuesta, clasificados por año de publicación, donde se puede apreciar
que los estudios sobre el tema han venido aumentando considerablemente, teniendo el
mayor número de publicaciones en el año 2018.
Figura 10. Documentos finales clasificados por año de publicación.
En la Figura 10, se puede observar que entre los estudios seleccionados 3 corresponden
al año 2015, 5 al año 2016, 3 al año 2017, 12 al año 2018 y 1 al año 2019. Para este último
año, cabe recordar que el proceso de recolección finalizó el 23 de abril del año 2019, por
lo que los estudios publicados después de esa fecha no estarían incluidos. En la Figura
10, también se puede apreciar que, de los estudios seleccionados, el 56.67% corresponde
a informes de conferencias, el 30% a artículos de revista científica, 9.99% a hojas de
trabajo, y sólo un 3.34% a secciones de libros.
En la Figura 11 se presenta una nube de palabras con los nombres de los autores de los
estudios seleccionados, en los cuales los nombres con mayor tamaño representan a los
autores con mayor cantidad de investigaciones en el tema de legibilidad del software.
Figura 11. Nube de palabras representando la frecuencia de los autores en los estudios
seleccionados. Fuente: Herramienta SASR7
En la Figura 11, se observa en mayor tamaño y de color verde, los nombres de los autores
con mayor número de investigaciones asociadas a las métricas de legibilidad del software,
encontrando hasta 3 estudios, demostrando un gran interés de su parte por el tema.
En la Figura 12, se presentan una nube que representa la frecuencia de las palabras clave,
denominadas TAGS, asignados en Mendeley de acuerdo al aporte encontrado en cada
estudio, para responder las preguntas de investigación del presente trabajo. Las palabras
7
Herramienta SASR: http://eiscapp.univalle.edu.co/uncode/
software
en español, corresponden a los TAGS asignados, mientras que las palabras en inglés, son
las asignadas por el autor de cada estudio.
seleccionados. Fuente: herramienta SASR.
En la Figura 12, se encuentran mezcladas las palabras clave asignadas por los autores a
cada uno de sus estudios y las palabras clave asignadas en este trabajo, de acuerdo al
aporte que el documento realizó para responder a las preguntas de investigación
planteadas en esta RSL.
En la extracción de datos se identificaron los aportes de cada uno de los documentos, los
cuales fueron clasificados como se presenta en la Tabla 13.
Tabla 13. Clasificación de los aportes encontrados en los estudios.
Clasificación del Descripción # Documentos Referencia

aporte
Conceptos Definiciones de los términos clave asociados a 7 [5] [11][14]
la legibilidad del software y aportes [18] [35]
relacionados con su evolución en el tiempo. [38][39]
Clasificación del Descripción # Documentos Referencia

aporte
Características Características o factores evaluados en el 22 [5][1][7]
código fuente, para poder evaluar su legibilidad. [10][6][14]
[18][20][24]
[25] [27] [29]
[30][31][32]
[33][35][36]
[39][40]
[41][42]
Métricas Métricas de legibilidad que permiten medir la 11 [5] [37] [12]
legibilidad del software. [25] [27][28]
[29] [32][33]
[38][42]
Mejores prácticas Mejores prácticas, convenciones de 8 [37][26][28]
programación, factores de embellecimiento del [29][30][34]
código fuente y enseñanza de la legibilidad del [40][43]
software.
Modelos Modelos automáticos para evaluar la legibilidad 13 [1] [7][10] [6]
en un fragmento de código fuente. [11][25][27]
[28][33][35]
[36][39] [42]
Otros modelos Modelos automáticos propuestos para 7 [37][12][24]
actividades diferentes a la medición de la [25][31][32]
legibilidad, pero relacionadas. [41]
Fragmentos Repositorios disponibles para ver y descargar 5 [5][24][28][3
los fragmentos de código fuente utilizados en 5][39]
las investigaciones.
Herramientas Repositorios o sitios web disponibles para ver y 12 [5] [37][12]
descargar las herramientas tecnológicas [25][26][31]
utilizadas en las investigaciones. [32][33][35]
[36] [39][42]
Documentación Repositorios disponibles para ver y descargar 4 [37] [26]
documentación de interés relacionada con la [40][42]
legibilidad del código fuente.
En la Tabla 13 anteriormente presentada, se describieron las categorías en las cuales se

clasificaron los aportes encontrados en los estudios, detallando a que se refiere cada una
y la cantidad de documentos en los que se encontró información relacionada, y cada una
software
de las referencias, lo cual permitió dar respuesta a las preguntas orientadoras planteadas
al inicio de la RSL. A continuación, se describen los capítulos o secciones que dan
respuesta a cada una de las preguntas de orientación.
 Pregunta 1: ¿Cuáles son las características que permiten medir la legibilidad del código
fuente de un software?
Esta pregunta se responde con el capítulo 4.
 Pregunta 2: ¿Qué métodos son utilizados para obtener el valor de medida de cada una
de esas métricas de forma automática?
Esta pregunta se responde con el capítulo 5.
 Pregunta 3: ¿Cuáles son los principales retos y aplicaciones de interés en las

investigaciones relacionadas con la legibilidad del software?
Esta pregunta se responde con todo el capítulo 6.

La revisión sistemática de literatura, abreviada como RSL, es el principal método usado
para hacer la síntesis de los mejores estudios científicos de calidad sobre un tema
específico o una pregunta de investigación, lo cual se denomina evidencia [13]. Siguiendo
los lineamientos de Kitchenham et al. (2018) [13], se establecieron 5 fases para esta RSL.
Las cuatro primeras corresponden a las actividades misionales de la propuesta, mientras
la quinta fase corresponde al proceso transversal de monitoreo y revisión de las
actividades. A continuación, se describen las fases:
 Fase 1: Estrategia de búsqueda: permitió que el proceso fuera guiado de forma

objetiva, identificando la bibliografía relevante de forma imparcial. La estrategia de
búsqueda contiene: las preguntas orientadoras; selección de las bases bibliográficas
para realizar la búsqueda; Los tipos de estudios recolectados: actas de congreso,
artículo de revista y sección de libro; Los términos usados: palabras clave y ecuaciones
de búsqueda que fueron 3 principales y 2 auxiliares; selección de la herramienta
Mendeley para la gestión bibliográfica; definición de los criterios de inclusión y
exclusión; diseño de la lista de chequeo de calidad; diseño de los formularios de
extracción de datos: hoja de cálculo y archivos de texto; y la definición del plan de

revisión.
 Fase 2: Recolección de documentos, utilizando como guía la estrategia de búsqueda
definida en la fase 1.
 Fase 3: Revisión de resultados de la búsqueda: Se revisaron los trabajos recolectados
en la fase 2 utilizando los criterios de inclusión y exclusión establecidos anteriormente,
evaluando las contribuciones de cada uno de los artículos y determinando cuales
pasaban a formar parte del corpus del trabajo final. Se realizaron en total 3 filtros: el
primero leyendo sólo el título y el resumen del documento; el segundo filtro se realizó
leyendo la sección de resultados y conclusiones, así como realizando una búsqueda
rápida del uso de los términos “legibilidad” y “métricas”; el tercer filtro se realizó con la
lectura completa de los documentos.
 Fase 4: Análisis y presentación de resultados: síntesis de los datos, lo que implicó
resumir los resultados recopilados en los estudios primarios. Se realizó una síntesis
descriptiva y se complementó con un resumen cuantitativo. Para la síntesis descriptiva,
se utilizaron tablas y figuras que permitieron resaltar similitudes y diferencias entre los
estudios, así como presentar la evolución en el tiempo de la legibilidad del código
fuente.
 Fase 5: Monitoreo: Utilizando el plan de revisión establecido en la fase 1, se mantuvo
la comunicación con el director de trabajo final y con la monitora de la maestría la
ingeniera Marcela Cardona, dando a conocer los avances, correcciones, inquietudes e
inconvenientes. Los medios de comunicación utilizados fueron: correo electrónico,
video llamada por Hangouts, carpetas de archivos compartidas en drive, reuniones
personales y llamadas telefónicas.
Al realizar la búsqueda en las fuentes se obtuvieron 308 resultados, de los cuales se

recolectaron 130. Luego se les aplicó el segundo filtro realizando lectura de los resultados,
logrando reducir la cantidad a 62. Se encontraron documentos duplicados, por lo que
fueron fusionados reduciendo la muestra a 33 estudios. A los 33 documentos se les realizó
lectura completa, seleccionando finalmente 24 archivos, los cuales fueron usados para
extraer los datos de interés. Adicionalmente, a los 24 documentos obtenidos con la RSL,
se sumaron 6 documentos que fueron utilizados en el año 2018 para la elaboración de la
software
propuesta del trabajo, logrando un total de 30 documentos que fueron utilizados para
responder las 3 preguntas de investigación en los capítulos 4, 5 y 6.
4. Capítulo 4. Características y métricas de

legibilidad del software
El término característica, en el contexto de la legibilidad del software, hace referencia a un
aspecto o cualidad del código fuente, que es tenido en cuenta para poder medir la
legibilidad. En algunos de los estudios relacionados con los modelos de legibilidad del
software, los autores propusieron, o mencionaron, algunas características del código
fuente, que consideraron, permitían medir la legibilidad de un fragmento. Las métricas, son
indicadores que permiten medir cuantitativamente las características propuestas para la
legibilidad del software. En este capítulo, se presenta el listado de las características y
métricas encontradas en la literatura, y se analiza y presenta, de acuerdo a los resultados
encontrados en esas investigaciones, las más relevantes.
4.1 Características para medir la legibilidad del código

fuente
Las características que se presentan en la Tabla 14, han sido extraídas de los estudios
recolectados y seleccionados de la RSL, y corresponden no sólo a los trabajos
relacionados a los modelos de legibilidad, sino a todos los estudios encontrados. Algunas
de las características presentadas fueron propuestas por los autores, mientras otras fueron
mencionadas por haber sido encontradas en estudios previos al año 2015.
Capítulo 4. Características y métricas de legibilidad del software 67
Tabla 14. Listado general ordenado de características de legibilidad del software.
Autores
Buse et Alawad Posnett Dorn Scalabrino Aman Borstler Choi Liu et Mi et Novais
Característica al. et al. et al. (2012) et al. et al. et al. et al. al. al. et al.
(2010) (2018) (2011) [6] [45] (2016- (2015) (2016) (2018) (2015) (2016) (2017)
[1] [5] [10][45] 2018) [25] [18] [27] [33] [37] [12]
[7] [45]
Java Java Java Java Java Java Java Java Java Cy --
C++
# Promedio de M A B A A
Espacios en
blanco
(identación)
# promedio de M A M A
Comentarios
# Máximo de B A B A
Espacios en
blanco
(identación)
Líneas de A A
código (LOC)
Longitud A M M
promedio de
línea (# de
caracteres)
Longitud A M M
máxima de
línea
(caracteres)
Legibilidad de M A
los
comentarios -
CR
# promedio de A M
Paréntesis
# promedio de B B A
operadores
aritméticos
Entropía8 B A
Volumen del A
programa9
# promedio de A
Identificadores
# Líneas de A
comentarios
dentro de un
método - LCM
nombres A
significativos
Control A
anidado
máximo
Longitud de A
los
comentarios
# promedio de M M
palabras clave
8 Entropía, es una medida de desorden que refleja la complejidad para mantener un software.
9 Volumen del programa, hace referencia a la cantidad de líneas y caracteres de un algoritmo.
Autores
(2010) (2018) (2011) [6] [45] (2016- (2015) (2016) (2018) (2015) (2016) (2017)
[1] [5] [10][45] 2018) [25] [18] [27] [33] [37] [12]
[7] [45]
C++
# promedio de M B
Comas
# promedio de B M
líneas en
blanco
# promedio de B M
bifurcaciones
(if)
# máximo de B M
palabras clave
Longitud M B
máxima del
identificador
# máximo de M
Identificadores
# máximo de M
ocurrencias de
algún
identificador
Preferencia de M
nombres
Estilo de M
comentarios
# de LOCom M
% de LOCom M
# máximo de M
ocurrencias de
algún caracter
# de métodos M
# de clases M
# de M
declaraciones
# de LOC M
% de LOC M
# de M
expresiones
relevantes de
legibilidad
# líneas en M
blanco
% líneas en M
blanco
Longitud de M
identación
Ciclos10 M
Longitud B B
promedio del
identificador
# promedio de B B
números11
10Un ciclo es un bloque de líneas de código que se repiten, mientras se cumpla una condición.
11# promedio de números, es la cantidad promedio de literares numéricos que se encuentran en
una sección de código.
Autores
(2010) (2018) (2011) [6] [45] (2016- (2015) (2016) (2018) (2015) (2016) (2017)
[1] [5] [10][45] 2018) [25] [18] [27] [33] [37] [12]
[7] [45]
C++
# máximo de B B
números
# promedio de B B
operadores de
comparación
# promedio de B B
bucles (for,
while)
# promedio de B B
asignaciones
Consistencia B
de los
comentarios e
identificadores
- CIC
Términos de B
identificadores
en diccionario
- ITID
Identificadores B
de significado
restringido -
NMI
Número de B
significados -
NM: Cuantos
significados
tiene una
misma
palabra.
Coherencia B
textual - TC:
Mide la
cohesión de
las clases
dentro del
código.
Número de B
conceptos -
NOC
Métodos de B
cadena12
Métrica de B
volumen de
Halstead
Cadena de B
palabras
(Strings)
Constantes B
Expresiones B
# promedio de B
puntos
12
El Método de cadena es un estilo de programación orientado a objetos, que consiste en que un
método que retorna un objeto puede ser usado como fuente para llamar a otro método.
En la Tabla 14, el nivel de relación de la característica con la legibilidad está representado

por A de alto, M de medio y B de bajo. Ese nivel de relación proviene de los resultados
finales que tuvieron cada uno de los autores en sus investigaciones, y refleja si la relación
de la característica con la predicción de la legibilidad del código fue alta, es decir, si influyó
o no en la predicción final, en cuyo caso es baja. Adicionalmente, para presentar el listado
de características en orden de relevancia, se utilizaron en la tabla fondos de colores verde,
azul y gris. El color verde representa las características más relevantes para evaluar la
legibilidad en un fragmento de código fuente. El color azul, las características
medianamente relevantes, y en color gris las menos frecuentes. Cada característica fue
ubicada en una franja de color de acuerdo a los niveles de relación encontrados (A, M y B)
y a la cantidad de trabajos que los mencionaban. En la franja verde, se encuentran los que
tienen al menos 1 mención de tipo A, o dos menciones de tipo M; en la franja azul, se
presentan las características medianamente relevantes, las cuales son las que tienen sólo
1 mención de nivel M; y en la franja de color gris, se encuentran las características que,
sin importar la cantidad de menciones, son de nivel B, es decir, en los resultados tuvieron
poca relación con la legibilidad, así que son los de menor importancia.
En la Tabla 14, se observa que las características del software que obtuvieron mejores
resultados de correlación con el juicio de legibilidad, de mayor a menor, fueron las
relacionadas con espacios en blanco (identación), comentarios, LOC, número de
paréntesis, número de operadores aritméticos, entropía, volumen del programa, número y
nombre de los identificadores, estructuras de control y número de palabras clave.
Los comentarios son importantes porque reflejan lo que el programador quiso realizar en
el código y generalmente son usados para mejorar la comprensión de los programas [25].
Sin embargo, a veces pueden ser usados para disimular la falta de legibilidad en el
software, y por ello un comentario bien escrito es considerado como un “desodorante para
disimular los malos olores” [25]. Debe tenerse en cuenta, que la programación es una
actividad que depende de la mente y la experiencia de cada desarrollador, por lo cual
diferentes programadores pueden escribir diferentes programas para la misma
especificación, y por ello es importante ir evaluando y controlando la calidad del programa
[25].
Aman et al. (2015) [25] analizaron los métodos en lenguaje Java de 4 proyectos de código
abierto y encontraron que los métodos mejor comentados son 1.6 a 2.8 más propensos a
fallos que los que no. Con mejor comentados, se refirieron sólo a la cantidad de líneas de
comentarios, no a la calidad del contenido, ni a la longitud de las mismas [25]. Un año más
tarde, en el 2016, Borstler et al. [18] realizaron un experimento con 104 estudiantes en una
universidad de Alemania, que cursaban asignaturas de programación, para evaluar la
relación entre las características personales de los participantes y la legibilidad del
software, así como la importancia de los métodos de cadena13 y los comentarios en la
legibilidad de los fragmentos de código fuente escritos en los lenguajes C++ y Java. Los
resultados del experimento, fueron que la presencia de los métodos de cadena no influyó
en el juicio de legibilidad, mientras que la presencia de los comentarios, sin importar si eran
buenos o malos, si influyó [18]. Adicionalmente, al evaluar la relación de las características
de los participantes con los juicios entregados, se encontró que los hombres tuvieron
mayor percepción de legibilidad que las mujeres [18].
Por otra parte, Fakhoury et al. (2018) [31] exploraron el efecto de un pobre léxico en el
código fuente y la legibilidad sobre la carga cognitiva, medido por una técnica de imagen
cerebral funcional de vanguardia y mínimamente invasiva llamada espectroscopía de
infrarrojo cercano funcional (fNIRS). En los resultados de la investigación, evidenciaron un
incremento significativo en la carga cognitiva de los participantes [31]. Cuando al código
fuente se le introdujeron anti patrones lingüísticos e inconsistencias estructurales, no
incrementó la carga cognitiva, pero sí incrementó en un 60% el porcentaje de participantes
que no pudieron completar las tareas [31]. Usando el rastreador ocular EyeTribe, los
participantes miraron el código en el IDE Eclipse, conectado al Plugin iTrace, lo que
permitió determinar los elementos del código fuente que estaban viendo, mediante el uso
de gafas bifocales y trifocales [31].
Continuando con los estudios relacionados con el efecto de la legibilidad en la carga

cognitiva del lector, en el año 2019, Wulff-Jensen et al. [41] desarrollaron un experimento
utilizando la técnica de seguimiento ocular con 21 estudiantes de la Universidad de
Copenhague (Dinamarca), con el objetivo de evaluar la legibilidad y la comprensibilidad de
13
El método de cadena es un estilo de programación orientado a objetos, que consiste en que un
método que retorna un objeto puede ser usado como fuente para llamar a otro método.
4 fragmentos de código fuente con presencia o ausencia de ciertas características

estructurales y textuales definidas en la literatura. Los parámetros de seguimiento ocular,
utilizados para evaluar la correlación con la carga cognitiva, fueron: pupilometría, velocidad
Saccade, duración de la fijación y dirección [41]. Se realizó el cuestionario en Google
Forms y en cada computador se conectó un EyeTribe de seguimiento ocular para capturar
la mirada [41]. El computador tenía las siguientes especificaciones: Procesador.
Intel®Core™ i7-4720HQ CPU @ 2.60 GHZ 2.59 GZ, 16.00 GB de RAM. Sistema operativo
Windows 10 64-bit [41]. Los parámetros del seguimiento ocular, extraídos usando el
programa Ogama, fueron: conteo de las fijaciones por sujeto, promedio de fijaciones por
segundo, duración de la fijación, relación entre número de fijaciones y número de
saccades14, longitud de saccades, velocidad promedio de saccades, tamaño de la pupila
para factores subjetivos y distancia al rastreador de ojos [41]. Los resultados del estudio,
fueron que la ausencia de elementos estructurales provocó que 1) la mirada del lector fuera
más rápida y caótica, 2) causó una mayor carga cognitiva en el lector, y 3) incrementó la
duración promedio de la fijación [41].
Por otra parte, Akour et al. (2016) [14] indicaron que los modelos de medición de la
legibilidad del software deben ser especializados, teniendo en cuenta el dominio de la
aplicación y el lenguaje de programación en el cual está desarrollado [14]. Los autores
explicaron que las características evaluadas para determinar la legibilidad del software no
pueden medirse de la misma forma en una aplicación A y en una aplicación B de un
dominio diferente, porque hay unos lenguajes de programación que facilitan más la
legibilidad que otros, debido a la naturaleza misma de su sintaxis, o de acuerdo a su
paradigma, que puede ser procedimental, funcional, imperativo, orientado a objetos, lógico
o simbólico [14]. De acuerdo a lo anterior, las métricas propuestas por los diferentes
autores deberían tener la posibilidad de tener factores de legibilidad variables, que se
adapten a un código fuente teniendo en cuenta su dominio y su lenguaje de programación
[14].
Akour et al. (2016) [14] argumentaron que cuando se va a desarrollar un software y se

define el dominio al que corresponde, eso condiciona la elección del lenguaje de
programación que se usará, teniendo en cuenta que algunos lenguajes se especializan o
14 Un Saccade se refiere a un movimiento rápido del ojo entre puntos de fijación.

facilitan el desarrollo de algunas operaciones. A continuación, en la Tabla 15, se presenta

una recopilación del autor de los lenguajes de programación recomendados de acuerdo al
dominio de la aplicación [14].
Tabla 15. Lenguajes de programación recomendados de acuerdo al dominio de la

aplicación (de acuerdo a Akour et al [14] en 2016).
Dominio Lenguaje de programación

Negocios Lenguaje COBOL. Usado en el 70% de las transacciones de negocios a
nivel mundial. PL/B también es un lenguaje moderno popular en el
dominio de negocios.
e-commerce PHP, Ruby.
Herramientas de PHP y Java son los lenguajes más populares. Otros son, Python,
gestión de proyectos ASP.NET, Ruby, C, y SQLite.
CMS (sistemas de La mayoría con PHP (11) y 1 con Ruby.
gestión de
contenido)
Inteligencia artificial Lenguajes Lisp, Prolog (es más conciso para éste y programación no-
numérica).
Desarrollo de C, Lua, and C++. Para el acceso rápido al hardware de la pantalla.
videojuegos
Sistemas embebidos C, C++, and java, porque ofrecen varias funcionalidades como
expresiones, flujo de control, funciones recursivas, excepciones,
recolector de basura.
Computación en la El Mapreduce es un modelo computacional utilizado para procesar

nube grandes conjuntos de datos de manera masivamente paralela. Las
bibliotecas de este modelo computacional han sido escritas en C ++ y en
java.
En la Tabla 15 se presenta la información en tres (2) columnas: la primera con el dominio

de la aplicación, la segunda con los lenguajes de programación que se recomienda usar
para desarrollar el software que corresponde al dominio. El aporte de esta información para
el tema de legibilidad del software, consiste en que, en el futuro, cuando se pueda
desarrollar la herramienta o algoritmo que permita medir la legibilidad del software en
tiempo de desarrollo, pueda seleccionarse el dominio de la aplicación, y de acuerdo a éste,
las características de legibilidad evaluadas se ajusten al lenguaje de programación
utilizado.
4.2 Métricas de legibilidad del software

Una métrica de legibilidad del software, es la medida de una o varias características del
software, que permiten cuantificarla. De acuerdo a lo anterior, para este trabajo se
clasifican las métricas en dos tipos: las simples, que consisten en tomar la medida por un
conteo; y las compuestas, donde la forma de medir es más compleja y requiere de una
ecuación para relacionar 2 o más métricas simples.
En la Tabla 16, se exponen las métricas simples encontradas para el lenguaje Java, y en
la Tabla 17 las métricas simples para el lenguaje C y C++.
Tabla 16. Listado de métricas simples en Java.
No. Nombre de la métrica Referencia

1 Número promedio de espacios en blanco (identación) [5] [1] [6] [18] [27]
2 Número promedio de comentarios [5] [1] [6] [27]
3 Número máximo de espacios en blanco (identación) [5] [1] [6] [18]
4 Longitud promedio de línea (número de caracteres) [1] [6] [37]
5 Longitud máxima de línea (número de caracteres) [1] [6] [37]
6 Número promedio de paréntesis [1] [6]
7 Número promedio de operadores aritméticos [1] [6] [27]
8 Volumen del programa [27]
9 Número promedio de Identificadores [1]
10 Número de líneas de comentarios dentro de un método (LCM) [25]
11 Número máximo de bucles anidados [27]
12 Longitud de los comentarios [18]
13 Número promedio de palabras clave [1] [6]
En la Tabla 16, se presentaron las métricas simples encontradas en la literatura, las cuales
consisten en un conteo sencillo de las ocurrencias de una característica en el código, o en
medir su tamaño. En la columna referencia, se indica la fuente de literatura en la cual se
encontró. Continuando con las métricas simples, se presenta la Tabla 17, que
corresponden a las métricas de legibilidad del lenguaje C y C++.
Tabla 17. Listado de métricas en C y C++, de la fuente [37].
Categoría de la métrica No. Métrica

1 La relación entre el número de líneas en blanco y el número
de líneas no en blanco.
Métricas de legibilidad para el 2 La relación entre el número de líneas de comentarios y el
estilo de comentarios número de líneas sin comentarios, es decir, líneas de
código puro.
3 La relación entre el número de líneas de comentario puro y
el número de líneas de comentario.
Categoría de la métrica No. Métrica

4 La relación entre el número de líneas de código con
comentarios en línea y el número de líneas de comentarios.
5 La relación entre el número de comentarios de una sola
línea (símbolo // ) y el número de LOC15 físicos.
6 La relación entre el número de comentarios de varias líneas
(la pareja de símbolos / * y * / ) y el número de LOC físicos.
7 La relación entre el número de comentarios de tipo TODO 16
y el número de líneas no en blanco.
8 Porcentaje de caracteres en mayúscula para el nombre de
la función.
9 Porcentaje de caracteres en minúscula para el nombre de la
función.
10 Porcentaje de caracteres numéricos para el nombre de la
función.
11 Porcentaje de caracteres de subrayado para el nombre de
la función.
Métricas de legibilidad para la 12 Porcentaje de caracteres en mayúscula para el nombre de
preferencia de nombres la variable.
13 Porcentaje de caracteres en minúscula para el nombre de la
variable.
14 Porcentaje de caracteres numéricos para nombre de
variable..
15 Porcentaje de caracteres de subrayado para el nombre de
la variable.
16 Longitud promedio del nombre de la función.
17 Longitud promedio del nombre de la variable.
Métricas de legibilidad para la 18 Promedio físico de LOC por función.
longitud de línea 19 Longitud promedio de línea de un LOC físico.
Continuando con el listado, se presentan en la Tabla 18 las métricas compuestas, las

cuales son más elaboradas e involucran a 2 o más características en una misma ecuación.
Tabla 18. Listado de métricas compuestas.
Métrica Descripción Uso Referencia

tradicional
ARI : Índice de Se basa en la relación entre la dificultad de la Legibilidad del [5] [29][38]
legibilidad oración y la dificultad de la palabra. La dificultad texto
de las oraciones se determina como palabras por
automático. oración, y la dificultad de las palabras es al
calcular letras por palabras.
Ecuación:
ARI = 4.71 (caracteres) + 0.5 (palabras) - 21.43
El valor de ARI significa el nivel de grado escolar

necesario para que una persona comprenda ese
texto.
15 LOC significa líneas de código fuente, por sus siglas en inglés.

16 Si un comentario contiene la palabra TODO, significa que el código está en un estado incompleto.

tradicional
SMOG: Medida Autor: G Harry McLaughlin [22] en 1969. Legibilidad del [5] [29] [38]
simple de texto
SMOG representa el nivel de grado escolar
Gobbledygook. necesario, para que una persona pueda leer ese
texto.
Ecuación:
SMOG = 3 + Raíz cuadrada de recuento
polisillable (conteo de palabras)
FKI: Índice de Ecuación: Legibilidad del [5] [29] [38]
legibilidad de FKI = 206.835 – (1.015 * (palabras totales / texto
sentencias totales)) - 84.6 * (silabas totales /
Flesch-Kincaid. palabras totales)
Un alto FKI indica una alta legibilidad del código,

y un valor bajo que el código es difícil de leer. El
rango es de 0 a 100.
GFI: El índice de Autor: Robert Gunning. Legibilidad del [5] [29] [38]
confusión de texto
Utiliza la longitud promedio de las oraciones y el
Gunning, porcentaje de palabras difíciles.
también conocida
como FOG. Ecuación:
GFI = 0.4 (ASL + PHW)
donde,
ASL = longitud promedio de la oración y
PHW = porcentaje de palabras difíciles.
Un puntaje GFI de 5 significa legible, 10 significa

duro, 15 significa difícil y 20 indica muy difícil.
CLI: Índice Autores: Meri Coleman y T. L. Liau. Legibilidad del [5] [29] [38]
Coleman-Liau. texto
Ecuación:
CLI = 0.0588L - 0.296S - 15.8
donde,
L = número promedio de letras
S = número promedio de sentencias
CLI representa el nivel de grado escolar

necesario, para que una persona pueda leer
adecuadamente ese texto.
SRES: Modelo Autores: Abbas, Borestler, Cspersend, and Legibilidad del [28]
de fácil puntaje Nordstrin (2009). código fuente
de legibilidad de Ecuación:
software. SRES = ASL - 0.1 AWL
Dónde, ASL es la métrica de longitud promedio

de sentencia, que es el número promedio de
tokens por declaración, y AWL es la métrica de
longitud promedio de palabra.
A mayor SRES, más difícil para leer.


tradicional
BW: Puntuación Autores: Buse y Weimer. Legibilidad del [5]
de legibilidad de código fuente
BW es el puntaje obtenido en el clasificador de
Buse et al. Buse y Weimer, en el cual, teniendo un
fragmento de código fuente como entrada, se
obtiene una predicción de legibilidad del mismo.
PHD: Puntuación Autores: Posnett et al. (2011). Legibilidad del [28] [11]
de legibilidad de código fuente
Ecuación:
Posnett et al. PHD = 1 / (1 + e-z)
Dónde,
Z = 8.87 – 0.033 V + 0.40 LOC -1.5 H
Dónde, V es el volumen de Halstead, LOC las

líneas de código y H es la información Shannon
de tokens, cuyas fórmulas son:
V = N log2 n
H(s) = ∑ni=1 pi log pi
Dónde, pi es la fracción de tokens (si) en una

fuente S
Legibilidad Ecuación: Legibilidad del [27]
cuantitativa código fuente
Legibilidad = (-0.020) * (LOC) + (0.040) * (# de
optimizada de comentarios) + (0.037) * (# de líneas en blanco)
Choi. + (-0.755) * (# de operadores bit a bit) + (-0.153)
* (control anidado máximo) + (-0.001) *
(Volumen de programa) + (-0.611) * (Entropía)
WSCR: métrica WSCR determina el puntaje de legibilidad para Legibilidad del [29]
de legibilidad un documento WSDL17 d. Considera las texto
características: alcance del documento,
centrada en el cohesión del documento y el índice simplificado
servicio web. de Dale-Chall.
WSCR(d) = Alcance(d) + Cohesión(d) +

DaCw(d)
El modelo utilizó los términos existentes del

diccionario de WordNet18, como entrada para
calcular el valor de legibilidad.
CR: métrica de Esta métrica se encuentra dentro de la Legibilidad del [32]
legibilidad del herramienta RETICULA, y permite la medición código fuente
mediante la explotación del conjunto de
código. características, tales como, el nivel de anidación
del código, la longitud promedio de las
declaraciones, etc.
RETICULA es un Plugin para el IDE IntelliJ,

propuesto por Frunzio et al. (2018), que permite
17 WSDL, significa lenguaje de descripción de servicios web, por sus siglas en inglés, y es un
programa con una interfaz bien definida que puede ser publicada, localizada e invocada usando un
protocolo de estándar web [29].
18 https://wordnet.princeton.edu/

tradicional
a los desarrolladores percibir la calidad del
código durante la fase de desarrollo, es decir, en
tiempo de desarrollo. Tiene un panel para
configurar las métricas que se desean medir y las
características que deben tener los proyectos de
software usados desde GitHub para realizar la
comparación.
AR: promedio de Autor: Liu et al. (2015) Legibilidad del [33]
legibilidad. código fuente
Ecuaciones:
AR = |Comentarios válidos| / |Todos los
RiC: legibilidad resultados|
en la clase.
RiC = |comentarios válidos en la clase| / |todos
los resultados en la clase|
RiG: legibilidad
en el paquete. RiG = sumatoria de todos los RiC del paquete
Si Ric o RiG < AR, entonces la legibilidad es

baja.
Si Ric y RiG > AR, entonces es legible.
CIC: Autor: Scalabrino et al. (2018). Legibilidad del [45]
Consistencia de código fuente
Ecuación:
los comentarios e CIC (m) = |comentarios(m) ∩ identificadores(m)
identificadores. | / |comentarios(m) U identificadores(m)|
donde, m es el método.
Teniendo en cuenta que pueden existir

sinónimos de las palabras en comentarios y en
identificadores, se tiene una variación de la
ecuación:
CIC(m)sin = |comentarios(m) ∩
identificadores(m) U sinónimos(m)|/
|comentarios(m) U identificadores(m) U
Sinónimos(m)|
donde,
sinónimos: es el conjunto de todos los sinónimos
de los términos que están en los identificadores.
ITID: Términos Autor: Scalabrino et al. (2018). Legibilidad del [45]
del identificador código fuente
Fue inspirado por las características de lenguaje
en diccionario. natural (lingüísticas) introducidas por Dorn.
ITID(I) = |Terminos(I) ∩ Diccionario| /

|Terminos(I) |
donde,
Términos: es el conjunto de términos extraídos
de una línea I de un método.
Diccionario: es un conjunto de palabras en un
diccionario.
NMI: Autor: Scalabrino et al. (2018) Legibilidad del [45]
Identificadores código fuente

tradicional
de significado Los términos deben tener un significado
estrecho. específico, no genérico que pueda generar
confusiones.
NMI(I) = ∑t ∈I particularidad(t)
donde,
t: es un término extraído de la línea de código I.
particularidad(t): es calculado como el número
de saltos desde el nodo t que lo contiene hasta
el nodo raíz del árbol hypernym19 de t. Usan el
árbol hypernym/hyponym20 del lenguaje inglés
definido para WordNet.
CR: Legibilidad Autor: Scalabrino et al. (2018). Legibilidad del [45]
de los código fuente
Calcula la legibilidad de los comentarios (CR)
comentarios. usando el índice Flesch-Kincaid comúnmente
utilizado para evaluar la legibilidad de textos en
lenguaje natural. El índice considera 3 tipos de
elementos: palabras, sílabas y frases.
Ecuación:
FK(S) = 206.835 - 1.015*(palabras(S)/frases(S))
- 84.600*(sílabas(S)/Palabras(S))
donde,
S: es el fragmento de código fuente.
Se calcula el CR al (1) juntar todas las líneas

comentadas del fragmento S; (2) unir los
comentarios con un carácter ".", para asegurar
de que no se unan diferentes comentarios
creando una sola frase; y (3) calcular el índice de
Flesch-Kincaid en dicho texto.
NM: número de Autor: Scalabrino et al. (2018). Legibilidad del [45]
significados. código fuente
El significado de una palabra puede ser
polisémico (tener más de un significado). La
característica mide el número de significados
(NM) o el nivel o polisemia de un fragmento.
Miden el número de significados derivados de
WordNet.
TC: Coherencia Autor: Scalabrino et al. (2018). Legibilidad del [45]
textual. código fuente
Se analiza el código fuente y se construye el
árbol de sintaxis abstracta (AST) para detectar
bloques sintácticos. Se calcula la superposición
de vocabulario entre todos los posibles pares de
bloques sintácticos distintos. La coherencia
textual (TC) de un fragmento se puede calcular
como el máximo, el mínimo o la superposición
promedio entre cada par de bloques sintácticos.
NOC: Número de Autor: Scalabrino et al. (2018). Legibilidad del [45]
conceptos. código fuente
19 Hypernym: una palabra cuyo significado incluye un grupo de otras palabras.

20 Hyponym: es una palabra cuyo significado está incluido dentro del significado de otra palabra.

tradicional
Captura directamente el número de conceptos
implementados en un fragmento de código a
nivel de línea. Crea un documento por cada
línea. Utiliza una técnica de clustering basada en
densidad, DBSCAN.
Miden la distancia entre 2 documentos así:
NOCdist (d1,d2) = |d1 ∩ d2| / |d1 U d2|
número de conceptos de un fragmento m:
NOC(m) = |Clusters(m)|
Normalizando NOC:
NOCnorm(m) = |Clusters(m)| / |Documentos(m)|

Legibilidad de la Autor: Xu et al. (2017). Legibilidad del [42]
variable. código fuente
La legibilidad de una variable “v” en un método
“m”, legibilidad (v, m), está definida como:
Legibilidad(v,m) = Concreción(v) X Retención(v)

Legibilidad de un Autor: Xu et al. (2017). Legibilidad del [42]
método. código fuente
La legibilidad de un método o constructor “m” en
una clase “c” está definida como la legibilidad
promedio de todas las variables “V” usadas en
“m”, incluyendo variables locales, parámetros,
constantes nombradas, variables instanciadas y
variables de clase.
Legibilidad(m,c) = ∑ni∈1 Legibilidad(vi, m) / |V|
Legibilidad de la Autor: Xu et al. (2017). Legibilidad del [42]

clase. código fuente
La legibilidad de la clase C en un programa
orientado a objetos P es definido como la
legibilidad promedio de todos los métodos y
constructores en “C”.
Legibilidad(c, P) = ∑ni∈1 Legibilidad(mi, c) / |M|
Legibilidad del Autor: Xu et al. (2017). Legibilidad del [42]

programa. código fuente
La legibilidad de un programa orientado a
objetos P está definida como la legibilidad
promedio de todas las clases en P.
Legibilidad(P) = ∑ni∈1 R(ci, P) / |C|
Como se observó en la Tabla 18, este tipo de métricas requieren un mayor esfuerzo para
ser medidas, debido a la complejidad de sus ecuaciones. Las fuentes bibliográficas que
mencionaron a las métricas, las utilizaron en fragmentos de código fuente escritos en

lenguaje Java.
Luego de analizar la información encontrada en la literatura, se puede llegar a la conclusión

de que las características que mejor funcionan para medir la legibilidad del software son:
 Identación (espacios en blanco): Hace referencia a los espacios en blanco ubicados

antes del primer carácter en una línea de código, los cuales se considera que
brindan orden y una mejor visibilidad.
 Los comentarios: un comentario presenta de forma explícita lo que hace una
sección del código, como una función. La sola existencia de un comentario en un
método, es considerado un factor de legibilidad.
 Líneas de código: para un lector es más legible un fragmento de código fuente, con
líneas de código cortas, que largas.
 Paréntesis: a mayor número de paréntesis anidados en una línea de código, es
más complejo para el lector, y por tanto, menos legible.
 Operadores aritméticos: la cantidad de operadores aritméticos en una misma línea
de código, es inversamente proporcional a su legibilidad.
 Estructuras de control: a mayor número de estructuras de control anidadas, menor
es la percepción de legibilidad.
 Nombre de los identificadores: el nombre debe tener un significado relacionado al
papel que desempeña en el código fuente.
De igual forma, las métricas relacionadas con las características anteriormente expuestas,
que mejor funcionaron en los estudios realizados por los autores para medir la legibilidad
del software fueron: la cantidad de espacios en blanco, la cantidad de comentarios, la
longitud de la línea de código y la cantidad de paréntesis. Adicionalmente, las métricas de
tipo compuestas que también presentaron buenos resultados fueron: la métrica de Posnett
abreviada como PHD, la métrica WSCR para el código fuente en lenguaje WSDL (servicios
web) y la legibilidad de los comentarios (CR) propuesta por Scalabrino et al.

El Capítulo 4 permite responder la primera pregunta de investigación: ¿Cuáles son las
características que permiten medir la legibilidad del código fuente de un software?.
La característica, en el contexto de la legibilidad del software, hace referencia a un aspecto

o cualidad del código fuente, que es tenido en cuenta para poder medir la legibilidad. Las
características más representativas para medir la legibilidad del software, porque
obtuvieron mejores resultados de correlación con el juicio de legibilidad, fueron las
relacionadas con espacios en blanco (identación), comentarios, LOC (líneas de código),
paréntesis, operadores aritméticos, entropía, volumen del programa, identificadores,
estructuras de control y palabras clave [5] [1] [7] [10] [6] [37] [18] [45] [25] [27] [33].
Los comentarios son importantes porque reflejan lo que el programador quiso realizar en
el código y generalmente son usados para mejorar la comprensión de los programas [25].
Borstler et al., encontraron que la presencia de los comentarios, sin importar si son buenos
o malos, influye en la percepción de legibilidad [18]. Sin embargo, a veces pueden ser
usados para disimular la falta de legibilidad en el software, como lo demostró Aman et al.
(2015) [25], quienes analizaron los métodos en lenguaje Java de 4 proyectos de código
abierto y encontraron que los métodos mejor comentados son 1.6 a 2.8 más propensos a
fallos que los que no.
Otros autores, como Fakhoury et al. (2018) [31], exploraron el efecto de un pobre léxico en
el código fuente y la legibilidad sobre la carga cognitiva, medido por una técnica de imagen
cerebral funcional de vanguardia y mínimamente invasiva llamada espectroscopía de
infrarrojo cercano funcional (fNIRS), encontrando que dificulta que los participantes puedan
completar las tareas [31]. Por otro lado, Wulff-Jensen et al. [41], encontraron que la
ausencia de elementos estructurales provocó que 1) la mirada del lector fuera más rápida
y caótica, 2) causó una mayor carga cognitiva en el lector, y 3) incrementó la duración
promedio de la fijación [41].
Para poder medir cuantitativamente las características propuestas para la legibilidad del
software, se utilizan las métricas. Para este trabajo final, se clasifican las métricas de
legibilidad del software en dos tipos: las simples, que consisten en tomar la medida por un
conteo, y las compuestas, donde la forma de medir es más compleja y requiere de una
ecuación para relacionar 2 o más métricas simples. Las métricas simples consisten en un
conteo sencillo de las ocurrencias de una característica en el código, o en medir su tamaño,
mientras que, las compuestas, son más elaboradas e involucran a 2 o más características
en una misma ecuación. Algunos de los modelos de legibilidad propuestos, incorporaron
alguna de estas métricas en su algoritmo, permitiendo tomar la medida automáticamente.
El capítulo 4, permite dar cumplimiento parcialmente al objetivo número 2 establecido en

este trabajo final, el cual era "Sintetizar los resultados en términos de la evolución de las
métricas de legibilidad del software, las características utilizadas para su medición y los
métodos automáticos de medición". En el siguiente capítulo se terminarán de sintetizar los
resultados correspondientes a este objetivo. En particular, se dará respuesta a la pregunta
de investigación número 2.
5 Capítulo 5. Modelos de legibilidad del

software
Los modelos de legibilidad del software, son algoritmos que permiten clasificar un
fragmento de código fuente como legible o no legible de forma automática. El primer
modelo fue presentado por Buse y Weimer en el año 2010 [1], quienes demostraron que
era posible medir algo subjetivo como lo es la legibilidad, lo que permitió que otros
investigadores continuaran los estudios. En este capítulo, se presenta la evolución en el
tiempo de los estudios relacionados con la legibilidad del software, los cuales permitieron
desarrollar los modelos automáticos para su medición. También, se presentan las
características evaluadas con cada modelo propuesto, las técnicas utilizadas, los
lenguajes de programación de los fragmentos de código fuente usados para el
entrenamiento de los modelos y las pruebas, así como los repositorios de datos que se
encuentran disponibles para la replicación de los estudios.
5.1 Evolución de la legibilidad del software

En el año 2010, Buse y Weimer [1] mediante su trabajo de investigación titulado “Learning
a Metric for Code Readability” realizaron una gran contribución en el área de la medición
de la legibilidad de software, creando el primer modelo de clasificación automática que
permitía predecir este aspecto tan subjetivo. El modelo consistió en un clasificador binario,
entrenado con datos anotados por humanos [1], utilizando técnicas de aprendizaje de
máquina (machine learning en inglés), lo que abrió las puertas para que otros
investigadores se interesaran en el tema y realizaran nuevos aportes, logrando así que en
la actualidad se tengan avances importantes en el tema. En la Tabla 19, se presentan los
Capítulo 5. Modelos de legibilidad del software 85
estudios encontrados en la literatura, que han permitido la evolución en el tiempo de la

legibilidad del software.
Tabla 19. Aportes a los estudios de legibilidad del software en el tiempo.
Año Autor Aporte Referencia

1990 Chung y Yung Introdujeron las métricas de legibilidad [38]
1997 Chung y Yung Propusieron 4 nuevas métricas: cantidad única de [38]
operadores, cantidad única de operandos, cantidad total
de ocurrencias de operadores y la cantidad total de
ocurrencias.
2000 Hunt y En el libro “Pragmatic Programmers” examinaron las [40]
Thomas herramientas, procesos y trucos que ayudan a los
programadores a dominar su oficio
2002 Aggarwal et al. Mostraron el impacto que tiene la legibilidad en el [11]
mantenimiento del software y en los casos de prueba.
Estimaron la legibilidad por el promedio de todas la
líneas para comentar líneas.
2005 Relf Estudió la influencia de los nombres de los [40]
identificadores en la legibilidad.
Herramienta de Relf para apoyar a los desarrolladores
en mejorar los nombres de las variables y los métodos.
2006 Emilio y Mostraron la relación de la legibilidad del software con [38]
Valerdi los costos de desarrollo del software, donde una mayor
legibilidad, requiere menor tiempo para el
mantenimiento, lo que significa menores costos en el
ciclo de vida del software, y poca legibilidad representa
mayor costo en el ciclo de vida del software.
2006 Collar y Propusieron que la legibilidad debería tener en cuenta [14]
Valerdi la estructura del código.
2006 Beck En el libro “Implementation Patterns”, abordaron buenos [40]

patrones de diseño para desarrollar software.
2006 Liblit et al. Estudiaron la influencia de los nombres de los [40]
identificadores en la legibilidad.
2008 Buse et al. Mostraron que la legibilidad está fuertemente [1]
correlacionada con algunos atributos de calidad del
software, tales como cambios de código, mensajes de
registro de defectos e informes automáticos de
defectos.
2008 Martin En el libro “Clean Code” direccionaron técnicas para [40]
ayudar a los desarrolladores a ser mejores
programadores.
2009 Binkley et al. Realizaron un estudio para analizar los efectos de las [35] [40]
convenciones para nombrar un identificador.
2010 Butler et al. Investigaron la relación entre la calidad del código y la [11] [40]
legibilidad. Estudiaron la influencia de los nombres de
los identificadores en la legibilidad.
2010 Buse & Propusieron el primer modelo automático para evaluar [5] [1] [18]
Weimer la legibilidad del software, con una precisión de 80% en [35] [38]
su propio conjunto de datos.

2011 Posnett et al. Propusieron un nuevo modelo automático para evaluar [5] [10] [18]
la legibilidad del software, que dependía principalmente [35][38]
del tamaño y la entropía.
2011 Wang et al. Especificó el rol de la legibilidad del código en el [38] [40]
desarrollo de la calidad de software.
Examinó la inserción automática de líneas en blanco en
el código para mejorar la legibilidad.
2012 Dorn Nuevo modelo automático para evaluar la legibilidad del [5] [6] [35]
software.
2012 Sivaprakasam Presentó un sistema para mejorar la legibilidad del [38]
et al. código, que consistía en agregar líneas en blanco. La
herramienta con el método propuesto tomaba un
método de Java como entrada y retornaba una nueva
versión del código más legible.
2013 Sasaki et al. Propusieron una técnica de re ordenamiento para [35] [40]
acortar la distancia de una variable hasta su referencia,
declarando las variables inmediatamente antes de
utilizarlas, para mejorar la legibilidad.
2013 Lee et al. Probaron que las violaciones en las convenciones de [35]
codificación afectan la legibilidad del software.
2014 Wang et al. Propusieron un algoritmo para insertar líneas blancas [35]
automáticamente para separar los bloques
significativos, mejorando la legibilidad.
2015 Allamanis et al. Propusieron un modelo para generar sugerencias [36]
automáticas de nombres para el método y la clase de
acuerdo a su contenido.
2015 Daka et al. Encontraron que las pruebas no leíbles son difíciles [11]
para mantener y pierden valor para los desarrolladores.
2015 Liu et al. Modelo de legibilidad, que analiza la correlación de la [33]
semántica entre el código y los comentarios, usando
WordNet21. Adicionalmente, propusieron 3 nuevas
métricas.
2016 Scalabrino et Propusieron un nuevo modelo de legibilidad, con [5] [35] [45]
al. características textuales adicionales, basadas en el
análisis léxico del código fuente.
2016 Borstler et al. Propusieron el SRES, un puntaje fácil de legibilidad de [35]
software, para evaluar la legibilidad de acuerdo a la
longitud promedio del lexema y al número promedio de
palabras por declaración o bloque.
2017 Pahal et al. Realizaron una revisión de métricas para la calidad del [5]
software. Concluyeron que la elección de las métricas
de legibilidad depende de diferentes empleos.
2017 Xu et al. Modelo de legibilidad, con enfoque basado en WCRM: [42]
concreción de palabras y retención de memoria de
nombres de variable. Adicionalmente, propusieron 4
nuevas métricas.
2018 Scalabrino et Propusieron nuevos modelos automáticos para evaluar [5] [45]
al. la legibilidad del software.
2018 Alawad et al. Confirmaron empíricamente la sabiduría existente de [5]
que la legibilidad y la complejidad están correlacionadas
negativamente.
21 https://wordnet.princeton.edu/

2018 Choi et al. Propusieron el modelo cuantitativo optimizado de [27]
2018 Mi et al. Propusieron 2 modelos de legibilidad, que utilizaban el [35] [36]
aprendizaje profundo (Deep learning en inglés), sin
proponer ninguna característica en particular. Un
modelo utilizó las redes neuronales convolucionales y el
otro la arquitectura de inicio (Inception en inglés).
Como se presentó en la Tabla 19, han sido varios los autores que han realizado
importantes aportes a la legibilidad del software, encontrando registros desde 1990. La
tabla que se encuentra ordenada por el año, presenta la descripción breve del aporte
realizado y los autores del mismo. Al analizar los datos encontrados, se observa que los
primeros aportes correspondieron a las primeras métricas propuestas para la legibilidad
del software. A partir del año 2002, se realizaron estudios para evaluar el impacto que tiene
la legibilidad del software en los costos asociados a su mantenimiento, y propusieron
nuevas características para tener en cuenta al medir la legibilidad del software, como los
nombres de los identificadores. En 2006 Collar y Valerdi [14] indicaron que debía tenerse
en cuenta la estructura del código para evaluar su legibilidad, y años después, en el 2010,
Buse y Weimer propusieron el primer modelo para evaluar la legibilidad del software, el
cual tenía en cuenta un conjunto de características de tipo estructurales, propuestas por
los autores. Los años siguientes, continuaron apareciendo nuevos modelos propuestos por
otros autores, pero aún no se considera alguno de ellos como el definitivo. Otro tipo de
aporte que apareció por primera vez en el 2012, consistió en una herramienta para mejorar
automáticamente la legibilidad de un fragmento de código fuente, la cual insertaba
espacios en blanco, lo cual significa que los investigadores no sólo quieren medir la
legibilidad en el software, sino que una vez identificadas las falencias, poderlas corregir de
forma automática. Los primeros modelos de legibilidad, estuvieron enfocados a un
conjunto de características propuestas por los autores, pero en el año 2018, aparecieron
2 nuevos modelos que utilizaron el aprendizaje profundo para evaluar la legibilidad, sin un
conjunto previo de características. Como se pudo apreciar, todos los aportes encontrados,
permitieron obtener un avance considerable en el tema de la legibilidad del software, y
aunque aún no se ha dicho la última palabra, las herramientas, métricas y características
encontradas, permiten tener una base sólida para continuar con los estudios.
5.2 Modelos de legibilidad del software

En el año 2010, Buse y Weimer lograron desarrollar el primer modelo para la predicción de
la legibilidad del software, mediante el entrenamiento de una serie de clasificadores, entre
los que se encontraban el modelo perceptrón multicapa (una red neuronal), un clasificador
bayesiano (basado en las probabilidades condicionales de las características), una
regresión logística y el enfoque del intervalo de característica por peso [1]. El conjunto de
datos usados para el entrenamiento y prueba de los clasificadores, consistió en datos
recolectados a partir de juicios humanos, que son fragmentos de código fuente etiquetados
por un conjunto de participantes como legibles o no legibles, así como las características
propuestas para evaluar la legibilidad de los fragmentos. Al encontrar una forma de
predecir un aspecto subjetivo como lo es la legibilidad, permitieron sentar las bases para
que otros investigadores continuaran la búsqueda de las métricas que permiten evaluar la
legibilidad del software [1]. En la Figura 13, se presentan mediante una línea de tiempo,
los modelos automáticos propuestos para evaluar la legibilidad del software [1][7][10][6]
[14] [20] [27][33][35][36][42][43] [45].
Figura 13. Evolución de los modelos de legibilidad del software.
Como se observa en la Figura 13, el primer modelo de legibilidad del software fue
propuesto por Buse y Weimer en el año 2010, el cual consistía de un clasificador binario,
implementado con la técnica de aprendizaje de máquina (machine learning en inglés). Los
otros modelos que le sucedieron y que también aplicaron las mismas técnicas, pero con
características diferentes, fueron el de Posnett et al. [10], Dorn [6] y Scalabrino [45]. El
modelo de Choi et al. [27], no propusieron ninguna característica, sino que presentaron
una ecuación optimizada, que utilizó un conjunto mínimo de las características ya
propuestas por los modelos anteriores de Buse et al. [1], Posnett et al. [10] y Dorn [6]. Los
modelos de Liu et al. [33] y Xu et al. [42], no usaron técnicas de aprendizaje de máquina,
sino técnicas de análisis léxico del texto. Los modelos de Mi et al. [35] [36], utilizaron el
aprendizaje profundo y evaluaron todo el código de los fragmentos, sin sesgar los
resultados a un conjunto limitado de características.
Los modelos para la predicción de la legibilidad en el software desarrollados por Buse [1],
Posnett [10], Dorn [6] y Scalabrino [45], consistieron en desarrollar y entrenar un
clasificador de legibilidad del software a través de estudios empíricos. Seleccionaron
fragmentos de código fuente de un lenguaje de programación y convocaron a un número
de participantes. Cada participante calificaba de forma individual cada fragmento con un
puntaje de 1 a 5, de acuerdo con su percepción de legibilidad en el mismo; dando 5 cuando
lo consideraba muy legible y 1 cuando era poco legible. Luego los investigadores
analizaron los datos y mediante el uso de fórmulas estadísticas y matemáticas, lograron
desarrollar una herramienta que evalúa fragmentos de código y los clasifica. Para concluir
estos trabajos, compararon los resultados del software con los de los participantes,
evaluando los aspectos y métricas más influyentes en la predicción de legibilidad [1] [7]
[10] [6] [45]. En la Tabla 20, se describen las características más relevantes que tuvo cada
uno de los trabajos de investigación, para proponer los modelos de predicción de la
legibilidad en el software, así como los resultados obtenidos, lo cual complementa la
información mostrada anteriormente en la Figura 13 [1] [7] [10] [6] [14][20] [27] [33] [35]
[36] [42][43] [45].
Tabla 20: Modelos de legibilidad del software.
Modelo Descripción Resultados Referencia
Buse y  Pionero en demostrar que un  81% de precisión con el [1] [14] [45]
Weimer aspecto subjetivo como la legibilidad podía conjunto de datos de Buse y
(2010) ser capturado y medido de forma automática. Weimer.
 Consideró únicamente el aspecto  78.6% de precisión con el
estructural del código fuente: 25 conjunto de datos de Dorn.
características.  72.5% de precisión con el
 Los fragmentos de código fuente conjunto de datos de Scalabrino.
evaluados, corresponden al lenguaje Java.  77.1% de precisión con
Gwm22
 77.4% de precisión con
Gam23
Posnett,  Presentó un enfoque teóricamente  Fue más fácil de medir y [10] [45]
Hindle y mejor fundado, más robusto y más simple que rápido de ejecutar.
Devanbu el de Buse y Weimer.
(2011)
22 Gwm: se calcula como la media ponderada de los valores de precisión para cada conjunto de
datos, donde los pesos son el número de fragmentos en cada conjunto de datos.
23 Gam: se calcula como la media aritmética de los valores de precisión para cada conjunto de
datos.
 Adicionó al modelo las métricas de  Más simple de usar y con

Volumen de Halstead y la entropía. medidas teóricamente mejor
 Usó sólo 3 características fundadas.
estructurales.  78% de precisión con el
 Los datos a evaluar son los mismos
conjunto de datos de Buse y
de Buse.
Weimer.
 72.8% de precisión con el
conjunto de datos de Dorn.
 66% de precisión con el
conjunto de datos de Scalabrino.
Gwm
Gam
Dorn  Mejoró el modelo de Posnett,  81% de precisión con el [6] [14]
(2012) [45]
haciéndolo más “general”. conjunto de datos de Buse y
 Creó un nuevo conjunto de datos de Weimer.
mayor tamaño, incluyendo fragmentos de
otros 2 lenguajes de programación (Python y
CUDA). Varió el tamaño de los fragmentos y conjunto de datos de Dorn.
diversificó la selección de participantes.
 Amplió el número de
características, organizadas en 4 categorías: conjunto de datos de Scalabrino.
características visuales, espaciales,
lingüísticas y de alineación.
 El modelo se enfocó en cómo el Gwm
código es leído por los humanos en las
pantallas.
Gam
Liu et al. Utilizan la herramienta WordNet para  El enfoque utilizando [33]
(2015) analizar automáticamente la correlación de la WordNet para analizar la legibilidad,
semántica entre el código y los comentarios, logra una alta precisión,
clasificando los comentarios en: válidos, no aproximadamente 97%, y puede
recomendados e inválidos. describir correctamente el
comportamiento del código.
 Propone y evalúa 3
métricas: AR, RiC y RiG.
Scalabrino, Modelo de características textuales de  La característica de [7] [45]
Linares- Scalabrino. longitud máxima de línea, tiene la
vasquez, Propuso mejorar los modelos anteriores, más alta correlación con la
Poshyvanyk y mediante la adopción de las siguientes legibilidad (superior a 0.7).
Oliveto características:  La legibilidad y la
(2016)  Aumentar el tamaño de la muestra, comprensibilidad, tienen baja o nula
evaluando también todos los datos usados en correlación (entre 0.0 y 0.3), es
los modelos anteriores. decir, que, si un fragmento es
legible, no quiere decir que sea
comprensible.
 Adicionan 7 características  Evaluaron cada modelo

textuales del código fuente que pueden (Buse, Posnett, Dorn y Scalabrino)
ayudar a clasificar su legibilidad. con los datos de Buse, Dorn y los de
Scalabrino.
Métodos de aprendizaje de máquina usados:
red de Bayes, RandomForest, ML perceptron conjunto de datos de Buse y
y SMO.
Weimer.
Para la clasificación usaron la regresión
logística.  78.1% de precisión con el
Para evaluar: precisión y AUC.
conjunto de datos de Dorn.
 77% de precisión con
Gwm
Gam
Xu et al. No se basó en el enfoque de características,  La legibilidad del código [42]
(2017) sino en el enfoque basado en WCRM: fuente basada en WCMR26 está
concreción24 de palabras y retención de fuertemente correlacionada con la
memoria25 de nombres de variable. tasa de alertas de defectos.
El modelo midió la legibilidad del código  Las alertas de defectos
fuente directamente desde los nombres de con mayor correlación son las
variable sin un proceso de entrenamiento. clasificadas en: malas prácticas,
Propuso 4 métricas para evaluar la vulnerabilidad de código malicioso y
legibilidad: Legibilidad de la variable, advertencias de corrección.
legibilidad del método, legibilidad de la clase  R2 fue de 62%.
y legibilidad del programa.
Utilizó el método de regresión lineal para
analizar la correlación entre la legibilidad y
otras variables dependientes.
Se usó R2, el coeficiente de determinación,
para medir la bondad de ajuste del modelo
de regresión lineal.
Scalabrino et Modelo de combinado de características  83% de precisión con el [45]
al. (2018) estructurales y visuales.
Características de Buse, Posnett y Dorn.
Métodos de aprendizaje de máquina usados: Weimer.
red de Bayes, RandomForest, ML perceptron
y SMO.
Para la clasificación usaron la regresión conjunto de datos de Dorn.
logística.
24 La concreción evalúa el grado en que el concepto denotado por una palabra se refiere a una
entidad perceptible. Una palabra concreta es más fácil de aprender, recordar y procesar que una
palabra abstracta.
25 La retención de memoria mide la habilidad de la mente humana para retener información.
26 WCMR: significa concreción de palabras y retención de memoria de nombres de variable, por sus
siglas en inglés.
Para evaluar: precisión y AUC.  77% de precisión con el

Gwm
Gam
Scalabrino et Modelo integral de legibilidad del código:  87% de precisión con el [45]
al. (2018) características estructurales, visuales y
textuales.
Características de Buse, Posnett, Dorn y Weimer.
Scalabrino.
Métodos de aprendizaje de máquina usados:
red de Bayes, RandomForest, ML perceptron conjunto de datos de Dorn.
y SMO.
Para la clasificación usaron la regresión
logística. conjunto de datos de Scalabrino.
Para evaluar: precisión y AUC.
Gwm
 85% de precisión con
Gam
Choi et al. Modelo que mide cuantitativamente la  Resultado: El modelo [27]
(2018) legibilidad del software, mediante la ecuación puede medir cuantitativamente el
optimizada: puntaje de legibilidad del software
usando 7 indicadores y el poder
Legibilidad = (-0.020) * (LOC) + (0.040) * (# explicativo se ha alcanzado al
de comentarios) + (0.037) * (# de líneas en 74.59%.
blanco) + (-0.755) * (# de operadores bit a  Los parámetros
bit) + (-0.153) * (control anidado máximo) + (- seleccionados para la ecuación
0.001) * (Volumen de programa) + (-0.611) * optimizada fueron: LOC,
(Entropía) numOfComments,
numOfBlankLines,
Evaluó el modelo con 20 características, y numOfBitOperators,
luego lo optimizó hasta lograr seleccionar maxNestedControl,
solo 7, con pesos personalizados. ProgramVolume, Entropy.
Mi et al. Modelo basado en las redes neuronales  El modelo DeepCRM [35]

(2018) convolucionales27, denominado ConvNets, logró un 83.8% de precisión y
DeepCRM que presentados en 3 diferentes 83.5% de medida F.
con ConvNets granularidades (convolucionales, pooling y  Los fragmentos de código
totalmente conectada), forman un framework x, fueron representados como una
de aprendizaje profundo, denominado matriz mxn, donde m denotó las
DeepCRM, el cual permite la clasificación de líneas de código y n denotó la
la legibilidad del software gracias al longitud máxima de línea.
aprendizaje automático de características  Cada ConvNet fue
complicadas desde el código fuente. implementado en Python usando
TensorFlow, y entrenado de
27Las redes neuronales convolucionales son tipos especiales de redes neuronales con estructuras
inspiradas en la biología.
El código fuente fue convertido en matrices manera supervisada usando el

de enteros para poder ser usado como algoritmo Adam.
entrada en ConvNets.  Mejoró un 2.4% con
respecto al modelo general de
legibilidad que reúne todas las
características de todos los
modelos anteriores y 17.2% con
respecto al modelo de Posnett.
 Para mitigar el riesgo del
sobre entrenamiento, fueron
recolectados 25000 fragmentos de
código de proyectos de código
abierto. Luego, se realizaron las
pruebas de clasificación utilizando
los conjuntos de datos de los
modelos anteriores.
Mi et al. IncepCRM utiliza el aprendizaje profundo  El modelo IncepCRM [36]
(2018) (Deep learning en inglés). Inspirados por logró una Precisión entre 82.2% y
IncepCRM GoogLeNet, adoptaron la arquitectura de 84.2%
inicio (inception en inglés), permitiendo así  Para implementarlo se
capturar de forma efectiva información a usó la librería Keras con
multiescala desde unos datos de entrada, y Tensorflow.
usando de forma simultánea convoluciones y  La tasa de error se
operaciones de agrupación. calculó con la función cross-entropy
loss.
 El modelo se entrenó de
forma supervisada usando el
optimizador Adam.
 Los datos de
entrenamiento fueron 210
fragmentos de código con un
tamaño de 50 x 305, obtenidos de
los modelos previos de Buse, Dorn
y Scalabrino, usando el 70% para
entrenamiento y el 30% para
pruebas.
Los modelos de Buse et al, Dorn, Posnett et al. y Scalabrino realizaron los siguientes pasos
descritos en la Figura 14 para lograr desarrollar sus modelos [1] [7] [10][6] [45].
Figura 14. Descripción del proceso realizado para desarrollar un modelo de legibilidad
enfocado a las características.
En la Figura 14, se observan los pasos realizados por algunos de los investigadores, en
los que se realizaron encuestas con la participación de estudiantes o profesionales del
área del software, para recolectar datos anotados, que permitieron entrenar los modelos.
En la encuesta, cada participante evalúo cada fragmento, asignándole un valor de 1 a 5,
donde 1 era poco legible y 5 era muy legible. La correlación fue evaluada con el coeficiente
de Spearman y la validación cruzada de k iteraciones, con k=10.
El modelo propuesto por Choi et al. (2018) [27], realizó un proceso diferente, el cual constó
de los pasos explicados en la Figura 15:
Figura 15. Descripción del proceso realizado en el modelo de legibilidad de Choi et al.
Como se pudo observar en la Figura 15, el proceso en el modelo de Choi fue similar al de
los modelos anteriores, pero con la variación de que no se realizó entrenamiento de un
clasificador binario, sino que se optimizaron los pesos para tener en cuenta en una nueva
versión de la ecuación de legibilidad, que permitiera lograr una alta precisión, pero con un
número reducido de características [27]. Para el análisis de regresión lineal se aplicaron
las técnicas regresión lineal múltiple y el análisis de regresión no lineal.
Los autores Mi et al. (2018) [35], identificaron algunas deficiencias en los modelos de
legibilidad anteriormente descritos, los cuales se basaban en el enfoque de características.
Las deficiencias identificadas fueron:
 Es inefectivo, porque capturaron información parcial sobre el código fuente, que puede
no ser adecuada. Las características que se pueden usar para un conjunto de datos
pueden no serlo para otro; y pueden existir redundancias y superposiciones entre las
características diseñadas manualmente, lo que probablemente limitará el rendimiento
del modelo [35].
 Es ineficiente, porque la elaboración de buenas características es difícil y lleva mucho

tiempo porque requiere un conocimiento específico de los dominios de aplicación.
Además, los investigadores y los profesionales deben examinar la validez de todas las
características prometedoras por separado o en combinación, lo que hace que el
enfoque manual sea costoso, e incluso, en algunos casos, inviable [35].
Además de identificar las deficiencias de los modelos anteriores, Mi et al. (2018)

propusieron un nuevo modelo, aplicando la técnica de aprendizaje profundo (Deep
learning), con lo cual, no desarrollaron el modelo entrenándolo para un conjunto específico
de características, brindando así una solución a las deficiencias descritas anteriormente.
El proceso que fue desarrollado para el modelo de Mi et al. [35], se explica en la Figura 16.
Figura 16. Descripción del proceso realizado en el modelo de legibilidad DeepCRM28 con
ConvNets29 de Mi et al.
En la Figura 16, se pueden apreciar los pasos del proceso para desarrollar el modelo de
legibilidad del software DeepCRM con ConvNets, donde el primer paso fue convertir los
fragmentos de código fuente a una matriz de enteros, la cual fue utilizada después como
insumo para el entrenamiento de cada una de las 3 redes convolucionales (ConvNet) [35].
Se crearon 3 redes convolucionales, cada una para representar un tipo de granularidad: a
nivel de carácter; a nivel de token, como palabras clave y operadores, realizando análisis
léxico; y a nivel de nodo, como declaraciones y definiciones, representadas en un árbol de
sintaxis abstracta [35]. Cada uno de los ConvNets fue implementado en Python usando
TensorFlow, y entrenado de manera supervisada usando el algoritmo Adam [35].
28 DeepCRM, es la abreviación de modelo de legibilidad del software con aprendizaje profundo, por
sus siglas en inglés.
29 ConvNets, es la abreviación de redes neuronales convolucionales, por sus siglas en inglés.
El problema identificado con los modelos de Mi et al. (2018), es que se ingresaba un

fragmento y se obtenía un veredicto de si es o no legible, pero no era posible conocer las
características del software que influyeron en esa decisión [35].
Adicionalmente, se encontró otro modelo que, pese a que no sirve para evaluar la
legibilidad en el software, permite mejorar una característica de la legibilidad, relacionada
con los nombres de los identificadores. El modelo para sugerencias automáticas de
nombres, fue desarrollado por Allamanis et al. (2015) [24], quienes utilizaron el lenguaje
neuronal log-bilineal, para capturar el contexto de la estructura del algoritmo, junto con un
modelo de subtoken para realizar una división del token que analiza las relaciones entre
palabras, lo que les permitió predecir neologismos, nombres nuevos que no habían
aparecido antes. El modelo incrusta cada token (palabra) dentro de un espacio continuo
de alta dimensión, como un vector [24]. Luego, para nombrar un método o una clase,
selecciona el nombre que es más similar en este espacio de inclusión a aquellos en el
cuerpo de la función [24]. De esta manera, el modelo se da cuenta de la famosa frase de
Firth: "Sabrás una palabra por la compañía que esta guarda" [24]. Este eslogan, encapsula
la hipótesis distributiva de que palabras semánticamente similares, tienden a coexistir con
las mismas palabras [24]. Las incorporaciones continuas de identificadores tienen muchas
otras aplicaciones potenciales en la ingeniería de software, tales como rechazar commits
en donde haya identificadores que violen las convenciones de codificación del proyecto;
exploración de anti patrones lingüísticos, tales como un getter que comienza con set; y
localización de características [24].
El modelo de Allamanis et al., demostró sugerir nombres con precisión, tanto para el
problema de denominación de variables simples, como para nombrar clases y métodos,
logrando puntajes F1-score del 60% en nombres de métodos y 55% en nombres de clase,
cuando sea necesario para predecir nombres para el 20% de las declaraciones de método
y clase [24].
5.3 Métodos y técnicas utilizadas en los modelos

Los modelos de legibilidad del software permiten determinar de forma automática si un
fragmento de código es o no legible. Para ello, los autores que los propusieron, utilizaron
diversas técnicas que les permitieron lograr los objetivos de sus investigaciones. En la
Tabla 21, se presentan las técnicas utilizadas en las investigaciones, para diferentes
actividades relacionadas, directa o indirectamente, con los procesos que permiten evaluar
la legibilidad en el software.
Tabla 21. Técnicas utilizadas en las investigaciones para medir la legibilidad en el software.
Técnica Uso en la legibilidad del software

Tipo Técnica Identificación de Clasificador Sugerencias Impacto en Medir
Referencia
características binario automáticas de la carga métrica
relevantes nombres cognitiva
Red neuronal X [1]
Red de Bayes X [1] [45]
RandomForest X [45]
ML perceptron X [45]
SMO X [45]
Enfoque del intervalo X [1]
Aprendizaje de de voto por
máquina (Machine característica (Voting
Learning en feature interval
inglés) - approach en inglés)
Supervisado Aprendizaje profundo X [35] [36]
(Deep learning en
inglés)
Red neuronal X [35]
convolucional
Arquitectura de inicio X [36]
(inception en inglés)
Aprendizaje de Agrupación (Clustering X X [45]
máquina - No en inglés) basada en
supervisado densidad - DBSCAN
Análisis de Regresión X [25] [27]
lineal [42]
Correlación Spearman X [18]
Análisis de Análisis de Regresión X [27]
regresión/ no lineal
correlación Selección basada en X [1] [5] [45]
correlación, con
herramienta WEKA.
Regresión logística X [1] [45]
lenguaje neuronal log- X [24]
bilineal
Modelo de subtoken X [24]
Análisis de texto AST: árbol de sintaxis X [45]
abstracta
Análisis de lenguaje X [45]
natural (léxico)
Espectroscopía de X [31]
Ocular infrarrojo cercano
funcional (fNIRS)
La Tabla 21 fue organizada de la siguiente forma: en la parte superior se describieron

brevemente los usos identificados en los estudios; en la parte izquierda, se encuentran las
técnicas que fueron halladas en los estudios seleccionados en la RSL, agrupados por el
tipo al que pertenece cada una de las técnicas; en la parte derecha, se adicionó una
columna con las referencias de los documentos en los que cuales se nombre la técnica.
Las técnicas identificadas, se clasificaron en 5 grupos principales: aprendizaje de máquina

supervisado30, el cual fue utilizado para crear el modelo de clasificación binario,
entrenándolo con datos etiquetados, y posteriormente evaluado con otros fragmentos de
código fuente, obteniendo de forma automática el resultado de si era o no legible; el
aprendizaje de máquina no supervisado31 y el análisis de regresión y correlación, que
fueron usados para identificar las características más representativas del software para
determinar su legibilidad; el análisis de texto, utilizado en el modelo que sugiere
automáticamente nombres de clases y métodos, y para calcular el valor de medida de
algunas métricas; por último, se encuentra la clasificación de tipo ocular, utilizado para
medir el impacto que tiene la falta de legibilidad en el código fuente, sobre la carga cognitiva
del lector.
El aprendizaje de máquina supervisado ha permitido obtener modelos para evaluar

automáticamente la legibilidad del software, que, aunque no son aún definitivos, han
logrado una precisión por encima del 80%. Los investigadores interesados en continuar
con los trabajos, podrían usar las mismas técnicas utilizadas en la literatura, tales como,
la red de Bayes, redes neuronales o el aprendizaje profundo, aplicándolas de forma
individual o combinadas, o proponer el uso de nuevas técnicas, teniendo en cuenta que el
aprendizaje profundo permite el entrenamiento y clasificación de los fragmentos en legible
y no legibles, pero no permite identificar las características del código fuente que influyeron
en su clasificación. Por otro lado, si lo que se desea es continuar con la búsqueda de las
características del código fuente que permiten medir la legibilidad del software, pueden
utilizar las técnicas de aprendizaje de máquina no supervisado, como el clustering
30 Aprendizaje de máquina supervisado, se refiere a crear modelos predictivos a partir de datos de

entrada y respuesta conocidos, denominados también datos etiquetados.
31 Aprendizaje de máquina no supervisado, permite crear modelos predictivos sin un conocimiento
previo del resultado, es decir, datos sin etiquetar.

(agrupación) o alguna de las técnicas de regresión para el análisis de la correlación entre

la característica y la predicción de legibilidad.
5.4 Lenguajes de programación evaluados y

participantes
Los modelos propuestos, encontrados en la literatura, para identificar si un fragmento de
código fuente es o no legible, fueron entrenados y probados con fragmentos de código
fuente, los cuales corresponden a un lenguaje de programación. En general, los modelos
fueron diseñados para el lenguaje Java, aunque en el modelo de Dorn, también se
incluyeron fragmentos de los lenguajes Python y CUDA. En la Tabla 22, se presenta el
detalle de los fragmentos de código utilizados, como la cantidad y el tamaño de
programación, así como la información de las personas que ayudaron a etiquetarlos de
forma manual, como legible y no legible.
Tabla 22. Detalle de los fragmentos de código fuente utilizados en los modelos de
Buse y Posnett Dorn [6] Scalabrino Choi et al Mi et al. Mi et al.

Weimer et al. [45] et al. [27] ConvNets y IncepCRM
[1] [45] [10] [45] [7][45] DeepCRM [36]
[35]
2010 2011 2012 2016 2018 2018 2018
Número de 100 Los 360 (120 de 100 de 60 50 de Buse 210
fragmentos mismos cada Buse +60 de Dorn + fragmentos de
de código de Buse lenguaje) + 360 de 100 de código,
fuente Dorn Scalabrino + obtenidos de
+ 200 21050 de los modelos
propios GitHub + 2009 previos de
de Buse, Dorn y
SourceForge + Scalabrino
2859 de
Apache
Lenguajes Java Los Java, Python Java, Java Java Java
evaluados mismos y CUDA Python y
de Buse CUDA
Tamaño de 92, 260 o Los 10, Todos los 13 a 96 LOC 7 a 31 LOC tamaño de 50
un fragmento 577 mismos 30 o anteriores x 305
caracteres de Buse 50 LOC
o
7 LOC
Número de 120 Los 5468 120 de -- -- --
Participantes mismos Buse
de Buse + 5468 de
Dorn
+ 9 propios
Buse y Posnett Dorn [6] Scalabrino Choi et al Mi et al. Mi et al.

Weimer et al. [45] et al. [27] ConvNets y IncepCRM
[1] [45] [10] [45] [7][45] DeepCRM [36]
[35]
2010 2011 2012 2016 2018 2018 2018
Total 12000 Los 76741 12000 de Los de Buse, Los de Buse,
juicios32 mismos Buse Dorn y Dorn y
(datos de Buse + 1800000 Scalabrino. Scalabrino,
anotados) de Dorn +
+ 1800 25000 Se usó el 70%
propios automáticos para
entrenamiento
y el 30% para
pruebas.
Origen de Universidad Los Convocatoria Todos los Estudiantes, Para los --
los de Virginia: mismos abierta en red anteriores investigadores nuevos, se usó
participantes estudiantes de Buse social: doctorales y herramientas
año 1, año estudiantes y programadores automáticas,
2, año 3-4, y profesionales de la industria evaluando
graduados de diferentes en Corea del convenciones:
niveles de la sur PMD y
ciudad de CheckStyle.
Virginia
En la Tabla 22, se mostró que el número de fragmentos de código fuente utilizados fue
muy variado, de acuerdo al modelo propuesto, encontrando cantidades desde 60 hasta
25000. Teniendo en cuenta que los modelos han tratado de replicar los anteriores, para
dar continuidad, el lenguaje común evaluado fue Java, con tamaños desde 7 LOC hasta
100 LOC. Las personas que participaron en la anotación de los datos, fueron estudiantes
universitarios que cursaban diferentes años y profesionales del área de software con
variada experiencia. Los autores seleccionaron participantes cercanos a su ubicación
geográfica, y por eso se encontró que las personas eran de estados unidos y corea del
sur.
Además de los modelos de legibilidad, se encontraron otros estudios en los cuales los
autores desarrollaron experimentos relacionados con la legibilidad del software, utilizando
fragmentos de código fuente, y, a veces, la participación de personas. En la Tabla 23, se
describen los lenguajes de programación, mencionados en los otros estudios.
32
Cantidad total de juicios: Son los datos anotados, es decir, los que tienen la etiqueta de legible o
no legible. En algunos casos es el producto obtenido al multiplicar el número de participantes por el
número de fragmentos.
Tabla 23. Lenguajes de programación utilizados en otros experimentos de legibilidad del

software.
Autor Descripción Lenguaje Participantes Referencia

Alawad et Relación de las Java -- [5]
al. (2018) construcciones de
código con la
legibilidad.
Allamanis Asignación Java -- [24]
et al. automática de
(2015) nombres para el
método y la clase
Aman et Relación entre el Java -- [25]
al. (2015) tamaño de los
comentarios y la
propensión a fallos
en los métodos
Borstler et Influencia de las Java 104 estudiantes de 1 y 2 [18]
al. (2016) cadenas de métodos C++ año de una universidad en
y los comentarios, Alemania, cursando
sobre la legibilidad 30 fragmentos asignaturas de
del software. alterados introducción a la
manualmente programación. 1 en C++ y
2 en crash en Java.
Coleman Relación entre la C -- [28]
(2018) legibilidad y la
estética del código
fuente
Fakhoury Efecto de la falta de Java 50 personas de nivel [31]
et al. legibilidad en la profesional, Magister y
(2018) carga cognitiva PhD.
Se les pago 15 dólares a

cada una.
Como se mostró en la Tabla 23, donde se presentan los otros estudios, a parte de los
modelos de legibilidad, donde se realizaron experimentos con fragmentos de código
fuente, casi todos corresponden al lenguaje de programación Java, lo que demuestra que
falta diversificar los estudios a otros lenguajes de programación. Adicionalmente, en dos
de los estudios donde participaron personas, se observó que los autores, quizás por
cuestiones prácticas, seleccionaron personas cercanas a su entorno, como estudiantes de
una misma institución o profesionales de la ciudad.
En el experimento de Borstler et al. (2016) [18], analizaron la relación entre el juicio de

legibilidad y el perfil del evaluador, tal como experiencia en programación, género,
experiencia específica en la tarea y preferencia en la asignación de nombres. Al finalizar,

encontraron que los hombres tienen mayor percepción de legibilidad que las mujeres.
5.5 Características y métricas propuestas

El término característica, en el contexto de los modelos de legibilidad del software, hace
referencia a un aspecto o cualidad del software, que influye sobre la percepción de
legibilidad del mismo. En algunos de los estudios relacionados con los modelos de
legibilidad del software, los autores propusieron, o mencionaron, algunas características
del software, que consideraron, permitían medir la legibilidad de un fragmento de código
fuente.
En la Tabla 25, se presentan de forma ordenada las características y las métricas

propuestas, en los modelos de legibilidad (para los modelos basados en características),
indicando en letras y colores la influencia que tuvo en los resultados de cada estudio, para
medir la legibilidad en un fragmento de código. En la Tabla 24, se detalla el significado de
cada letra y cada color que se utiliza en la Tabla 25.
Tabla 24. Representación de la importancia de cada característica.
Representación
Categoría Descripción NA Alta Media Baja
Estructurales Conteo simple de caracteres. X A M B
Textuales Para los nombres de los identificadores tiene X A M B
en cuenta los estándares de nomenclatura
de las variables, que generalmente están en
idioma inglés y el análisis léxico del código
fuente, como nociones de lenguaje natural.
Visuales Se considera la pantalla donde el X A M B
programador ve el código, como una matriz
de caracteres de color y espacios en blanco.
Y si utiliza un IDE, el resaltado de la sintaxis
con colores.
Espaciales Hace referencia a la longitud, volumen y X A M B
anidación presente en una línea de código,
lo que la hace más o menos densa.
Alineación Alineación de operadores y espacios en X A M B
blanco que permiten una estructura limpia.
Tabla 25. Características que permiten medir la legibilidad del software.
Característica Modelo
Posnett Scalabrino et Choi et
Buse et Dorn
Métrica et al. al. (2016- al.
Categoría Nombre al. (2010) (2012)
(2011) 2018) (2018)
[1] [6] [45]
[10] [45] [7] [45] [27]
Estructural y LOC Longitud AA MM
Visual promedio de línea
(# de caracteres)
Estructural y LOC Longitud máxima AA MM
Visual de línea
(caracteres)
Estructural LOC Líneas de código A A
(LOC)
Estructural, Identificadores # promedio de AA A
Visual, textual y Identificadores
espacial
A
Estructural, Identificadores # máximo de MM M
Visual, textual y Identificadores
espacial
M
Estructural, Identificadores Longitud BB B BBB
Visual, textual y promedio del
espacial identificador
B B
Estructural, Identificadores Longitud máxima MM BBB
Visual, textual y del identificador
espacial
MM B
Estructural Identificadores # máximo de M
ocurrencias de
algún identificador
Estructural, Palabras clave # promedio de MM M MMM
Visual y espacial palabras clave
Estructural, Palabras clave # máximo de BBB MMM
Visual y espacial palabras clave
Estructural, Comentarios # promedio de MM MMM AA
Visual y espacial Comentarios
M A
Estructural y Puntos # promedio de BB
visual puntos
Estructural y Comas # promedio de MM BB
visual Comas
Estructural y Espacios en # Promedio de MM BB AA
visual blanco Espacios en blanco
(identación)
Estructural y Espacios en # Máximo de BB BB
visual blanco Espacios en blanco
(identación)
Visual Espacios en Longitud de M
blanco identación
Estructural y Paréntesis # promedio de AA MM
visual Paréntesis
Estructural, Números # promedio de BBB BBB
visual, espacial números
Estructural, Números # máximo de BBB BBB
visual, espacial números
Estructural y Líneas en blanco # promedio de BB MM
visual líneas en blanco
Estructural y Asignaciones # promedio de BB BB
visual asignaciones
Estructural y Estructura de # promedio de BB
visual control bifurcaciones (if)
Estructural y Estructura de # promedio de BB BB
visual control bucles (for, while)
Característica Modelo
Posnett Scalabrino et Choi et
Buse et Dorn
Métrica et al. al. (2016- al.
Categoría Nombre al. (2010) (2012)
(2011) 2018) (2018)
[1] [6] [45]
[10] [45] [7] [45] [27]
Estructural Estructura de Control anidado A
control máximo
Visual Estructuras de Ciclos M
control
Estructural, Operadores # promedio de BBB BBB AA
espacial, visual y operadores
alineación aritméticos
B B AA
Estructural, Operadores # promedio de BBB BBB
espacial, visual y operadores de
alineación comparación
B B
Estructurales Operadores # máximo de M
ocurrencias de
algún caracter
Estructurales Entropía Entropía B A
Estructurales Halstead Métrica de B
volumen de
Halstead
Espacial Cadena de palabras Cadena de B
palabras (Strings)
Espacial Cadena de palabras Constantes B
Alineación Cadena de palabras Expresiones B
Textuales Consistencia de B
los comentarios e
identificadores -
CIC
Textuales Términos de B
identificadores en
diccionario - ITID
Textuales Identificadores de B
significado
restringido - NMI
Textuales Legibilidad de los M
comentarios - CR
Textuales Número de B
significados - NM:
Cuantos
significados tiene
una misma
palabra.
Textuales Coherencia textual B
- TC: Mide la
cohesión de las
clases dentro del
código.
Textuales Número de B
conceptos - NOC
Estructurales volumen Volumen del A
programa
En la Tabla 25, se organizaron las características y sus métricas, por categorías, entre las
que se encuentran: estructurales, visuales, alineación, espaciales y textuales, que fueron
explicadas en la Tabla 24. El primer modelo de legibilidad, el cual fue el de Buse et al.
(2010) [1], propuso las de tipo estructural, que consistía en simples conteos de los
caracteres presentes en el código fuente. Años más tarde, Dorn (2012) [6] propuso para
su modelo, la introducción de las características de tipo visuales, de alineación y
espaciales, al considerar importante la forma en la que un programador ve en pantalla el
código fuente que está leyendo, y las características de tipo textual, al considerar que los
nombres de las variables, y demás identificadores, utilizan lenguaje natural que en su
mayoría se encuentra en idioma inglés. Años más tarde Scalabrino et al. (2016) [45],
propuso características de tipo textual, que se basan en el análisis léxico del código fuente,
tales como, la consistencia entre los comentarios y el código fuente, la especificidad de los
identificadores, la coherencia textual y la legibilidad de los comentarios. En el año 2018,
Choi propuso un modelo cuantitativo para medir la legibilidad del software, que consistió
en una ecuación matemática que tiene en cuenta varias características del código fuente,
presentadas en años anteriores por otros autores, y le asignaba diferentes pesos a cada
una, hasta lograr el resultado más óptimo, es decir, un valor alto de legibilidad con el menor
número de características posibles. Las características seleccionadas en la ecuación final
de Choi fueron: número de comentarios, número de líneas en blanco, número de
operadores bit a bit, control anidado máximo, volumen de programa y la entropía.
En la Tabla 25, también se puede apreciar que las características que tuvieron mejores
resultados en los estudios, es decir, tuvieron una mayor correlación con la predicción de
legibilidad, fueron: la longitud promedio de línea, la longitud máxima de línea, las líneas de
código (LOC), el número promedio de identificadores, el número promedio de comentarios,
el número promedio de espacios en blanco y el número promedio de paréntesis.
5.6 Recursos disponibles

Algunos de los estudios, aportaron los vínculos web de los repositorios, donde
almacenaron de forma pública los fragmentos de código fuente utilizados en sus
experimentos, así como las herramientas propias o libre utilizadas, y algunos documentos
con información relevante para los estudios. El propósito de los repositorios, es permitir la
replicación de los estudios, o simplemente facilitar el material para que otros investigadores
puedan continuar avanzando en el tema.
5.6.1 Datasets: Fragmentos de código fuente

Los fragmentos de código fuente, son porciones del código de un programa, que pueden
corresponder a un método o una clase. A continuación, en la Tabla 26, se presentan los
repositorios que contienen fragmentos de código fuente, encontrados en la literatura, y que
pueden ser utilizados por otras personas con fines de investigación.
Tabla 26. Repositorios que contienen fragmentos de código fuente.
Lenguaje de
No. Vínculo Referencia
programación
1 Java https://github.com/zibranm/dataset [5]
2 Java http://groups.inf.ed.ac.uk/cup/naturalize/#evaldata [24]
3 C https://github.com/roncoleman125/Pretty [28]
4 Java https://github.com/CityU- [35]
QingMi/DeepCRM/tree/master/Code%20Snippet%20Repository
5 Java https://dibt.unimol.it/report/readability/ [45]
Como se puede apreciar en la Tabla 26, 4 de los 5 repositorios corresponden a fragmentos

de código fuente en lenguaje Java, mientras que sólo 1 es de un lenguaje diferente, que,
en este caso, corresponde al lenguaje C.
5.6.2 Herramientas
En algunos de los estudios seleccionados en la RSL, se utilizaron herramientas que
facilitaron el desarrollo de algunas de las actividades. Entre las herramientas, se
encuentran programas de uso libre, así como algoritmos propios desarrollados por los
autores de los estudios. A continuación, en la Tabla 27, se relacionan las herramientas
encontradas en los documentos, con el vínculo del repositorio en el cual se pueden
descargar.
Tabla 27. Repositorios que contienen herramientas libres o propias utilizadas en los
estudios.
No. Descripción Vínculo Referencia

1 Permite medir las métricas de https://github.com/ipeirotis/ReadabilityMetrics [5] [29]
legibilidad: ARI, SMOG, FKI,
GFI, CLI, BRS.
2 Permite contar o extraer http://se.cite.ehime-u.ac.jp/tool/ [25]
elementos del código fuente.
3 Analizador de código https://pmd.github.io/ [12][25][26]
estático.

4 Evalúa el estilo y diseño del https://checkstyle.sourceforge.io/ [26]
código fuente, de acuerdo a
las convenciones.
5 Algoritmos usados para el https://github.com/Smfakhoury/fNIRS-and-Cognitive- [31]
grupo de control y los grupos Load
de tratamiento, en el estudio
de la carga cognitiva.
6 Plugin para el IDE IntelliJ, que https://reticulaplugin.github.io/ [32]
permite evaluar la calidad en
tiempo real.
7 Base de datos léxica del https://wordnet.princeton.edu/ [33]
idioma inglés
8 Programa en Python para https://github.com/CityU-QingMi/DeepCRM [35]
contar el número de
violaciones de reglas y otro
programa para transformar los
fragmentos a una matriz de
enteros.
9 Librería Keras para https://github.com/keras-team/keras [36]
implementar la técnica de
aprendizaje profundo.
Es un API para redes
neuronales de alto nivel.
10 Permite extraer métricas de https://github.com/robertyuyang/StylisticFingerprinting [37]
estilo y generar un archivo
CSV.
11 Modelo de legibilidad de https://dibt.unimol.it/report/readability/ [45]
Scalabrino et al.
12 Algoritmo para la https://pypi.org/project/wordsegment/ [42]
segmentación de palabras en
inglés.
13 Embellecedor de código http://prettyprinter.de/ [37]
fuente online.
14 Embellecedor de código http://astyle.sourceforge.net/ [37]
fuente.
15 Calcular la legibilidad del https://github.com/Bowie-State- [42]
código. University/ReadablilityCaculate
En la Tabla 27, anteriormente presentada, se encuentran algoritmos que permiten extraer

o medir métricas del código fuente, herramientas para el análisis estático del código fuente,
librerías para la implementación de técnicas, algoritmos para transformar datos y uno de
los modelos propuestos para evaluar la legibilidad de un fragmento.
5.6.3 Documentación
Además de encontrar herramientas y conjuntos de datos en los estudios seleccionados de
la RSL, también se encontraron vínculos de documentos, cuyo contenido se relaciona con
las propuestas para medir la legibilidad en el software. A continuación, en la Tabla 28, se
relacionan los documentos encontrados en los estudios, con el vínculo del repositorio en
el cual se pueden descargar.
Tabla 28. Repositorios que contienen documentos de interés.

1 Guías de estilo de https://github.com/google/styleguide [37][26]
Google.
2 Estándares de https://github.com/facebook/jcommon/wiki [26]
codificación.
3 Estándares de http://www.gnu.org/prep/standards/ [37]
codificación GNU.
4 Palabras clave de https://en.cppreference.com/w/cpp/keyword [37]
C++
5 Convertir http://sedano.org/toddsedano/2013/02/19/improving-code- [40]
comentarios en readability-turning-comments-into-methods.html
métodos.
En la Tabla 28, se presentan repositorios que contienen información de los estándares de

codificación de algunos lenguajes de programación, un listado de las palabras clave en el
lenguaje C++ y un blog donde el autor Sedano, explica una forma de convertir los
comentarios en métodos, con el objetivo de hacer el código más legible.

El Capítulo 5 permite responder la segunda pregunta de investigación: ¿Qué métodos son
utilizados para obtener el valor de medida de cada una de esas métricas de forma
automática?
En el año 2010, Buse y Weimer [1] crearon el primer modelo de clasificación automática
para evaluar la legibilidad de un fragmento de código fuente, logrando así cuantificar algo
tan subjetivo. El modelo consistió en un clasificador binario, entrenado con datos anotados
por humanos [1], utilizando técnicas de aprendizaje de máquina (machine learning en
inglés), lo que abrió las puertas para que otros investigadores se interesaran en el tema,
brindando nuevos aportes, tales como, métricas de legibilidad, características del código
que influyen, impacto de la legibilidad en los costos de mantenimiento, modelos
automáticos para evaluarla, y algoritmos para sugerir o mejorar automáticamente alguna
característica del código que impacte la legibilidad del código.
Después del modelo de Buse et al. [1], propuesto en el año 2010, donde evaluaron
características estructurales del software, llegaron nuevas propuestas de modelos de
legibilidad del software, tales como: el modelo de Posnett et al. en el año 2011 [10], que
redujo el conjunto de características de Buse et al., pero adicionó el token de entropía y la
métrica del volumen de Halstead; el modelo de Dorn en el año 2012 [6], propuso
características de tipo visual, espacial, de alineación y lingüísticas; el modelo de Liu et al.
en el año 2015 [33], evaluó sólo la correlación de la semántica entre el código y los
comentarios, usando la herramienta WordNet. En el año 2016 Scalabrino et al. [7],
adicionaron 7 características de tipo textual y crearon un modelo que las usaba; En 2017,
el modelo de Xu et al. [42], propusieron no enfocarse en las características, sino en la
concreción de palabras y la retención de memoria (WCRM). En el año 2018, Scalabrino et
al. [45] propusieron 2 nuevos modelos de legibilidad: el combinado de características
estructurales y visuales, y el integral de características estructurales, visuales y textuales,
cuya precisión usando todos los conjuntos de datos fue del 85%. En el año 2018 Choi et
al. [27], presentaron el modelo cuantitativo de legibilidad, que consistió en una ecuación
optimizada que usaba sólo 7 características; en el mismo año, Mi et al. [35] [36] proponen
2 nuevos modelos de legibilidad, usando la técnica de aprendizaje profundo, sin limitar el
conjunto de características del software a evaluar, los cuales son DeepCRM [35] que usa
redes neuronales convolucionales, y el modelo IncepCRM [36] con arquitectura de inicio
(inception en inglés).
Las técnicas utilizadas en los modelos, para el entrenamiento de los clasificadores,

corresponden al aprendizaje de máquina supervisado, como redes neuronales, red de
Bayes y aprendizaje profundo. Para la identificación de las características relevantes para
la legibilidad en el código, se usaron el aprendizaje de máquina no supervisado con la
técnica de agrupación (clustering en inglés), y el análisis de correlación. Las técnicas de
análisis de texto, fueron utilizadas en el algoritmo para sugerir automáticamente nombres
para la clase y el método, y para medir algunas métricas de legibilidad.
En algunos estudios se hallaron las direcciones de los sitios web, donde se pueden obtener
los fragmentos de código fuente utilizados en los experimentos, así como herramientas
disponibles para la descarga y documentación relacionada, que pueden ser utilizados por
otros investigadores para realizar una replicación de los estudios o realizar uno nuevo. La
mayoría de fragmentos corresponden al lenguaje de programación Java.
Con este quinto capítulo, se termina de responder al objetivo número 2 establecido en este
trabajo final, el cual era "Sintetizar los resultados en términos de la evolución de las
métricas de legibilidad del software, las características utilizadas para su medición y los
métodos automáticos de medición".
Capítulo 6. Retos y aplicaciones de la legibilidad del software 113
6 Capítulo 6. Retos y aplicaciones de la

legibilidad del software
Los autores de los estudios seleccionados, en el ejercicio de sus investigaciones, lograron
brindar aportes significativos en el tema, en cuanto a las características, métricas y
modelos de legibilidad del software, pero también identificaron otras áreas de interés,
donde la legibilidad del software puede ser aplicada. Adicionalmente, los autores
reconocieron las debilidades y las oportunidades en sus propios estudios, lo que les
permitió identificar los retos que deben enfrentar los investigadores que deseen dar
continuidad a los trabajos de investigación relacionados con la legibilidad del software.
En este capítulo, se presentan las aplicaciones y los retos identificados en la literatura,

para la legibilidad del software.
6.1 Aplicaciones de interés

Los autores de los estudios seleccionados en la RSL, presentaron en sus investigaciones
algunas aplicaciones de interés para la legibilidad del software, las cuales se encuentran
sintetizadas en la Tabla 29.
Tabla 29. Aplicaciones identificadas en la literatura para la legibilidad del software.
No. Aplicación Referencia

1 Modelos de legibilidad del software. [1][7][10][6][14][25]
[27][33][35][36][42]
[45]
2 Apoyar el aprendizaje de las buenas prácticas de legibilidad y los [26] [28] [34] [40][43]
estilos de embellecimiento, en los cursos de programación de las
instituciones de educación superior.
3 Evaluar el impacto de las características de legibilidad del código [31] [41]
fuente en la carga cognitiva del lector.
No. Aplicación Referencia

4 Implementación del método de gamificación para el aprendizaje [34]
de la legibilidad del software en estudiantes universitarios.
5 Sistema automático para identificar el perfil de las personas, en [12]
las pruebas de reclutamiento de las empresas de software para
el cargo de programador, analizando el código fuente de los
programas que desarrollaron, evaluando el nivel de habilidad en
el lenguaje y el nivel de legibilidad.
6 Asignación automática de nombres para los identificadores de la [24]
clase y el método, de acuerdo al contenido del código fuente.
7 Predecir los métodos propensos a fallas de acuerdo a la cantidad [25]
de comentarios que tienen.
La aplicación número 1 de la Tabla 29, hace referencia a los modelos automáticos que
permiten evaluar la legibilidad de un fragmento de código fuente, y que fueron presentados
en el Capítulo 5, así como la aplicación número 6 que fue presentada en la sección 5.2. La
aplicación número 3, del impacto de la legibilidad en la carga cognitiva del lector, se explicó
en el Capítulo 4, sección 4.1. La aplicación número 7, se refiere a la relación que tiene la
legibilidad con la propensión a fallas, lo que permite que las métricas de legibilidad puedan
utilizarse en las herramientas de detección a fallas, para mejorarlas.
Para la aplicación número 5 de la Tabla 29, Novais et al. (2017) [12], diseñaron la
herramienta “Perfil del programador”, abreviada como PP, para identificar los perfiles de
los programadores, mediante la extracción automática de las métricas en los programas
desarrollados por ellos en lenguaje Java, utilizando técnicas de procesamiento de
lenguaje. Los resultados clasifican a los programadores de acuerdo a su nivel de habilidad
en el lenguaje y nivel de legibilidad en el código fuente [12]. La herramienta PP fue usada
junto a la herramienta PMD, que es un analizador de código fuente, para capturar
información sobre el uso de las buenas prácticas de Java [12].
Las habilidades de los programadores fueron clasificadas de la siguiente forma:
 Habilidad en el lenguaje (skill en inglés): definido como el conocimiento adquirido y la

habilidad para aplicar ese conocimiento de una manera eficiente [12].
 Legibilidad del lenguaje (readability en inglés): definido como la estética, claridad y todo
lo relacionado con la comprensión del código escrito [12].
Los perfiles fueron clasificados en 5 categorías: Novato (baja habilidad y baja legibilidad),
iniciante avanzado (baja a media habilidad y legibilidad), competente (baja a media
habilidad y alta legibilidad), experto (alta habilidad y media a baja legibilidad) y maestro
(alta habilidad y alta legibilidad) [12].
Para las aplicaciones número 2 y 4 de la Tabla 29, relacionadas con la adopción de buenas
prácticas de legibilidad y con la enseñanza de las mismas desde las instituciones de
educación superior, se dedican las siguientes secciones 6.1.1 y 6.1.2.
6.1.1 Enseñanza de la legibilidad del software desde las

instituciones de educación superior
Mi et al. (2018) desarrollaron una plataforma online, denominada GamiCRS, para motivar
la enseñanza interactiva de la legibilidad del software, a los estudiantes de una universidad
de Hong Kong, que estaban cursando asignaturas de programación [34]. El método de
aprendizaje que utilizaron se conoce como gamificación, y consiste en aplicar elementos
típicos del diseño de juegos en un contexto que no sea juego, mediante el uso de la
motivación intrínseca33 y extrínseca34 [34]. La herramienta estaba compuesta de una vista
con la información del perfil de usuario, un tablero de clasificación general, una sección
para mostrar los fragmentos de código fuente para evaluar y el formulario para la
evaluación [34]. El experimento fue realizado con 161 estudiantes de la Universidad de
Hong Kong, y los resultados mostraron que GamiCRS fue eficaz para motivar y retener a
los estudiantes para que aprendieran la legibilidad del código [34].
Por otra parte, Sedano (2016) [40], realizó un estudio para evaluar la legibilidad del código
con 21 estudiantes de maestría en ingeniería de software, del curso “Craft of Software
Development” de la Universidad Carnegie Mellon, Estados Unidos, en 2013. La prueba
consistió en 4 sesiones donde se reunió un programador, denominado el autor, y un lector,
donde el primero dio una breve descripción de la funcionalidad y el lector luego leía y
comprendía por sí sólo cómo el código realizaba los procesos [40]. Al finalizar, el lector
daba la retroalimentación correspondiente y el programador realizaba los ajustes para la
33 La motivación intrínseca, se refiere a hacer una actividad por satisfacción propia, donde una
persona disfruta la actividad [34].
34 La motivación extrínseca, se refiere a hacer una actividad por alguna recompensa adicional, como
un incentivo, que puede ser: puntos, insignias, tablas de clasificación [34].

siguiente sesión [40]. Los resultados de la investigación mostraron que la capacidad de los
programadores para escribir código legible mejoró, así como la identificación de las
soluciones frecuentes para mejorar la legibilidad del código [40]. Las sugerencias más
frecuentes que se obtuvieron al finalizar las pruebas fueron: mejorar los nombres de las
variables, mejorar los nombres de los métodos, crear nuevos métodos para reducir la
duplicación del código, simplificar las condiciones y estructuras, y simplificar las
condiciones del bucle [40].
Otro concepto relacionado con la legibilidad del software, son las convenciones de código,
las cuales son un conjunto de reglas de codificación que adoptan algunos desarrolladores
de software para escribir código fuente [26]. El beneficio de aplicarlo es que facilitará la
lectura y comprensión del mismo en las tareas de mantenimiento [26]. Esas reglas se
dividen en las siguientes categorías: estructura del archivo, identación, comentarios,
espacios en blanco, nombre de identificadores, declaraciones y prácticas específicas para
lenguajes de programación [26], las cuales coinciden con las características que permiten
evaluar la legibilidad en el software, presentadas en el Capítulo 4. Por lo anterior, Chen et
al. (2018) [26], desarrollaron la herramienta web ProgEdu, con el objetivo de apoyar el
aprendizaje en los cursos de programación en lenguaje Java, evaluando el cumplimiento
de las convenciones en el código fuente. El experimento, que consistió en el proceso de
aprendizaje iterativo, expuesto en la Figura 17, fue realizado con estudiantes universitarios,
en una institución educativa de Taiwán [26].
Figura 17. Proceso de aprendizaje iterativo de Chen.
Los instructores y los estudiantes podían ingresar a ProgEdu, donde podían consultar su
asignación y ver de forma amigable los resultados de la revisión del código y la evolución
en el trabajo [26]. Al finalizar el experimento, se encontró que las violaciones de
codificación más comunes fueron de identación y espacios en blanco para los programas
en lenguaje Java; y la identación, espacios en blanco y nombre de identificadores para las
aplicaciones móviles en Java [26].
6.1.2 Buenas prácticas de la legibilidad del software

Sampaio y Barbosa (2016) [43], realizaron en Portugal un trabajo de investigación cuyo
objetivo principal fue desarrollar un conjunto de buenas prácticas para la legibilidad del
software, para ser usada en POO35 en los programas de educación superior de su país
(Portugal). Para ello, evaluaron la importancia que tenía para los docentes de asignaturas
relacionadas con la programación de software, la enseñanza de buenas prácticas que
permitieran a los nuevos desarrolladores construir código legible [43]. Como parte inicial
35 POO: Programación Orientada a Objetos.

del trabajo, realizaron una RSL de los trabajos relacionados con la legibilidad del software
y al final, obtuvieron un listado con las mejores prácticas para escribir código fuente legible,
la cual denominaron la “lista compilada de buenas prácticas de la legibilidad del software”
[43]. La lista se muestra a continuación, dividida en dos tablas: la primera tabla,
denominada Tabla 30, contiene las especificaciones que son consideradas como buenas
prácticas de legibilidad en el código fuente, mientras que la segunda tabla, denominada
Tabla 32, contiene las que representan las malas prácticas de legibilidad al escribir código
fuente. La lista de prácticas fue complementada con aportes de los autores Dos Santos et
al. (2018) [30], Alawad et al. (2018) [5] y Chen et al. (2018) [26].
Tabla 30. Lista compilada de buenas prácticas en la escritura de código fuente. Fuente
principal: Sampaio y Barbosa (2016) [43].
BUENAS PRÁCTICAS
No. Descripción Referencia
1 Longitud máxima de línea. [43]

2 Identación de líneas. [26][43]
3 Uso de corchetes en expresiones. [43]
4 Uniformidad en la notación, terminología y símbolos usados. [43]
5 Romper la línea después del punto y coma. [43]
6 Líneas en blanco. [43]
7 Líneas de código relacionadas deberían aparecer juntas. [43]
8 Distancia corta entre la definición y la referencia de una variable. [43]
9 La función que llama debe estar por encima de la función que se llama. [43]
10 El operador de asignación igual (=), debe incluir un espacio en blanco antes y [43]
después.
11 Espacios en blanco entre los argumentos y/o parámetros de funciones. [26][43]
12 Espacios en blanco para enfatizar la precedencia de operadores en una expresión. [26][43]
13 Uso de constantes simbólicas en lugar de constantes numéricas. [43]

14 Uso de enumeraciones en lugar de variables. [43]
15 Usar { y } para encerrar las instrucciones de un bucle. [43]
16 Nombrar los identificadores apropiadamente. [26][43]
17 Longitud máxima del identificador: de 9 a 16 caracteres aproximadamente. [43]
18 Comentarios: consistentes con el código y controlado. [43]

19 Evitar más las ramas de decisiones. [43]
BUENAS PRÁCTICAS
20 Reorganización de instrucciones en un módulo para reducir el alcance de la variable. [43]
21 Evitar las funciones recursivas. [43]

22 Usar sobre escritura de métodos cuando sea adecuado. [43]
23 Preferir contenedores a vectores. [43]
24 Alcance estrecho de las variables. [43]
25 Consistencia de la variable de acuerdo a todos sus usos. [43]
26 El bucle while es mejor que el bucle do-while. [5]
27 Las llaves que abren un bloque de código deben residir en la misma línea de sus [30]
declaraciones, en caso de que haya una; las llaves de cierre deben residir en sus
propias líneas.
28 Debe haber una línea en blanco después del bloque de código que abre y cierra [30]
llaves; excepción: llaves cerradas que terminan bloques de código de declaraciones
que contienen rutas secundarias de ejecución, por ejemplo: llaves cerradas de
declaraciones “if” seguidas de otra cosa; cerrar llaves de declaraciones try seguidas
de una captura;
29 Las longitudes de línea deben mantenerse dentro del límite de 80 caracteres; [30]
30 No debe haber más de tres niveles de anidación de bloque de código; [30]
31 Evite escribir varias declaraciones separadas por un ";" en una sola línea. Cada [30]
declaración debe estar en una línea propia;
32 Evite, siempre que sea posible, el uso de nombres completos para hacer referencia [30]
a los nombres de clase en el código; use cláusulas de importación en su lugar.
33 Las llamadas frecuentes a las subpropiedades de las propiedades de los miembros [30]
de la clase deben hacerse almacenando una referencia a esa subpropiedad,
evitando múltiples declaraciones que contengan largas cadenas de objetos y
subpropiedades
34 Los nombres de los identificadores deben usar palabras del diccionario [30]
La Tabla 30, está compuesta por tres campos: el primero es una numeración de la lista,
que solo es utilizada para mostrar orden, pero no representa ningún tipo de relevancia. La
segunda columna es la descripción de la práctica, y la tercera columna, denominada
referencia, indica la fuente de la literatura en la cual se encontró mención de la práctica.
Algunas de las prácticas mencionadas, corresponden a características que debe tener el
código fuente para ser considerado legible [43]. En la revisión de literatura desarrollada por
Sampaio y Barbosa [43], encontraron que las prácticas con mayor número de referencias
fueron: longitud máxima de línea, identación de líneas, líneas en blanco, nombres
apropiados para los identificadores, longitud máxima del identificador, cohesión de los
comentarios con el código fuente, las cuales corresponden a características relevantes

medidas en los modelos de predicción de la legibilidad del software.
Para el lenguaje de servicios web WSDL, De Renzis et al. (2016) [29], propusieron las
buenas prácticas expuestas en la Tabla 31.
Tabla 31. Buenas prácticas para el lenguaje WSDL. Obtenido de la fuente [29].
No. Práctica
1 Convenciones de nomenclatura adecuadas.
2 Identificadores descriptivos para las operaciones, mensajes y los parámetros, que representan
la funcionalidad de una operación.
3 Conceptos específicos para reducir la ambigüedad.
4 Nombres de parámetros no crípticos, que describen el uso.
5 Nombres de mensajes relacionados a sus operaciones.
6 Acrónimos y abreviaturas familiares, que se auto describen.
Continuando con el listado, se presenta la Tabla 32, que corresponde a las malas prácticas
de legibilidad del software, las cuales indican lo que no debe tener un código fuente para
que sea considerado como legible.
Tabla 32. Lista compilada de malas prácticas en la escritura de código fuente. Fuente
principal: Sampaio y Barbosa (2016) [43].
MALAS PRÁCTICAS
1 Método largo. [43]
2 Lista larga de parámetros. [43]
3 Código idéntico o muy similar en más de una ubicación. [43]
4 Nombres de identificadores en nombres de métodos. [43]
5 Nombres de métodos que no describen lo que hace el método. [43]
6 Definición o uso incorrecto de la herencia. [43]

7 Bloques lógicos condicionales largos. [43]
8 Declaración local sin criterio. [43]
9 El uso de matrices y bucles anidados. [5]
En la Tabla 32 se observan 3 columnas: la primera es una numeración de la lista, que solo

es utilizada para identificar cada práctica presentada, pero no representa el orden de
importancia. La segunda columna es la descripción de la práctica en sí, y la tercera
columna, denominada “Referencia”, indica la fuente de la literatura, en la cual se encontró,
que corresponde en su mayoría al estudio realizado por Sampaio y Barbosa (2016) [43].
Por otra parte, en el 2010 Butler et al. [20], realizaron un estudio que evaluó la importancia
de los nombres de los identificadores en el código fuente, los cuales son creados por
diseñadores y programadores, y reflejan su comprensión, cognición e idiosincrasia sobre
el software [20]. También indicaron que, una pobre calidad en los nombres de los
identificadores es una barrera para la comprensión del programa, lo que indica falta de
entendimiento del problema o la solución dada en el código fuente, lo que se traduce
finalmente en una pobre calidad del software [20]. Con el fin de poder identificar nombres
de calidad, Butler et al. se enfocaron en el uso de los elementos del lenguaje natural,
ignorando el tema de contenido semántico y el uso de la gramática [20]. Como resultado
lograron obtener una guía de estilo con recomendaciones para aplicar a los nombres de
los identificadores, las cuales se listan a continuación en la Tabla 33.
Tabla 33. Guía de estilo recomendada para los identificadores. Obtenida de la fuente [20].
No. Recomendación
1 Palabras excesivas: recomiendan que un nombre compuesto tenga máximo 4 palabras.
2 Longitud del nombre.
3 Anomalía de la convención del nombre.
4 Palabras que no están en el diccionario: de acuerdo al idioma natal del programador será un
diccionario de palabras en inglés u otro idioma.
5 Número de palabras: un nombre compuesto debe crearse con 2 a 4 palabras.
6 Nombre numérico para un identificador: El nombre de un identificador no debe tener exclusivamente
palabras que indiquen un valor, por ejemplo, forty_one.
7 Nombres cortos: no deberían tener menos de 8 caracteres a excepción de una lista de nombres
personalizados.
8 Tipo de codificación: no debería usarse notación húngara o similar.
Las recomendaciones de estilo para identificadores, listadas en la Tabla 33, no fueron

asociadas por el autor [20] a un lenguaje de programación en particular, por lo que podrían
ser aplicados a cualquier lenguaje, y evaluar posteriormente los resultados.
6.2 Retos
En la literatura revisada, algunos autores mencionaron deficiencias en sus propuestas, así
como posibles mejoras que pueden realizar ellos u otros investigadores que deseen
continuar con los estudios. Por ello, en la Tabla 34, se presenta una síntesis de los retos
que deben afrontar los autores que deseen continuar con los estudios relacionados a la
Tabla 34. Retos identificados para los trabajos futuros de legibilidad del software.
No. Reto Referencia

1 Desarrollar una herramienta, algoritmo, o un Plugin de apoyo, para [5] [1] [7] [10] [6]
que un programador pueda medir la legibilidad de su código fuente [27] [32] [35] [36]
en tiempo de desarrollo. [45]
2 Continuar las investigaciones y proponer mejores métricas para [5][1][7][10] [6] [11]
evaluar la legibilidad del software. Por ejemplo, tener una métrica [25] [36] [45]
basada en la calidad de los comentarios, analizando el contenido
del mismo usando técnicas de procesamiento de lenguaje natural,
no por la cantidad de líneas.
3 Diversificar los lenguajes de programación de los conjuntos de [5]
datos utilizados en los estudios, teniendo en cuenta que casi todos [25][26][27][28][31]
los fragmentos corresponden al lenguaje Java. [35] [45]
Probar el nuevo conjunto de datos en los modelos ya propuestos,
así como en la replicación de otros estudios.
4 Utilizar el algoritmo de asignación automática de nombres a otros [24]
tipos de identificadores en el código fuente, aparte de la clase y el
método, mejorando así la legibilidad.
5 Permitir la parametrización en los modelos de legibilidad, para que [14]
de acuerdo al tipo de lenguaje de programación, se ajusten las
características y las métricas a evaluar .
6 Para los experimentos que usaron la herramienta WordNet, [29]
reemplazarla por otras alternativas como DISCO y NER.
7 Diversificar el conjunto de participantes, que ayudaron con la [31]
anotación de los datos en los estudios relacionados con los
modelos de legibilidad, en cuanto a la experiencia y el origen.
8 Mejorar el rendimiento del modelo de legibilidad IncepCRM, [36]
ajustando parámetros.
En la Tabla 34, se presentan los retos ordenados por número de menciones, presentando
desde el más relevante, hasta el menos relevante. En primer lugar, se encuentra el reto de
desarrollar una herramienta, algoritmo o Plugin que, pueda ser incorporado a algún IDE de
desarrollo, para evaluar la legibilidad del software en tiempo de desarrollo, lo cual, sería la
solución definitiva a la problemática identificada con la legibilidad del software. El reto
número 2, indica que es necesario que se sigan realizando estudios de investigación
asociados a la predicción de la legibilidad del software, ya que aún no se cuenta con un
modelo definitivo. El reto número 3, hace referencia a que los modelos de predicción de
legibilidad propuestos hasta la fecha, han estado principalmente enfocados al lenguaje de
programación Java, y aunque Dorn [6], incorporó en su modelo los lenguajes Python y
CUDA, quedan muchos lenguajes de programación ampliamente utilizados por fuera de
estos estudios. Para el reto 7, se presenta la necesidad de diversificar más el grupo de
participantes que ayudan con la anotación de los datos, pues, a pesar de que los
investigadores intentaron hacerlo, eligiendo a estudiantes universitarios del área de
Ingeniería de Software de varios niveles y profesionales de la industria con diferentes años

de experiencia, los participantes de cada experimento pertenecen a una misma
localización, como una misma ciudad, y es posible que los resultados se vean influenciados
por factores culturales.

El Capítulo 6 permite responder la tercera pregunta de investigación: ¿Cuáles son los
principales retos y aplicaciones de interés en las investigaciones relacionadas con la
legibilidad del software?
Las aplicaciones, hacen referencia a los usos que algunos autores realizaron con el tema
de legibilidad del software, para apoyar o solucionar alguna problemática de la industria
del software o la academia.
Las aplicaciones más relevantes encontradas fueron: la creación de modelos para medir
la legibilidad del software de forma automática [1] [7] [10] [6] [14] [25] [27] [33] [35] [36][42]
[45]; y el apoyo a las instituciones de educación superior, con el aprendizaje de buenas
prácticas de legibilidad [26] [28] [34] [40] [43].
Adicionalmente, los autores reconocieron las debilidades y las oportunidades en sus

propios estudios, lo que les permitió identificar los retos que deben enfrentar los
investigadores que deseen dar continuidad a los trabajos de investigación relacionados
con la legibilidad del software.
Los retos más importantes fueron: 1) desarrollar una herramienta, algoritmo o Plugin que,
pueda ser incorporado a algún IDE de desarrollo, para evaluar la legibilidad del software
en tiempo de desarrollo, lo cual, sería la solución definitiva a la problemática identificada
con la legibilidad del software [5][1] [7] [10] [6] [27] [32] [35] [36] [45]; 2) Continuar las
investigaciones y proponer mejores métricas para evaluar la legibilidad del software [5][1]
[7] [10] [6] [11] [25] [36] [45]; y 3) Diversificar los lenguajes de programación de los
conjuntos de datos utilizados en los estudios, teniendo en cuenta que casi todos los
fragmentos corresponden al lenguaje Java [5] [25] [26] [27] [28][31] [35] [45].
El capítulo 6, permite dar cumplimiento al objetivo número 3 establecido en este trabajo

final, el cual era "Identificar los retos actuales y las aplicaciones de interés para la
comunidad científica en el área".
Capítulo 7. Conclusiones y recomendaciones 125
7 Capítulo 7. Conclusiones y
recomendaciones
7.1 Conclusiones
Este trabajo final de maestría, realizó una revisión sistemática de literatura sobre las
métricas de legibilidad del software, para lo cual se diseñó e implementó una estrategia de
búsqueda, la cual, luego de ser ejecutada en 5 bases de datos bibliográficas, permitió
obtener y seleccionar 30 documentos finales, con información relevante de las
características del código fuente que permiten evaluar la legibilidad del mismo, las
métricas, los modelos para la evaluación automática, así como determinar la evolución que
han tenido las investigaciones sobre el tema. Adicionalmente, se identificaron los retos y
aplicaciones propuestos por investigadores de varios lugares del mundo.
Las características del software utilizadas para medir la legibilidad del código fuente, son
los espacios en blanco (identación), comentarios, LOC, número de paréntesis, número de
operadores aritméticos, entropía, volumen del programa, número y nombre de los
identificadores, estructuras de control y número de palabras clave.
Se encontró evidencia sobre la evolución de las métricas de legibilidad de software, desde

el año 1990, donde fueron introducidas por Chung y Yung. En la década del 2000, se
realizaron varias investigaciones, donde mostraron el fuerte impacto que tiene la legibilidad
en los costos asociados a la fase de mantenimiento, y continuaron los estudios sobre las
características y métricas que permiten medir la legibilidad en el software. En el año 2010,
Buse y Weimer [1] propusieron el primer modelo automático para medir la legibilidad de un
fragmento de código fuente, y en años posteriores, aparecieron los modelos de Posnett et
al. (2011) [10], Dorn (2012) [6], Liu et al. (2015) [33], Scalabrino et al. (2016 y 2018) [45],
Xu et al. (2017) [42], Choi et al. (2018) y Mi et al. (2018) [35] [36]. Los modelos utilizaron
técnicas de aprendizaje de máquina, entrenando clasificadores de forma supervisada
como red de Bayes y aprendizaje profundo. Otros modelos, usaron técnicas de análisis
léxico, tomando al código fuente como un texto. Para evaluar la relación de las
características propuestas con la percepción final de legibilidad, se usaron técnicas de
análisis de correlación.
Las aplicaciones que se le está dando a la legibilidad del software, según la literatura
encontrada, fueron los modelos automáticos de legibilidad, al apoyo del aprendizaje de
buenas prácticas y estilos de embellecimiento en las instituciones de educación superior
[32] [34] [41], el impacto de las características de legibilidad en la carga cognitiva del lector
[31] [32], y el uso para identificar los perfiles de los programadores en un proceso de
reclutamiento [12].
Los retos identificados son, desarrollar una herramienta, algoritmo o Plugin que, pueda ser
incorporado a algún IDE de desarrollo, para evaluar la legibilidad del software en tiempo
de desarrollo, lo cual, sería la solución definitiva a la problemática identificada con la
legibilidad del software. Es necesario continuar con los estudios de investigación asociados
a la predicción de la legibilidad del software, ya que aún no se cuenta con el modelo, las
características y las métricas definitivas. Teniendo en cuenta, que los modelos de
predicción de legibilidad propuestos hasta la fecha, han estado principalmente enfocados
al lenguaje de programación Java, es necesario incorporar otros lenguajes de
programación.
Los resultados presentados en este documento, brindan a los futuros investigadores una
fuente útil de información, reuniendo los datos y los estudios realizados hasta la fecha,
sobre las métricas de legibilidad del software, para que puedan dar continuidad a las
investigaciones.
7.2 Recomendaciones
Los investigadores que deseen continuar con los estudios, pueden realizar una replicación
de los mismos, pero utilizando nuevos conjuntos de datos que correspondan a lenguajes
Capítulo 7. Conclusiones y recomendaciones 127
de programación diferentes a Java. También, pueden desarrollar nuevos modelos de

legibilidad del software, proponiendo nuevas características y métricas que les permita
medir con mayor precisión, o utilizando nuevas técnicas basadas en aprendizaje profundo
(Deep learning).
Teniendo en cuenta el modelo para sugerencias automáticas de nombres desarrollado por

Allamanis et al. (2015) [24], el cual sugiere de forma acertada nombres para variables
simples, nombres para la clase o para un método, según el contenido del código, puede
proponerse un modelo integral de legibilidad, que no sólo permita medir la legibilidad de
un fragmento de código fuente en tiempo de desarrollo, sino que permita la corrección
automática de las secciones que no lo sean. Adicionalmente, ese nuevo modelo integral
de legibilidad podría ser parametrizable, de acuerdo a su dominio y al lenguaje de
programación en el que se encuentre el fragmento de código fuente a evaluar, así como lo
propuso Akour et al. (2016) [14].
Referencias
[1] R. P. L. Buse and W. R. Weimer, “Learning a Metric for Code Readability,” IEEE
Trans. Softw. Eng., vol. 36, no. 4, pp. 546–558, Jul. 2010.
[2] Jose Luis Martinez Flores, “Metricas de software en lenguajes de cuarta generacion,”
universidad autonoma de nuevo leon, 1994.
[3] J. M. Ruiz, C. D. Pacifico, and M. M. Pérez, “Clasificación y Evaluación de Métricas

de Mantenibilidad Aplicables a Productos de Software Libre,” Ruiz, J. M., Pacifico, C.
D., Pérez, M. M. (n.d.). Clasif. y Evaluación Métricas Mantenibilidad Apl. a Prod.
Softw. Libr. Retrieved from
http//sedici.unlp.edu.ar/bitstream/handle/10915/61928/Documento_completo.pdf-
PDFA.pdf?s.
[4] E. Irrazábal and J. Garzás, “Revista española de innovación, calidad e ingeniería del
software.,” Rev. española innovación, Calid. e Ing. del Softw., vol. 6, no. 3, 2010.
[5] D. Alawad, M. Panta, M. Zibran, and R. Islam, “An Empirical Study of the
Relationships between Code Readability and Software Complexity,” 2018.
[6] J. Dorn, “A General Software Readability Model,” 2012.
[7] S. Scalabrino, G. Bavota, C. Vendome, M. Linares-Vasquez, D. Poshyvanyk, and R.

Oliveto, “Automatically assessing code understandability: How far are we?,” in 2017
32nd IEEE/ACM International Conference on Automated Software Engineering
(ASE), 2017, pp. 417–427.
[8] M. Red de Ingeniería de Software de Latinoamérica, Ó. Pedreira, and C. M.

Fernández, Revista latinoamericana de ingeniería de software., vol. 3, no. 3. 2015.
[9] I. BARRIO, “Legibilidad y salud: Los métodos de medición de la legibilidad y su

aplicación al diseño de folletos educativos sobre salud,” Universidad Autónoma de
Madrid, 2007.
[10] D. Posnett, A. Hindle, and P. Devanbu, “A simpler model of software readability,” in

Proceeding of the 8th working conference on Mining software repositories - MSR ’11,
2011, p. 73.
[11] U. A. Mannan, I. Ahmed, and A. Sarma, “Towards understanding code readability and
Referencias 129
its impact on design quality,” in Proceedings of the 4th ACM SIGSOFT International
Workshop on NLP for Software Engineering - NL4SE 2018, 2018, pp. 18–21.
[12] D. J. F. Novais, M. J. V. Pereira, and P. R. Henriques, “Program analysis for

Clustering Programmers’ Profile,” 2017, pp. 701–705.
[13] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey, and S. Linkman,

“Systematic literature reviews in software engineering – A systematic literature
review,” Inf. Softw. Technol., vol. 51, pp. 7–15, 2008.
[14] M. Akour and B. Falah, “Application domain and programming language readability
yardsticks,” in 2016 7th International Conference on Computer Science and
Information Technology (CSIT), 2016, pp. 1–6.
[15] B. Pereira, A. Farid, H. Quintero, I. Granadillo, and J. Bustamante, “Métricas de

Calidad de Software.” .
[16] G. Mena Mendoza, “ISO 9126-3: Métricas Internas de la Calidad del Producto de
Software,” 2006. [Online]. Available:
http://mena.com.mx/gonzalo/maestria/calidad/presenta/iso_9126-3/. [Accessed: 01-
Apr-2018].
[17] P. Hegedűs, I. Kádár, R. Ferenc, and T. Gyimóthy, “Empirical evaluation of software

maintainability based on a manually validated refactoring dataset,” Inf. Softw.
Technol., vol. 95, pp. 313–327, Mar. 2018.
[18] J. Borstler and B. Paech, “The Role of Method Chains and Comments in Software
Readability and Comprehension—An Experiment,” IEEE Trans. Softw. Eng., vol. 42,
no. 9, pp. 886–898, Sep. 2016.
[19] F. Scalone, “ESTUDIO COMPARATIVO DE LOS MODELOS Y ESTANDARES DE

CALIDAD DEL SOFTWARE,” UNIVERSIDAD TECNOLOGICA NACIONAL
FACULTAD REGIONAL BUENOS AIRES, 2006.
[20] S. Butler, M. Wermelinger, Yijun Yu, and H. Sharp, “Exploring the Influence of
Identifier Names on Code Quality: An Empirical Study,” in 2010 14th European
Conference on Software Maintenance and Reengineering, 2010, pp. 156–165.
[21] G. Rincón, M. Pérez, and S. Hernández, “MODELO DE CALIDAD (MOSCA+) PARA

EVALUAR SOFTWARE DE SIMULACIÓN DE EVENTOS DISCRETOS,” 2003.
[22] B. Kitchenham, “Procedures for performing systematic reviews,” Br. J. Manag., vol.
14, no. 0, pp. 207–222, 2004.
[23] F. Garcia, “Revisión sistemática de literatura para artículos,” Tecnológico de

Monterrey. Tecnológico de Monterrey y Universidad de Salamanca, Monterrey, 2017.
[24] M. Allamanis, E. T. Barr, C. Bird, and C. Sutton, “Suggesting accurate method and
class names,” in Proceedings of the 2015 10th Joint Meeting on Foundations of
Software Engineering - ESEC/FSE 2015, 2015, pp. 38–49.
[25] H. AMAN, S. AMASAKI, T. SASAKI, and M. KAWAHARA, “Lines of Comments as a

Noteworthy Metric for Analyzing Fault-Proneness in Methods,” Okayama, JAPON,

2015.
[26] H. M. Chen, W. H. Chen, and C. C. Lee, “An automated assessment system for
analysis of coding convention violations in Java programming assignments*,” J. Inf.
Sci. Eng., vol. 34, no. 5, pp. 1203–1221, 2018.
[27] S. Choi, S. Kim, J.-H. Lee, J. Kim, and J.-Y. Choi, “Measuring the Extent of Source
Code Readability Using Regression Analysis,” Springer, Cham, 2018, pp. 410–421.
[28] R. Coleman, “Aesthetics Versus Readability of Source Code,” Int. J. Adv. Comput.
Sci. Appl., vol. 9, no. 9, pp. 12–18, 2018.
[29] A. De Renzis, M. Garriga, A. Flores, A. Cechich, C. Mateos, and A. Zunino, “A domain

independent readability metric for web service descriptions,” Comput. Stand.
Interfaces, vol. 50, pp. 124–141, Feb. 2017.
[30] R. M. dos Santos and M. A. Gerosa, “Impacts of coding practices on readability,” in

Proceedings of the 26th Conference on Program Comprehension - ICPC ’18, 2018,
pp. 277–285.
[31] S. Fakhoury, Y. Ma, V. Arnaoudova, and O. Adesope, “The effect of poor source code
lexicon and readability on developers’ cognitive load,” in Proceedings of the 26th
Conference on Program Comprehension - ICPC ’18, 2018, pp. 286–296.
[32] L. Frunzio, B. Lin, M. Lanza, and G. Bavota, “RETICULA: Real-time code quality
assessment,” in 2018 IEEE 25th International Conference on Software Analysis,
Evolution and Reengineering (SANER), 2018, pp. 542–546.
[33] Y. Liu, X. Sun, and Y. Duan, “Analyzing program readability based on WordNet,” in
Proceedings of the 19th International Conference on Evaluation and Assessment in
Software Engineering - EASE ’15, 2015, pp. 1–2.
[34] Q. Mi, J. Keung, X. Mei, Y. Xiao, and W. K. Chan, “A Gamification Technique for
Motivating Students to Learn Code Readability in Software Engineering,” in 2018
International Symposium on Educational Technology (ISET), 2018, pp. 250–254.
[35] Q. Mi, J. Keung, Y. Xiao, S. Mensah, and Y. Gao, “Improving code readability
classification using convolutional neural networks,” Inf. Softw. Technol., vol. 104, pp.
60–71, Dec. 2018.
[36] Q. Mi, J. Keung, Y. Xiao, S. Mensah, and X. Mei, “An Inception Architecture-Based
Model for Improving Code Readability Classification,” in Proceedings of the 22nd
International Conference on Evaluation and Assessment in Software Engineering
2018 - EASE’18, 2018, pp. 139–144.
[37] Q. Mi, J. Keung, and Y. Yu, “Measuring the Stylistic Inconsistency in Software
Projects using Hierarchical Agglomerative Clustering,” in Proceedings of the The 12th
International Conference on Predictive Models and Data Analytics in Software
Engineering - PROMISE 2016, 2016, pp. 1–10.
[38] A. Pahal and R. S. Chillar, “Code Readability: A Review of Metrics for Software
Referencias 131
Quality,” Int. J. Comput. Trends Technol., vol. 46, no. 1, 2017.
[39] S. Scalabrino, M. Linares-Vásquez, R. Oliveto, and D. Poshyvanyk, “A

comprehensive model for code readability,” J. Softw. Evol. Process, vol. 30, no. 6, p.
e1958, Jun. 2018.
[40] T. Sedano, “Code Readability Testing, an Empirical Study,” in 2016 IEEE 29th
International Conference on Software Engineering Education and Training (CSEET),
2016, pp. 111–117.
[41] A. Wulff-Jensen, K. Ruder, E. Triantafyllou, and L. E. Bruni, “Gaze Strategies Can

Reveal the Impact of Source Code Features on the Cognitive Load of Novice
Programmers,” 2019.
[42] W. Xu, D. Xu, and L. Deng, “Measurement of Source Code Readability Using Word
Concreteness and Memory Retention of Variable Names,” in 2017 IEEE 41st Annual
Computer Software and Applications Conference (COMPSAC), 2017, pp. 33–38.
[43] I. B. Sampaio and L. Barbosa, “Software readability practices and the importance of
their teaching,” in 2016 7th International Conference on Information and
Communication Systems (ICICS), 2016, pp. 304–309.
[44] S. Scalabrino, G. Bavota, C. Vendome, M. Linares-Vasquez, D. Poshyvanyk, and R.

Oliveto, “Automatically assessing code understandability: How far are we?,” in 2017
32nd IEEE/ACM International Conference on Automated Software Engineering
(ASE), 2017, pp. 417–427.
[45] S. Scalabrino, M. Linares-Vásquez, R. Oliveto, and D. Poshyvanyk, “A

comprehensive model for code readability,” J. Softw. Evol. Process, vol. 30, no. 6, p.
e1958, Jun. 2018.

Métricas de Legibilidad Del Software

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Métricas de Legibilidad Del Software

Загружено:

Авторское право:

Доступные форматы

Métricas de legibilidad del software:

Una revisión sistemática de literatura

Ingrid Sofia Echavarría Flórez

Universidad Nacional de Colombia

Métricas de legibilidad del software:

Ingrid Sofía Echavarría Flórez

Universidad Nacional de Colombia

Dedico este trabajo a mi hija Julieta, quien

A mi mamá Yolanda y a mi tía Ruth por

Gracias a la Doctora en Ingeniería Diana Marcela Cardona, quien me brindó asesoría y

A pesar de los esfuerzos e investigaciones en el área de legibilidad del software, aún no se

Palabras clave: Métrica; Legibilidad; Código fuente; Software; Calidad; Clasificación;

Lista de figuras ................................................................................................................ 12

Lista de tablas ................................................................................................................. 13

2. Capítulo 2. Contexto: calidad y legibilidad del software ............................................ 22

3. Capítulo 3. Revisión sistemática de literatura de métricas de legibilidad del software36

3.6 Criterios de exclusión ......................................................................................... 43

4. Capítulo 4. Características y métricas de legibilidad del software ............................. 66

5 Capítulo 5. Modelos de legibilidad del software ........................................................ 84

6 Capítulo 6. Retos y aplicaciones de la legibilidad del software ............................... 113

6.2 Retos................................................................................................................ 121

7 Capítulo 7. Conclusiones y recomendaciones ........................................................ 125

Figura 1: Clasificación de las métricas de software. ........................................................ 25

Figura 2. Clasificación de las métricas de calidad de un producto de software. ............... 26

Figura 4. Línea de tiempo de los modelos y estándares de calidad aplicados a productos

Figura 5. Fases de trabajo de la RSL para las métricas de legibilidad. ............................ 37

Figura 6. Formato de evaluación de la calidad del estudio. ............................................. 45

Figura 7. Imagen de la herramienta de gestión bibliográfica Mendeley con las carpetas. 47

Figura 10. Documentos finales clasificados por año de publicación. ............................... 59

Figura 13. Evolución de los modelos de legibilidad del software. .................................... 89

Figura 17. Proceso de aprendizaje iterativo de Chen. ................................................... 117

Tabla 1. Definición de modelos y estándares de calidad de software. ............................. 30

Tabla 2. Descripción de los modelos/estándares de calidad de software. ....................... 31

Tabla 3. Listado de palabras clave. ................................................................................. 40

Tabla 4. Listado de palabras clave descartadas. ............................................................. 41

Tabla 5. Factores evaluados en la lista de chequeo. ....................................................... 45

Tabla 6. Detalle del formato de extracción de datos. ....................................................... 49

Tabla 7. Ecuaciones de búsqueda utilizadas para la recolección. ................................... 53

Tabla 8. Parametrización adicional realizada en las fuentes bibliográficas. ..................... 53

Tabla 9. Resultados cuantitativos de la RSL. .................................................................. 54

Tabla 10. Resultados cuantitativos de la RSL. Parte 2. ................................................... 55

Tabla 11. Cantidad total de documentos seleccionados. ................................................. 55

Tabla 12. Listado de estudios seleccionados en la RSL. ................................................. 56

Tabla 13. Clasificación de los aportes encontrados en los estudios. ............................... 61

Tabla 15. Lenguajes de programación recomendados de acuerdo al dominio de la

Tabla 16. Listado de métricas simples en Java. .............................................................. 74

Tabla 17. Listado de métricas en C y C++, de la fuente [37]............................................ 74

Tabla 18. Listado de métricas compuestas...................................................................... 75

Tabla 20: Modelos de legibilidad del software. ................................................................ 90

Tabla 21. Técnicas utilizadas en las investigaciones para medir la legibilidad en el

Tabla 23. Lenguajes de programación utilizados en otros experimentos de legibilidad del

Tabla 24. Representación de la importancia de cada característica. ............................. 104

Tabla 28. Repositorios que contienen documentos de interés. ...................................... 110

Entre las características implícitas de la calidad del software se encuentra la mantenibilidad

Adicionalmente, dentro de la labor de mantenimiento, según estudios, los desarrolladores

A la fecha del presente documento, se encuentra en vigencia la familia de normas ISO/IEC

Barrio [9] definió la legibilidad, en general, como el conjunto de características tipográficas

1.2. Definición del problema

en el lenguaje de programación, conocimientos previos, costumbres, cultura y preferencias

1.3. Pregunta de investigación

1.4.1. Objetivo general

1.4.2. Objetivos específicos

1.5.1. Tipo de investigación