En el ámbito del desarrollo y mantenimiento de productos software, el movimiento ágil ha tomado relevancia a nivel mundial, a la fecha existen diversas metodologías ágiles en el mercado. Una de estas metodologías es la programación extrema o XP desarrollada en la década de los 90s. Una de las doce prácticas de esta metodología es la programación en pareja. Existen diversos estudios donde se examinan los efectos de esta práctica. En este trabajo se presentan los resultados de un estudio empírico donde se examina la calidad del producto software desarrollado con esta práctica con y sin apoyo de un entorno de desarrollo integrado IDE. Siguiendo un enfoque experimental, el estudio aquí presentado se realizó en la Universidad Autónoma de Yucatán (México) donde participaron estudiantes de la carrera en Ingeniería de Software (8 parejas y 8 programadores solos) realizando algunos ejercicios de programación.

1. Calidad del producto software en
la programación en pareja con y
sin apoyo de un IDE
Omar S. Gómez, Prometeo-SENESCYT
Escuela Superior Politécnica de Chimborazo
Facultad de Informática y Electrónica
IV Jornadas Internacionales de Investigación Científica –
Universidad Técnica de Ambato
28 Julio 2015

2. Agenda
• Introducción
• Programación en pareja
• Trabajo relacionado
• Objetivo de la investigación
• Contexto del estudio
• Análisis
• Conclusiones

3. Introducción
• En la actualidad el uso de enfoques ágiles para el desarrollo y
mantenimiento de productos software ha tomado relevancia
Imagen de: http://www.versionone.com/agile-101/agile-development-methodologies-scrum-kanban-lean-xp/

4. Introducción
• Uno de estos enfoques es el conocido como programación
extrema (XP), creada por Kent Beck, donde una de las doce
prácticas propuestas es la programación en pareja
Imagen de: http://www.oocities.org/vladimir_levin/SoftwareProject/extreme_programming.html

5. Programación en pareja
• La programación en pareja es un método de
programación en el cual dos personas desarrollan en
conjunto algún producto software
Imagen de: https://rules.ssw.com.au/Management/RulesToSuccessfulProjects/Pages/PairWork.aspx

6. Programación en pareja
• Una persona, «el controlador» o driver, escribe en el teclado
• La otra persona, «el observador» o navegador revisa las líneas de
código escritas, revisando posibles errores y pensando en el diseño
general. El observador también puede tomar notas sobre
estrategias de diseño o implementación así como llevar el control
de tiempos y defectos
Imagen de: http://www.aunclicdelastic.com/wp-content/uploads/Pair_programming_Wikipedia-640x337.jpg

7. Trabajo relacionado
• Existen diversos estudios donde se examinan los efectos de
la programación en pareja (Nosek, 1998; Williams et al. 2000;
Lui y Chan, 2003; McDowell et al. 2003; Müller 2005; Canfora
et al. 2007; Lui et al. 2008, entre otros)
• De manera general en estos estudios se reportan efectos
benéficos en el uso de esta práctica. Algunos efectos
observados son:
• La codificación de programas más pequeños
• Incide en la implementación de mejores diseños
• Los programas codificados contienen menos defectos que
aquellos escritos de manera individual
• Las parejas suelen requerir menos tiempo en completar alguna
tarea

8. Objetivo de la investigación
• Aunque existen diversos estudios sobre el tema, no se han
estudiado los efectos de la programación en pareja con y
sin apoyo de un entorno de desarrollo integrado (IDE)
• El objetivo de esta investigación consiste en evaluar la
calidad del producto software desarrollado por parejas y
por programadores individuales con y sin apoyo de un IDE
• Este estudio tiene sus orígenes en una investigación previa
(Gómez et al. 2013)

9. Preguntas de investigación
• ¿Existe alguna diferencia en la calidad del producto
desarrollado por parejas con respecto al producto
desarrollado de manera individual?
• ¿El uso de un IDE incide en la calidad del producto tanto en
las parejas como en los programadores individuales?
Para este estudio, la calidad del producto software se mide
como la tasa de defectos inyectados por hora

10. Hipótesis de trabajo
H0a: Calidad del producto sw = parejas = solos
H0b: Calidad del producto sw = IDE = S/IDE

11. Contexto del estudio
Imagen de: http://whatscookingmexico.com/2008/01/11/a-taste-of-yucatan/

12. Contexto del estudio
Imagen de: http://www.panoramio.com/user/1276188?with_photo_id=13625238

13. • Estudiantes de 6to nivel de la carrera de Ingeniería de Software
• Estudio realizado a finales de 2013 (oct-nov) en la asignatura de DoE
• Los estudiantes cuentan con conocimientos en matemáticas,
programación, diseño y arquitecturas de software
• 8 estudiantes actuando como programadores solos y 8 parejas
(aleatorización)
• El estudio se conformó por cuatro sesiones, donde las dos primeras
fueron de entrenamiento
• En cada sesión los estudiantes codificaron un programa dada una
especificación
• La duración de las sesiones en promedio fue de dos horas
• Como IDE se utilizó Netbeans
• Los programas se codificaron en el lenguaje de programación Java
Contexto del estudio

14. Contexto del estudio: variable de respuesta
• En este estudio, la calidad del producto software es medida
de acuerdo a la tasa de defectos inyectaos por hora
Tasa de defectos = 60 x def. inyectados / tiempo de prog.

15. • Diseño factorial conformado por un factor con dos niveles
(parejas y solos) y un factor con dos niveles (con y sin IDE)
• Este diseño se mantiene en cada sesión con un programa a
desarrollar distinto (medidas repetidas)
• En total se recolectaron 32 mediciones
Contexto del estudio: diseño factorial 22 con
medidas repetidas

