DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
METODOLOGÍA XP
“Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La
tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio
en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de
adaptarnos a dicho cambio cuando éste tiene lugar”. - Kent Beck
Las características más importantes de la metodología XP son:
 Actualmente es utilizada en Ingeniería de Software para desarrollar sistemas a corto plazo.
 Permite desarrollar proyectos sin dar mucha importancia a la documentación.
 Realiza la codificación y pruebas de forma paralela y no secuencial, así como permite la
colaboración y comunicación directa de los clientes, otorgando respuestas inmediatas ante la
eventualidad de presentarse algún cambio.
 Dispone de herramientas informáticas y no informáticas para desarrollar por completo un
proyecto de desarrollo Web.
 Verifica que el desarrollo del proyecto funcione por medio de prototipos. Por regla general
estos se deben producir cuando sean realmente necesarios.

VENTAJAS DE LA METODOLOGÍA XP
Las ventajas que se pueden obtener al utilizar la metodología XP son las siguientes:
 Potenciar el trabajo en grupo durante el desarrollo de la aplicación.
 Entregar periódicamente avances del sistema.
 Realizar pruebas continuas hasta obtener la aplicación final.
 Los cambios que se realizan en la aplicación no deben aumentar con el tiempo.
 Realizar un desarrollo de manera eficiente, sencilla y clara; para facilitar el rendimiento y su
actualización.
 Da lugar a una programación sumamente organizada.
 Ocasiona eficiencias en el proceso de planificación y pruebas.
 Cuenta con una tasa de errores muy pequeña.
 Propicia la satisfacción del programador.
 Fomenta la comunicación entre los clientes y los desarrolladores.
 Facilita los cambios.
 Permite ahorrar mucho tiempo y dinero.
 Puede ser aplicada a cualquier lenguaje de programación.
 El cliente tiene el control sobre las prioridades.
 Se hacen pruebas continuas durante el proyecto.
 La XP es mejor utilizada en la implementación de nuevas tecnologías.

ROLES DE LA METODOLOGÍA XP
Los roles que posee la metodología XP permite a los desarrolladores organizar y distribuir el trabajo
de manera más equilibrada y eficiente.
Estos roles se pueden resumir de la siguiente manera:

PROGRAMADOR
Responsable de construir, analizar, programar, tomar decisiones y realizar pruebas del sistema.
JEFE DE PROYECTO
Responsable de coordinar, gestionar y administrar las reuniones para considerar las condiciones de
cómo avanza el proyecto.
CLIENTE
Persona que debe especificar qué construir, cuándo y dónde realizar las pruebas.
1
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ENCARGADO DE PRUEBAS
Delegado de ayudar al cliente para que las pruebas sean realizadas y superadas.
RASTREADOR
Responsable de obtener datos históricos; encargados de observar sin molestar durante el
desarrollo del sistema.
ENTRENADOR
Facultado de visualizar el proceso y desarrollo del sistema, desde un segundo plano.
Cuando se utilizan los roles de la metodología XP se trata al cliente como parte del equipo de
desarrolladores, lo que evita la redundancia de información, y permite que se realicen pruebas
constantes de la aplicación. Otro beneficio de esta inclusión es que se efectúan cambios mientras
avanza el desarrollo según los requerimientos solicitados evitando pérdidas de tiempo. (Bustamante
& Rodriguez, 2014)

ARTEFACTO DE LA METODOLOGÍA XP
Los artefactos de la metodología XP son: Historias de usuario, iteración, tarjeta CRC.

