Primer metodología Agil, Metodología XP

1. UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA
FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN
SECRETARÍA DE POSGRADO
MAESTRÍA EN SISTEMAS DE INFORMACIÓN
Metodología de Análisis y Diseño de Sistemas de Información
Titular o Catedrático: Ing Francisco Mariscal Flores
Tema: METODOLOGIA XP
Alumna: Ing. Renata Cecilia Briseño Mendoza
No. Matricula: P297722
Guadalajara, Jalisco. 03/10/2015

2. 1
INTRODUCCIÓN:
La programación extrema o eXtreme Programming (XP) es un enfoque de la
ingeniería de software formulado por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el más
destacado de los proceso ágiles de desarrollo de Software
DESARROLLO
¿Qué es la Programación Extrema o XP?
Es una metodología liviana de desarrollo de software, que contiene un conjunto de
prácticas y reglas empleadas para desarrollar software, se basa en diferentes ideas
acerca de cómo enfrentar ambientes cambiantes. En vez de planificar, analizar y
diseñar para el futuro, hacer todo esto un poco cada vez, a través de todo el proceso
de desarrollo.
OBJETIVOS
Sus objetivos son claros, y están bien definidos como una de las mejores prácticas
de Ingeniería de Software, entre ellos los que se enuncian a continuación:
proyectos.
expectativas del cliente.
está siguiendo un camino correcto o equivocado, evitando retroceder cuando sea
demasiado tarde.
CARACTERÍSTICAS
Las características primarias de la metodología liviana o metodología XP, es que es
una metodología basada en prueba y error para obtener un software que funcione
realmente, Está fundamentada en Principios. Es expresada en forma de 12 Prácticas

3. 2
(conjunto completo, complementándose unas a otras). Las cuales son conocidas
pero su novedad es juntarlas y que está orientada hacia quien produce y usa el
software (el cliente participa muy activamente).
Las ventajas de esta metodología se logran observar al ver Reducidos los costos del
cambio en todas las etapas del ciclo de vida del sistema, combina las que han
demostrado ser las mejores prácticas para desarrollar software, y las lleva al
extremo. Normalmente tienen a un Cliente bien definido que debe formar parte del
equipo central para poder retroalimentar rápidamente y disipar dudas reduciendo
igual tiempos de incertidumbre, sobre todo por que al ser una metodología ágil una
de las características principales es que los requisitos pueden cambiar. El grupo de
trabajo debe ser un grupo muy pequeño y muy integrado (2 - 12 personas).
Fundamentalmente se trabaja en parejas. En cuanto a la formación y las
características de los miembros del equipo, es que cada miembro debe tener
formación elevada y capacidad de aprender.
PRINCIPIOS DEL MÉTODO X.P.
Este método se basa principalmente en 4 valores o principios bien definidos:
1. Simplicidad: La simplicidad consiste en desarrollar sólo el sistema que realmente
se necesita. Implica resolver en cada momento sólo las necesidades actuales.
2. Feedback o Retroalimentación Continua: Una metodología basada en el
desarrollo iterativo de pequeñas partes, con entregas y pruebas frecuentes y
continuas, proporciona un flujo de retro- información valioso para detectar los
problemas o desviaciones.
3. Decisión:
Implica saber tomar decisiones difíciles.
4. Comunicación: Algunos problemas en los proyectos tienen origen en que alguien
no dijo algo importante en algún momento. XP hace casi imposible la falta de

4. 3
comunicación, ya que pone en comunicación directa y continua a clientes y
desarrolladores.
PRÁCTICAS BASADAS EN X.P. Entre los requisitos de esta metodología ágil se
deben de cumplir los siguientes lineamientos para que se considere una metodología
liviana, si falta alguno de estas prácticas, no se podría considerar como una
metodología ágil y mucho menos tradicional:
1. Equipo completo: Forman parte del equipo todas las personas que tienen algo
que ver con el proyecto, incluido el cliente y el responsable del proyecto.
2. Planificación: Se hacen las historias de usuario y se planifica en qué orden se
van a hacer y las mini-versiones. (Normalmente, son entre 20 y 80 historias) La
planificación se revisa continuamente.
3. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus
propias pruebas para validar las mini-versiones.
4. Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas
como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan
algo útil al usuario final y no fragmentos de código que no pueda ver funcionando.
5. Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla
posible. Mantener siempre sencillo el código.
6. Pareja de programadores: Los programadores trabajan por parejas (dos delante
del mismo ordenador) y se intercambian las parejas con frecuencia.
7. Desarrollo guiado por las pruebas automáticas: Se deben realizar programas
de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más
pruebas se hagan, mejor.
8. Integración continua: Deben tenerse siempre un ejecutable del proyecto que
funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse
y probarse. Es un error mantener una versión congelada dos meses mientras se
hacen mejoras y luego integrarlas todas de golpe.
9. El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte
del código. Para eso se hacen las pruebas automáticas.

5. 4
10. Normas de codificación: Debe haber un estilo común de codificación (no
importa cuál), de forma que parezca que ha sido realizado por una única persona.
11. Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan
las distintas partes del programa, de forma que sólo con los nombres se pueda uno
hacer una idea de qué es lo que hace cada parte del programa.
12. Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber días muertos en que no se
sabe qué hacer y que no se deben hacer un exceso de horas otros días. Hay que
trabajar para conseguir el objetivo cercano de terminar una historia de usuario o mini-
versión. En algunas versiones de está metodología se indica que no pueden trabajar
más de 40 horas y que no se deben trabajar horas extras más de dos semanas, esto
con la finalidad de que los programadores estén sanos y saludables para que la
mente puedan trabajar a su máxima capacidad.
Se observa el siguiente gráfico que representa las 12 entidades previamente
definidas.
CICLO DE VIDA
El ciclo de vida ideal de XP consiste de seis fases:
Exploración:

6. 5
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.
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.
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

7. 6
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.
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).
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.
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

8. 7
ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando
no hay presupuesto para mantenerlo.
CONCLUSIÓN:
La metodología XP da lugar a una programación sumamente organizada, cuenta con
una tasa de errores muy pequeña, Propicia la satisfacción del programador, facilita
los cambios, permite ahorrar mucho tiempo y dinero, puede ser aplicada a cualquier
lenguaje de programación. Además el cliente tiene el control sobre las prioridades y
Se hacen pruebas continuas durante el proyecto.
Algunos de los inconvenientes o recomendaciones que se observan es que es
recomendable emplearla solo en proyectos a corto plazo. En caso de fallar, las
comisiones son muy altas. Requiere de un rígido ajuste a los principios de XP. Puede
no siempre ser más fácil que el desarrollo tradicional.
BIBLIOGRAFÍA
Piattini et al., 2007. Análisis y diseño de Aplicaciones Informáticas de Gestión. Una perspectiva
de Ingeniería del Software. Ra-Ma. Junio 2007.
Pressman, 2005. Ingeniería del Software: Un Enfoque Práctico. 6ª Edición. McGraw-Hill, 2005.
Pfleeger, 2002. Ingeniería del Software. Teoría y Práctica. Prentice Hall, 2002.
Sommerville, 2005. Ingeniería del Software. 7ª Edición, Addison-Wesley. Julio 2005.