Metodologia XP (Programacion Extrema).

1. UNIVERSIDAD NACIONAL DE TRUJILLO
SUBSEDE VALLE JEQUETEPEQUE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
INGENIERIA INFORMATICA
________________________________________
MONOGRAFIA
METODOLOGIA AGIL XP (PROGRAMACION EXTREMA)
AUTOR: GARRO PORTALES, HARRY
GUADALUPE – PERU
2013

2. “Dedicamos el presente proyecto a
nuestro Dios, por habernos brindado la
salud y la sabiduría para poder
guiarnos en el proyecto, a nuestros
padres que con su esfuerzo y apoyo
deposita su confianza en estos años
de estudio.”
2

3. INDICE
DEDICATORIA
2
INTRODUCCION
5
1. MARCO TEORICO
6
6
6
6
1.1 Planteamiento del problema
1.2 Solución al Problema
1.3 Desarrollo clásico vs Agíl
2. METODOLOGIA AGIL XP
7
2.1 Objetivo
2.2 Definición Metodología Agíl
2.3 Definición Metodología XP
7
7
7
3. VALORES DE PROGRAMACION EXTREMA
3.1 Comunicación
3.2 Simplicidad
3.3 Retroalimentación
3.4 Coraje
7
7
7
8
8
4. PRACTICAS DE PROGRAMACION EXTREMA
4.1) Practica de codificación
4.2) Practica de Desarrollo
4.3) Practica de Negocio
8
8
9
9
5. ROLES DE PROGRAMACION EXTREMA
9
5.1) Cliente
5.2) Programador
5.3) Encargado de Pruebas
5.4) Encargado de seguimiento
5.5) Jefe de proyecto
5.6) Consultor
6.
9
9
10
10
10
10
10
FASES DE LA PROGRAMACION EXTREMA
6.1)
1 Fase: PLANIFICACION DE PROYECTO
6.1.1) Historia de Usuario
10
10
10
3

4. Ejemplo de historia de Usuario
6.1.2) ReleasePlanning (Plan Lanzamiento)
6.1.3) Iteraciones
6.1.4) La Velocidad del Proyecto
6.1.5) Programación en Parejas
6.2) 2 Fase: DISEÑO
11
12
12
12
12
12
12
12
12
13
13
6.2.1) Diseño Simple
6.2.2) Glosarios de Términos
6.2.3) Riesgos
6.2.4) Funcionabilidad Extra
6.2.5) Refactorizar
6.3) 3 Fase: CODIFICACION
13
6.4) 4 Fase: PRUEBAS
13
7. TARJETAS CRC
14
8. VENTAJAS Y DESVENTAJAS
14
14
14
8.1) Ventajas
8.2 Desventajas
9. CONCLUSIONES
14
10. WEBGRAFIA
14
4

5. INTRODUCCION
Las metodologías ágiles o livianas tienen un origen muy reciente en el
entorno de la ingeniería de software, comparada con las metodologías
tradicionales (pesadas). En la década de los 90, surge Programación
Extrema, mejor conocida como XP, una nueva metodología catalogada
entre las ágiles por sus aportes al manifiesto ágil. Su creador, Kent Beck se
convirtió en el padre de la programación extrema.
Todo en el software cambia. Los requisitos cambian. El diseño cambia. 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.
XP no se basa en principios nuevos, sino que todas, o casi todas, sus
características ya se conocen dentro de la ingeniería del software, las
cuales se complementan para minimizar los problemas que pueden surgir
en todo desarrollo de proyectos software.
5

6. 1. MARCO TEORICO
1.1Planteamiento del problema
Como punto principal hablaremos como es que surgen las metodologías
ágiles o livianas, se podría decir que surgen de la necesidad de resolver
problemas como retrasos continuos, sobrecostes y deficiencias de calidad
o de utilidad que se producían en el desarrollo de software.
La realidad es que la gestión de procesos para el desarrollo de software no
funcionaba en entornos inestables, y másaún cuando los requisitos
cambiaban. Entonces más adelante algunas empresas estaban obteniendo
buenos resultados aplicando metodologías que contravenían la forma de
gestionar proyectos, y empezó a nacer el término de “Agilísimo”, que surge
como modelo desarrollo basado en procesos.
Luego de esto surgen varias metodologías ágiles, una de ella XP
(Programación extrema), surgen debido al entorno muy cambiante.
1.2 Solución al Problema
ELAVORAR UN PLAN DE TRABAJO(método)
Con el claro objetivo de garantizar el cumplimiento de lo planificado en
términos de tiempo, coste y calidad.
PRODUCION DE SOFTWARE A BASE DE PROCESOS
El objetivo es garantizar la calidad del resultado final a través del uso en la
producción de unos procesos de calidad para el desarrollo de software y el
cliente quede satisfecho.
1.3 Desarrollo clásico Vs Agíl
Modelo Clásico
Modelo empleado para proyectos complejos, de grandes magnitudes, lo
cual era complicado cambiar algún requerimiento del software, además
perderíamos tiempo en efectuar dichos cambios.
Modelo ágil
Se basa en la adaptación(Adaptabilidad). Se tiene una visión general de lo
que se desea que haga el software, aunque sin especificar el resultado
final, es posible un cambio de requerimiento en cualquier punto de
desarrollo, este modelo es empleado en proyectos pequeños o medianos.
6