A) HISTORIA DE USUARIO:
Las historias de usuario explican de una manera simple y entendible los requisitos de la empresa ya
que son escritas por los clientes involucrados en el desarrollo utilizando un lenguaje común (sin
tecnicismos).
Para su elaboración se utilizan tarjetas de papel o a través de una computadora. En estas se plasman
los requisitos del usuario con lo que el desarrollador podrá visualizar el ámbito y fijar prioridades para
el desarrollo de la aplicación, así como generar estimaciones, consecuencias y definir procesos a ser
realizados.
Por medio de las historias de usuario se puede formalizar de manera casi exacta la estimación del
tiempo que llevará realizar el desarrollo de la aplicación. Permiten proporcionar la estimación de
riesgo de cada requisito y verificar si se cumple correctamente con lo solicitado cuando se realicen
las pruebas.
También ayudan a definir las funciones que realizan los usuarios cuando utilizan el software y
determinar quiénes deben poseer acceso ilimitado y limitado para evitar errores.
Cada una de las historias debe ser limitada y clara para ser implementada por los desarrolladores
máximo en tres semanas; si se requiere más tiempo esta debe ser divida entre dos personas para
obtener un mejor desempeño.
Al inicio es común que no se especifiquen todas las historias de usuario, pero estas se incrementarán
al realizar las iteraciones. Se debe tomar en cuenta que para cada historia de usuario debe existir una
prueba de aceptación.

2
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
B) ITERACIÓN
Las iteraciones permiten realizar un análisis más exhaustivo antes de implementar una historia de
usuario; de esta forma el desarrollador en conjunto con el cliente deben realizar las fichas de tareas
para obtener la información necesaria para un mejor desarrollo.
Las iteraciones son útiles para verificar el avance del proyecto; entre menos errores este tenga se
puede observar un gran avance en el mismo, tanto en calidad como en tiempo. Dentro de cualquier
desarrollo se establece como mínimo tres interacciones.
En la tabla 02 se visualiza el modelo de ficha para realizar las tareas.

C) TARJETAS CRC (TARJETAS, RESPONSABILIDADES Y COLABORACIÓN)

Una tarjeta CRC representa una clase en la programación orientada a objetos.
Son utilizadas por la metodología XP para diseñar el sistema uniendo todas las funcionalidades.
Ayudan a definir actividades mientras se está diseñando el sistema.
Como se visualiza en la tabla 03 la tarjeta CRC representa: la clase a la que pertenece el objeto, las
responsabilidades que deben realizar el objeto y las colaboraciones con otras clases para conocer
cómo se comunican entre ellas y cumplen con cada responsabilidad del objeto.

Las ventajas de crear las tarjetas CRC son las siguientes:

 Permiten contribuir al diseño de todo el equipo del proyecto.
 Permiten reducir el modo de pensar procedural y apreciar la tecnología de objetos.
 Las tarjetas CRC son simples, fáciles de comprender y flexibles de realizarlas.
 Se visualiza en forma resumida todo el funcionamiento de una clase.

3
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FASES DE LA METODOLOGÍA XP

I) PLANIFICACIÓN
Permite obtener y recolectar la información necesaria para conocer lo que el cliente requiere; se
debe estar al tanto de los objetivos del proyecto, el tiempo que tomará desarrollar el sistema,
personas involucradas en el desarrollo, presentación de prototipos y la evaluación de calidad.
Esta fase lo componen las siguientes etapas:
a) Historias de Usuario
El primer paso de cualquier proyecto que siga la metodología XP 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 o 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.

b) Plan de entregas
Consiste en facilitar un cronograma como resultado de la información obtenida de las historias de
usuario, que debe ser analizado por todos los actores del proyecto. Dicho plan puede ser
modificado o actualizado de ser requerido, para lo cual se debe realizar una nueva reunión entre
los actores.
Este cronograma tiene que especificar el tiempo establecido para la implementación de las
historias de usuario, prioridad de desarrollo de cada una y especificar la presentación de pequeñas
versiones del proyecto.
Por medio del plan de entregas se debe obtener los siguientes factores:
 Objetivos: Clasificar las historias de usuario.
 Tiempo: Desarrollar y publicar los prototipos.

4
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Personas involucradas: Especificar el número de personas necesarias.
 Evaluaciones: Verificar la calidad del proyecto.

Nº TIEMPO ESTIMADO
ITERACION PRIORIDAD ESFUERZO
HU FECHA DE INICIO FECHA DE TERMINO
01 1
02 1
03 1
04 1
05 2
06 2
07 2
08 3
09 3

c) 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 "Plan
de entregas".

