GXP – Adaptación y Aplicación de eXtreme Programming

Beatriz Pérez
Universidad de la República, Grupo de Ingeniería de Software (Gris),
Montevideo,Uruguay, 11000
bperez@fing.edu.uy

Abstract
The Software Engineering Group (Gris) of the Computation Science Institute (In.Co) at the Engineering School of
the Universidad de la República of Uruguay has been working on a program for the construction and testing of
software development processes. The processes that have been put into practice until 2003 are all adaptations of
Rational Unified Processes (RUP). The testing of these processes is being made by students groups of “Software
Engineering Project”, a fourth year course of the Computer Engineering Career.
In this work we describe the experience in adapting the agile methodology eXtreme Programming (XP) for student
groups of Software Engineering Project, using Genexus for development -a fourth generation visual development
tool (4GL)-. The adaptation proposed is called GXP and was put into practice during the year 2003. The client for
this experience was the University Central Service of Informatics (SeCIU) , which required a viability research on
the use of a web application for managing and tracking electronic and paper records, developed with Genexus.

Keywords: Software Engineering, Software process, Methodology, eXtreme Programming, Genexus.

Resumen
Desde el año 2000 el Grupo de Ingeniería de Software (Gris), del Instituto de Computación (InCo) de la Facultad de
Ingeniería de la Universidad de la República de Uruguay, se encuentra embarcado en un programa de construcción y
prueba de procesos. Los procesos que se han puesto en la práctica hasta el año 2003 fueron adaptaciones de Rational
Unified Process (RUP). La prueba de estos procesos se realiza con grupos de estudiantes de la asignatura “Proyecto
de Ingeniería de Software” del cuarto año de la carrera Ingeniero en Computación.
En el presente trabajo se describe la experiencia de adaptar la metodología de desarrollo ágil eXtreme Programming
(XP) para grupos de estudiantes de “Proyecto de Ingeniería de Software”, donde la herramienta de desarrollo es
Genexus, una herramienta de desarrollo visual de cuarta generación (4GL). La adaptación fue puesta en práctica en
el 2003, teniendo como cliente al Servicio Central de Informática Universitario (SeCIU) de la Universidad de la
República, quienes requerían un estudio de viabilidad de contar con una aplicación web que permita la gestión y
seguimiento de expedientes electrónicos y en papel, desarrollada con la herramienta Genexus.

Palabras claves: Ingeniería de software, Procesos de software, Metodología, eXtreme programming, Genexus.
1. INTRODUCCIÓN
Desde el año 2000 el Grupo de Ingeniería de Software (Gris)[1], del Instituto de Computación (InCo) de la Facultad
de Ingeniería de la Universidad de la República de Uruguay, se encuentra embarcado en un programa de
construcción y prueba de modelos de procesos, el cual puede ser consultado en [2]. Los procesos que se han puesto
en la práctica hasta el año 2003 fueron adaptaciones de Rational Unified Process (RUP) [3][5][6][7]. La prueba de
estos procesos se realiza con grupos de estudiantes de la asignatura “Proyecto de Ingeniería de Software” del cuarto
año de la carrera Ingeniero en Computación [4].
La metodología de eXtreme Programming (XP) adhiere a los principios del Manifiesto para el Desarrollo Ágil de
Software [8][9]. Kent Beck es el creador de XP y en su libro “Embrace the change” [10] muestra como llevar
algunas prácticas y principios de la ingeniería de software al extremo para mitigar los riesgos más comunes en
cualquier desarrollo de software. XP asume que el costo del cambio no crece con el tiempo y se basa en cuatro
valores que deben guiar a los integrantes del equipo de desarrollo: comunicación, simplicidad, retroalimentación y
coraje. Existen 12 prácticas que ayudan al equipo a lograr esos valores, siguiendo un desarrollo iterativo e
incremental.
GeneXus es un entorno de desarrollo visual de cuarta generación (4GL), que permite desarrollar de forma completa,
y posteriormente mantener, aplicaciones orientadas a bases de datos. La herramienta genera automáticamente un
modelo de datos a partir de las visiones de usuario de los datos, y genera también los programas de aplicación para
mantenerlos. Posee un lenguaje y ambiente de desarrollo propios para definir las características de las interacciones
con el usuario con un elevado nivel de abstracción y a partir de estas definiciones, genera los programas para
diversas plataformas y manejadores de bases de datos, y con distintas arquitecturas (centralizadas y diversas
variantes de Cliente/Servidor)[11][12].
El objetivo de este artículo es presentar la adaptación realizada de eXtreme Programming para desarrollo con
Genexus y su puesta en práctica por grupos de estudiantes de “Proyecto de Ingeniería de Software”.
El poner en la práctica XP en un proyecto particular trae aparejado cambios que van más allá de la herramienta con
que se desarrolla. Es por esto que se definen dos niveles distintos de abstracción en este trabajo. Un nivel más
general de la metodología, que llamaremos GXP que es la adaptación de XP para desarrollo con Genexus.
La puesta en práctica de GXP por grupos de estudiantes constituye un nivel más particular y a esta metodología le
llamaremos GXPP. La distinción se hace por el hecho de que las consideraciones realizadas para GXP son válidas
para una organización que desarrolla con Genexus y desea realizar eXtreme Programming.
La experiencia práctica con GXP es una de las primeras experiencias conocidas en Uruguay de uso de eXtreme
Programming y la primer experiencia de uso de XP para desarrollo con Genexus.
La contribución principal de este artículo es la de presentar la experiencia de adaptar XP a las condiciones
particulares de un proyecto, en este caso en el marco de un proyecto de estudiantes y su evaluación una vez que la
experiencia ha concluido.
En la sección 2 se brinda una breve descripción de XP y de Genexus y se detallan las adaptaciones que debieron
realizarse. En la sección 3 se describe la experiencia práctica de desarrollar software siguiendo GXP y en la sección
4 se presentan las conclusiones.

