METODOLOGÍA XP

Esta es una de las metodologías de desarrollo de software más utilizada en la

actualidad, para proyectos de corto plazo y corto equipo. Consiste en una
programación rápida o extrema, cuya particularidad es tener como parte del equipo, al
usuario final como uno de los requisitos para llegar al éxito del proyecto.

En esta metodología, el cliente se convierte en un miembro más del equipo de trabajo

y es el encargado de decidir que se implementa, puede añadir, cambiar o quitar
requerimientos en cualquier momento para lo cual debe estar enterado
constantemente del estado real y el progreso del proyecto obteniendo lo máximo de
cada semana de trabajo.

XP trabaja cuatro fases principales: Planificación, Diseño, Desarrollo y Pruebas.

Estas fases se dividen, a su vez, en subfases de desarrollo que poseen una serie de
pasos que permiten realizar un adecuado desarrollo del proyecto.
Fase: Planificación del proyecto.

Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P
es definir las historias de usuario con el cliente. Las historias de usuario tienen la
misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4
líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los
detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de
diseños de base de datos adecuados, etc. Son usadas para estimar tiempos de
desarrollo de la parte de la aplicación que describen. También se utilizan en la fase
de pruebas, para verificar si el programa cumple con lo que especifica la historia de
usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los
desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha
historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3
semanas.

Plan de Entregas: .Después de tener ya definidas las historias de usuario es necesario

crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las
historias de usuario que se crearán para cada versión del programa y las fechas en las
que se publicarán estas versiones. Un "Release plan" es una planificación donde los
desarrolladores y clientes establecen los tiempos de implementación ideales de las
historias de usuario, la prioridad con la que serán implementadas y las historias que
serán implementadas en cada versión del programa. Después de un "Release plan"
tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que
son principalmente las historias que se deben desarrollar en cada versión), el tiempo
que tardarán en desarrollarse y publicarse las versiones del programa, el número de
personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo
realizado. (*Release plan: Planificación de publicaciones).

Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones

de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los
clientes deben seleccionar las historias de usuario definidas en el "Release planning"
que serán implementadas. También se seleccionan las historias de usuario que no
pasaron el test de aceptación que se realizó al terminar la iteración anterior . Estas
historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se
asignarán a los programadores.

Velocidad del proyecto: La velocidad del proyecto es una medida que representa la

rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con
contar el número de historias de usuario que se pueden implementar en una iteración;
de esta forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas
iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se
puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar
esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar
con el cliente un nuevo "Release Plan”.

Programación en pareja: La metodología X.P. aconseja la programación en parejas

pues incrementa la productividad y la calidad del software desarrollado. El trabajo en
pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno
codifica haciendo hincapié en la calidad de la función o  método que está
implementando, el otro analiza si ese método o función es adecuado y está bien
diseñado. De esta forma se consigue un código y diseño con gran calidad.

Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen
que ser fluidas y todo el mundo tiene que tener voz y voto.

Fase: Diseño.

Diseños simples: La metodología X.P sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir
un diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo
y esfuerzo desarrollar.

Glosarios de términos: Usar glosarios de términos y una correcta especificación de los

nombres de métodos y clases ayudará a comprender el diseño y facilitará sus
posteriores ampliaciones y la reutilización del código.
Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al máximo el  riesgo que
supone ese problema.

Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se

piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que
implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo
y recursos.

Refactorizar: es mejorar y modificar la estructura y  codificación de códigos ya creados

sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para
procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que
contienen funcionalidades que no serán usadas y diseños obsoletos. Esto es un error
porque puede generar código completamente inestable y muy mal diseñado; por este
motivo, es necesario refactorizar cuando se va a utilizar código ya creado.

Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration)

permiten al programador centrarse y apreciar el desarrollo orientado a objetos
olvidándose de los malos hábitos de la programación procedural clásica.

Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede
escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden
escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las
clases que colaboran con cada responsabilidad.

Fase: Codificación.

Disponibilidad del Cliente: Como ya se dijo en la introducción, el cliente es una parte