d) Iteraciones
Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de aproximadamente 3
a 4 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias
de usuario definidas en el "Plan de entregas" 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.

5
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

e) Rotaciones
Permite mantener un lazo de comunicación con todos los actores del proyecto para que los
involucrados conozcan el diseño y la codificación del sistema en su totalidad.
Esta característica permite que una persona rote por todas las funcionalidades durante el
desarrollo del sistema, y dado que se crean patrones de codificación todos los individuos
involucrados son aptos de entender el funcionamiento del mismo. Así la metodología XP trata de
evitar cuellos de botella o códigos que no pueden ser reutilizados por otros programadores.
f) Reuniones
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.

II) DISEÑO
Fase en la que se crea estándares y patrones para realizar la codificación; de esta forma se
obtendrá un código más eficiente, con calidad y comprensión para todos los involucrados en el
desarrollo. Esta fase lo determinan los siguientes componentes:

a) Metáfora del Sistema

En la metodología XP es importante crear una metáfora entre los desarrolladores y el cliente. La
metáfora consiste en narrar cómo funcionaría el sistema en el momento de la entrega final.
Permite conocer el alcance, propósito y es utilizada como una guía para desarrollar el sistema.
“Una metáfora para el sistema es una historia que todo el mundo puede contar acerca de cómo el
sistema funciona”. Kent Beck.
Para un mejor desarrollo de la metáfora se debe especificar nombres (se debe definir las
nomenclaturas de clases y métodos del sistema) y analizar posibles problemas que puedan
generarse.
Las ventajas de crear una metáfora son las siguientes:
 Conocer la mayoría o todo lo que se va a implementar.
 Permite entender de forma clara el objetivo del sistema.

6
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 El cliente pueda hablar cómodamente sobre el funcionamiento del sistema.
 Los desarrolladores conocen el mismo lenguaje y si hay nuevos desarrolladores les permite
adaptarse más rápido y sin dificultades.
 Permite implementar los patrones de diseño que podrían ser utilizados durante el desarrollo
del sistema.

b) Tarjetas CRC
Las tarjetas Clase – Responsabilidad - Colaboración su técnica consiste en dibujar una tarjeta por
cada clase u objeto, y dividirla en tres zonas:
 En la parte superior, el nombre de la clase.
 Debajo, en la parte izquierda, las responsabilidades de dicha clase. Son sus objetivos, a alto
nivel.
 A la derecha de las responsabilidades, los colaboradores, que son otras clases que ayudan a
conseguir cumplir a esta con sus responsabilidades

c) Soluciones Puntuales
La metodología XP utiliza las soluciones puntuales llamadas Spike, para encontrar posibles
respuestas a problemas (técnico, arquitectura del software, estimación de tiempo) que pueden
aparecer durante el desarrollo del sistema.
Estos pequeños programas son utilizados para probar y evaluar soluciones; son considerados
desechables, ya que una vez utilizados y valorados los resultados obtenidos de su ejecución se los
puede descartar.
La metodología XP da preferencia a la solución de los problemas de manera automática y no
manual; de esta forma se trata de disminuir el riesgo y aumentar la confiabilidad en el desarrollo
de alguna historia de usuario.

d) Funcionalidad mínima
La metodología XP indica que la funcionalidad extra consume recursos, representa una pérdida de
tiempo y quizás nunca se utilice esas funcionalidades.
Por esta razón se da prioridad a una eficiente programación, focalizando en quien realiza la tarea
programada para cada día, creando el código necesario y verificando que realice su trabajo
correctamente. De esta forma, se evita crear código que quizás no sea utilizado.
Por lo tanto 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.

e) Reciclaje
Es una actividad que utiliza la metodología XP para obtener un mejor control cuando se programa.
Consiste en eliminar la redundancia de código, simplificar y crear una estructura fácil de
comprender y modificar para futuros cambios.
Es necesario revisar el código cada vez que se termina una iteración, tomando en cuenta los
siguientes puntos:
 Desplazamiento fácil en el sistema. (Si/No)
 Existen varios objetos que realizan lo mismo. (Si/No)
 Existe suficiente espacio para el contenido del sistema. (Si/No)
 Existe código de funciones que fueron eliminadas. (Si/No)
 Comunica la visión principal u original del sistema. (Si/No)
