EVALUACIÓN EN EL CICLO

DE INVESTIGACIÓN
ACCIÓN EN INGENIERÍA DE
SOFTWARE

Breve descripción
Material compilado con fines didácticos

Cecilia Milena Hinojosa Raza

cmhinojosa@espe.edu.ec
Contenido
EVALUACIÓN EN EL CICLO DE INVESTIGACIÓN ACCIÓN (Staron, 2020) ..........................2
1 Introducción ..................................................................................................................2
2 Limpieza y preparación de los datos ............................................................................... 3
3 Visualización de datos ....................................................................................................4
4 Estadística descriptiva ................................................................................................... 5
5 Conceptos básicos de estadística inferencial ................................................................... 7
6 Métodos de aprendizaje automático ............................................................................. 9
6.1 Agrupación ........................................................................................................... 10
6.2 Clasificación ......................................................................................................... 13
7 Análisis de datos cualitativos ........................................................................................ 17
7.1 Familiarizarse con los datos ................................................................................... 17
7.2 Generando códigos iniciales................................................................................... 18
7.3 Búsqueda de temas ............................................................................................... 20
7.4 Revisión de temas ................................................................................................. 21
7.5 Definir y nombrar temas ........................................................................................ 21
8 Análisis continuo de datos ........................................................................................... 22
9 Evaluación en la segunda y subsiguiente acción ............................................................ 23
10 Resumen ................................................................................................................... 23
Referencias ....................................................................................................................24

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 EVALUACIÓN EN EL CICLO DE INVESTIGACIÓN ACCIÓN
(Staron, 2020)

1 Introducción
Comprender el impacto de la acción tomada es una fase crucial de cualquier ciclo de investigación
acción. Al recopilar datos antes, durante y después de la acción, podemos explorar el impacto de
nuestra acción y así evaluarla.

La evaluación es crucial ya que basamos las decisiones en los próximos pasos del estudio en los
resultados de la misma. La forma típica de trabajar en la fase de evaluación de un ciclo de investigación
acción es la siguiente:

1. Limpiar y preparar los datos.

2. Visualizar y explorar los datos.
3. Ejecutar estadísticas inferenciales para verificar el efecto de la acción.
4. Interpretar y validar el hallazgo con el equipo de acción y el equipo de referencia.

La limpieza de los datos es un paso importante en cada estudio. Durante la recopilación de datos,
nuestro enfoque es obtener puntos de datos, encontrar entidades de medición relevantes y aplicar
instrumentos de medición. Solo observamos la calidad de los datos una vez que se recopilan, ya sea al
final o una vez que recopilamos grupos de puntos de datos. En el proceso de evaluación de la calidad,
a menudo encontramos que los datos deben limpiarse: pueden incorporar ruido, debido a los
instrumentos de medición y pueden contener datos no balanceados (por ejemplo, los módulos
defectuosos son menos que los módulos no defectuosos que necesitan equilibrio) cuando usamos el
aprendizaje automático para analizar los datos.

La limpieza de los datos a menudo se entrelaza con la visualización de los datos. Exploramos los datos
visualmente usando diagramas y gráficos, y al mismo tiempo, podemos identificar valores atípicos,
valores perdidos o dependencias inesperadas. La visualización de los datos se centra en proporcionar
la conciencia de los datos, no tanto en los análisis, para eso utilizamos estadísticas inferenciales y
aprendizaje automático. Sin embargo, la visualización debe ser objetiva y exhaustiva, ya que puede ser
engañosa. Puede suceder que desencadenemos involuntariamente una cadena de decisiones
incorrectas si los datos no se visualizan correctamente (Fig. 1).

Fig.1 Ejemplo de dos diagramas (a) engañosos con la escala que comienza en el objetivo 90 (b)

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

También necesitamos usar las estadísticas inferenciales para asegurarnos de que sabemos cuán
significativo (estadísticamente) es el efecto observado. Hay muchas pruebas estadísticas diferentes para
usar en diferentes circunstancias, y recomiendo leer un libro sobre métodos estadísticos para
profundizar en cómo usarlos. En este documento, nos centramos en los más populares para ilustrar el
uso de las estadísticas inferenciales.

Finalmente, en nuestro flujo de trabajo con los datos, necesitamos interpretar los resultados de las
pruebas estadísticas, y debemos validar estos hallazgos discutiéndolos con el equipo de referencia y
las partes interesadas. Aquí, el flujo de trabajo difiere un poco de los estudios de casos, experimentos
e investigaciones científicas de diseño, ya que el equipo de acción discute explícitamente los resultados
con el equipo de referencia. Esta discusión puede conducir al cambio en la fase de diagnóstico para el
próximo ciclo, por ejemplo, mediante el diseño de acciones adicionales.

2 Limpieza y preparación de los datos

En todos los procedimientos de recopilación de datos, corremos el riesgo de obtener datos que
requieren limpieza o filtrado. Es normal que la recopilación de datos no siempre se realice de acuerdo
con el plan. Nuestros guiones pueden dejar de funcionar, o nuestros encuestados pueden estar
enfermos cuando necesitamos pedir su opinión. Por lo tanto, antes de comenzar a explorar los datos,
debemos limpiarlos de valores faltantes, puntos de datos dañados o puntos de datos incompletos.