2. ADAPTACIÓN DE XP PARA DESARROLLO CON GENEXUS

En esta sección se describe brevemente eXtreme Programming y Genexus. Se describe cada una de las practicas de
XP y las adaptaciones realizadas. Finalmente se resumen las adaptaciones realizadas para GXP y para su experiencia
práctica GXPP

2.1 eXtreme Programming

La metodología eXtreme Programming asume que el costo del cambio no crece con el tiempo. Se diseña y
desarrolla cada día, sin la necesidad de anticiparse al mañana. Se basa en cuatro valores que deben guiar a los
integrantes del equipo de desarrollo: comunicación, simplicidad, retroalimentación y coraje.
Existen 12 prácticas que ayudan al equipo a lograr esos valores, mitigando los riesgos más comunes en los proyectos
de software. Las prácticas se soportan entre sí, las debilidades de unas son cubiertas por las fortalezas de otras,
requiriendo de las otras prácticas para poder balancearse[10].
En XP, las 12 prácticas son llevadas a cabo por el cliente y el equipo de desarrollo. Cada persona cumple alguno de
los siguientes roles: desarrollador, verificador, entrenador (coach) y encargado de registrar (tracker).
Los desarrolladores trabajan de a pares, el desarrollo es guiado por las pruebas y se escriben las pruebas unitarias
automatizadas a la vez que se diseña; luego se codifica. Hasta que todos los casos de prueba corran no se sigue con
el próximo requerimiento.

2
El verificador se focaliza en ayudar al cliente a diseñar y escribir pruebas funcionales. Es responsable de ejecutar las
pruebas regularmente y poner los resultados en un lugar visible para el equipo de desarrollo.
El entrenador (coach) y el encargado de registrar (tracker) cumplen papeles de dirección del equipo. El entrenador es
encargado de la ejecución técnica y la evolución del proceso. Debe ser un buen comunicador, con un buen nivel
técnico y confidente. El tracker es quien registra las estimaciones y las mediciones para tener una visión global del
proyecto. Debe saber cuando no se está pudiendo llegar a finalizar la iteración o cuando no se va a llegar al alcance
comprometido, para poder planteárselo a tiempo al equipo.

2.2 Genexus

A mediados de los años 80, Breogán Gonda y Nicolás Jodal propusieron generar de forma automática el diseño de
una base de datos en tercera forma normal a partir de las visiones parciales de los datos de los distintos usuarios.
Esta idea cristalizó al poco tiempo en una herramienta llamada Genexus. Esta herramienta genera además el código
para navegar, modificar y hacer reportes contra la base de datos. Posee un lenguaje y ambiente de desarrollo propios
para definir las características de las interacciones con el usuario con un elevado nivel de abstracción y a partir de
estas definiciones, genera los programas para diversas plataformas y manejadores de bases de datos, y con distintas
arquitecturas (centralizadas y diversas variantes de Cliente/Servidor).
Ellos diseñaron la herramienta de forma que cuando los requerimientos cambian, se pueden reformular los
requerimientos, reejecutar (recompilar) y Genexus rediseña la base de datos, convirtiendo la base de datos previa
automáticamente al nuevo diseño, regenerando solo aquellos programas que fueron afectados por los cambios en el
diseño de la base de datos.
GeneXus permite desarrollar de forma completa, y posteriormente mantener, aplicaciones orientadas a bases de
datos. La herramienta genera automáticamente un modelo de datos a partir de las visiones de usuario de los datos, y
genera también los programas de aplicación para mantenerlos. [11][12][21].

2.3 Las 12 Prácticas de XP y las adaptaciones realizadas

A continuación se describen brevemente las 12 prácticas de XP y para cada una se explican las adaptaciones
realizadas. En cada caso se hace la distinción si la modificación fue debido a la adaptación para Genexus (GXP) o
por su puesta en práctica por los grupos de estudiantes de “Proyecto de Ingeniería de Software”(GXPP), la
descripción completa de la metodología GXPP se puede encontrar en [13].

2.3.1 Cliente en el lugar

En XP, un cliente real debe sentarse en el lugar de desarrollo, disponible para contestar preguntas y resolver
prioridades de pequeña escala. Debe ser alguien que vaya a usar el sistema cuando esté en producción. El cliente
escribe los requerimientos en Historias (que pueden verse como casos de uso simplificados) y escribe las pruebas
funcionales.
Esta práctica no es modificada en GXP. En la puesta en práctica (GXPP) aparecen dos problemas: conseguir un
lugar físico donde el grupo trabaje junto y tener un cliente que escriba historias y esté dispuesto a trabajar con el
equipo de desarrollo todo el día.
La Facultad de Ingeniería no cuenta con un lugar físico donde el grupo trabaje junto. Resulta bastante difícil
conseguir un cliente que tenga la infraestructura como para que todo el grupo de proyecto trabaje en su
organización, pero es posible conseguir que el cliente tenga en su organización una computadora a disposición del
grupo de proyecto. Por esta razón en GXPP se definió que los integrantes del grupo desarrollarán en sus casas, y que
la computadora en la organización del cliente puede utilizarse para desarrollar y para validar prototipos. Esta
computadora es usada también al terminar una tarea como máquina de integración. Los pares integran, corren las
pruebas automatizadas y validan con el cliente.
Por las características del proyecto, la posibilidad de conseguir un cliente que esté dispuesto a escribir los
requerimientos y realizar la verificación del software son muy pocas. Es más probable conseguir uno que esté
interesado en el proyecto, dispuesto a dedicar tiempo a validar los requerimientos, contestar dudas y defina las
pruebas de aceptación. Debido a estas razones, se crea el rol de Analista, rol que no existe en XP, que tiene como
función relevar requerimientos y escribirlos en Historias. El Cliente valida las Historias escritas por los Analistas y
los prototipos generados durante el proyecto, toma las decisiones respecto al alcance y prioridades de las historias y
se compromete a estar disponible en horario de oficina para que los pares de desarrollo consulten sus dudas.
Se definen reuniones de requerimientos con el cliente y todos los integrantes del equipo 2 veces por semana en la
primera fase del proyecto. Los Analistas escriben las Historias, que son validadas por el cliente y también por los
desarrolladores, de forma que todos los involucrados tengan la misma visión del sistema a construir.

