GXP Adaptacin y Aplicacin de eXtreme Programming

Beatriz Prez
Universidad de la Repblica, Grupo de Ingeniera 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 Repblica 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 ao 2000 el Grupo de Ingeniera de Software (Gris), del Instituto de Computacin (InCo) de la Facultad de
Ingeniera de la Universidad de la Repblica de Uruguay, se encuentra embarcado en un programa de construccin y
prueba de procesos. Los procesos que se han puesto en la prctica hasta el ao 2003 fueron adaptaciones de Rational
Unified Process (RUP). La prueba de estos procesos se realiza con grupos de estudiantes de la asignatura Proyecto
de Ingeniera de Software del cuarto ao de la carrera Ingeniero en Computacin.
En el presente trabajo se describe la experiencia de adaptar la metodologa de desarrollo gil eXtreme Programming
(XP) para grupos de estudiantes de Proyecto de Ingeniera de Software, donde la herramienta de desarrollo es
Genexus, una herramienta de desarrollo visual de cuarta generacin (4GL). La adaptacin fue puesta en prctica en
el 2003, teniendo como cliente al Servicio Central de Informtica Universitario (SeCIU) de la Universidad de la
Repblica, quienes requeran un estudio de viabilidad de contar con una aplicacin web que permita la gestin y
seguimiento de expedientes electrnicos y en papel, desarrollada con la herramienta Genexus.

Palabras claves: Ingeniera de software, Procesos de software, Metodologa, eXtreme programming, Genexus.

2
1. INTRODUCCIN

Desde el ao 2000 el Grupo de Ingeniera de Software (Gris)[1], del Instituto de Computacin (InCo) de la Facultad
de Ingeniera de la Universidad de la Repblica de Uruguay, se encuentra embarcado en un programa de
construccin y prueba de modelos de procesos, el cual puede ser consultado en [2]. Los procesos que se han puesto
en la prctica hasta el ao 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 Ingeniera de Software del cuarto
ao de la carrera Ingeniero en Computacin [4].
La metodologa 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 prcticas y principios de la ingeniera de software al extremo para mitigar los riesgos ms 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: comunicacin, simplicidad, retroalimentacin y
coraje. Existen 12 prcticas que ayudan al equipo a lograr esos valores, siguiendo un desarrollo iterativo e
incremental.
GeneXus es un entorno de desarrollo visual de cuarta generacin (4GL), que permite desarrollar de forma completa,
y posteriormente mantener, aplicaciones orientadas a bases de datos. La herramienta genera automticamente un
modelo de datos a partir de las visiones de usuario de los datos, y genera tambin los programas de aplicacin para
mantenerlos. Posee un lenguaje y ambiente de desarrollo propios para definir las caractersticas de las interacciones
con el usuario con un elevado nivel de abstraccin 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 artculo es presentar la adaptacin realizada de eXtreme Programming para desarrollo con
Genexus y su puesta en prctica por grupos de estudiantes de Proyecto de Ingeniera de Software.
El poner en la prctica XP en un proyecto particular trae aparejado cambios que van ms all de la herramienta con
que se desarrolla. Es por esto que se definen dos niveles distintos de abstraccin en este trabajo. Un nivel ms
general de la metodologa, que llamaremos GXP que es la adaptacin de XP para desarrollo con Genexus.
La puesta en prctica de GXP por grupos de estudiantes constituye un nivel ms particular y a esta metodologa le
llamaremos GXPP. La distincin se hace por el hecho de que las consideraciones realizadas para GXP son vlidas
para una organizacin que desarrolla con Genexus y desea realizar eXtreme Programming.
La experiencia prctica 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 contribucin principal de este artculo 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 evaluacin una vez que la
experiencia ha concluido.
En la seccin 2 se brinda una breve descripcin de XP y de Genexus y se detallan las adaptaciones que debieron
realizarse. En la seccin 3 se describe la experiencia prctica de desarrollar software siguiendo GXP y en la seccin
4 se presentan las conclusiones.


2. ADAPTACIN DE XP PARA DESARROLLO CON GENEXUS

En esta seccin 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
prctica GXPP

2.1 eXtreme Programming