También necesitamos preparar los datos para el análisis. Necesitamos cambiar la forma de los datos
para aplicar los métodos estadísticos apropiados para el análisis en cuestión.

Datos recopilados antes y después de la acción

En el proyecto de investigación acción que presenta un nuevo marco para el manejo de bases de datos,
el equipo de acción planteó una hipótesis de que el número de defectos cambió como resultado de
esa acción. La medida fue el número de defectos reportados por día. La Figura 2 muestra los defectos
recogidos 10 días antes y después de la acción.

Fig. 2 El número de defectos reportados antes y después de la acción tomada. Los datos se muestran tal como se
muestran en Microsoft Excel. Los datos son solo para los primeros 10 días de medición y los primeros 10 días
después de la acción.

La serie de datos no contiene datos faltantes y, por lo tanto, podemos usar los datos tal como están
para las visualizaciones y los análisis estadísticos.

Uno de los problemas más comunes con la recopilación de datos es la falta de datos. Los instrumentos
de medición que se utilizan para recopilar los datos pueden funcionar mal y, por lo tanto, nuestro

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

conjunto de datos puede estar incompleto. Si esto sucede, podemos usar varias técnicas de imputación
de datos para agregar el punto al conjunto de datos. También podemos eliminar el punto de datos.
Este último se recomienda si tenemos un número suficiente de puntos de datos, mientras que el
primero se recomienda cuando los puntos de datos son escasos.

Imputación de datos utilizando valores medios

En el proyecto de investigación acción que presenta un nuevo marco para el manejo de bases de datos,
el equipo de acción planteó una hipótesis de que el número de defectos cambió como resultado de
esa acción. La medida fue el número de defectos reportados por día. La Figura 6.3 muestra los defectos
recogidos 10 días antes y después de la acción. Faltaba uno de los puntos de datos.

Fig. 6.3 Punto de datos imputados (5), que es un valor medio de los puntos antes y después

La serie de datos con el punto de datos imputado es mayor que si los datos fueron eliminados. Sin
embargo, si usamos estadísticas inferenciales y comparamos valores medios, los resultados de la
imputación pueden sesgar la prueba. Esto debería discutirse como una amenaza para la validez de
nuestras conclusiones.

Otros métodos utilizados para la limpieza de datos son:

• eliminación de valores atípicos [BFM11],
• conjuntos de datos de equilibrio para aprendizaje automático [BPM04],
• eliminación de elementos duplicados,
• eliminación de datos irrelevantes (por ejemplo, defectos informados antes y después del
proyecto),
• reformatear (por ejemplo, "Defecto" debe reemplazarse por "defecto"), y
• escalamiento, normalización y estandarización.
El uso de estas técnicas nos proporciona los datos que conducen a resultados más correctos cuando
se usan en pruebas estadísticas.

3 Visualización de datos
El primer paso para visualizar los datos es trazar todos los puntos de datos en un diagrama relevante.
En la mayoría de los casos, podemos usar los diagramas estadísticos básicos como gráficos de barras,
gráficos de líneas o gráficos de dispersión. Estos diagramas dan la primera comprensión de cómo se
ven los datos.

Visualización de los datos sobre la entrada de defectos

En el proyecto de investigación acción que presenta un nuevo marco para el manejo de bases de datos,
el equipo de acción planteó una hipótesis de que el número de defectos cambió como resultado de

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

esa acción. La medida fue el número de defectos reportados por día. La Figura 6.4 muestra los defectos
antes y después de la acción.

Fig. 6.4 Defectos informados antes (verde) y después (azul) de la acción tomada. Los datos se ordenan por día:
100 días antes de la acción y 100 días después de la acción.

La figura muestra que el número de defectos cambió. El número de defectos informados después de
la acción es menor que antes de la acción.

Sin embargo, podemos usar técnicas de visualización más avanzadas para una exploración de datos
más avanzada, como:
• mapas de calor para explorar la frecuencia de conjuntos de datos tridimensionales, por
ejemplo, [SHF + 13],
• mapa de calor circular para explorar la frecuencia en datos estacionales, por ejemplo, [BRE13]
• gráfico bipartito para mostrar las dependencias entre dos conjuntos de datos, por ejemplo,
[ÇSM18], y
• círculo de embalaje para mostrar las jerarquías de herencia y la contención, por ejemplo,
[Tor15]

Las técnicas de exploración visual son populares en la ingeniería de software contemporánea, y hay
buenos libros y documentos sobre el tema, por ejemplo, [Tel07]. Existen muchas herramientas
excelentes de visualización de datos para acompañar las teorías de visualización, como Tableau, MS
Power BI, QlikSense y Tibco Spotfire. Alentamos a todos los equipos de acción a experimentar con la
visualización de datos y utilizar las herramientas más apropiadas para la tarea de visualización en
cuestión.

4 Estadística descriptiva

Una vez que vamos más allá de la simple visualización de datos, debemos comenzar a analizar los
datos utilizando técnicas estadísticas. Allí, también necesitamos visualizar los datos, no como puntos
de datos individuales sino como grupos, tendencias o distribuciones.