7
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Por lo tanto, 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.

III) DESARROLLO
La metodología XP indica que el código expresa tú interpretación del problema, así podemos
utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar.

a) Disponibilidad del cliente

Para la metodología XP es necesario crear una comunicación fluida, personal y directa entre el
cliente y el equipo de trabajo en todas las fases del proyecto; de este modo se reduce el tiempo
de desarrollo del sistema y evita malos entendidos por cuanto se trata de una comunicación oral
y no escrita.
Las funciones que realiza un cliente son:
 Realizar las historias de usuario y especificar el plan de entrega.
 Validar el sistema cuando se realicen las pruebas funcionales.
 Toma de decisiones sobre las funciones que realiza el sistema.
 Responder dudas, determinar prioridades, especificar mejoras y resolver posibles
problemas.
 Tener un compromiso de trabajo en equipo.
 Estar presente antes de desarrollar cada historia de usuario y comunicar más
detalladamente su funcionamiento.
 Determinar cuando el sistema puede ser colocado en producción.
Por medio de la comunicación permanente se puede prevenir a tiempo cualquier situación o
funcionalidad que no es deseable o necesaria para el proyecto, sin necesidad de esperar a
estar en el ciclo de desarrollo para comenzar a realizar las correcciones, que a la postre
puedan ser consideradas muy complicados.

b) Unidad de pruebas
La metodología XP recomienda crear las pruebas de unidad antes del código y de la
implementación del sistema, para obtener un conocimiento global del comportamiento del
sistema.
Estas pruebas deben ser ejecutadas cada vez que exista una modificación en el sistema. Como
resultado se obtiene un código conciso y simple ya que se implementa únicamente las
características necesarias que requiere el sistema.
Todas las características que tiene el sistema tienen que ser probadas constantemente, lo que
permite adaptarse a nuevos cambios.
Las pruebas de unidad tienen las siguientes características:
 Se crean una vez y se ejecutan constantemente durante todo el desarrollo del proyecto.
 Verifican el funcionamiento correcto evitando redundancia.
 Al principio se obtiene una prueba y función simple; se van agregando nuevos requerimientos
dependiendo de las etapas en la que se encuentre hasta obtener toda la funcionalidad
requerida.
 Una funcionalidad se la determina como finalizada cuando paso correctamente todas las
pruebas de unidad.

8
DESARROLLO DE SOFTWARE INGENIERIA DE SISTEMAS IX SEMESTRE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
c) Programación por parejas
La metodología XP 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.

d) Integración
El objetivo de la metodología XP fomenta que la programación siempre debe ser en pareja, para
desarrollar el código de manera continua, rotar funciones y escribir con los mismos estándares.
Existen dos tipos de integraciones que utiliza la metodología XP, que son:
 Integración continua
Se realiza la integración de código cada vez que esté listo por los desarrolladores, para luego ser
probado; esta debe ser realizada, de ser posible, varias
veces en un día. Aquí todos trabajan con la última versión del proyecto.
Al utilizar este tipo de integración se detecta o evade de manera eficiente los posibles problemas
de compatibilidad que pueden surgir.
 Integración secuencial
Es recomendable realizar la integración de código en una máquina para evitar posibles problemas
o redundancia en el código; ya que los desarrolladores trabajan en paralelo en donde se debe
elegir únicamente a una pareja de desarrolladores que integren, prueben y realicen cambios en el
código.

IV) PRUEBAS
Uno de los pilares de la metodología XP es el uso de test para comprobar el funcionamiento de
los códigos que vayamos implementando.
El uso de los test en XP es el siguiente:
a) Implantación
 Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico
para test.
 Hay que someter a test 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á.
 Como se comentó anteriormente los distintos test se deben subir al repositorio de código
acompañados del código que verifican.
 Test de aceptación: Los test mencionados anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario.
 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.
b) Prueba de aceptación
Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido
dividida una historia de usuario.