La metodologa eXtreme Programming asume que el costo del cambio no crece con el tiempo. Se disea y
desarrolla cada da, sin la necesidad de anticiparse al maana. Se basa en cuatro valores que deben guiar a los
integrantes del equipo de desarrollo: comunicacin, simplicidad, retroalimentacin y coraje.
Existen 12 prcticas que ayudan al equipo a lograr esos valores, mitigando los riesgos ms comunes en los proyectos
de software. Las prcticas se soportan entre s, las debilidades de unas son cubiertas por las fortalezas de otras,
requiriendo de las otras prcticas para poder balancearse[10].
En XP, las 12 prcticas 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 disea; luego se codifica. Hasta que todos los casos de prueba corran no se sigue con
el prximo requerimiento.


3
El verificador se focaliza en ayudar al cliente a disear 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 direccin del equipo. El entrenador es
encargado de la ejecucin tcnica y la evolucin del proceso. Debe ser un buen comunicador, con un buen nivel
tcnico y confidente. El tracker es quien registra las estimaciones y las mediciones para tener una visin global del
proyecto. Debe saber cuando no se est pudiendo llegar a finalizar la iteracin o cuando no se va a llegar al alcance
comprometido, para poder planterselo a tiempo al equipo.

2.2 Genexus

A mediados de los aos 80, Breogn Gonda y Nicols Jodal propusieron generar de forma automtica el diseo 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 adems el cdigo
para navegar, modificar y hacer reportes contra la base de datos. Posee un lenguaje y ambiente de desarrollo propios
para definir las caractersticas de las interacciones con el usuario con un elevado nivel de abstraccin 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 disearon la herramienta de forma que cuando los requerimientos cambian, se pueden reformular los
requerimientos, reejecutar (recompilar) y Genexus redisea la base de datos, convirtiendo la base de datos previa
automticamente al nuevo diseo, regenerando solo aquellos programas que fueron afectados por los cambios en el
diseo de la base de datos.
GeneXus permite desarrollar de forma completa, y posteriormente mantener, aplicaciones orientadas a bases de
datos. La herramienta genera automticamente un modelo de datos a partir de las visiones de usuario de los datos, y
genera tambin los programas de aplicacin para mantenerlos. [11][12][21].

2.3 Las 12 Prcticas de XP y las adaptaciones realizadas
A continuacin se describen brevemente las 12 prcticas de XP y para cada una se explican las adaptaciones
realizadas. En cada caso se hace la distincin si la modificacin fue debido a la adaptacin para Genexus (GXP) o
por su puesta en prctica por los grupos de estudiantes de Proyecto de Ingeniera de Software(GXPP), la
descripcin completa de la metodologa 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 pequea escala. Debe ser alguien que vaya a usar el sistema cuando est en produccin. El cliente
escribe los requerimientos en Historias (que pueden verse como casos de uso simplificados) y escribe las pruebas
funcionales.
Esta prctica no es modificada en GXP. En la puesta en prctica (GXPP) aparecen dos problemas: conseguir un
lugar fsico donde el grupo trabaje junto y tener un cliente que escriba historias y est dispuesto a trabajar con el
equipo de desarrollo todo el da.
La Facultad de Ingeniera no cuenta con un lugar fsico donde el grupo trabaje junto. Resulta bastante difcil
conseguir un cliente que tenga la infraestructura como para que todo el grupo de proyecto trabaje en su
organizacin, pero es posible conseguir que el cliente tenga en su organizacin una computadora a disposicin del
grupo de proyecto. Por esta razn en GXPP se defini que los integrantes del grupo desarrollarn en sus casas, y que
la computadora en la organizacin del cliente puede utilizarse para desarrollar y para validar prototipos. Esta
computadora es usada tambin al terminar una tarea como mquina de integracin. Los pares integran, corren las
pruebas automatizadas y validan con el cliente.
Por las caractersticas del proyecto, la posibilidad de conseguir un cliente que est dispuesto a escribir los
requerimientos y realizar la verificacin del software son muy pocas. Es ms probable conseguir uno que est
interesado en el proyecto, dispuesto a dedicar tiempo a validar los requerimientos, contestar dudas y defina las
pruebas de aceptacin. Debido a estas razones, se crea el rol de Analista, rol que no existe en XP, que tiene como
funcin 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 tambin por los
desarrolladores, de forma que todos los involucrados tengan la misma visin del sistema a construir.