3
2.3.2 El juego de la planificación
En XP existen dos niveles de planificación: la planificación de la liberación y la planificación de la iteración.
La planificación de la liberación se hace entre el cliente y los desarrolladores. Se planifica la liberación del producto
donde el cliente decide sobre el alcance, combinando sus prioridades con las estimaciones del equipo de desarrollo,
teniendo en cuenta que si la realidad sobrepasa al plan, este debe ser modificado.
En la planificación de la iteración interviene solo el equipo de desarrollo; es donde planifica sus actividades. Se
divide la iteración en tareas de desarrollo de pocos días, cada tarea tiene un integrante del equipo responsable para
su completitud.
Esta práctica se sigue sin cambios en GXP. En la puesta en práctica, el principal riesgo son las estimaciones de
tiempo de las historias por parte de los estudiantes, ya que es la primera vez que estiman su trabajo.

2.3.3 Pruebas automatizadas

En XP, los desarrolladores escriben las pruebas unitarias, que deben correr sin defectos para poder continuar con su
próxima tarea. Los clientes escriben pruebas funcionales para demostrar que los requerimientos se han completado.
Las pruebas unitarias en XP se realizan con JUnit, ya que la metodología está pensada para desarrollos orientados a
objetos donde la herramienta es Java.
Dado que en GXP y en GXPP el desarrollo se realiza con Genexus, la unidad es un objeto Genexus, el cual tiene una
interfaz gráfica. Se define que tanto las pruebas unitarias como las pruebas de funcionalidad se automatizan con la
herramienta Rational Robot [16]. Los desarrolladores escriben pruebas unitarias de cada objeto Genexus que van a
desarrollar antes de desarrollarlo, usando SQA Basic, lenguaje propietario de Rational Robot. Luego, desarrollan la
funcionalidad para la tarea que deben realizar, corren las pruebas y todas deben ser exitosas. Los verificadores
escriben las pruebas funcionales con Rational Robot para cada Historia, trabajando con el cliente para definir qué
criterios se tendrán en cuenta para la aceptación del producto.

2.3.4 40 horas semanales

La regla en XP es no trabajar más de 40 horas a la semana. Nunca se debe trabajar extra dos semanas seguidas. En
GXP esta práctica no tiene cambios. En GXPP los estudiantes tienen una dedicación de 15 horas semanales a este
proyecto, por lo que la regla es: 15 horas semanales.

2.3.5 Integración continua

En XP se integra el sistema varias veces al día, cada vez que una tarea es completada. En GXP esta práctica no tiene
cambios. En GXPP, debido a que los estudiantes tienen una carga de 15 horas semanales, se modifica esta práctica
para que la integración se realice cada 3 días. La computadora que se usa para integrar es la que está en la
organización del cliente.

2.3.6 Pequeñas liberaciones

En XP, la práctica es poner un sistema simple rápidamente en producción y liberar versiones nuevas en ciclos
cortos. En GXP esta práctica no tiene cambios. En GXPP, debido a que el proyecto tiene 14 semanas de duración, se
libera al finalizar la semana 12 del proyecto la primer y única versión para ser puesta en producción.

2.3.7 Metáfora
En XP, la idea es guiar todos los desarrollos compartiendo una historia simple de como el sistema trabaja. Debe
ayudar a todos (equipo y cliente) a entender los elementos básicos y sus relaciones. Esta práctica no fue modificada
en GXP ni en su puesta en práctica (GXPP).

2.3.8 Diseño Simple

En XP, el sistema debe ser diseñado tan simple como sea posible en un momento dado. La complejidad extra es
sacada tan pronto como es descubierta.
En GXP y GXPP se diseña definiendo los objetos Genexus y sus interacciones de forma que queden lo más simple
posible. El diseño al ser desarrollado debe correr todas las pruebas realizadas por los desarrolladores, no debe tener
lógica duplicada y debe tener la mínima cantidad de objetos.

2.3.9 Refactoring
En XP, Refactoring es el nombre de la técnica que permite reestructurar código de una forma disciplinada. El diseño
simple viene de la mano con el hecho de que los programadores reestructuren el sistema sin cambiar su
comportamiento para sacar duplicados, mejorar la comunicación, simplificar o agregar flexibilidad. XP está pensado
para desarrollos orientados a objetos (OO), donde los patrones de diseño (design patterns) ayudan a mejorar la
estructura interna, ofreciendo modelos que han sido probados con éxito en el pasado.
En GXP, GeneXus genera automáticamente el código necesario para crear y mantener la base de datos y generar y
mantener los programas para manejar sus objetos. Ante cambios en la descripción de algún objeto Genexus, la

