UNIVERSIDAD DE HUANUCO

SEDE-TINGO MARIA




FACULTAD DE INGENIERIA DE SISTEMAS E
INFORMATICA



TEMA: METODOLOGIA XP



CURSO: TALLER DE PROGRAMACIN II


ALUMNO: RUIZ ARCE NOLI BILDAD


DOCENTE: NOEL JUIPA CAMPO


SEMESTRE: 2014- I




TINGO MARIA
2014

METODOLOGIA XP



INTRODUCCION

Extreme Programming (XP) surge como una nueva manera de encarar proyectos de
implicidad y agilidad. Las metodologas de desarrollo de software tradicionales (ciclo de
vida en cascada, evolutivo, en espiral, iterativo, etc.) aparecen, comparados con los
nuevos mtodos propuestos en XP, como pesados y poco eficientes. La crtica ms
frecuente a estas metodologas clsicas es que son demasiado burocrticas. Hay tanto
que hacer para seguir la metodologa que, a veces, el ritmo entero del desarrollo se
retarda. Como respuesta a esto, se ha visto en los ltimos tiempos el surgimiento de
Metodologas giles. Estos nuevos mtodos buscan un punto medio entre la ausencia
de procesos y el abuso de los mismos, proponiendo un proceso cuyo esfuerzo valga la
pena. Software, proponiendo una metodologa basada esencialmente en la Los mtodos
giles cambian significativamente algunos de los nfasis de las metodologas clsicas

Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave
para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose
por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se
basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin
fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje
para enfrentar los cambios. XP se define como especialmente adecuada para proyectos
con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico.


























PROGRAMACION EXTREMA (XP)


La programacin extrema o EXtreme Programming (XP) es un enfoque de la Ingeniera de
Software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change 1999. Es el ms destacado de los procesos
giles de desarrollo de software.
Al igual que stos, la programacin extrema se diferencia de las metodologas
tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Los defensores de 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 aproximacin mejor y ms realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios
en los requisitos.
Resumiendo: Se puede definir la programacin extrema como la adopcin de las
mejores Metodologas de Desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinmica durante el Ciclo de Vida del Software.


QU ES PROGRAMACIN EXTREMA O XP?
La Programacin Extrema PX, mejor conocida por su nombre en ingls Extreme
Programming (PX), es una de las llamadas Metodologas giles de desarrollo de software
ms exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de
software hace aproximadamente unos seis aos, y ha causado un gran revuelo entre el
colectivo de programadores del mundo. Kent Beck, su autor, es un programador que ha
trabajado en mltiples empresas y que actualmente lo hace como Programador en la
conocida empresa automovilstica DaimlerChrysler.
Con sus teoras ha conseguido el respaldo de gran parte de la industria del software y el
rechazo de otra parte. La programacin extrema se basa en la simplicidad, la
comunicacin y el reciclado continuo de cdigo, para algunos no es ms que aplicar una
pura lgica.

Metodologa liviana de desarrollo de software
Conjunto de prcticas y reglas empleadas para desarrollar software
Basada en diferentes ideas acerca de cmo enfrentar ambientes muy cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y disear para el futuro distante, hacer todo esto un
poco cada vez, a travs de todo el proceso de desarrollo






OBJETIVOS.
Establecer las mejores prcticas de Ingeniera de Software en los desarrollo de
proyectos.
Mejorar la productividad de los proyectos.
Garantizar la Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.