4
2.3.2 El juego de la planificacin
En XP existen dos niveles de planificacin: la planificacin de la liberacin y la planificacin de la iteracin.
La planificacin de la liberacin se hace entre el cliente y los desarrolladores. Se planifica la liberacin 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 planificacin de la iteracin interviene solo el equipo de desarrollo; es donde planifica sus actividades. Se
divide la iteracin en tareas de desarrollo de pocos das, cada tarea tiene un integrante del equipo responsable para
su completitud.
Esta prctica se sigue sin cambios en GXP. En la puesta en prctica, 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
prxima 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 metodologa 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 grfica. 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 tendrn en cuenta para la aceptacin del producto.

2.3.4 40 horas semanales
La regla en XP es no trabajar ms de 40 horas a la semana. Nunca se debe trabajar extra dos semanas seguidas. En
GXP esta prctica no tiene cambios. En GXPP los estudiantes tienen una dedicacin de 15 horas semanales a este
proyecto, por lo que la regla es: 15 horas semanales.

2.3.5 Integracin continua
En XP se integra el sistema varias veces al da, cada vez que una tarea es completada. En GXP esta prctica no tiene
cambios. En GXPP, debido a que los estudiantes tienen una carga de 15 horas semanales, se modifica esta prctica
para que la integracin se realice cada 3 das. La computadora que se usa para integrar es la que est en la
organizacin del cliente.

2.3.6 Pequeas liberaciones
En XP, la prctica es poner un sistema simple rpidamente en produccin y liberar versiones nuevas en ciclos
cortos. En GXP esta prctica no tiene cambios. En GXPP, debido a que el proyecto tiene 14 semanas de duracin, se
libera al finalizar la semana 12 del proyecto la primer y nica versin para ser puesta en produccin.

2.3.7 Metfora
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 bsicos y sus relaciones. Esta prctica no fue modificada
en GXP ni en su puesta en prctica (GXPP).

2.3.8 Diseo Simple
En XP, el sistema debe ser diseado tan simple como sea posible en un momento dado. La complejidad extra es
sacada tan pronto como es descubierta.
En GXP y GXPP se disea definiendo los objetos Genexus y sus interacciones de forma que queden lo ms simple
posible. El diseo al ser desarrollado debe correr todas las pruebas realizadas por los desarrolladores, no debe tener
lgica duplicada y debe tener la mnima cantidad de objetos.

2.3.9 Refactoring
En XP, Refactoring es el nombre de la tcnica que permite reestructurar cdigo de una forma disciplinada. El diseo
simple viene de la mano con el hecho de que los programadores reestructuren el sistema sin cambiar su
comportamiento para sacar duplicados, mejorar la comunicacin, simplificar o agregar flexibilidad. XP est pensado
para desarrollos orientados a objetos (OO), donde los patrones de diseo (design patterns) ayudan a mejorar la
estructura interna, ofreciendo modelos que han sido probados con xito en el pasado.
En GXP, GeneXus genera automticamente el cdigo necesario para crear y mantener la base de datos y generar y
mantener los programas para manejar sus objetos. Ante cambios en la descripcin de algn objeto Genexus, la

5
herramienta realiza automticamente un anlisis 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
automticamente en la base de datos y en los programas. Segn 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 mnimo
que incorpora los nuevos requerimientos.[21]

2.3.10 Programacin por pares
En XP, todo el cdigo es producido con dos programadores en una computadora con un teclado y un mouse. Los
pares son dinmicos, si dos personas estn juntas en la maana, en la tarde pueden hacer par con otros dos.
En GXP esta prctica no tiene cambios. En GXPP, debido a que la carga semanal de cada estudiante es de 15 horas,
el equipo debe definirse semanalmente como cambiarn los pares de desarrollo, los pares deben cambiar por lo
menos 2 veces por semana.

2.3.11 Estndares de codificacin
En XP, se enfatiza la comunicacin a travs del cdigo, siguiendo reglas de codificacin. Si todos los
programadores pueden cambiar cdigo, cambiando de pares y haciendo refactoring del cdigo de otro, se debe tener
estandarizada la forma de escribir cdigo. Esta prctica no tiene cambios ni en GXP ni en su puesta en prctica.