más del equipo de desarrollo; su presencia es indispensable en las distintas fases de
X.P. A la hora de codificar una historia de usuario su presencia es aún más necesaria.
No olvidemos que los clientes son los que crean las historias de usuario y negocian los
tiempos en los que serán implementadas. Antes del desarrollo de cada historia de
usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá
que estar presente cuando se realicen los test que verifiquen que la historia
implementada cumple la funcionalidad especificada.

La codificación debe hacerse ateniendo a estándares de codificación ya creados.

Programar bajo estándares mantiene el código consistente y facilita su comprensión y
escalabilidad.
Unidad de Pruebas: Crear test que prueben el funcionamiento de los distintos códigos
implementados nos ayudará a desarrollar dicho código. Crear estos test antes nos
ayuda a saber qué es exactamente lo que tiene que hacer el código a implementar y
sabremos que una vez implementado pasará dichos test sin problemas ya que dicho
código ha sido diseñado para ese fin. Se puede dividir la funcionalidad que debe
cumplir una tarea a programar en pequeñas unidades, de esta forma se crearán
primero los test para cada unidad y a continuación se desarrollará dicha unidad, así
poco a poco conseguiremos un desarrollo que cumpla todos los requisitos
especificados.

Programación en Parejas: Como ya se comentó anteriormente, X.P opta por la

programación en pareja ya que permite un código más eficiente y con una gran
calidad. X.P sugiere un modelo de trabajo usando repositorios de código dónde las
parejas de programadores publican cada pocas horas sus códigos implementados y
corregidos junto a los test que deben pasar. De esta forma el resto de programadores
que necesiten códigos ajenos trabajarán siempre con las últimas versiones. Para
mantener un código consistente, publicar un código en un repositorio es una acción
exclusiva para cada pareja de programadores.

X.P también propone un modelo de desarrollo colectivo en el que todos los

programadores están implicados en todas las tareas; cualquiera puede modificar o
ampliar una clase o método de otro programador si es necesario y subirla al
repositorio de código. El permitir al resto de los programadores modificar códigos que
no son suyos no supone ningún riesgo ya que para que un código pueda ser publicado
en el repositorio tiene que pasar los test de funcionamiento definidos para el mismo.

La optimización del código siempre se debe dejar para el final. Hay que hacer que
funcione y que sea correcto, más tarde se puede optimizar.

X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el
planificado para ser finalizados no podrán ser terminados a tiempo se haga lo que se
haga, aunque se añadan más desarrolladores y se incrementen los recursos. La
solución que plantea X.P es realizar un nuevo "Release plan" para concretar los nuevos
tiempos de publicación y de velocidad del proyecto.

A la hora de codificar no seguimos la regla de X.P que aconseja crear test de

funcionamiento con entornos de desarrollo antes de programar. Nuestros test los
obtendremos de la especificación de requisitos ya que en ella se especifican las
pruebas que deben pasar las distintas funcionalidades del programa, procurando
codificar pensando en las pruebas que debe pasar cada funcionalidad.
Fase: Pruebas.

Uno de los pilares de la metodología X.P es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando.

El uso de los test en X.P es el siguiente:

Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.

Hay que someter a tests las distintas clases del sistema omitiendo los métodos más
triviales.

Se deben crear los test que pasarán los códigos antes de implementarlos; en el
apartado anterior se explicó la importancia de crear antes los test que el código.

Un punto importante es crear test que no tengan ninguna dependencia del código que
en un futuro evaluará. Hay que crear los test abstrayéndose del futuro código, de esta
forma aseguraremos la independencia del test respecto al código que evalúa.

Como se comentó anteriormente los distintos test se deben subir al repositorio de

código acompañados del código que verifican. Ningún código puede ser publicado en
el repositorio sin que haya pasado su test de funcionamiento, de esta forma,
aseguramos el uso colectivo del código (explicado en el apartado anterior).

El uso de los test es adecuado para observar la refactorización. Los test permiten
verificar que un cambio en la estructura de un código no tiene por qué cambiar su
funcionamiento.

Test de aceptación. Los test mencionados anteriormente sirven para evaluar las
distintas tareas en las que ha sido dividida una historia de usuario. Para asegurar el
funcionamiento final de una determinada historia de usuario se deben crear "Test de
aceptación"; estos test son creados y usados por los clientes para comprobar que las
distintas historias de usuario cumplen su cometido.

Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se

