Una de las metodologías de software.!!!

1. METODOLOGÍAS XP

2. Definición:
Es una metodología de desarrollo de la ingeniería de software formulada por Kent
Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de
software. Al igual que éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad.

3. CARACTERÍSTICAS
1. Desarrollo interactivo e incremental:
Pequeñas mejoras, unas tras otras.
2. Pruebas Unitarias Continuas:
frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se
aconseja escribir el código de la prueba antes de la codificación. Véase, por
ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a
Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas
inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework
orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.

4. 3. Programación en Pareja:
se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. La mayor calidad del código escrito de esta manera -el código es
revisado y discutido mientras se escribe- es más importante que la posible pérdida de
productividad inmediata.
4. Frecuente integración del equipo de programación con el cliente o usuario:
Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
5. Corrección de todos los errores:
Antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

5. 6. Refactorización del código:
Es decir, reescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar
que en la refactorización no se ha introducido ningún fallo.
7. Propiedad del código compartida:
En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de
trabajo distintos, este método promueve el que todo el personal pueda corregir y
extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan
que los posibles errores serán detectados.
8. Simplicidad en el código:
Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá
añadir funcionalidad si es necesario. La programación extrema apuesta que es más
sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizás nunca utilizarlo.

7. CICLO DE DESARROLLO
1. 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.

8. 2. Planeacion de 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.

9. 3. 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.

10. 4. 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).

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

12. 6. Muerte de 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.

13. EJEMPLOS

14. RESUMEN
Es una metodología de desarrollo de la ingeniería de software formulada por Kent
Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de
software. Al igual que éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios
de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y
más realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos después en controlar los cambios en los requisitos. Es una
herramienta que facilita el proceso de conceptualización y análisis de causalidades, así
como el diseño, ejecución, monitoreo y evaluación de programas y proyectos desde
una perspectiva de orientación por objetivos.

15. SUMMARY
It is a development methodology of software engineering made by Kent Beck, author of
the first book on the subject, Extreme Programming Explained: Embrace Change (1999).
It is the highlight of agile software development processes. Like them, extreme
programming differs from traditional methodologies mainly in putting more emphasis
on adaptability in predictability. Proponents of XP consider changing requirements on
the fly is a natural, inevitable and even desirable aspect of project development. They
believe that being able to adapt to changing requirements at any point in the project
life is better and more realistic than trying to define all requirements early in the project
and invest in control efforts after changes in approach one requisitos.Es tool that
facilitates the process of conceptualization and causality analysis and design,
implementation, monitoring and evaluation of programs and projects from the
perspective of goal orientation.

16. RECOMENDACIONES
No aplicar la metodología si existe la posibilidad de no cumplir con los plazos
establecidos en la etapa de planeación, ya que además se incrementaría de gran
manera los costos del proyecto.Es recomendable que se consulten diversas fuentes
bibliográficas para lograr un mayor entendimiento del tema.Se recomienda que antes
de elegir una metodología se analicen sus ventajas y desventajas a fin de que sea la
mas adecuada para el proyecto a realizar.

17. CONCLUSIONES
• En la practica es un poco complicado aplicar “al pie de la letra” los postulados de la
Metodología XP si los involucrados no cuentan con total disponibilidad de tiempo.
• La metodología XP es de uso común desde hace varios años de manera que
adquirir información acerca de ella resulto sencillo, ya que la mayoría de textos
técnicos y de proyectos realizados por otras personas hablan de esta metodología.

18. GLOSARIO DE TÉRMINOS
• REFACTORIZACION:
Se usa a menudo para describir la modificación del código fuente sin cambiar su
comportamiento, lo que se conoce informalmente por limpiar el código.

19. LINKOGRAFIAS
• https://sites.google.com/site/xpmetodologia/
• http://es.slideshare.net/EvelingGiselleCruzVs/metodologia-monografia.
• http://desarrollo-de-software-j.blogspot.pe/2012/03/metodologia-xpprogramacion-
extrema.html.

20. GRACIAS