2.3.12 Propiedad colectiva
En XP, cualquiera puede cambiar cualquier cdigo 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 cdigo, debe hacerlo y
mejorarlo si eso hace su vida ms fcil.
En GXP esta prctica no tiene cambios. En GXPP se sigue esta prctica, teniendo en cuenta que al no integrar
diariamente, los cambios al cdigo deben ser comunicados al resto del grupo de forma inmediata. Se debe tener
especial cuidado con la gestin de configuracin, el grupo debe definir la forma en que gestionar la configuracin,
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 prcticas de:
Pruebas automatizadas, Diseo simple y Refactoring, segn lo explicado anteriormente.
El poner en la prctica XP en un proyecto particular trae aparejado cambios que van ms all de la herramienta con
que se desarrolla. Es por esta razn que GXP es una gua y para ser utilizada en una organizacin que desarrolla con
Genexus y desea realizar eXtreme Programming, deben seguirse para su adaptacin las recomendaciones hechas por
Kent Beck [10].

2.5 GXPP
Para poner en prctica GXP por grupos de estudiantes, debieron ser tenidas en cuenta las caractersticas del proyecto
que son descritas en la seccin 3.1. Esas caractersticas introdujeron cambios en las prcticas de XP que no se deben
al desarrollo con Genexus. Las prcticas que debieron modificarse en GXPP incluyen las de GXP y agrega debido a
las caractersticas del proyecto: Cliente en el lugar, 40 horas semanales, Integracin continua, Pequeas liberaciones
y Propiedad colectiva. Las modificaciones a estas prcticas fueron explicadas anteriormente.
3. GXPP EN LA PRCTICA

En esta seccin se describe la puesta en prctica de GXPP, adaptacin realizada de XP para ser usado por grupos de
estudiantes de Proyecto de Ingeniera de Software que desarrollan con Genexus.

3.1 Caractersticas del proyecto

En esta seccin se presentan las principales caractersticas del proyecto, las cuales deban ser tomadas en cuenta para
la puesta en prctica de eXtreme Programming.
Los estudiantes de cuarto ao de la carrera Ingeniero en Computacin, cursan en el primer semestre la asignatura
Introduccin a la Ingeniera de Software[14], donde obtienen los conocimientos tericos sobre ingeniera de
software. Estos son puestos en la prctica en el segundo semestre, en la asignatura Proyecto de Ingeniera de
Software[4], la cual tiene criterios establecidos que deben cumplir los proyectos realizados por los estudiantes que
se describen a continuacin.

6
La duracin 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 cumpla cada integrante, los roles definidos podran ser cambiados por el grupo.
Un integrante del grupo deba cumplir el rol combinado de Analista, Encargado de registrar ( tracker) y Verificador,
un integrante del grupo deba cumplir el rol de Analista y Desarrollador, un integrante del grupo deba cumplir el rol
de Desarrollador y Verificador, los otros cuatro integrantes seran 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 da tiene una reunin corta donde todos pueden ver lo que el resto est haciendo, esto ayuda a que
la comunicacin fluya a travs del equipo. Por las caractersticas del proyecto, se decide cambiar la reunin diaria
por dos reuniones semanales, una reunin del grupo y una reunin de seguimiento, las cuales quedan separadas en
la semana por 3 das.
En la reunin 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 dinmica es hacer una ronda
donde todos cuentan en que estn trabajando y comunican sus problemas, el encargado de registrar informa el estado
de la iteracin. El entrenador ayuda en posibles conflictos y en explicar el proceso.
En la reunin 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 reunin no participa el entrenador.
Dado que Genexus tiene un lenguaje propio, que requiere tiempo de estudio y prctica 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
verificacin automatizada usando Rational Robot.

3.3 El Cliente y el Producto
Los grupos que siguieron GXPP, tuvieron como cliente al Servicio Central de Informtica Universitario
(SeCIU)[18] de la Universidad de la Repblica. Ellos necesitaban estudiar la viabilidad de contar con una
aplicacin web que permitiera la gestin y seguimiento de expedientes electrnicos y en papel, desarrollada con la
herramienta Genexus. El manejo de expedientes electrnicos deba realizarse usando GXFlow, un workflow
propietario de Genexus. El rea de trabajo del usuario deba centralizar el manejo de los distintos tipos de
expedientes: electrnicos y en papel, permitiendo a los usuarios ingresar en secciones o dependencias a travs de un
explorador web.
3.4 Las fases del proyecto