7. 2. METODOLOGIA AGIL XP
2.1 Objetivo
Elaborar grupos pequeños y medianos de construcción de software en
donde los requisitos aún son muy confusos, cambian rápidamente o son
de alto riesgo, es importante hacer notar que esta metodología se
preocupa mucho por que el cliente este conforme.
2.2 Definición de metodología Agíl
Son métodos basados en el desarrollo interactivo, para apoyar este
método se ha creado “Frame Works” o Grupos de trabajo. Además esta
metodología minimiza riesgos ya que el software se desarrolla en
lapsos cortos de tiempo.
2.3 Definición de programación extrema (XP)
Un proceso Ligero, de bajo riesgo, flexible, predecible, científico y
divertido de desarrollar software. Según Kent Beck.
3. VALORES DE PROGRAMACION EXTREMA
Programación extrema resalta una serie de valores que deben ponerse
en práctica, durante el desarrollo del proyecto, son los siguientes:
3.1 Comunicación:
Es muy importante que exista un ambiente de colaboración y
comunicación al interior del equipo de desarrollo (trabajo), así como
la interacción de este con el cliente, Además en XP el cliente se
considera parte del equipo de desarrollo.
3.2) Simplicidad
Se aplica en todos los aspectos de la Programación Extrema, desde
diseños muy sencillos donde lo más relevante, es la funcionalidad
que requiere el cliente, hasta la simplificación de código mediante la
refactorización.
Además
XP
no
usa
recursos
para
actividadescomplejas, solo se desarrolla lo que el cliente demanda,
de la forma más simple.
7

8. 3.3) Retroalimentación
Presente desde el inicio del proyecto, nos ayuda a encaminarlo y
darle forma. Presenta dos sentido, por parte del equipo de trabajo
hacia el cliente, con el fin de informar sobre la evolución del sistema
y desde el cliente hacia el equipo en los aportes sobre construcción
del proyecto.
3.4) coraje
Equipo debe estar preparado para los continuos cambios que se
presentaran. Cada integrante debe tener el valor de exponer los
problemas o dudas que halle en la realización del proyecto. Incluso
con estas variaciones, las jornadas de trabajo deben proporcionar el
máximo rendimiento.
4. PRACTICAS DE PROGRAMACION EXTREMA
A partir de los valores mencionados anteriormente se plantearon
una serie de prácticas que servirán de Guía para los desarrolladores,
que utilizara la metodología extrema en el proyecto.
4.1) Practica de codificación
Cada módulo o porción de código se evalúa para ver su correcto
funcionamiento.
Simplicidad de código y de diseño para producir software fácil
de modificar.
Reingeniería continua para lograr que el código tenga un
diseño óptimo
Desarrollar estándares de codificación, para comunicar ideas
con claridad a través del código.
Desarrollar un vocabulario común, para comunicar las ideas
sobre el código con claridad.
8

9. 4.2) Practica de Desarrollo
Adoptar un método de desarrollo basado en las pruebas
para asegurar que el código se comporta según lo
esperado.
Programación por parejas, para incrementar el
conocimiento, la experiencia y las ideas.
Asumir la propiedad colectiva del código, para que todo el
equipo sea responsable de él.
Integración continua, para reducir el impacto de la
incorporación de nuevas funcionalidades.
4.3) Practica de tienda (Negocio)
Integración de un representante del cliente en el equipo,
para encauzar las cuestiones de negocio del sistema de
forma directa, sin retrasos o pérdidas por intermediación.
Adoptar el juego de la planificación para centrar en la
agenda el trabajo más importante.
Entregas regulares y frecuentes para satisfacer la inversión
del cliente.
Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.
5.ROLES DE PROGRAMACION EXTREMA
5.1) Cliente
Define especificaciones (historia de Usuario)
Influye sin controlar
Confía en el grupo de desarrollo
5.2) Programador
Responsable sobre el código
Responsable sobre el diseño (refactorización, simplicidad)
Responsable sobre la integridad del sistema (pruebas)
Capacidad de comunicación (par de programadores)
Acepta críticas (código colectivo)
9