4
herramienta realiza automáticamente un análisis de impacto de los cambios necesarios en la base de datos y de los
programas que deben generarse o regenerarse. Si se decide realizar los cambios, Genexus los genera
automáticamente en la base de datos y en los programas. Según Ken Orr [22], Genexus crea un ciclo cerrado de
refactoring basado en los requerimientos de los datos. Cuando los requerimientos cambian, simplemente se
reingresan los cambios, se recompila el sistema y se tienen un sistema nuevo, completamente integrado y mínimo
que incorpora los nuevos requerimientos.[21]

2.3.10 Programación por pares

En XP, todo el código es producido con dos programadores en una computadora con un teclado y un mouse. Los
pares son dinámicos, si dos personas están juntas en la mañana, en la tarde pueden hacer par con otros dos.
En GXP esta práctica no tiene cambios. En GXPP, debido a que la carga semanal de cada estudiante es de 15 horas,
el equipo debe definirse semanalmente como cambiarán los pares de desarrollo, los pares deben cambiar por lo
menos 2 veces por semana.

2.3.11 Estándares de codificación

En XP, se enfatiza la comunicación a través del código, siguiendo reglas de codificación. Si todos los
programadores pueden cambiar código, cambiando de pares y haciendo refactoring del código de otro, se debe tener
estandarizada la forma de escribir código. Esta práctica no tiene cambios ni en GXP ni en su puesta en práctica.

2.3.12 Propiedad colectiva

En XP, cualquiera puede cambiar cualquier código en cualquier momento. Todos toman la responsabilidad por el
sistema completo. Por ejemplo: si un par está trabajando y ve la oportunidad de mejorar el código, debe hacerlo y
mejorarlo si eso hace su vida más fácil.
En GXP esta práctica no tiene cambios. En GXPP se sigue esta práctica, teniendo en cuenta que al no integrar
diariamente, los cambios al código deben ser comunicados al resto del grupo de forma inmediata. Se debe tener
especial cuidado con la gestión de configuración, el grupo debe definir la forma en que gestionará la configuración,
ya que Genexus no brinda un mecanismo automatizado para hacer esto.

2.4 GXP

XP fue ideado para desarrollos orientados a objetos. Para adaptar XP a Genexus, deben modificarse las prácticas de:
Pruebas automatizadas, Diseño simple y Refactoring, según lo explicado anteriormente.
El poner en la práctica XP en un proyecto particular trae aparejado cambios que van más allá de la herramienta con
que se desarrolla. Es por esta razón que GXP es una guía y para ser utilizada en una organización que desarrolla con
Genexus y desea realizar eXtreme Programming, deben seguirse para su adaptación las recomendaciones hechas por
Kent Beck [10].

2.5 GXPP

Para poner en práctica GXP por grupos de estudiantes, debieron ser tenidas en cuenta las características del proyecto
que son descritas en la sección 3.1. Esas características introdujeron cambios en las prácticas de XP que no se deben
al desarrollo con Genexus. Las prácticas que debieron modificarse en GXPP incluyen las de GXP y agrega debido a
las características del proyecto: Cliente en el lugar, 40 horas semanales, Integración continua, Pequeñas liberaciones
y Propiedad colectiva. Las modificaciones a estas prácticas fueron explicadas anteriormente.

3. GXPP EN LA PRÁCTICA
En esta sección se describe la puesta en práctica de GXPP, adaptación realizada de XP para ser usado por grupos de
estudiantes de “Proyecto de Ingeniería de Software” que desarrollan con Genexus.

3.1 Características del proyecto

En esta sección se presentan las principales características del proyecto, las cuales debían ser tomadas en cuenta para
la puesta en práctica de eXtreme Programming.
Los estudiantes de cuarto año de la carrera Ingeniero en Computación, cursan en el primer semestre la asignatura
“Introducción a la Ingeniería de Software”[14], donde obtienen los conocimientos teóricos sobre ingeniería de
software. Estos son puestos en la práctica en el segundo semestre, en la asignatura “Proyecto de Ingeniería de
Software”[4], la cual tiene criterios establecidos que deben cumplir los proyectos realizados por los estudiantes que
se describen a continuación.

5
La duración del proyecto es de 14 semanas, con una carga horaria de cada estudiante de 15 horas semanales. Se
forman grupos de estudiantes de entre 8 y 13 personas. Los docentes del curso son los encargados de dirigir a los
grupos cumpliendo el rol de “director”, los grupos deben tener una agenda donde se pauta para cada semana, las
principales actividades a realizar y los productos que se espera se entreguen al cliente y al director. El producto se
instala en el ambiente del cliente en las últimas dos semanas del proyecto y no se realiza mantenimiento del mismo.
Dos grupos llevan a cabo el mismo proyecto en paralelo para el mismo cliente.

3.2 El equipo de desarrollo