El ciclo de desarrollo de un proyecto XP es iterativo e incremental, en cada iteracin 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:
Exploracin, Planificacin, Produccin y Mantenimiento. En GXP esto no tiene cambio.
La puesta en prctica (GXPP) solo incluy las fases de Exploracin, Planificacin y Produccin ya que no se hace
mantenimiento del software.
A continuacin se describen las principales actividades de cada Fase en GXPP:
Durante la Fase de Exploracin 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 tecnologa.
La Fase de Planificacin 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 iteracin. El equipo tiene reuniones cada tres
das y las 12 prcticas guan el desarrollo.
La Fase de Produccin tiene como objetivo liberar el sistema en el ambiente de produccin, concluyendo con la
aceptacin del software por parte del cliente. Para esto las pruebas funcionales y de aceptacin deben correr sin
problemas.
En la agenda que los grupos deban seguir estaba fija la duracin de cada Fase. La de Exploracin deba durar 4
semanas. La de Planificacin 8 semanas y la de Produccin 2 semanas. Las iteraciones dentro de cada fase duraran

7
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 prctica, la agenda que siguieron los grupos fue la pautada. Esto se debi principalmente a que desde el
principio de la Fase de Planificacin, 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 tambin similar, el grupo 1 tuvo un total de 2154 horas y el grupo 2 un total de 2047. Respecto al
tamao del producto obtenido, vemos que el tamao 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
versin final entregada. De la evaluacin 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 evaluacin del
producto en general, en una escala del 1 al 5 es de 4 para ambos grupos.

La evaluacin de los proyectos, incluye la calidad del producto ms 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 evaluacin del cliente.

Funcionalidad Usabilidad Eficiencia
Evaluacin del
Producto
(Escala: 1 al 5)
Evaluacin del
Proyecto
(Escala: 1 al 12)
Grupo 1
5 defectos
encontrados de
importancia media
5 defectos de
baja
importancia
2 defectos de
baja
importancia
4 11
Grupo 2
7 defectos
encontrados de
importancia media
8 defectos
encontrados de
importancia
baja
2 defectos de
baja
importancia
4 10
Figura 2 Evaluacin por parte del Cliente de los grupos
3.6 Desviaciones

En esta seccin 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. Recin en la tercer iteracin de la Fase de
Planificacin (semana 9 del proyecto) lograron realizar estimaciones acertadas. La poca experiencia en estimar hizo
tambin que les resultara difcil dividir las Historias en Tareas. En general, las Tareas les llevaban ms de 3 das y
eso haca que la integracin se realizara en lugar de cada 3 das 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 metodologa propuesta. Se peda que los desarrolladores escribieran pruebas de cada objeto
Genexus que van a desarrollar, antes de desarrollarlo, usando SQA Basic. En la prctica, los grupos no llegaron a
tener la destreza suficiente en SQABasic. Lo sustituyeron por realizar los datos de prueba antes de desarrollar cada
objeto almacenndolos en Robot. Luego de que el objeto Genexus haba 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.

8
La integracin continua que se defini para realizarse cada 3 das en GXPP, en la prctica se realiz una vez por
semana y la integracin total de las Historias de la iteracin se haca al finalizar la iteracin. Para mitigar este
riesgo, los grupos tomaron como prevencin 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 prctica de 15 horas semanales. Los integrantes realizaban un promedio
de 20 horas semanales y eso sucedi por ms de 2 semanas seguidas. Al principio del proyecto, el grupo no conoca
su productividad y se comprometan a ms de lo que podan para una iteracin. Con las semanas comenzaron a
mejorar las estimaciones.

3.7 Liviano versus Pesado