10. 5.3) Encargado de pruebas
Apoya al cliente en la preparación/realización de las pruebas
funcionales.
Ejecuta las pruebas funcionales y publica los resultados.
5.4) Encargado de seguimiento
Recoge, analiza y publica información sobre la marcha del proyecto
sin afectar demasiado el proceso
Supervisa el cumplimiento de la estimaciones en cada iteración
Informa sobre la marcha de la iteración en curso
5.5) Jefe de Proyecto
Favorece la relación entre usuarios y desarrolladores
Asegura que alcanza sus objetivos
5.6) Consultor
Apoya al equipo XP en cuestiones puntuales
6. FASES DE LA PROGRAMACION EXTREMA
Existen 4 fases en XP, según Kent Beck las mencionaremos.
6.2)
1 Fase: PLANIFICACION DE PROYECTO
6.1.1) Historia de Usuario
El usuario
decide las tareas que realizara la aplicación, el
planeamiento también se desarrolla durante todo el proyecto. Las
historias de usuario son usadas para dar a conocer los
requerimientos del sistema al equipo de desarrollo. Son pequeños
texto en los que el cliente describe una actividad que realizara el
sistema, debe ser clara y sencilla. Es necesario que el cliente o
algún representante estén disponibles, para solucionar algunas
dudas. Las historias de usuario también son utilizadas para estimar el
tiempo que el equipo de desarrollo tomará para realizar las entregas.
10

11. En una entrega se puede desarrollar una o varias historias de
usuario, esto depende del tiempo que demore la
implementación de cada una de las mismas, algo importante a
Tener en cuenta es:
Trozos de funcionalidad que aportan valor.
Se les asignan tareas de programación con un número de
horas de desarrollo.
Deben ser claras y precisas.
Ejemplo de Historia de Usuario.

Numero de Historia
1
Nombre Historia
Venta
Fecha
25/11/2013
Entrevistado
Clara Ramírez Núñez
Tiempo estimado
16 horas
Descripción
El cliente se acerca con los productos, vendedor evalúa
monto a pagar, vendedor pide pago de cada uno de los
productos, cliente entrega pago,
vendedor registra
yevalúa si hay vuelto. Entrega producto y se registra
venta es opcional generar factura de ser necesaria o así
le pide el cliente.
Información de factura:
-Número Factura, código, Ruc
-Nombre Producto, código
-Precio Producto.
-Pago Total etc.
11

12. 6.1.2) ReleasePlanning (Plan Lanzamiento)
Después de tener ya definidas las historias de usuario es necesario
crear un plan de publicaciones, 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.
6.1.3) Iteraciones
Aproximadamente 1-4 semanas de duración. Al comienzo de cada
iteración los clientes deben seleccionar las historias de usuario
definidas en el "Releaseplanning" que serán implementadas.
6.1.4) 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.
6.1.5) Programación en Parejas:
La programación en parejas pues incrementa la productividad y la
calidad del software desarrollado.
6.2) 2 Fase: DISEÑO
6.2.1) Diseño Simple
Conseguir diseños simples y sencillos. Hacerlo todo lo menos
complicado posible para conseguir un diseño fácilmente.
6.2.2) 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.
6.2.3) Riesgos
Si surgen problemas potenciales durante el diseño, utilizar una pareja
para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
12

13. 6.2.4) Funcionabilidad 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.
6.2.5) Refactorizar
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.
6.3) 3 Fase: CODIFICACION
El cliente es una parte más del equipo de desarrollo, su presencia es
indispensable en las distintas fases de XP. 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. Tendrá que estar
presente cuando se realicen los test que verifiquen que la historia
implementada cumple la funcionalidad especificada.
6.4) 4 Fase: PRUEBAS
Hacer un test (Pruebas) nos permite comprobar el funcionamiento de
los códigos que vayamos implementando. El uso de los test en XP es el
siguiente:
Test de aceptación. Los test mencionados anteriormente sirven
para evaluar las distintas tareas en las que ha sido dividida una
historia de usuario.
Hay que someter a test las distintas clases del sistema
Se deben crear los test que pasarán los códigos antes de
implementarlos
Un punto importante es crear test que no tengan ninguna
dependencia del código que en un futuro evaluará.
13

14. 7. TARJETAS CRC
Representa a una clase es cualquier, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que
realizan, sus atributos y métodos. Los colaboradores de una clase son
las demás clases con las que trabaja en conjunto para llevar a cabo
sus responsabilidades.
8. VENTAJAS Y DESVENTAJAS
8.1) Ventajas
Programación organizada.
Menor taza de errores.
8.2 Desventajas
Es recomendable emplearlo solo en proyectos a corto plazo.
9. CONCLUSIONES
La programación extrema puede aportar nuevas formas de buscar y
optimizar el modelo de desarrollo de software.
Una de las cualidades más destacables de XP es su sencillez, tanto
en su aprendizajecomo en su aplicación, reduciendo así los costos
de implantación en un equipo de desarrollo.
10. WEBGRAFIA
A continuación se muestra la fuente de donde se recopilo la información.
http://www.dosideas.com/noticias/metodologias/822-una-introduccion-aextreme-programming.html
http://www.ecured.cu/index.php/Programaci%C3%B3n_Extrema_(XP)
14