Dos grupos realizaron la experiencia de desarrollar siguiendo GXPP, cada uno con 7 integrantes[16][17]. Se
definieron roles combinados que cumplía cada integrante, los roles definidos podrían ser cambiados por el grupo.
Un integrante del grupo debía cumplir el rol combinado de Analista, Encargado de registrar ( tracker) y Verificador,
un integrante del grupo debía cumplir el rol de Analista y Desarrollador, un integrante del grupo debía cumplir el rol
de Desarrollador y Verificador, los otros cuatro integrantes serían Desarrolladores. El rol de entrenador (coach) que
debe ser parte del equipo de desarrollo, fue cumplido por el docente encargado de dirigir el taller. En XP el equipo
de desarrollo cada día tiene una reunión corta donde todos pueden ver lo que el resto está haciendo, esto ayuda a que
la comunicación fluya a través del equipo. Por las características del proyecto, se decide cambiar la reunión diaria
por dos reuniones semanales, una reunión del grupo y una reunión de seguimiento, las cuales quedan separadas en
la semana por 3 días.
En la reunión de seguimiento participan todos los integrantes del grupo, incluyendo al entrenador. Las reuniones
tienen como fin que el equipo discuta con el entrenador el estado del proyecto. La dinámica es hacer una ronda
donde todos cuentan en que están trabajando y comunican sus problemas, el encargado de registrar informa el estado
de la iteración. El entrenador ayuda en posibles conflictos y en explicar el proceso.
En la reunión de grupo es donde se planifica el trabajo de la semana, definiendo los pares de desarrollo y las fechas
de integraciones y pruebas funcionales. En esta reunión no participa el entrenador.
Dado que Genexus tiene un lenguaje propio, que requiere tiempo de estudio y práctica para programar
correctamente, los estudiantes debieron realizar de forma previa al comienzo del proyecto, un curso donde aprenden
a utilizar la herramienta. La semana anterior a comenzar el proyecto los estudiantes realizaron un curso de
verificación automatizada usando Rational Robot.

3.3 El Cliente y el Producto

Los grupos que siguieron GXPP, tuvieron como cliente al Servicio Central de Informática Universitario
(SeCIU)[18] de la Universidad de la República. Ellos necesitaban estudiar la viabilidad de contar con una
aplicación web que permitiera la gestión y seguimiento de expedientes electrónicos y en papel, desarrollada con la
herramienta Genexus. El manejo de expedientes electrónicos debía realizarse usando GXFlow, un workflow
propietario de Genexus. El área de trabajo del usuario debía centralizar el manejo de los distintos tipos de
expedientes: electrónicos y en papel, permitiendo a los usuarios ingresar en secciones o dependencias a través de un
explorador web.

3.4 Las fases del proyecto

El ciclo de desarrollo de un proyecto XP es iterativo e incremental, en cada iteración se desarrollan y se verifican

Historias, cada Historia es una funcionalidad que el cliente quiere en el software. Las fases de un proyecto XP son:
Exploración, Planificación, Producción y Mantenimiento. En GXP esto no tiene cambio.
La puesta en práctica (GXPP) solo incluyó las fases de Exploración, Planificación y Producción ya que no se hace
mantenimiento del software.
A continuación se describen las principales actividades de cada Fase en GXPP:
• Durante la Fase de Exploración el equipo mantiene reuniones de requerimientos con el Cliente. Los Analistas
escriben las historias, los desarrolladores estiman las Historias, exploran distintas posibilidades para la
arquitectura y se entrenan en la tecnología.
• La Fase de Planificación tiene como objetivo desarrollar el sistema para el Cliente. Durante esta fase se
planifica el alcance junto con el cliente y el grupo planifica cada iteración. El equipo tiene reuniones cada tres
días y las 12 prácticas guían el desarrollo.
• La Fase de Producción tiene como objetivo liberar el sistema en el ambiente de producción, concluyendo con la
aceptación del software por parte del cliente. Para esto las pruebas funcionales y de aceptación deben correr sin
problemas.
En la agenda que los grupos debían seguir estaba fija la duración de cada Fase. La de Exploración debía durar 4
semanas. La de Planificación 8 semanas y la de Producción 2 semanas. Las iteraciones dentro de cada fase durarían

6
2 semanas, con un total de 7 iteraciones para todo el proyecto. El proyecto comenzó el 25 de agosto del 2003 y
finalizó el 30 de noviembre del 2003.
En la práctica, la agenda que siguieron los grupos fue la pautada. Esto se debió principalmente a que desde el
principio de la Fase de Planificación, marcaron con el cliente la agenda de validaciones de forma que fuera una vez
cada dos semanas.

3.5 Resultados Obtenidos

Una vez concluido el proyecto, las mediciones obtenidas respecto a cantidad de Historias para ambos grupos son
muy similares. El grupo 1 relevó 24 historias y el grupo 2 relevó 21. La cantidad total de horas dedicadas al
proyecto es también similar, el grupo 1 tuvo un total de 2154 horas y el grupo 2 un total de 2047. Respecto al
tamaño del producto obtenido, vemos que el tamaño del producto del grupo 1 es mayor al del grupo 2
En la figura 1 se muestran las mediciones de ambos grupos.

Grupo Historias Horas trabajadas Objetos Web Panels Transacciones Procedimientos

1 24 2154 149 78 24 31
2 21 2047 120 41 28 41

Figura 1 – Mediciones al finalizar el proyecto

Se le pidió al cliente que evaluara los productos de ambos grupos, y que cuantificara los defectos encontrados en la
versión final entregada. De la evaluación del cliente se desprende que los defectos encontrados en ambos grupos
son de importancia similar, siendo estos en general de gravedad media o baja. Para el cliente la evaluación del
producto en general, en una escala del 1 al 5 es de 4 para ambos grupos.

La evaluación de los proyectos, incluye la calidad del producto más la forma en que el grupo se relacionó con el
cliente y la forma en como se presentaron los productos intermedios. El cliente se mostró satisfecho con ambos
grupos. El grupo 1 fue calificado por el cliente con un 11 en la escala del 1 al 12 y el grupo 2 con un 10. En la figura
2 se pueden consultar la evaluación del cliente.

Evaluación del Evaluación del

Funcionalidad Usabilidad Eficiencia Producto Proyecto
(Escala: 1 al 5) (Escala: 1 al 12)
5 defectos 5 defectos de 2 defectos de
Grupo 1 encontrados de baja baja 4 11
importancia media importancia importancia
8 defectos
7 defectos 2 defectos de
encontrados de
Grupo 2 encontrados de baja 4 10
importancia
importancia media importancia
baja