CONTEXTO XP
Cliente bien definido
Los requisitos pueden (y van a) cambiar
Grupo pequeo y muy integrado (mximo 12 personas
Equipo con formacin elevada y capacidad de aprender


CARACTERSTICAS XP

DESARROLLO ITERATIVO E INCREMENTAL: pequeas mejoras, unas tras
otras.

PRUEBAS UNITARIAS CONTINUAS: frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de
la prueba antes de la codificacin. Vase, 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 inspir en SUnit, el primer framework orientado a realizar tests,
realizado para el lenguaje de programacin Smalltalk.


PROGRAMACIN EN PAREJAS: se recomienda que las tareas de desarrollo se
lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor
calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido
mientras se escribe- es ms importante que la posible prdida de productividad
inmediata.

FRECUENTE INTEGRACIN DEL EQUIPO DE PROGRAMACIN CON EL
CLIENTE O USUARIO. Se recomienda que un representante del cliente trabaje
junto al equipo de desarrollo.

CORRECCIN DE TODOS LOS ERRORES ANTES DE AADIR NUEVA
FUNCIONALIDAD. Hacer entregas frecuentes.


REFACTORIZACIN DEL CDIGO: es decir, reescribir ciertas partes del cdigo
para aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha
introducido ningn fallo.



PROPIEDAD DEL CDIGO COMPARTIDA: en vez de dividir la responsabilidad
en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo
promueve el que todo el personal pueda corregir y extender cualquier parte del
proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores
sern detectados.

SIMPLICIDAD EN EL CDIGO: es la mejor manera de que las cosas funcionen.
Cuando todo funcione se podr aadir funcionalidad si es necesario. La
programacin extrema apuesta que es ms sencillo hacer algo simple y tener un
poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y
quizs nunca utilizarlo.



PRCTICAS BSICAS DE LA PROGRAMACIN EXTREMA


Para que todo esto funcione, la programacin extrema se basa en doce "prcticas
bsicas" que deben seguirse al pie de la letra. Dichas prcticas estn definidas.

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.}

PLANIFICACIN: Se hacen las historias de usuario y se planifica en qu orden se
van a hacer y las mini-versiones. La planificacin se revisa continuamente.

TEST DEL CLIENTE: El cliente, con la ayuda de los desarrolladores, propone sus
propias pruebas para validar las mini-versiones.

VERSIONES PEQUEAS: Las mini-versiones deben ser lo suficientemente
pequeas como para poder hacer una cada pocas semanas. Deben ser versiones
que ofrezcan algo til al usuario final y no trozos de cdigo que no pueda ver
funcionando.

DISEO SIMPLE: Hacer siempre lo mnimo imprescindible de la forma ms
sencilla posible. Mantener siempre sencillo el cdigo.

PAREJA DE PROGRAMADORES: Los programadores trabajan por parejas (dos
delante del mismo ordenador) y se intercambian las parejas con frecuencia (un
cambio diario).

DESARROLLO GUIADO POR LAS PRUEBAS AUTOMTICAS: Se deben
realizar programas de prueba automtica y deben ejecutarse con mucha
frecuencia. Cuantas ms pruebas se hagan, mejor.

INTEGRACIN CONTINUA: Deben tenerse siempre un ejecutable del proyecto
que funcione y en cuanto se tenga una nueva pequea funcionalidad, debe
recompilarse y probarse. Es un error mantener una versin congelada dos meses
mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo,
no se sabe qu es lo que falla de todo lo que hemos metido.

EL CDIGO ES DE TODOS: Cualquiera puede y debe tocar y conocer cualquier
parte del cdigo. Para eso se hacen las pruebas automticas.

NORMAS DE CODIFICACIN: Debe haber un estilo comn de codificacin (no
importa cul), de forma que parezca que ha sido realizado por una nica persona.

METFORAS: Hay que buscar unas frases o nombres que definan cmo
funcionan las distintas partes del programa, de forma que slo con los nombres se
pueda uno hacer una idea de qu es lo que hace cada parte del programa. Un
ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los
programadores (y el cliente) sepan de qu estamos hablando y que no haya mal
entendidos.

RITMO SOSTENIBLE: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber das muertos en que no se
sabe qu hacer y que no se deben hacer un exceso de horas otros das. Al tener
claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para
conseguir el objetivo cercano de terminar una historia de usuario o mini-versin.

VALORES XP

XP se basa en cuatro valores, que deben estar presentes en el equipo de desarrollo para
que el proyecto tenga xito

COMUNICACIN
Muchos de los problemas que existen en proyectos de software (as como en
muchos otros mbitos) se deben a problemas de comunicacin entre las personas.
La comunicacin permanente es fundamental en XP. Dado que la documentacin
es escasa, el dilogo frontal, cara a cara, entre desarrolladores, gerentes
comunicacin tiene que estar presente durante todo el proyecto.