En la asignatura Proyecto de Ingeniera de Software al mismo tiempo que dos grupos ponan en la prctica GXPP,
el resto de los grupos de estudiantes seguan adaptaciones de RUP [5][6][7]. RUP es considerado un proceso
pesado en contraposicin con metodologas giles como XP[8]. A continuacin se muestran las principales
diferencias que se observaron en la prctica entre estas dos metodologas:
En RUP los roles tienen una gran cantidad de documentacin 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 conocan qu tareas realizaba el resto y por qu las tena que realizar y que sus compaeros
mostraron compromiso y capacidad de iniciativa.
Con respecto a la facilidad de entender la metodologa, los grupos que siguieron la adaptacin de XP consideran que
es de una complejidad mediana de aprender y que los productos que deban generar todas las semanas eran de
utilidad para el proyecto. A los grupos que siguen adaptaciones de RUP el proceso les resulta bastante difcil de
entender.
Los grupos que siguen RUP tienen entre 11 y 13 integrantes, lo que tambin hace que la comunicacin y
coordinacin del grupo sea difcil, principalmente al comienzo cuando los integrantes del grupo no se conocen. En
contrapartida vimos que en GXPP trabajar con 7 integrantes ayuda a la comunicacin y a la coordinacin y la
prctica de programacin por pares ayuda al buen compaerismo.
La escasa documentacin asociada con GXPP hace que el entrenador tenga que estar muy al tanto de cmo 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 comn de trabajo, lo cual hizo que el
grupo tuviera que coordinarse y trabajar unido (lo que al principio no les result nada fcil). En los grupos que
siguen adaptaciones de RUP la documentacin que generan ayuda a conocer el avance del proyecto.

En la experiencia prctica 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 cmodas con esta forma de trabajo y deben llevarse muy bien con todos sus
compaeros, ya que los pares de programacin son dinmicos.
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 aceptacin. La experiencia
trabajando con Clientes en la asignatura Proyecto de Ingeniera de Software es que muchas veces no cuentan
con ese tiempo, y para esos clientes, no es aplicable esta metodologa.

3.8 Evaluacin de la experiencia

Desde el punto de vista del docente del curso que cumpli el rol de entrenador de los grupos, la relacin entre los
integrantes de cada grupo era muy buena y la relacin con el entrenador tambin. 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 cmodos con sus tareas y tambin plantearon cambios a la metodologa para poder trabajar mejor. En las
reuniones de seguimiento se discuta la forma de trabajo y los integrantes del grupo decidan, orientados por el
entrenador, como iba a ser su trabajo en la semana. Result muy efectiva la recomendacin de Kent Beck [10] de
llevar comida como tcnica de motivacin.
El entrenador concurra a las principales validaciones y reuniones de planificacin que el grupo tena con el Cliente,
y en su rol de docente del curso, mantena comunicacin 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 ms fcil tener un administrador
que los coordine y les d una visin global de la evolucin del proyecto. (En definitiva, lo que necesitaban era la
figura del entrenador (coach) todos los das y no solo una vez por semana).

9
Respecto al Diseo Simple, ambos grupos trataron de hacer lo ms simple en cada momento. La filosofa de la
simplicidad les sirvi como criterio para ponerse de acuerdo, la experiencia mostr que de esta forma el diseo de
las Historias de la iteracin se haca rpido, pero tenan que hacer grandes cambios (Refactoring) al pasar a la
siguiente iteracin donde diseaban una nueva Historia. El principal problema con esto no era el tiempo en el
Refactoring sino que muchas veces haba cambios en la interfaz de la aplicacin 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 entendan su importancia, al momento de realizarlas haba algo ms importante para hacer. Las pruebas
automatizadas, ya sean unitarias o funcionales, es la prctica en la que el entrenador debi hacer ms hincapi para
que los grupos siguieran la metodologa. Aprender a verificar y encontrar defectos les llev casi toda la Fase de
Planificacin. Recin en la ltima iteracin del proyecto los grupos lograron entender cmo 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 correccin. En general, los programas de prueba
pudieron ser reutilizados para las pruebas de regresin 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
Exploracin hubiera durado una semana ms para poder lograr mayor habilidad en el uso de las herramientas.
La prctica que ms motiv en ambos grupos fue la programacin por pares. Los miembros del equipo cambiaban
cada tres das de pares. Esta prctica la vieron como muy positiva, encontrando que el trabajo se hace ms ameno y
que entre dos personas surgen ms y mejores ideas, y se cometen menos errores. Como los pares de desarrolladores
son dinmicos, eso ayud a unificar la forma de escribir cdigo. Los grupos plantearon que una de las razones por
las cuales los Verificadores no se sentan motivados en la verificacin era que los verificadores no trabajaban en
pares y eso haca que se sintieran aislados del proyecto mientras cumplan con ese rol. Hicieron cambios de roles
para que los verificadores tambin 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 comunicacin inmediata que requera. Debido a que hay personas que comentan el cdigo ms que
otras, algunas veces les llevaba ms tiempo entender el cdigo. Se definieron y siguieron estndares de codificacin,
lo que ayud a esta prctica.
De los 14 estudiantes que hicieron la experiencia de desarrollar siguiendo GXPP, solamente uno concluye que la
metodologa no le parece buena y que no se sinti a gusto con la forma de trabajo, en especial la prctica de diseo
simple. Sin embargo esta persona, s ve como positiva la programacin 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 desempear sus tareas.
La comunicacin entre el cliente y los grupos fue muy buena. El rol de Analista escribiendo las Historias logr
interpretar lo que quera 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 colaboracin del cliente, el
cual demostr mucho inters y siempre estuvo disponible para validar Historias, contestar dudas por correo
electrnico 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 cmodo por la dinmica de comunicacin con los grupos.