Figura 2 – Evaluación por parte del Cliente de los grupos

3.6 Desviaciones

En esta sección se comentan las principales desviaciones por parte de los grupos que siguieron GXPP. El principal
problema al momento de planificar fueron las estimaciones, tanto de las historias como de las tareas. Esto se debe a
que era la primera vez que el grupo se enfrentaba a realizar estimaciones. Recién en la tercer iteración de la Fase de
Planificación (semana 9 del proyecto) lograron realizar estimaciones acertadas. La poca experiencia en estimar hizo
también que les resultara difícil dividir las Historias en Tareas. En general, las Tareas les llevaban más de 3 días y
eso hacía que la integración se realizara en lugar de cada 3 días cada una semana.
La falta de experiencia en Rational Robot por parte de los estudiantes hizo que para poder realizar las pruebas
unitarias se cambiara la metodología propuesta. Se pedía que los desarrolladores escribieran pruebas de cada objeto
Genexus que van a desarrollar, antes de desarrollarlo, usando SQA Basic. En la práctica, los grupos no llegaron a
tener la destreza suficiente en SQABasic. Lo sustituyeron por realizar los datos de prueba antes de desarrollar cada
objeto almacenándolos en Robot. Luego de que el objeto Genexus había sido desarrollado, se grababa la prueba
automatizada para el objeto de forma que levantara los datos de prueba almacenados previamente. Con esta forma
de trabajo, el desarrollador pensaba en los datos a probar antes de desarrollar, pero tiene como contra que queda
librado a cada desarrollador el pensar la forma en que se usará el objeto previo a desarrollarlo.

7
La integración continua que se definió para realizarse cada 3 días en GXPP, en la práctica se realizó una vez por
semana y la integración total de las Historias de la iteración se hacía al finalizar la iteración. Para mitigar este
riesgo, los grupos tomaron como prevención que cada vez que un par modifica un objeto del que no es responsable,
debe notificarlo al resto del grupo.
Los grupos en general no pudieron seguir la práctica de 15 horas semanales. Los integrantes realizaban un promedio
de 20 horas semanales y eso sucedió por más de 2 semanas seguidas. Al principio del proyecto, el grupo no conocía
su productividad y se comprometían a más de lo que podían para una iteración. Con las semanas comenzaron a
mejorar las estimaciones.

3.7 Liviano versus Pesado

En la asignatura “Proyecto de Ingeniería de Software” al mismo tiempo que dos grupos ponían en la práctica GXPP,
el resto de los grupos de estudiantes seguían adaptaciones de RUP [5][6][7]. RUP es considerado un proceso
“pesado” en contraposición con metodologías ágiles como XP[8]. A continuación se muestran las principales
diferencias que se observaron en la práctica entre estas dos metodologías:
En RUP los roles tienen una gran cantidad de documentación que realizar. En general el grupo no ve su utilidad.
Cada rol está muy enfocado en sus tareas y no conoce lo que hacen los otros. Muchas veces no ven la importancia
que tienen los otros roles en el proyecto. En GXPP los integrantes de ambos grupos consideran que durante el
proyecto todos conocían qué tareas realizaba el resto y por qué las tenía que realizar y que sus compañeros
mostraron compromiso y capacidad de iniciativa.
Con respecto a la facilidad de entender la metodología, los grupos que siguieron la adaptación de XP consideran que
es de una complejidad mediana de aprender y que los productos que debían generar todas las semanas eran de
utilidad para el proyecto. A los grupos que siguen adaptaciones de RUP el proceso les resulta bastante difícil de
entender.
Los grupos que siguen RUP tienen entre 11 y 13 integrantes, lo que también hace que la comunicación y
coordinación del grupo sea difícil, principalmente al comienzo cuando los integrantes del grupo no se conocen. En
contrapartida vimos que en GXPP trabajar con 7 integrantes ayuda a la comunicación y a la coordinación y la
práctica de programación por pares ayuda al buen compañerismo.
La escasa documentación asociada con GXPP hace que el entrenador tenga que estar muy al tanto de cómo va el
grupo y tener confianza en que lo que dice el grupo que hace, es lo que realmente está haciendo. Esto se manifiesta
especialmente en este tipo de proyecto donde no se contaba con un lugar común de trabajo, lo cual hizo que el
grupo tuviera que coordinarse y trabajar unido (lo que al principio no les resultó nada fácil). En los grupos que
siguen adaptaciones de RUP la documentación que generan ayuda a conocer el avance del proyecto.

En la experiencia práctica pudimos constatar los siguientes puntos que Kent Beck advierte sobre eXtreme
Programming [10]:

• Es fuertemente dependiente de la figura del entrenador (coach) como persona que explica el proceso.
• No es trasladable a cualquier cliente ni a cualquier equipo de desarrollo de software. Las personas del equipo de
desarrollo deben sentirse cómodas con esta forma de trabajo y deben llevarse muy bien con todos sus
compañeros, ya que los pares de programación son dinámicos.
• El cliente debe estar dispuesto a comprometerse en dedicarle las horas que el equipo de desarrollo requiera para
explicar requerimientos, contestar dudas, validar prototipos y realizar pruebas de aceptación. La experiencia
trabajando con Clientes en la asignatura “Proyecto de Ingeniería de Software” es que muchas veces no cuentan
con ese tiempo, y para esos clientes, no es aplicable esta metodología.

3.8 Evaluación de la experiencia