En las visualizaciones y exploraciones estadísticas básicas, las estadísticas descriptivas principales son
las más comunes:
• media y desviación estándar: para describir la distribución,
• mediana y modo: para comprender la centralidad de los datos y el valor más común, y

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 • intervalos de confianza: para comprender cuál es la dispersión de los datos en nuestro
conjunto de datos.
Utilizamos estas estadísticas para describir los grupos y para mostrar las tendencias generales en los
datos. Comparamos el impacto de nuestra acción con la línea de base antes de la acción. Para razonar
sobre la certeza de que los resultados observados no se deben cambiar; Recopilamos muchos puntos
de datos. Para razonar sobre el impacto, necesitamos agrupar los puntos de datos utilizando medios
y medianas para verificar si existe una diferencia entre estos grupos.

Los gráficos asociados con estas estadísticas descriptivas, por ejemplo, los diagramas de caja y los
histogramas, son útiles en la exploración visual de los datos. Ayudan al equipo de acción a comprender
el efecto de su acción. También ayudan al equipo de acción a comunicar los efectos al grupo de
referencia y a las partes interesadas.

Visualización de distribuciones de entrada de defectos

En la exploración visual de los datos de entrada de defectos en la Fig. 6.4, el equipo de acción
entendió que hay una diferencia en el número de defectos reportados por día.
Por lo tanto, el equipo decidió crear el diagrama de diagrama de caja para comparar las
distribuciones, que se presenta en la figura 6.5.

Fig. 5 Diagramas de cajas para las distribuciones de defectos

La figura muestra que el número de defectos cambió. El número de defectos informados después de
la acción es menor que antes de la acción. Por lo tanto, el equipo también decidió visualizar las
distribuciones y compararlas con las distribuciones normales con los mismos parámetros, que se
muestran en la figura 6.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

Fig. 6 Histograma con las distribuciones de defectos. La línea roja muestra la distribución normal con los mismos
parámetros que la distribución de entrada de defectos (media, desviación estándar)

El histograma proporcionó al equipo de acción una imagen similar: las dos series de datos, antes y
después de la acción, eran diferentes.

Las estadísticas descriptivas proporcionan la comprensión de los datos subyacentes, pero no

proporcionan los niveles de significancia, es decir, no proporcionan ninguna probabilidad de que la
diferencia observada en dos conjuntos de datos sea causada por casualidad. Para eso, necesitamos
usar estadísticas inferenciales, y necesitamos volver al principio básico de la acción, en comparación
con una línea de base antes de que se tomara la acción.

5 Conceptos básicos de estadística inferencial

Las pruebas de significación utilizando estadísticas inferenciales nos permiten comprender qué tan
probables son los resultados observados. La estadística inferencial se basa en el concepto de hipótesis
nula, es decir, la hipótesis de que no hay diferencia entre dos factores o niveles de tratamiento. Todas
las pruebas en estadística inferencial son específicas para un propósito, y en este libro, nos enfocamos
en la forma más común de usar estas pruebas: probar una hipótesis nula de que no hay diferencia
entre las medias de dos variables (o series de datos).

En la mayoría de los casos, la verificación de que no hay diferencia en las medias se realiza utilizando
la prueba t de Student o su corresponsal no paramétrico Wilcoxon [DS + 11]. Casi todos los libros de
estadísticas proporcionan buenas explicaciones de las matemáticas detrás de estas pruebas, por lo que
no detallamos cómo funcionan, sino que nos centramos en cómo aplicarlos.

Para saber si debemos usar la prueba t o Wilcoxon, debemos verificar si los datos se distribuyen
normalmente. Esto se puede hacer usando otra prueba: el Shapiro-Wilk. El Shapiro-Wilk verifica cuál
es la probabilidad de que la serie de datos dada no provenga de una distribución normal. Si la prueba
determina que los datos probablemente provengan de la distribución normal, entonces podemos usar
la prueba t paramétrica. La prueba t verifica si la diferencia entre las medias de dos conjuntos de datos
es estadísticamente significativa.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

La figura 6 muestra un ejemplo de dos distribuciones: pudimos ver que los picos estaban separados
entre sí. En la figura 4, también pudimos observar que las series estaban separadas. Visualmente,
obtuvimos la indicación de que la diferencia en las medias es significativa. La prueba t nos proporciona
la probabilidad de que esta diferencia se deba al azar o que cualquier punto dado pueda provenir de
cualquiera de las series. El valor p de las estadísticas nos proporciona la respuesta a eso. El valor p es
la probabilidad de aprobar la hipótesis nula cuando los datos muestran lo contrario, es decir, el llamado
error de tipo II.

Comprobación del supuesto de normalidad y uso de la prueba t

Una vez que el equipo de acción observó la diferencia en los medios para el flujo de entrada de
defectos por día antes y después de la acción, necesitaban comprender qué tan fuerte es el efecto. Por
lo tanto, decidieron ejecutar las pruebas estadísticas. Primero, tenían que ejecutar la prueba de
normalidad, la prueba de Shapiro-Wilk, para determinar si podían usar estadísticas paramétricas o no
paramétricas.

Los resultados de la prueba de Shapiro-Wilk fueron:

Visualmente, los gráficos Q-Q para ambas series de datos muestran que las desviaciones de la
distribución normal son pequeñas.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

Los resultados muestran que tanto antes como después, las series de entrada de defectos se
distribuyeron normalmente. Por lo tanto, el equipo decidió utilizar la prueba t para evaluar la
importancia de la diferencia observada en los medios de entrada de defectos por día antes y después
de la acción. Junto con la prueba t, también ejecutamos la prueba de Levene para la igualdad de
varianzas, para asegurarnos de que los datos de ambas series se puedan comparar usando la prueba
t.