SIMPLICIDAD
XP, como metodologa gil, apuesta a la sencillez, en su mxima expresin.
Sencillez en el diseo, en el cdigo, en los procesos, etc. La sencillez es esencial
para que todos puedan entender el cdigo, y se trata de mejorar mediante
recodificaciones continuas.


RETROALIMENTACIN
La retroalimentacin debe funcionar en forma permanente. El cliente debe brindar
retroalimentacin de las funciones desarrolladas, de manera de poder tomar sus
comentarios para la prxima iteracin, y para comprender, cada vez ms, sus
necesidades.
Los resultados de las pruebas unitarias son tambin una retroalimentacin
permanente que tienen los desarrolladores acerca de la calidad de su trabajo.

CORAJE
Cuando se encuentran problemas serios en el diseo, o en cualquier otro aspecto,
se debe tener el coraje suficiente como para encarar su solucin, sin importar que
tan difcil sea. Si es necesario cambiar completamente parte del cdigo, hay que
hacerlo, sin importar cuanto tiempo se ha invertido previamente en el mismo.


ACTIVIDADES DE XP

CODIFICAR
Es necesario codificar y plasmar nuestras ideas a travs del cdigo. En
programacin, el cdigo expresa la interpretacin del problema, as podemos
utilizar el cdigo para comunicar, para hacer comunes las ideas, y por tanto para
aprender y mejorar.
HACER PRUEBAS
Las caractersticas del software que no pueden ser demostradas mediante
pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo
implementado es lo que en realidad se tena en mente. Las pruebas nos indican
que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que
pudiese originar un fallo en nuestro sistema, entonces habremos acabado por
completo.



ESCUCHAR
En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas
cosas que las personas de negocios piensan que son interesantes. Si ellos
pudieran programarse su propio software para qu nos querran?".
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y
tenemos que preguntar a quin necesita la informacin. Tenemos que escuchar a
nuestros clientes cules son los problemas de su negocio, debemos de tener una
escucha activa explicando lo que es fcil y difcil de obtener, y la realimentacin
entre ambos nos ayudan a todos a entender los problemas.
DISEAR
El diseo crea una estructura que organiza la lgica del sistema, un buen diseo
permite que el sistema crezca con cambios en un solo lugar. Los diseos deben
de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo
apropiado es dividirla en varias. Si hay fallos en el diseo o malos diseos, estos
deben de ser corregidos cuanto antes.
Resumiendo las actividades de Xp: Tenemos que codificar porque sin cdigo no
hay programas, tenemos que hacer pruebas porque sin pruebas no sabemos si
hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no
sabemos que codificar ni probar, y tenemos que disear para poder codificar,
probar y escuchar indefinidamente.


CICLO DE VIDA
El ciclo de vida de Xp se enfatiza en el carcter interactivo e incremental del desarrollo.
Las iteraciones son relativamente cortas ya que se piensa que entre ms rpido se le
entreguen desarrollos al cliente, ms retroalimentacin se va a obtener y esto va a
representar una mejor calidad del producto a largo plazo. Existe una fase de anlisis
inicial orientada a programar las iteraciones de desarrollo y cada iteracin incluye diseo,
codificacin y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.
La siguiente figura muestra las fases en las que se subdivide el ciclo de vida Xp:
CICLO DE VIDA DE EXTREME PROGRAMMING

FASE DE LA EXPLORACIN
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de inters para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologas y prcticas que se
utilizarn en el proyecto.

Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo. La fase de exploracin toma de pocas
semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los
programadores con la tecnologa.

FASE DEL PLANEAMIENTO