4 CONCLUSIONES

En este trabajo se presentaron la adaptacin realizada de eXtreme Programming para desarrollo con Genexus y su
puesta en prctica por grupos de estudiantes de Proyecto de Ingeniera de Software.
El poner en la prctica XP en un proyecto particular trae aparejado cambios que van ms all de la herramienta con
que se desarrolla. Es por esto que se definieron dos niveles distintos de abstraccin en este trabajo. Un nivel ms
general llamado GXP, que es la adaptacin de XP para desarrollo con Genexus. En este nivel se realiz un cambio
en las siguientes prcticas de XP: Pruebas automatizadas, Diseo 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 caractersticas del proyecto. La organizacin que desee hacer esto debe adaptar como se hizo
en esta experiencia, cada una de las restantes prcticas a su realidad particular.
GXPP es la puesta en prctica de GXP por grupos de estudiantes y constituye un nivel ms particular, en este trabajo
se evala la experiencia, mostrando las desviaciones encontradas a la metodologa 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.

10
La experiencia prctica 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 evaluacin 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 metodologa GXPP en los puntos donde ocurrieron desviaciones para volver a
utilizarlo como gua para desarrollar software.
Referencias
[1] Grupo de Ingeniera de Software, Universidad de la Repblica, Uruguay, Facultad de Ingeniera,
http://www.fing.edu.uy/inco/grupos/gris , 2003.
[2] Trianes, J : TLREQ: Proceso para desarrollo a distancia. JIISIC03, 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 Ingeniera de Software, Universidad de la Repblica, Uruguay, Facultad de Ingeniera,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/index.htm , 2003.
[5] Delgado, A; Prez, B: Modelo de Proceso Java 2003, In.Co, Universidad de la Repblica, 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 Trianes. In.Co, Universidad de la Repblica, 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 Repblica, 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] Trianes, 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] Prez, B : GXP , In.Co, Universidad de la Repblica, Uruguay, Facultad de Ingeniera,
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/GXP/index.htm , 2003.
[14] Introduccin a la Ingeniera de Software, Universidad de la Repblica, Uruguay, Facultad de Ingeniera,
http://www.fing.edu.uy/inco/cursos/ingsoft/iis/index.html ,2003.
[15] Rational Robot, versin 2002.05.00. Rational Software, www.rational.com, 2003.
[16] Alvarez, J; Benass, S; Carbonell, P; Flevaris, A; Garassini, J; Guridi, R; Sgaravatti, M: UniFlow, Proyecto
de Ingeniera de Software Ao 2003, Director: Beatriz Prez, Universidad de la Repblica, Uruguay.
[17] Alvarez, F; Arroyo, R; Canedo, G; Cocaro, F; Ramos, M; Settimo, R; Torres, C: S.E.P.E, Proyecto de
Ingeniera de Software Ao 2003, Director: Beatriz Prez, Universidad de la Repblica, Uruguay.
[18] Servicio Central de Informtica universitario, SeCIU, Universidad de la Repblica, 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 Consortiums 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.