Las estadísticas inferenciales nos brindan la capacidad de razonar sobre nuestros datos en el contexto
en el que comparamos los datos de la línea de base y después de la acción. Sin embargo, a menudo
necesitamos más información sobre los datos, es decir, agrupar casos similares, explorar correlaciones
o caracterizar los datos.

6 Métodos de aprendizaje automático

La visualización de datos y las estadísticas inferenciales son herramientas poderosas para analizar los
datos recopilados durante la toma de medidas. Sin embargo, las herramientas modernas de desarrollo
de software proporcionan datos de mayor volumen y mayor variabilidad. Por lo tanto, a menudo
podemos usar métodos más potentes para analizar estos datos, sacar conclusiones y hacer
predicciones y evaluaciones.

En la última década, el campo del aprendizaje automático ha evolucionado de ser accesible

principalmente para expertos en estadística a ser accesible para casi todos con los conocimientos
básicos en estadística. Una de las principales funciones fue la disponibilidad de herramientas de código
abierto fáciles de usar que implementan algoritmos de aprendizaje automático, por ejemplo, Weka o
R.

La figura 7 muestra una de las plataformas de aprendizaje automático más populares utilizadas en la
investigación: Weka. La herramienta proporciona a los ingenieros de software y equipos de acción, la
posibilidad de experimentar con diferentes algoritmos. La herramienta también puede generar código
Java, implementando estos algoritmos, para ser utilizados en sistemas de medición.

La disponibilidad de herramientas, como Weka, permite a los investigadores y los equipos de acción
trabajar con algoritmos para agrupar entidades en función de sus propiedades medidas, clasificar
entidades con un objetivo de medición específico y predecir tendencias en los datos basados en
mediciones. Como el campo del aprendizaje automático está creciendo rápidamente, solo nos
enfocamos en estos tres, dejando técnicas como el aprendizaje reforzado, el aprendizaje profundo y
el descubrimiento de conocimiento, a la literatura dedicada sobre el aprendizaje automático [Qui14],
[Lan13], [Har12 ]

Para el equipo de acción, los algoritmos de aprendizaje automático son útiles para dar sentido a los
resultados de medición, ya que proporcionan interpretación a los datos de medición.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Fig. 7 Herramienta de código abierto para el aprendizaje automático: Weka

6.1 Agrupación

Una de las áreas de aplicaciones para el aprendizaje automático es la agrupación. En la investigación

acción, los equipos de acción a menudo se enfrentan con el problema de agrupar elementos en función
de determinadas características o encontrar cuántos grupos de entidades se miden por un conjunto
de datos dado. El equipo de acción puede utilizar una serie de algoritmos para abordar este desafío
de cuántos grupos de entidades existen en el conjunto de datos, por ejemplo:
1. K vecinos más próximos (k-nearest neighbor) (kNN), que es un algoritmo basado en centroide
que divide el conjunto de datos en grupos basados en la búsqueda de centroides y la distancia
entre puntos de datos y centroides.
2. Agrupación jerárquica, que es un algoritmo basado en la conectividad que divide el conjunto
de datos en grupos basados en la similitud entre puntos de datos individuales y grupos de
puntos de datos.
3. Algoritmo de maximización de expectativas, que es un algoritmo basado en la distribución
que divide el conjunto de datos en función de la probabilidad de que los puntos de datos
pertenezcan a la misma distribución.
4. DBSCAN, que es un algoritmo basado en la densidad que divide el conjunto de datos en
función de la identificación de regiones en el conjunto de datos de densidad variada.

Según nuestra experiencia, uno de los algoritmos más útiles es el algoritmo kNN para identificar grupos.
Lo usamos en nuestros estudios anteriores debido a su simplicidad y visualización intuitiva, lo que hace
que los resultados sean fáciles de explicar en la práctica [ASM + 14].

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

6.1.1 Ejemplo de uso de clustering para encontrar la complejidad de los módulos de software

Para ilustrar cómo podemos usar la agrupación en la práctica, al interpretar los resultados de medición,
podemos explorar un ejemplo de cómo encontrar una complejidad percibida de un módulo de código
fuente recientemente desarrollado.

Para hacer posible este tipo de predicción, necesitamos definir qué significa la complejidad percibida.
En nuestro ejemplo, la complejidad percibida es una combinación del tamaño (medido en LOC) y la
complejidad (medido en la complejidad ciclomática de McCabe). No definimos los umbrales para estos
valores, y en su lugar queremos que el algoritmo de agrupación (kNN) encuentre los grupos correctos.
Solo limitamos el conjunto de grupos a tres.

Para enseñar el algoritmo kNN, necesitamos proporcionarle al algoritmo los datos del sistema actual.
En nuestro ejemplo, estos datos se presentan en la figura 6.8. La figura muestra nueve módulos
diferentes (1–9), y cada uno de los módulos se caracteriza por usar dos medidas: LOC y McCabe.

Fig. 8 Un conjunto de módulos actuales

Para simplificar el ejemplo, preparamos los módulos de tal manera que podamos ver claramente que
hay tres grupos, baja complejidad, complejidad media y alta complejidad, que podemos visualizar en
el diagrama de dispersión de la figura 9.