Se priorizan las historias de usuario y se acuerda el alcance del release. Los
programadores estiman cunto esfuerzo requiere cada historia y a partir de all se
define el cronograma. La duracin del cronograma del primer release no excede
normalmente dos meses. La fase de planeamiento toma un par de das. Se deben
incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa
de planeamiento se realiza a un nmero de iteraciones, cada una toma de una a
cuatro semanas en ejecucin. La primera iteracin crea un sistema con la
arquitectura del sistema completo. Esto es alcanzado seleccionando las historias
que harn cumplir la construccin de la estructura para el sistema completo. El
cliente decide las historias que se seleccionarn para cada iteracin. Las pruebas
funcionales creadas por el cliente se ejecutan al final de cada iteracin. Al final de
la ltima iteracin el sistema est listo para produccin.

FASE DE PRODUCCIN
Requiere prueba y comprobacin extra del funcionamiento del sistema antes de
que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden
todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el
release actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a
tres semanas. Las ideas y las sugerencias pospuestas se documentan para una
puesta en prctica posterior por ejemplo en la fase de mantenimiento. Despus de
que se realice el primer release productivo para uso del cliente, el proyecto de Xp
debe mantener el funcionamiento del sistema mientras que realiza nuevas
iteraciones.





FASE DE MANTENIMIENTO

Requiere de un mayor esfuerzo para satisfacer tambin las tareas del cliente. As,
la velocidad del desarrollo puede desacelerar despus de que el sistema est en
la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva
gente y cambiar la estructura del equipo.

FASE DE MUERTE
Es cuando el cliente no tiene ms 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 documentacin final del
sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto
tambin ocurre cuando el sistema no genera los beneficios esperados por el
cliente o cuando no hay presupuesto para mantenerlo.

ACTORES Y RESPONSABILIDADES DE XP
Existen diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y
propsitos durante el proceso:
PROGRAMADOR (PROGRAMMER)
Responsable de decisiones tcnicas
Responsable de construir el sistema
Sin distincin entre analistas, diseadores o codificadores
En Xp, los programadores disean, programan y realizan las pruebas
CLIENTE (CUSTOMER)
Es parte del equipo
Determina qu construir y cundo
Escribe tests funcionales para determinar cundo est completo un determinado
aspecto
ENTRENADOR (COACH)
El lder del equipo - toma las decisiones importantes
Principal responsable del proceso
Tiende a estar en un segundo plano a medida que el equipo madura
RASTREADOR (TRACKER)
Metric Man
Observa sin molestar
Conserva datos histricos
PROBADOR (TESTER)
Ayuda al cliente con las pruebas funcionales
Se asegura de que los tests funcionales se ejecutan


VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING

VENTAJAS:
Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Facilita los cambios.
Permite ahorrar mucho tiempo y dinero.
Puede ser aplicada a cualquier lenguaje de programacin.
El cliente tiene el control sobre las prioridades.
Se hacen pruebas continuas durante el proyecto


DESVENTAJAS:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
Requiere de un rgido ajuste a los principios de XP
Puede no ser siempre ser ms fcil que es desarrollo tradicional.

CONCLUSIONES
Apostolado de metodologas exitosas
Aporte de la experiencia prctica a los modelos tericos
Enfoque de conjunto de prcticas como rompecabezas
Tecnologa en expansin
Importancia de revisitar las metodologas desde la experiencia prctica



















BIBLIOGRAFIA

Metodologas agiles.
EXTREME PROGRAMMING (XP)
(Clemente Mndez Javier, Rodrguez Cotorruelo Enrique)

Extreme Programming from a CMM Perspective Mark C. Paulk, Software Engineering
Institute IEEE SOFTWARE, November/December 2001

Reglas y Prcticas en eXtreme Programming
Ing. Jos Joskowicz

Metodologas giles para el desarrollo de software: Xtreme Programming (XP)
Patricio Letelier y M Carmen Penads

WEBGRAFIA



The Case Against Extreme Programming
Matt Stephens January 26, 2003 Software Reality
http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp
www.xprogramming.com/xpmag/whatisxp.htm.

Programacin Extrema
http://www.ecured.cu/index.php/Programaci%C3%B3n_Extrema_(XP)
PROGRAMACION EXTREMA XP
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
METODOLOGA EXTREME PROGRAMMING (XP)
http://ingsoftware072301.obolog.es/metodologia-xp-2012877