harán test que analicen partes de las mismas, sino que las pruebas se realizarán para
las funcionalidades generales que debe cumplir el programa especificado en
la descripción de requisitos.
 Otra Explicación de XP

Metodología XP. (Extreme Programing)1 Es una de las metodologías de desarrollo de

software más utilizada en la actualidad para proyectos de corto plazo y corto equipo,
consiste en una programación rápida o extrema, cuya particularidad es tener como
parte del equipo, al usuario final como uno de los requisitos para llegar al éxito del
proyecto.

Figura 4: Metodología Extreme Programing

(Tomado de Metodologías De Desarrollo De Software)2

En esta metodología, como se menciona anteriormente, el cliente se convierte en un

miembro más del equipo de trabajo y es el encargado de decidir que se implementa,
puede añadir, cambiar o quitar requerimientos en cualquier momento para lo cual
debe estar enterado constantemente del estado real y el progreso del proyecto
obteniendo lo máximo de cada semana de trabajo.

Esta metodología trabaja cuatro fases principales que a la vez contienen subfases de
desarrollo, en la figura 5. se detalla el diagrama correspondiente a la metodología XP.

1
Ibíd.
2
Ibíd.
 Figura 5. Fases del la Metodología XP
(Tomado de Introducción a Extreme Programming)3

En la primera fase de planificación, se realiza toda la planeación del proyecto, los

clientes relatan a grandes rasgos las historias de usuario o requerimientos, al tiempo
que los desarrolladores se familiarizan con las herramientas tecnologías y prácticas
que se implementan en el proceso de desarrollo. Una vez seleccionada la tecnología,
se exploran las posibilidades de arquitectura del sistema y se hace un diseño previo.
En general esta fase contiene los siguientes procesos que se desarrollan para
determinar la planeación:
 Historias de Usuario.
 Plan de entregas.
 Iteraciones.
 Reuniones.

Las historias de usuario tienen el mismo propósito que los casos de uso, pero no son lo
mismo. Las escriben los propios clientes tal y como ven ellos las necesidades del

3
Introducción a Extreme Programming [en línea]. (Consultado en Marzo de 2008)
http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf
 sistema. Por tanto serán descripciones cortas y escritas en el lenguaje del usuario, sin
terminología técnica4.

Estas historias son reportadas por el usuario y registradas en manuscrito en un

formato como el que se muestra en la figura 6, aquí no solo se limitan a la descripción
de la interfaz de usuario sino que relatan una visión general pero detallada de la
funcionalidad o los requerimientos del sistema.

Historia del Cliente y Tarjeta de Tareas

Fecha Tipo de Actividad: Nueva:___ Fijar:___ Mejorar:___
Numero de historia Prioridad: Usuario___ Desarrollador:_____
___
Referencia anterior Riesgo:____________ Tecnicas de estimación:________
Descripcion de Tarea:

Notas:

Tareas de Seguimiento
Fecha Estado Hacer Observaciones

Figura 6. Historia de usuario (Tomado de Introducción a Extreme Programming)5

El Plan de entregas está basado en las historias de usuario, se usan para crear los
planes de iteración y consisten en un cronograma elaborado en conjunto con el cliente
con fechas de pequeñas entregas que son revisadas en cada reunión ya que allí están
presentes tanto desarrolladores como usuarios. De esta forma se puede trazar el plan
de entregas en función de dos parámetros: tiempo de desarrollo ideal y grado de
importancia para el cliente. Las iteraciones individuales son planificadas en detalle
justo antes de que comience cada iteración.

En las iteraciones los clientes seleccionan las historias de usuario que serán
implementadas en cada iteración, también seleccionan las historias de usuario que no