En la figura 9, podemos ver que estos módulos están agrupados en tres grupos. Los módulos
recientemente desarrollados se caracterizan como se presenta en la figura 10, donde tenemos tres
módulos, también caracterizados por LOC y McCabe. Cuando miramos los datos sobre los módulos
desarrollados recientemente, podemos ver intuitivamente que estos tres módulos pertenecen a tres
grupos diferentes. Ahora, también podemos usar el algoritmo kNN para clasificarlos.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Fig. 9 Un conjunto de módulos actuales visualizados como un diagrama de dispersión; los colores indican
racimos

El script, que usamos para hacer la agrupación y encontrar a dónde pertenecen los módulos
desarrollados recientemente, se presenta en la figura 11.

Fig. 10 Un conjunto de módulos recién agregados

Fig. 11 Script R para agrupamiento

Las líneas 1–10 preparan los conjuntos de datos para los análisis, los archivos de datos se leen en las
matrices en R, y los nombres de los módulos se eliminan de los datos (líneas 7 y 8), ya que no los
necesita para el algoritmo de agrupamiento.

La línea 13 es donde ejecutamos el algoritmo de agrupación, para encontrar los tres grupos en los
datos y nombre estos grupos (línea 16). La trama, de la figura 9, se presenta en la línea 22.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

Finalmente, la clasificación real de los módulos recientemente desarrollados para los tres grupos se
realiza en la línea 28. Es cuando la clasificación se vincula al conjunto de datos y se imprime en la línea
32. El resultado de este algoritmo se muestra en la figura 6.12, donde podemos ver que los tres módulos
se clasifican en tres grupos diferentes. Los resultados de la ejecución del algoritmo nos proporcionan
también las estadísticas relacionadas con la agrupación real, como los medios de cuadrados o
distancias al centroide. Sin embargo, estos no son necesarios en la práctica, ya que describen la calidad
del proceso de agrupación.

Este sencillo ejemplo ilustra cómo podemos usar la agrupación de aprendizaje automático para
proporcionar interpretación para los resultados de la medición. Cuando usamos este algoritmo de
aprendizaje automático a lo largo del tiempo, las predicciones mejoran y la carga sobre las partes
interesadas disminuye. La parte interesada no necesita hacer evaluaciones manuales de los datos, pero
el algoritmo puede usar las evaluaciones anteriores para derivar las nuevas. Desde nuestra experiencia,
esto puede ser muy útil al construir modelos de predicción y modelos de análisis basados en analogías.

Fig. 12 Resultados de clasificación

6.2 Clasificación

En general, el problema de la clasificación es similar al problema de la agrupación con una diferencia

significativa. El problema de clasificación se centra en qué clase pertenece una nueva observación dada.
Las clases se derivan de un conjunto de entrenamiento. En el ejemplo de agrupamiento en la secta.
6.6.1, el último paso, cuando clasificamos el módulo recientemente desarrollado, ya toca el área de
clasificación en el aprendizaje automático. Sin embargo, los problemas de clasificación pueden estar
dentro de varias áreas, por ejemplo:

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 1. binario o multi-clase, dependiendo de si la clasificación da como resultado la asignación de
una de dos clases (por ejemplo, el defecto es fácil o difícil de arreglar) o múltiples (por ejemplo,
el defecto es muy fácil, moderadamente fácil o difícil de arreglar), y
2. recuadro negro o recuadro blanco, dependiendo de si conocemos las reglas de cómo se
realiza la clasificación (recuadro blanco) o no (recuadro negro)

La tendencia actual en el aprendizaje automático es el enfoque en algoritmos de aprendizaje profundo

con múltiples capas de clasificación, agrupación, predicción, etc. Este enfoque también ha impulsado
la popularización de técnicas más simples, como los árboles de decisión para la clasificación.

Los árboles de decisión son útiles en el análisis de datos, en áreas similares al uso de algoritmos de
agrupamiento, para proporcionar automáticamente interpretaciones de los datos de medición.

La diferencia entre los algoritmos de agrupamiento y los algoritmos de clasificación es que los
algoritmos de agrupamiento no están supervisados, mientras que los algoritmos de clasificación están
supervisados. Para los algoritmos no supervisados, no hay respuestas correctas o incorrectas y, por lo
tanto, para los algoritmos de agrupamiento, no existe un clúster incorrecto. Para los algoritmos
supervisados, hay una respuesta correcta e incorrecta, y por lo tanto para los árboles de decisión, hay
clasificaciones correctas y clasificaciones incorrectas.

Los algoritmos de árbol de decisión más comunes y simples son:

1. árbol de clasificación, que predice la clase a la que pertenece la entidad, y
2. árbol de regresión, que predice un número como el número de defectos la próxima semana
o el costo de un proyecto.

Los árboles de decisión son útiles para el análisis cuando necesitamos verificar cómo se realizó la
clasificación. Sin embargo, no son útiles cuando las cantidades de datos son demasiado grandes para
ser utilizadas en un simple pase de entrenamiento (por ejemplo, cuando se trata de lotes). Para ese
propósito, necesitamos usar otras técnicas, por ejemplo, redes neuronales.

6.2.1 Ejemplo de clasificación de defectos utilizando árboles de decisión en Weka

