Aplicando Experimentación Científica a la Ingeniería del Software

La ingeniería de software (IS) es una disciplina joven donde, a diferencia de otras ingenierías, solemos construir sistemas no en base a leyes inmutables, sino en base a ideas o creencias, a las que llamamos “mejores prácticas”, pero ... ¿qué sustenta a dichas prácticas?

 En este artículo presentamos de manera general un enfoque experimental que podemos usar para sustentar con evidencia científica nuestras decisiones al construir sistemas de software. El experimento examina la duración y esfuerzo que conlleva la programación por pares.

Proceso de experimentación

Así como en nuestra disciplina contamos con un proceso para construir software, en la experimentación se cuenta con un proceso para hacer experimentos. Este proceso consta básicamente de las siguientes fases: Idea, Definición, Diseño, Ejecución y Análisis.

 Una de las doce prácticas de la programación extrema (XP) [1] consiste en programar por pares. Básicamente, esto consiste en que dos programadores trabajan juntos en una misma tarea usando una computadora. Uno de los programadores —quien toma el rol de controlador— escribe el código mientras que el otro programador —identificado como observador— revisa de manera activa el trabajo realizado por el controlador con el fin de detectar posibles defectos. El observador puede hacer anotaciones o definir estrategias para llevar a cabo la tarea a realizar, también puede buscar referencias para ayudar a resolver alguna cuestión que se presente durante la realización de la tarea.

 Se dice que el uso de esta práctica ayuda a producir programas más pequeños, implementar mejores diseños y que los programas contienen menos defectos que aquellos escritos de manera individual. Se dice también que la productividad al trabajar de este manera es mayor que si las personas trabajaran de manera individual.

Idea

Dada la información que acabamos de leer sobre programación por pares, nos viene a la mente contrastar con hechos esta práctica para conocer de manera más confiable en qué medida se cumplen las bondades que de ella se mencionan.

Definición

El objetivo del experimento es evaluar la productividad al programar por pares, comparado con la programación individual. El estudio se realiza en el contexto de un aula con computadoras donde alumnos de la carrera en Ingeniería de Software de la Universidad Autónoma de Yucatán (UADY) realizarán dos programas ya sea por pares o de manera individual.

Diseño

Básicamente se especifica cómo se asignan los tratamientos a los sujetos, el tipo de sujetos a emplear así como la preparación de instrumentos o materiales para ejecutar el experimento.

 En este experimento participaron 21 sujeto-estudiantes: 14 de ellos trabajaron en pares (siete pares) y 7 de manera individual. El experimento se dividió en dos sesiones, en cada sesión los sujetos codificaron un programa diferente (variable de bloque). En la primera sesión los sujetos que trabajaron individualmente utilizaron el NetBeans IDE para codificar el primer programa mientras que los sujetos que trabajaron en pares usaron como herramienta un editor de texto. En la segunda sesión se intercambió la herramienta de soporte (variable de bloque), los sujetos que antes trabajaron individualmente con NetBeans IDE ahora trabajaron con un editor de texto, mientras que los sujetos que trabajaron en pares codificaron el segundo programa con NetBeans IDE. Para las sesiones del experimento se eligieron programas pequeños que los sujetos pudieran codificar en cada sesión.

Ejecución

Los sujetos registraron el tiempo de inicio y final que les llevó codificar el programa. La diferencia de estos tiempos (calculada en minutos) se usó como métrica para obtener la duración y el esfuerzo. Respecto a la métrica de esfuerzo, que mide la cantidad de trabajo gastado para realizar una tarea (en este caso persona-minuto), se duplicó el tiempo usado por los pares.

Análisis

En esta fase se emplean diferentes técnicas estadísticas para analizar e interpretar las métricas generadas. Usualmente en el diseño de experimentos se emplea el análisis de la varianza (en inglés ANOVA). Básicamente el ANOVA se basa en examinar la variabilidad de las métricas recabadas y la variabilidad de otros elementos como pueden ser otras variables así como el error experimental. La Tabla 1 muestra de manera resumida los resultados tras aplicar dos ANOVAS, una por cada métrica.

Tabla 1. Valores p obtenidos tras el análisis de la varianza

 El ANOVA usa un tipo de prueba conocido como prueba F de Fisher que ayuda al investigador a determinar si hay o no una diferencia significativa entre los tratamientos examinados en el experimento. El valor p es la probabilidad de obtener un resultado (en este caso F) al menos tan extremo como el observado. Usualmente el investigador define un valor crítico llamado alfa (α) para contrastarlo con el valor p observado. Si un valor p es menor o igual al valor alfa entonces la hipótesis nula es rechazada.

 La Figura 1 muestra los histogramas con las medias de los tratamientos respecto a la duración y esfuerzo.

Figura 1. Resultados

 La Tabla 2 muestra las diferencias obtenidas (pares y solos) en minutos con respecto a la duración y esfuerzo. Como se observa en esta tabla, se obtuvo una diferencia de 36 minutos a favor de la programación por pares, lo cual significa un ahorro del 28%. Con un nivel de confianza del 95%, esta diferencia puede variar de 6 a 66 minutos (ahorro del 4% al 51%). A pesar del ahorro en tiempo obtenido en la programación por pares, al tomar en cuenta el esfuerzo medido en minutos-persona, la programación individual tiene una ventaja de 56 minutos (30% menor) sobre la programación en pares. Este valor puede variar de 8 a 104 minutos (decremento de 4% a 55%).

Tabla 2. Diferencias entre pares y solos respecto a duración y esfuerzo

Conclusiones

En este artículo mostramos un ejemplo de cómo aplicar experimentación científica para evaluar prácticas de ingeniería de software. Las organizaciones desarrolladoras de software podrían aplicar experimentos como este para sustentar decisiones sobre prácticas que quieran institucionalizar o tecnologías que deseen evaluar antes de institucionalizarlas. Para concluir, en palabras de Pfleeger, llevar a cabo experimentos en IS nos permitirá aumentar la comprensión de qué hace ser a un software bueno y cómo construir software bien.

Referencias

• [1] K. Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Professional, 1999.
• [2] G.E.P. Box et al. Statistics for Experimenters: An Introduction to Design, Data Analysis, and Model Building. John Wiley & Sons, 1978.