Desde el punto de vista del docente del curso que cumplió el rol de entrenador de los grupos, la relación entre los
integrantes de cada grupo era muy buena y la relación con el entrenador también. En el transcurso del proyecto, se
realizaron los cambios de roles que cada grupo consideró necesario para que todos los integrantes del equipo se
sintieran cómodos con sus tareas y también plantearon cambios a la metodología para poder trabajar mejor. En las
reuniones de seguimiento se discutía la forma de trabajo y los integrantes del grupo decidían, orientados por el
entrenador, como iba a ser su trabajo en la semana. Resultó muy efectiva la recomendación de Kent Beck [10] de
llevar comida como técnica de motivación.
El entrenador concurría a las principales validaciones y reuniones de planificación que el grupo tenía con el Cliente,
y en su rol de docente del curso, mantenía comunicación directa con el Cliente. Los estudiantes de uno de los grupos
concluyen que al finalizar el proyecto se dan cuenta de que les hubiera resultado más fácil tener un administrador
que los coordine y les dé una visión global de la evolución del proyecto. (En definitiva, lo que necesitaban era la
figura del entrenador (coach) todos los días y no solo una vez por semana).

8
Respecto al Diseño Simple, ambos grupos trataron de hacer lo más simple en cada momento. La filosofía de la
simplicidad les sirvió como criterio para ponerse de acuerdo, la experiencia mostró que de esta forma el diseño de
las Historias de la iteración se hacía rápido, pero tenían que hacer grandes cambios (Refactoring) al pasar a la
siguiente iteración donde diseñaban una nueva Historia. El principal problema con esto no era el tiempo en el
Refactoring sino que muchas veces había cambios en la interfaz de la aplicación y las pruebas automatizadas con
Rational Robot quedaban inutilizadas.
Los desarrolladores en un principio mostraron bastante rechazo a realizar las pruebas unitarias automatizadas. Si
bien entendían su importancia, al momento de realizarlas había algo más importante para hacer. Las pruebas
automatizadas, ya sean unitarias o funcionales, es la práctica en la que el entrenador debió hacer más hincapié para
que los grupos siguieran la metodología. Aprender a verificar y encontrar defectos les llevó casi toda la Fase de
Planificación. Recién en la última iteración del proyecto los grupos lograron entender cómo organizar el ambiente
de pruebas y aprovechar eficientemente la herramienta de pruebas. Las pruebas unitarias automatizadas realizadas
por los desarrolladores encontraron defectos, ahorrando tiempo de corrección. En general, los programas de prueba
pudieron ser reutilizados para las pruebas de regresión de las distintas versiones. Los estudiantes consideran que
como era la primera vez que trabajaban con Genexus y con Rational Robot hubiera sido conveniente que la Fase de
Exploración hubiera durado una semana más para poder lograr mayor habilidad en el uso de las herramientas.
La práctica que más motivó en ambos grupos fue la programación por pares. Los miembros del equipo cambiaban
cada tres días de pares. Esta práctica la vieron como muy positiva, encontrando que el trabajo se hace más ameno y
que entre dos personas surgen más y mejores ideas, y se cometen menos errores. Como los pares de desarrolladores
son dinámicos, eso ayudó a unificar la forma de escribir código. Los grupos plantearon que una de las razones por
las cuales los Verificadores no se sentían motivados en la verificación era que los verificadores no trabajaban en
pares y eso hacía que se sintieran aislados del proyecto mientras cumplían con ese rol. Hicieron cambios de roles
para que los verificadores también trabajaran en pares y eso dio buenos resultados.
La propiedad colectiva no fue un problema entre ellos. Para seguirla desde el principio fueron conscientes de la
necesidad de comunicación inmediata que requería. Debido a que hay personas que comentan el código más que
otras, algunas veces les llevaba más tiempo entender el código. Se definieron y siguieron estándares de codificación,
lo que ayudó a esta práctica.
De los 14 estudiantes que hicieron la experiencia de desarrollar siguiendo GXPP, solamente uno concluye que la
metodología no le parece buena y que no se sintió a gusto con la forma de trabajo, en especial la práctica de diseño
simple. Sin embargo esta persona, sí ve como positiva la programación por pares. El resto se sintió muy a gusto con
la forma de trabajo y el equipo.
La falta de un lugar donde el grupo contara con la infraestructura para desarrollar juntos no fue impedimento para
lograr el proyecto, pero los estudiantes debieron acomodar sus horarios ya que varios trabajan y viven en zonas
lejanas entre ellos. Seguramente, de tener a todo el equipo reunido los resultados hubieran sido mucho mejores y los
integrantes hubieran tenido mejores posibilidades para desempeñar sus tareas.
La comunicación entre el cliente y los grupos fue muy buena. El rol de Analista escribiendo las Historias logró
interpretar lo que quería el usuario en los tiempos esperados. Las validaciones de las Historias en reuniones de
requerimientos con el cliente hicieron que el grupo comprendiera el sistema a construir. Las validaciones de
prototipos al finalizar las iteraciones (cada dos semanas) permitieron que el cliente tuviera control sobre la marcha
del proyecto. Tanto el cliente como los grupos consideran que la cantidad de reuniones que tuvieron fueron
suficientes y que se sintieron distendidos. Los grupos consideran como fundamental la colaboración del cliente, el
cual demostró mucho interés y siempre estuvo disponible para validar Historias, contestar dudas por correo
electrónico o personalmente en su oficina y validar los prototipos cada dos semanas. El cliente está muy conforme
con el producto obtenido y se sintió muy cómodo por la dinámica de comunicación con los grupos.