Para esta sección, podemos centrarnos en los árboles de clasificación y su uso para resolver un
problema de clasificación de defectos. Imagine que nos gustaría saber si debemos priorizar un defecto
específico o no. La figura 13 muestra esto conceptualmente.

Para ejemplificar cómo funciona la clasificación, utilizamos un conjunto de defectos para entrenar el
árbol de decisión. Utilizamos el conjunto de datos presentado en la Tabla 1.

En Weka, utilizamos el algoritmo del árbol de decisión J48, que produce el árbol de clasificación como
se muestra en la figura 14. El árbol de clasificación muestra que si el remitente es "juan", entonces la
mayoría de los defectos es "difícil", independientemente de en qué fase se encuentren. Si el remitente
es "María", entonces la mayoría de los defectos es "fácil". Sin embargo, si el remitente es "tom", entonces
la clasificación depende también de la fase donde se encontró el defecto.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

Ahora, como mencionamos antes, los árboles de clasificación son un tipo de aprendizaje supervisado,
lo que significa que podemos probar si las clasificaciones son buenas en la práctica. Para esto, usamos
el conjunto de datos especificado en la Tabla 2.

Si examinamos el conjunto de pruebas, podemos ver que hay defectos que no entran fácilmente en la
clasificación (es decir, podríamos esperar algunas desviaciones entre la clasificación y los datos de la
prueba). Por ejemplo, el defecto con ID de 3 es un ejemplo. Después de aplicar el árbol de clasificación
al conjunto de prueba, Weka produce la salida visible en la figura 15.

Fig. 6.13 A conceptual view on classifying defects using machine learning

Table 1 Existing defect data—training set

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Table 2 Existing defect data—training set

En el resultado de la clasificación podemos ver tres partes: (1) resumen, (2) precisión por clase y (3)
matriz de confusión. La parte de resumen resume los parámetros de la clasificación, como el número
de instancias clasificadas con precisión, las estadísticas de Kappa o el error absoluto medio. Las primeras
dos líneas, el número de instancias clasificadas, nos dan una buena visión general de cuán bueno es el
algoritmo; en nuestro caso, diez defectos se clasificaron correctamente y tres no.

La sección detallada nos proporciona más información sobre qué clase fue la más difícil de clasificar
correctamente. En nuestro caso, esta era la clase con defectos moderados ya que no teníamos ningún
defecto moderado en el conjunto de prueba.

La clase que se clasificó mejor fue la clase de defectos imposibles. Para obtener más información acerca
de cuántos casos se clasificaron incorrectamente y a qué clases, necesitamos ejemplificar la última
sección: la matriz de confusión. La matriz muestra cuántos casos se clasificaron en qué clase y dónde
deberían clasificarse.

Fig. 6.14 Estructura del árbol de decisión mediante el algoritmo J48 de Weka

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Fig. 6.15 Resultados de la aplicación del algoritmo de clasificación en los datos de prueba

7 Análisis de datos cualitativos

Hasta ahora, discutimos cómo trabajar con datos cuantitativos. Dado que este tipo de datos está más
cerca del corazón de cada ingeniero, es bastante obvio. Sin embargo, también mencionamos que los
equipos de acción deberían tomar nota de cómo las organizaciones perciben sus acciones, y deberían
realizar entrevistas y talleres, que resultan en toneladas de datos cualitativos. Por lo tanto, también
necesitamos conocer los conceptos básicos sobre cómo analizar los datos cualitativos.

Al igual que con el análisis de datos cuantitativos, existen varios métodos para el análisis de datos
cualitativos, y casi cualquier buen libro de métodos de investigación para ciencias sociales proporciona
buenas referencias para ello. Yo personalmente uso el libro de Robson [RM16], y en este libro, nos
enfocamos en una técnica: el análisis temático. Según Braun y Clarke [BC06], el análisis temático es "un
método para identificar, analizar e informar patrones (temas) dentro de los datos".
El análisis temático se organiza en cinco fases seguidas de informes:
1. Familiarizarse con los datos.
2. Generando códigos iniciales.
3. Búsqueda de temas.
4. Revisión de temas.
5. Definir y nombrar temas.

Las fases progresan desde la comprensión y el análisis de los datos hasta la síntesis de un conjunto
coherente de temas. Un tema captura un concepto que es importante en relación con la pregunta de
investigación y representa un cierto nivel de respuesta o significado dentro del texto [BC06].

7.1 Familiarizarse con los datos

Para empezar, necesitamos leer los documentos varias veces. Necesitamos leer el texto con
comprensión, y debemos tomar notas sobre ideas y significados que puedan extraerse del texto. Dado

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

que tenemos en mente nuestra pregunta de investigación original, debemos centrarnos en encontrar
los significados relacionados con ella.

Para el equipo de acción, es importante que utilicemos el marco de evaluación definido antes de la
acción como guía aquí. Si usamos el marco GQM aquí, identificamos las preguntas que necesitan un
análisis cualitativo, y estas preguntas deberían guiar nuestro análisis temático

Familiarizarse con los datos

El equipo de acción necesitaba comprender el impacto de su introducción del nuevo proceso de
prueba en la organización. Han recopilado los datos de las entrevistas y los han transcrito. La figura 16
muestra los resultados de la primera lectura de la transcripción.

Fig. 16 Texto transcrito con el significado extraído