16. • Previo a cada sesión se entregó a los participantes la
especificación del programa a codificar
• Los equipos conformados por parejas se dividieron en dos
grupos que trabajaron con Netbeans o con un editor de textos
(compilando en modo consola)
• Sólo se tomaron en cuenta defectos lógicos (no se tomaron
en cuenta defectos de sintaxis)
• De manera similar los programadores solos, divididos en dos
grupos, trabajaron ya sea con Netbeans o con un editor de
textos
Ejecución del estudio

17. Análisis descriptivo por tipo de programación

18. Análisis descriptivo por entorno

19. Análisis descriptivo por programa

20. Modelo estadístico
yijkl=μ+αi+βj+dijl+γk+(αβ)ij+(αγ)ik+(βγ)jk+(αβγ)ijk+εijkl
Donde μ es el promedio general, α i es el efecto del i-ésimo
tratamiento (tipo de programación), βj es el efecto del j-ésimo
tratamiento (entorno de programación), dijl es el error experimental
aleatorio de los sujetos dentro de los tratamientos (tipo de
programación y entorno) con varianza σ2
d, γk es el efecto del
tratamiento k-ésimo tratamiento (programa), (αβ)ij es la interacción
entre el tipo de programación y el entorno, (αγ)ik es la interacción
entre el tipo de programación y el programa, (βγ)jk es la interacción
entre el entorno y el programa, (αβγ)ijk es la interacción entre el tipo de
programación, entorno y programa, εijkl es el error experimental
aleatorio sobre las medidas aleatorias que asume una distribución
normal con varianza σ2
e

21. Resultados ANOVA con respecto a tasa de
defectos inyectados por hora
componente DFn Dfd F p<0.05 ges (eta^2)
tipo programación 1 12 0.9396 0.3514 0.0548
entorno 1 12 7.9132 0.0156 0.3284
programa 1 12 13.4911 0.0031 0.2250
tipo_prog:entorno 1 12 2.3088 0.1545 0.1248
tipo_prog:programa 1 12 1.3369 0.2700 0.0279
entorno:programa 1 12 4.2646 0.0612 0.0840
tipo:prog:ent_prog 1 12 0.1522 0.7032 0.0032

22. Gráfico de interacciones
Defectosinyectadosxhora

23. • Los equipos conformados por parejas tienden a inyectar un
número menor de defectos cuando el programa es más
complejo (el prog. calculadora tiene mayor VG)
• Cuando el programa no es tan complejo, las parejas y
programadores solos inyectan menos defectos al trabajar sin
IDE
• Los equipos conformados por programadores solos tienden a
inyectar más defectos con el uso de un IDE
• Parece que las parejas tienden a inyectar más defectos sin el
uso de un IDE (diferencia no significativa)
• La programación en pareja tiende a comportarse mejor con el
uso de IDE (aunque la diferencia no es significativa)
Evidencias

24. Limitaciones del estudio
Los estudios empíricos pueden estar sujetos a ciertas limitaciones
• con respecto a las amenazas de validez interna:
• las sesiones se llevaron a cabo acorde a lo planificado sin
presentar algún incidente (efecto de historia)
• Se ha minimizado el efecto de sesgo por selección dado el
mecanismo de aleatorización empleado en el diseño
experimental
• Durante las sesiones del experimento se observó interés por
parte de los estudiantes en realizar las actividades por lo que
puede asumirse un efecto de desmoralización mínimo
• Con respecto a las amenazas de validez externa los resultados aquí
presentados son parcialmente generalizables a estudiantes con
características similares a los estudiantes empleados en el estudio
aquí reportado

25. Conclusiones
• La programación en pareja en una de las 12 prácticas de la
programación extrema (XP)
• Existen varios trabajos donde se han estudiado los efectos de la
programación en pareja
• Con respecto a estudios previos, el estudio aquí presentado soporta
parcialmente (tendencia) la evidencia previa en favor de la
reducción de defectos al emplear esta práctica (usando un IDE)
• En general se inyectan menos defectos al trabajar sin IDE, quizás el
empleo de ciclos largos de compilación ocasione un mayor empeño
en la tarea a codificar
• Dada esta evidencia, una posible recomendación es que en cursos
iniciales de programación los estudiantes trabajen sin un IDE

26. Referencias
K. Beck. Extreme programming explained: embrace change . Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 2000.
G. Canfora, A. Cimitile, F. Garcia, M. Piattini, and C. A. Visaggio. Evaluating performances of
pair designing in industry. Journal of Systems and Software, 80(8):1317 – 1327, 2007.
K. M. Lui and K. C. C. Chan. When does a pair outperform two individuals? In Proceedings of
the 4th international conference on Extreme programming and agile processes in software
engineering, XP’03, pages 225–233, Berlin, Heidelberg, 2003. Springer-Verlag.
M. M. Müller. Two controlled experiments concerning the comparison of pair programming to
peer review. Journal of Systems and Software, 78(2):166 – 179, 2005.
J. T. Nosek. The case for collaborative programming. Commun. ACM , 41(3):105–108, Mar.
1998.
L. Williams, R. Kessler, W. Cunningham, and R. Jeffries. Strengthening the case for pair
programming. Software, IEEE, 17(4):19 –25, jul/aug 2000.
O. S. Gómez, J. L. Batún, and R. A. Aguilar. Pair versus Solo Programming – An Experience
Report from a Course on Design of Experiments in Software Engineering. Int. J. of Comp.
Science Issues (IJCSI), Vol. 10 Issue 1, p734 2013.

27. ¡Gracias!
¿Alguna pregunta?
Omar S. Gómez
http://es.slideshare.net/OmarSGmez/calidad-del-producto-
software-en-la-programacin-en-pareja-con-y-sin-apoyo-de-
un-ide