4 CONCLUSIONES
En este trabajo se presentaron la adaptación realizada de eXtreme Programming para desarrollo con Genexus y su
puesta en práctica por grupos de estudiantes de “Proyecto de Ingeniería de Software”.
El poner en la práctica XP en un proyecto particular trae aparejado cambios que van más allá de la herramienta con
que se desarrolla. Es por esto que se definieron dos niveles distintos de abstracción en este trabajo. Un nivel más
general llamado GXP, que es la adaptación de XP para desarrollo con Genexus. En este nivel se realizó un cambio
en las siguientes prácticas de XP: Pruebas automatizadas, Diseño Simple y Refactoring. Estos cambios se deben a
que XP fue ideado para desarrollos orientados a objetos. La posibilidad de utilizar GXP en un proyecto de desarrollo
real, dependen de las características del proyecto. La organización que desee hacer esto debe adaptar como se hizo
en esta experiencia, cada una de las restantes prácticas a su realidad particular.
GXPP es la puesta en práctica de GXP por grupos de estudiantes y constituye un nivel más particular, en este trabajo
se evalúa la experiencia, mostrando las desviaciones encontradas a la metodología planteada. Esta experiencia es
una de las primeras experiencias conocidas en Uruguay de uso de eXtreme Programming y la primer experiencia de
uso de XP para desarrollo con Genexus.

9
La experiencia práctica por parte de grupos de estudiantes muestra que desarrollar software siguiendo XP resultó
una grata experiencia tanto para los integrantes de los grupos, como para el cliente y el docente que cumplió el rol
de entrenador. La evaluación de la experiencia muestra que el producto obtenido cumplió con las expectativas del
cliente en los plazos estipulados.
Como trabajo a futuro se mejorará la metodología GXPP en los puntos donde ocurrieron desviaciones para volver a
utilizarlo como guía para desarrollar software.

Referencias
[1] Grupo de Ingeniería de Software, Universidad de la República, Uruguay, Facultad de Ingeniería,
http://www.fing.edu.uy/inco/grupos/gris , 2003.
[2] Triñanes, J : “TLREQ: Proceso para desarrollo a distancia”. JIISIC’03, Chile, 2003.
[3] Jacobson, I; Booch, G; Rumbaugh, J: “The Unified Software Development Process”, ISBN 201-57169-2.
Addison Wesley Longman, Inc.,1999.
[4] Proyecto de Ingeniería de Software, Universidad de la República, Uruguay, Facultad de Ingeniería,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/index.htm , 2003.
[5] Delgado, A; Pérez, B: “ Modelo de Proceso Java 2003”, In.Co, Universidad de la República, Uruguay,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/Java03/index.htm , 2003.
[6] Correa, D; Romano, X: “MoDSGX un modelo de proceso para desarrollo con GeneXus”. Proyecto de Grado.
Tutor: Jorge Triñanes. In.Co, Universidad de la República, Uruguay,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/sitioweb/experiencia2002/ModsGX/index.htm , 2002.
[7] Vallespir, D: “Proceso Java Integrado”, In.Co, Universidad de la República, Uruguay,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/Java03/index.htm , 2003.
[8] Beck, K; Fowler,M: “Manifesto for Agile Software Development”. http://www.agilemanifesto.org/, 2001.
[9] Fowler, M: “The new Methodology”, http://martinfowler.com/articles/newMethodology.html, 2000.
[10] Beck, K: “Extreme Programming Explained Embrace Change” ISBN 201-61641-6. Addison Wesley,1999
[11] Triñanes, J; Correa, D; Romano, X: “MoDSGX : Estudio de un caso de desarrollo de un Modelo de Proceso”,
2003.
[12] ARTech, www.artech.com.uy, Montevideo, Uruguay.
[13] Pérez, B : “GXP” ”, In.Co, Universidad de la República, Uruguay, Facultad de Ingeniería,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/GXP/index.htm , 2003.
[14] Introducción a la Ingeniería de Software, Universidad de la República, Uruguay, Facultad de Ingeniería,
http://www.fing.edu.uy/inco/cursos/ingsoft/iis/index.html ,2003.
[15] Rational Robot, versión 2002.05.00. Rational Software, www.rational.com, 2003.
[16] Alvarez, J; Benasús, S; Carbonell, P; Flevaris, A; Garassini, J; Guridi, R; Sgaravatti, M: “UniFlow”, Proyecto
de Ingeniería de Software Año 2003, Director: Beatriz Pérez, Universidad de la República, Uruguay.
[17] Alvarez, F; Arroyo, R; Canedo, G; Cocaro, F; Ramos, M; Settimo, R; Torres, C: “ S.E.P.E”, Proyecto de
Ingeniería de Software Año 2003, Director: Beatriz Pérez, Universidad de la República, Uruguay.
[18] Servicio Central de Informática universitario, SeCIU, Universidad de la República, Uruguay,
http://www.rau.edu.uy/seciu/ ,2003
[19] Beck, K; Fowler, M: “Planning Extreme Programming”. ISBN 201-71091-9. Addison Wesley,2000
[20] Wake, C: “Extreme Programming Explored”. ISBN 201-73397-8. Addison Wesley,2001.
[21] Highsmith, J; Orr, K: “Extreme Programming” Cutter Consortium’s e-Bussiness Application Delivery
newsletter, http://rockfish-cs.cs.unc.edu/COMP290-agile/xp-highsmith.pdf, Febrero 2000.
[22] Orr, K. Ken Orr Institute, www.kenorrinst.com , Topeka, KS,USA
[23] Ambler, S: “Refactoring for Fitness”. SDMagazine, http://www.sdmagazine.com/documents/s=826/sdm0202j ,
Febrero 2002.

10