El significado extraído fue importante ya que permitió al equipo de acción comprender cómo mejorar
el método para el siguiente paso en el ciclo de investigación acción. Sin embargo, también tenían que
hacer los códigos iniciales para vincular los resultados a la parte específica del marco de evaluación.

El resultado de esta primera fase del análisis temático es un texto con los significados anotados en los
márgenes. Una vez que tengamos estos, podemos comenzar con la generación de códigos iniciales.

7.2 Generando códigos iniciales

Podemos iniciar la generación de los códigos iniciales comenzando con nuestra comprensión del
problema de investigación y las intenciones detrás de la acción. Los códigos iniciales que se extraen
del marco de evaluación pueden ayudarnos, pero definitivamente no deberían ser el conjunto final de
códigos.

En la codificación inicial, necesitamos comprender e interpretar fragmentos de texto y asignarles

códigos. Estos códigos deben reflejar la interpretación y el significado del texto y no la intención de
capturar una palabra clave específica. Por lo tanto, es importante que intentemos interpretar cada parte
del texto desde diferentes perspectivas y también que reutilicemos algunos de los códigos si es
necesario.

Si es necesario, la codificación inicial puede repetirse varias veces, y cada parte del texto puede
codificarse utilizando diferentes códigos o incluso utilizando esquemas de codificación ortogonales.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

Por ejemplo, podemos codificar el mismo texto con los códigos relacionados con el proceso (cómo fue
la acción) y el contenido / producto (qué acción se tomó).

Conjunto inicial de códigos

El equipo analizó la transcripción y extrajo los códigos iniciales del texto. Cada fragmento de texto tiene
varios códigos asociados. Un ejemplo se presenta en la figura 6.17. Cada código está vinculado al texto
utilizando el color.

Fig. 17 Texto transcrito con el significado extraído

En este texto, los códigos identificados están relacionados con la forma en que se utilizaron los nuevos
métodos y el contexto de su uso (herramientas). Los códigos identificados en el primer análisis deben
agruparse en temas en el siguiente paso.

Al crear los códigos iniciales, es importante identificar los vínculos entre los códigos y las acciones
tomadas por el equipo. También es importante identificar los códigos que indican factores de
confusión, es decir, factores que contribuyen al impacto positivo o negativo de la acción pero que no
son causados por la acción misma.

Por ejemplo, un factor de confusión relacionado con la introducción del nuevo proceso de prueba es
la introducción simultánea de un nuevo proceso de gestión de defectos (no realizado por el equipo de
acción). La introducción del nuevo proceso de gestión de defectos puede cambiar la forma en que los
ingenieros informan las fallas, omitiendo la notificación de fallas relacionadas con la prueba de la
unidad. Esto afecta el flujo de entrada de defectos, por lo que debe explorarse más a fondo para
separar los efectos de la introducción del nuevo proceso de prueba de la introducción del nuevo
proceso de gestión de defectos.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

7.3 Búsqueda de temas

La búsqueda de temas comienza como una actividad de agrupación de códigos e identificación de

temas. Dado que los temas pueden formar jerarquías, la actividad de buscar temas puede ser iterativa
y puede comenzar desde la agrupación de códigos individuales a los temas.

Una buena herramienta para el análisis temático es un mapa temático, que se asemeja a un mapa
mental, pero puede contener muchos nodos iniciales. Un ejemplo de un mapa temático se presenta
en la figura 6.18. Los códigos están vinculados a subtemas que están vinculados a temas.

El mismo código (o un subtema) se puede vincular a varios temas. Un mapa temático puede ser
bastante grande inicialmente y, por lo tanto, es bueno usar herramientas para el mapeo mental y la
diagramación para dibujarlos, especialmente porque es posible que necesitemos reorganizar el mapa
varias veces en el transcurso del análisis. Dado que el primer conjunto de temas no siempre es (o casi
nunca) lo suficientemente bueno, debemos estar preparados para tal reorganización. Es normal ya que
el mapa temático inicial es la primera visualización de nuestros códigos, y revela interpretaciones
insuficientes y excesivas.

Fig. 6.18 Construcción de un mapa temático.

Identificando los temas

El equipo de acción analizó la transcripción completa e identificó los códigos iniciales. La actividad de
encontrar temas proporcionó al equipo una idea de los posibles problemas y desafíos a abordar al
presentar el nuevo método de prueba. El conjunto inicial de temas se presenta en la figura 6.19 como
un mapa temático.

Fig. 6.19 Mapa temático inicial

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

El mapa temático contenía dos conjuntos de temas que parecían no estar relacionados y dónde
comenzó la revisión del mapa temático.

7.4 Revisión de temas

La revisión y el refinamiento de los temas tienen como objetivo vincular los temas con el objetivo de la
investigación. En el caso de la investigación acción, esta vinculación se realiza conectando las hipótesis,
preguntas u objetivos del marco de evaluación a los códigos iniciales.

Al revisar los temas, también debemos investigar si los códigos y los temas indican un impacto positivo
o negativo de la acción tomada.

Identificando los temas

Una vez que el equipo de acción comenzó a revisar los temas iniciales, descubrieron que algunos de
los temas no reflejaban el objetivo inicial. El equipo de acción revisó el texto original detrás de los
códigos y temas, renombrando los códigos y reelaborando los temas. También codificaron por colores
los códigos para reflejar el impacto positivo y negativo de la acción en la organización. El mapa revisado
se presenta en la figura 6.20.