4
Introducción a Extreme Programming [en línea]. (Consultado en Marzo de 2008
http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Trabajo-XP.pdf
5
Ibíd.
pasaron el test de aceptación que se realizó al terminar la iteración anterior. El trabajo
de cada iteración es expresado en tareas de programación que son asignadas a un
programador como responsable, pero llevadas a cabo por parejas de programadores.

Se programan reuniones frecuentes con el fin de hacer correcciones o cambiar las

reglas por consenso ya que participan el cliente, el director del proyecto y los
desarrolladores. Esta reuniones son importantes para que haya comunicación entre
las diferentes partes que interviene en el proyecto, allí se analizan los problemas y se
dan las soluciones respectivas, se distribuyen las tareas o responsabilidades que serán
analizadas en la siguiente sesión. XP recomienda que estas reuniones sean diarias con
el objetivo de hacer un seguimiento continuo y no dejar pasar algún detalle.

En la fase de Diseño, se establecen unas recomendaciones o premisas para lograr un

diseño simple pero funcional, estas recomendaciones son:
 Elegir una metáfora para el sistema.
 Usar tarjetas CRC
 Crear soluciones puntuales para reducir riesgos.
 Funcionalidad Mínima.
 Reciclaje.

La metáfora es una historia en la que se relata al usuario el funcionamiento básico del

sistema; esta debe ser lo más clara posible para que le sea de fácil entendimiento al
usuario. En la metáfora se deben utilizar nombres que orienten la implantación del
proyecto para no perder la esencia del mismo y reflejar lo que se quiere representar
para el mundo real.

Una tarjeta CRC representa un objeto, mediante la utilización de estas tarjetas se logra
que todo el equipo de trabajo contribuya en la tarea de diseño ya que en ellas se
definen las acciones que cumple cada clase6.

El diseño de estas tarjetas permite el trabajo en equipo y cumple con tres principios
básicos: Cargo o Clase, Responsabilidad y Colaboración (CRC). Las tarjetas CRC
6
Introducción a Extreme Programming [en línea]. (Consultado en Marzo de 2008)
http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Trabajo-XP.pdf
permiten que el equipo completo contribuya en la tarea del diseño, en ellas se registra
el nombre de la clase a modo de título, las responsabilidades se colocan a la izquierda
y las clases que se implican en cada responsabilidad a la derecha, en la misma línea
que su requerimiento correspondiente como se muestra en la figura 7.

Figura 7. Tarjetas CRC

Las Soluciones Puntuales consisten en tener un plan de posibles soluciones a los

problemas que se puedan presentar en el desarrollo e implementación del proyecto,
como cuando el cliente no esté a gusto con el diseño, problemas en la programación o
mala adecuación de los sistemas, entre otros, para esto se crea un formato el cual se
registran los posibles errores, la solución posible al inconveniente y la aprobación del
usuario.
 PLAN DE POSIBLES SOLUCIONES
No. No.
Errores Historia Iteración Soluciones Puntuales Aprobado

Tabla 3. Formato Plan de Posibles Soluciones

El concepto de funcionalidad mínima en metodología XP busca entregar al usuario
proyectos que satisfagan sus necesidades. Para esto es indispensable que los
desarrolladores tengan presente qué debe hacer el sistema y no exageren en
implementar partes que pueden cambiar el curso de los requerimientos y que pueden
entorpecer el proceso de programación. Se debe ser claro en la funcionalidad mínima,
sin crear tareas en las que se perderá tiempo y que no son necesarias para el proyecto.

Cuando se reutiliza la información que ya existe en programas o desarrollos anteriores

se elimina redundancia, funcionalidad inútil, y se recicla código fuente. De tal manera
que en el ciclo de vida del proyecto no se pierda tiempo en hacer nuevamente lo que
ya está hecho y se asegura al cliente que el producto cuenta con un nivel de calidad
excelente. Esto implica que los desarrolladores deban estar pendientes de no pasar
por alto ningún error; además, les facilita ampliar y modificar los códigos de acuerdo a
los requerimientos.

La fase de Desarrollo reúne una serie de características o cualidades que basan todo el
desarrollo general del proyecto:
 Disponibilidad del cliente.
 Unidad de Pruebas.
 Programación por parejas.
Para la metodología XP es fundamental contar con el apoyo y la disponibilidad del
cliente7, porque es la persona encargada de revisar y decidir si lo que se está haciendo
cubre las necesidades adecuadas para el proyecto; de este modo el cliente se
convierte en parte del equipo. En la plantación previa del proyecto el cliente es quien
elige las historias de usuarios que se deben utilizar a lo largo de la implementación. Es
con el cliente con quien se negocian los plazos para las entregas de avances de la
ejecución del proyecto. Luego es el quién revisa los resultados obtenidos y aprueba el
funcionamiento del proyecto.

Al momento de desarrollar, primero se debe tener claridad de lo que se desea hacer,

para ello, el programador realiza uno o varios tests de unidad de prueba que le
permiten seguir unas reglas básicas de utilidades de la aplicación que se desarrollará.
Estos tests tienen la particularidad de ayudar al desarrollador a visualizar claramente
como se desea hacer y que comportamiento debe tener el proyecto, de tal manera,
que se puedan hacer correcciones a tiempo y evitar problemas en la implementación.

Para que el plan de desarrollo tenga éxito es indispensable que las personas que lo
trabajan cuenten con la herramienta y el conocimiento suficiente para sacarlo
adelante. De esta manera, se incrementará la calidad del software desarrollado sin
afectar el tiempo de entrega. Para que funcione la programación en parejas, ambas
personas deben crear un método que les ayude a avanzar de manera eficiente en la
implementación del proyecto; mientras uno trabaja en la implementación de tareas, el
otro verifica que se esté desarrollando el proyecto de acuerdo a los parámetros de
calidad establecidos.

Fase de pruebas, las unidades o test de pruebas son parte indispensable de la Extreme
Programming (XP). Estas se convierten en una herramienta de desarrollo y material de
apoyo, mas no en un paso de verificación que puede despreciarse por más que parezca
que el código esté funcionando correctamente. Es por esto que la metodología XP

7
Introducción a Extreme Programming [en línea]. (Consultado en Marzo de 2008)
http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Trabajo-XP.pdf
exige constantes pruebas en el desarrollo, ya que descubrir todos los errores que
puedan presentarse lleva tiempo y más si se dejan para el final del proyecto.

En esta fase es importante tener en cuenta las siguientes características:

 Implantación.
 Pruebas de Aceptación.

El proceso de implantación se realiza luego de garantizar que el código se encuentra

completo. Lo que quiere decir que se han realizado las pruebas de aceptación y se ha
hecho una revisión de los requerimientos planteados por el cliente, que aseguran que
el código esta de acuerdo con la solicitud. El código será implantado cuando supere sus
correspondientes unidades de test.

Las pruebas de aceptación están basadas en las historias de usuario, se hace un

planteamiento de los puntos del desarrollo que deben probarse para corroborar que
funcionen correctamente. Es para esto que se crean las pruebas de aceptación,
determinando cuales son los aspectos que el cliente desea revisar y así garantizar su
correcto funcionamiento. Por ello la importancia de crear cuantas pruebas de
aceptación sean necesarias para que todo el trabajo realizado cuente con la calidad
que exige. Es fundamental desarrollar los test de aceptación, por que es de esta forma
que se demuestra el progreso y el proceso que se sigue en la ejecución del plan de
iteraciones para las historias de usuario, ya que estas no se consideran completas
hasta que no superan sus pruebas de aceptación.
 Resultados de un proyecto desarrollado con XP

3. METODOLOGIA DE DESARROLLO.

Haciendo una comparación de las metodologías de desarrollo propuestas en el marco

teórico, se observa que la Metodología RUP es más adaptable para proyectos a largo
plazo, la Metodología XP para proyectos de corto plazo y la Metodología MSF se
adapta a proyectos de cualquier dimensión y de cualquier tecnología. Para elegir la
metodología más apropiada en la implementación de un software es necesario
determinar su alcance y de acuerdo a las especificaciones de cada metodología
escoger la que más se acople a la aplicación.

En el presente proyecto se aplicara la metodología XP teniendo en cuenta que sus

características para el desarrollo de software son compatibles con la especificaciones
propias de este; principalmente porque es un proyecto a corto plazo y cuenta con un
grupo de trabajo en el que participan dos desarrolladores, además, se trabaja en
equipo con el cliente como elemento esencial para el planteamiento de los
requerimientos y el éxito del proyecto.

3.1. FASE DE PLANIFICACIÓN

En esta fase se realizó toda la planeación general de proyecto, el Dr. Nicolás Barbosa
como usuario final relato los requerimientos del proyecto y entrego la documentación
correspondiente al test de Carrera de Navette de la Batería de condición física Eurofit,
con base en esta historia de usuario, con el Ingeniero Efraín Patiño, director del
proyecto se realizó la distribución de tareas, el cronograma de entregas y la
programación de las reuniones que se muestran a continuación.

3.1.1. Historia de Usuario. De acuerdo a las especificaciones del Dr. Nicolás y la

distribución del Ingeniero Efraín Patiño, se realizaron 8 historias de usuario basadas en
los requerimientos principales del proyecto, estas historias son:

 Historia de usuario 1. Recuento general del requerimiento.

En esta historia de usuario el Dr. Nicolás relata a grandes rasgos los requerimientos
básicos del proyecto, da una visión general del objetivo que se pretende cumplir.
 Historia de usuario 2. Diseño inicial de la interfaz de usuario.

Teniendo en cuenta lo relatado en la historia de usuario 1, en conjunto con el cliente

se hace el planteamiento general de la interfaz de usuario y se identifican 3 ventanas
 iniciales. La pantalla inicial o de presentación del software con sus respectivos menús,
una pantalla posterior para realizar la consulta de los participantes y la ventana de
realización de la prueba.

 Historia de usuario 3. Diseño detallado de la Interfaz de usuario

Luego de presentar el diseño de las pantallas iniciales y contar con el visto bueno del
cliente se hace una revisión general de la navegabilidad de estas y se identifican los
requisitos pendientes entre los cuales se encuentra la conexión a la base de datos, ya
que para que esta navegabilidad sea funcional se requiere de esta conexión y hacer
consultas a la misma

 Historia de usuario 4. Base de datos.

La historia de usuario 4 implica directamente la creación de la conexión con la base de
datos, se identifica la necesidad de crear una ruta que especifique la ubicación de la
base de datos para implementar la conexión.

 Historia de usuario 5. funcionalidad de los módulos

Se diseñaron los requisitos específicos de cada uno de los módulos de consulta y
evaluación, los campos requeridos y la funcionalidad del mismo.

 Historia de usuario 6. hardware

Se tuvo en cuenta un diseño inicial con sensores de tacto, posteriormente con
sensores de láser que fueron implementados, el diseño de un circuito y la estructura
física que por sugerencia del Dr. Nicolás se realizo por medio de trípodes.

 Historia de usuario 7. Conexión del Software y Hardware

Mediante la implementación de un puerto serial se logra la comunicación del circuito
con el software, teniendo en cuenta que los equipos portátiles no cuentan con este
puerto es necesaria la conversión de la conexión a puerto USB mediante un cable
convertidor, se realizaron las pruebas respectivas y fueron satisfactorias.

 Historia de usuario 8. Pruebas de campo.

3.1.2. Plan de entregas En la reunión de planificación se realizó el cronograma de

actividades o plan de entregas del proyecto, estas entregas se programaron de acuerdo a las
historias de usuario y se incluyó las observaciones realizadas por el cliente en cada entrega.
 Tabla 6. Cronograma de entregas

ITERAC DESCRIPCION FECHA FECHA OBSERVACIÓN APROB.

PREVISTA ENTREGA
Diseño de pantallas Feb/08 Feb/08 El cliente hizo las correcciones
en el diseño y añadió partes y
textos a las pantallas (ver anexo
No. …)
Navegabilidad Feb/08 Feb/08 Fue revisado y se agregaron
mensajes de validación.
Conexión a base de Datos Mar/08
Diseño detallado Interfaz Mar/08
de Usuario
Diseño unidad de hardware Mar/08
Montaje del Hardware en Mar/08
protoboard
Pruebas de la unidad de Abr/08
Hardware
Rediseño de la unidad de
hardware
Conexión con Software y Abr/08
Hardware
Presentación previa a Abr/08
sustentación.
Quemado de la placa
electrónica
Diseño y elaboración del
prototipo físico
Correcciones. Abr/08
Pruebas. May/08
Entrega Final Jun/08

3.1.3. Iteraciones. Con base en las historias de usuario definidas anteriormente se

realiza el plan de iteraciones de la siguiente manera.
Historia de usuario 1. Diseño inicial de la interfaz de usuario.
 Diseño de pantallas principales
 Navegabilidad.

Historia de usuario 2. Base de datos.

 Conexión a la base de datos.
 Verificación de la conexión a la base de datos.

Historia de usuario 3. Diseño detallado de la Interfaz de usuario:

  Modulo de registro.
 Modulo de consulta.
 Modulo de evaluación.

Historia de usuario 4. Hardware.

 Diseño de la unidad de hardware
 Montaje del hardware en protoboard
 Pruebas de la unidad de hardware.
 Rediseño de la unidad de hardware.
 Quemado de la placa electrónica.
 Diseño y elaboración del prototipo físico.

Historia de usuario 5. Funcionalidad de hardware

 Conexión de Software y Hardware.

Historia de usuario 6. Pruebas de campo.

 Aplicación de prueba a participantes.

3.1.4. Reuniones. El cronograma de reuniones se programó desde Febrero de 2008

hasta Junio de 2008 realizando reuniones dos veces de lunes a viernes y todos los fines
de semana, incluyendo festivos y semana santa, en estas reuniones participó el usuario
haciendo sus respectivas observaciones y mejoras a los entregables presentados, los
cuales fueron corregidos siempre para la siguiente entrega.

3.2. DISEÑO

Para esta fase se realizo el análisis de las historias de usuario y los requerimientos con
el fin de diseñar el software, se desarrollo una metáfora del sistema en la cual se relata
el funcionamiento del sistema, las tarjetas CRC para realizar la distribución de las
tareas especifica y un plan de posibles errores para implementar la solución,
inicialmente se presento un diseño en borrador al cliente y luego de las correcciones
realizadas se procedió al desarrollo

3.2.1 Metáfora del sistema Este sistema representa la sistematización del test de
Carrera Navette el cual se realiza en un espacio plano con dos líneas paralelas a 20 m
de distancia, los participantes de la prueba se encuentran registran en la base de datos
QAPACE con sus datos principales, documento, nombre, edad, peso, talla, entre otros,
son consultados por medio del software e incluidos en la tabla de registros de la
prueba que esta diseñada para 10 participantes, una vez la tabla se encuentre
diligenciada o con al menos un participante se da inicio a la prueba, los participantes se
pondrán en marcha al oír la señal de salida, tendrán que desplazarse hasta la línea
contraria (20 m) y pisarla esperando volver a oír la siguiente señal y repetirán
constantemente este ciclo hasta que no pueda llegar a pisar la línea en el momento
que lo señale el magnetófono. Durante cada ciclo de desplazamiento por medio de
los sensores se garantiza que el participante llegue a los dos extremos y se registra el
dato correspondiente a un palier o periodo que es cuando el participante regrese a su
sitio de origen.

La prueba va finalizando para cada competidor en la medida en que no puedan o

alcancen a llegar al otro extremo al ritmo marcado y en le momento que suena la
señal, aquí se muestra para cada participante su resultado de la resistencia
cardiovascular obtenida en la prueba.

3.2.2. Tarjetas CRC. Se realizo la distribución de las tareas registrando en las tarjetas
CRC las principales responsabilidades del sistema y especificando las acciones a realizar
por cada una. Las principales responsabilidades que implementa el sistema son:
Conexión a Base de Datos, Consulta, registro y realizar prueba, para cada una se realizo
su respectiva tarjeta CRC.

3.2.3. Soluciones Puntuales para el plan de soluciones puntuales se realizaron las

validaciones de cada responsabilidad del sistema registrando en un formato las
posibles errores con la solución propuesta al mismo.
3.3. DESARROLLO.

Luego de tener definido un diseño previo con las validaciones necesarias y la solución a
posibles errores, se procede a realizar el desarrollo del software con la aprobación y
acompañamiento continuo del cliente.

3.3.1. Disponibilidad del cliente. Teniendo en cuenta que en el presente proyecto, el

cliente participo como director del mismo, se contó siempre con la accesoria y apoyo
continuo a las diferentes actividades realizadas, las soluciones planteadas fueron
llevadas a cabo y se tuvo siempre en cuenta su criterio y aprobación.
3.3.2. Unidad de Pruebas se definió en conjunto con el cliente las unidades de pruebas
necesarias para la funcionalidad del sistema y ser registraron el la tabla
correspondiente.

3.3.3. Programación por parejas. El grupo de desarrolladores del presente proyecto

esta integrado por dos personas, Johanna Rangel y Andrés Gámez, por tanto en todo
momento se aplico la programación en parejas para el desarrollo del software, fueron
distribuidas las tareas pero realizadas en conjunto como lo especifica la metodología.

3.4. PRUEBAS.
3.4.1. Implantación.
FALTA COMPLETAR

3.4.2. Pruebas de Aceptación.

3.5 IMPLEMENTACIÓN HARDWARE

Para el desarrollo de este hardware se pensó inicialmente en la elaboración de un

dispositivo inalámbrico como el mas conveniente ya que la prueba se realiza
generalmente en un campo abierto de 20 metros de distancia y por la estructura
misma del dispositivo es recomendable lo inalámbrico, pero luego de las
investigaciones realizadas, se decidió la elaboración alambica del dispositivo debido a
que los costos se incrementan en un 80% para dispositivos inalámbricos de este tipo
principalmente en lo referente a los sensores que se deben utilizar.

En la figura 13. se realiza un diseño de la estructura general del hardware.

Figura 13. Diseño General del hardware.

El diseño específico del dispositivo consiste en la programación de un pic que recibe

señales de los pulsadores, realiza el procesamiento respectivo de la información y
envía los datos al software a través del puerto serie.

La programación del microcontrolador o PIC se desarrollo en PIC Basic plus, en la

Figura 14. se muestra el código desarrollado para el funcionamiento del PIC que recibe
las señales de los pulsadores.
 Figura 14. Programación de PIC 16F84A.

La conexión con el PC para el procesamiento de la información se implementó a través

del puerto serie bajo la norma RS 232.

El ciclo de vida ideal de XP consiste de seis fases [LetelierPenades03]:

I. Exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de interés para la primera entrega del producto. Al mismo tiempo el equipo
de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades
de la arquitectura del sistema construyendo un prototipo. La fase de exploración
toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad
que tengan los programadores con la tecnología.

II. Planificación de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la
primera entrega y se determina un cronograma en conjunto con el cliente. Una
entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos
días. Las estimaciones de esfuerzo asociado a la implementación de las historias
la establecen los programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programación. Las historias generalmente valen
de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la
“velocidad” de desarrollo, establecida en puntos por iteración, basándose
principalmente en la suma de puntos correspondientes a las historias de usuario
que fueron terminadas en la última iteración. La planificación se puede realizar
basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para
establecer cuántas historias se pueden implementar antes de una fecha
determinada o cuánto tiempo tomará implementar un conjunto de historias. Al
planificar por tiempo, se multiplica el número de iteraciones por la velocidad del
proyecto, determinándose cuántos puntos se pueden completar. Al planificar
según alcance del sistema, se divide la suma de puntos de las historias de usuario
seleccionadas entre la velocidad del proyecto, obteniendo el número de
iteraciones necesarias para su implementación.

III. Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la
primera iteración se puede intentar establecer una arquitectura del sistema que
 pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creación de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qué historias se
implementarán en cada iteración (para maximizar el valor de negocio). Al final
de la última iteración el sistema estará listo para entrar en producción. Los
elementos que deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas
de aceptación no superadas en la iteración anterior y tareas no terminadas en la
iteración anterior. Todo el trabajo de la iteración es expresado en tareas de
programación, cada una de ellas es asignada a un programador como
responsable, pero llevadas a cabo por parejas de programadores.

IV. Producción

La fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al
mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas
características a la versión actual, debido a cambios durante esta fase. Es posible
que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas
que han sido propuestas y las sugerencias son documentadas para su posterior
implementación (por ejemplo, durante la fase de mantenimiento).

V. Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe

mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar después de la puesta del
sistema en producción. La fase de mantenimiento puede requerir nuevo personal
dentro del equipo y cambios en su estructura.

VI. Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentación final del
sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios esperados por el
cliente o cuando no hay presupuesto para mantenerlo.

Figura 5.2. Ciclos en eXtreme Programming