Fig. 6.20 Revisado

El mapa reveló que el impacto de la acción en la organización fue mayor de lo esperado inicialmente.
Se extendió tanto sobre el proceso como sobre las herramientas. También reveló algunos efectos
negativos que el equipo de acción no anticipó al comienzo del estudio.

La redefinición de temas es un proceso iterativo. Podemos revisar los códigos una y otra vez; por lo
tanto, debemos recordar un aspecto muy importante: la interpretación. Cuando trabajamos con
revisiones, podemos sentir la tentación de cambiar el nombre del código ligeramente para reflejar
mejor el tema. Sin embargo, si lo hacemos varias veces, corremos el riesgo de perder el significado
original del código. Por lo tanto, debemos verificar el texto / datos subyacentes para el código antes
de renombrarlo. Tenemos que asegurarnos de que el vínculo entre los códigos y los datos son válidos
en todo momento.

7.5 Definir y nombrar temas

Los temas finales de definición y denominación tienen como objetivo convertir los temas en una
"historia" coherente contada por los datos. Repetimos los temas y los agrupamos en una descripción

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

coherente de los datos. En la investigación de la acción, en particular, la descripción coherente está
vinculada a la descripción de los efectos de la acción. Describimos cómo la organización experimentó
la acción y describimos los efectos positivos y negativos.

También debemos tener en cuenta los factores de confusión y las acciones adicionales que debemos
considerar en la fase de diagnóstico en el próximo ciclo de investigación acción.

La forma más fácil de crear tal descripción es:

• Agrupe los temas de acuerdo con el marco de evaluación definido anteriormente.

• Enumere los códigos y temas en cada grupo.
• Proporcione una descripción de los aspectos positivos y negativos relacionados con cada tema
en el grupo.

Una vez que se cuenta con la lista, debe usarse como entrada en la fase de diagnóstico para el próximo
ciclo de investigación acción. No todos los temas deben investigarse más a fondo, pero deben
considerarse y debatirse en la fase de diagnóstico. Deben presentarse al equipo de referencia y a las
partes interesadas.

8 Análisis continuo de datos

En los proyectos de investigación acción que involucran cambios continuos o experimentación

continua, necesitamos trabajar un poco diferente con el análisis. Naturalmente, debemos mantener
intactos los principios de experimentación, pero en lugar de ejecutar pruebas y recopilar / analizar
continuamente datos cuantitativos, debemos establecer indicadores clave de rendimiento (KPI, [SNB18],
[SMNA16]).

Los KPI se utilizan para monitorear procesos y productos durante un período de tiempo y, por lo tanto,
son muy adecuados para el monitoreo de mejoras continuas o acciones a lo largo del tiempo.

Definiendo un KPI

En uno de los proyectos, el equipo de acción introdujo una nueva forma de revisar el código fuente.
Este nuevo proceso impactó el tiempo requerido para integrar componentes de software en
subsistemas y en todo el sistema. Dado que este proceso requirió tiempo para asentarse e impactar a
una parte más grande de la organización, el equipo estableció un tablero para monitorear la evolución.
El equipo de acción definió un KPI: promedio semanal de tiempo para integrar el código. El KPI se
calculó semanalmente y se presentó en un tablero, junto con los datos sin procesar, como se presenta
en la figura 21.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Fig. 21 Tablero con un KPI y datos sin procesar

El tablero de instrumentos brindó al equipo la posibilidad de observar los efectos de la acción en un

período de tiempo más largo.

9 Evaluación en la segunda y subsiguiente acción

El análisis de datos en el segundo, tercer y más ciclos es muy similar al primer ciclo. La principal
diferencia es que el marco de evaluación puede haber evolucionado a lo largo de los ciclos. Es bastante
común ya que la metodología de investigación acción es flexible y está alineada con las necesidades
de la organización colaboradora.

Desde la perspectiva de un investigador, necesitamos hacer un seguimiento de la evolución del marco

de evaluación para asegurar la comparabilidad de los resultados. Necesitamos informar la evolución, y
si no podemos comparar los resultados entre ciclos, debemos indicar claramente cuándo se rompió
esta cadena de razonamiento.

10 Resumen

Después de la fase de toma de acción, hemos recopilado datos sobre los efectos de nuestras acciones.
En la fase de evaluación, analizamos estos datos y sacamos conclusiones sobre los efectos de la acción.
Esta evaluación, que, ni que decir tiene que ser objetiva, es necesaria ya que podemos tener un sesgo
hacia el resultado positivo o negativo de la acción. Como humanos, tenemos cierta actitud hacia el
cambio que queríamos introducir: a veces necesitamos el cambio para solucionar un problema, pero
a veces hacemos el cambio para verificar si algo es mejor que otra cosa. Esto significa que estamos
sesgados hacia un resultado específico; si nos gusta el cambio, observamos sus efectos a través de esta
perspectiva y viceversa.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.

 Referencias
Genero, M., Cruz, J., & Piattini, M. (2014). Métodos de investigación en ingeniería de software.
Madrid: Ra-Ma.

Staron, M. (2020). Action Research in Software Engineering: Theory and Applications. Springer.

Investigación acción en ingeniería de software Material compilado por Cecilia Hinojosa R.