Académique Documents
Professionnel Documents
Culture Documents
Bachilleres:
Bustamante Dayana C.I: 22.983.709
Rodrguez Jean C. C.I: 21.169.047
INTRODUCCIN
METODOLOGAS GILES
METODOLOGA XP
Segn Kent Beck 1999
ORIGEN DE LA METODOLOGA XP
La programacin extrema o eXtreme Programming (XP) es una metodologa de
desarrollo de la ingeniera de software formulada 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. Se puede considerar
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.
CARACTERSTICAS DE LA METODOLOGA XP
Se diferencia de las metodologas tradicionales principalmente en que pone
ms nfasis en la adaptabilidad que en la previsibilidad.
Se aplica de manera dinmica durante el ciclo de vida del software.
Es capaz de adaptarse a los cambios de requisitos.
Los individuos e interacciones son ms importantes que los procesos y
herramientas.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y
las herramientas.
La gente es el principal factor de xito de un proyecto software. Es ms
importante construir un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que el equipo se adapte
automticamente. Es mejor crear el equipo y que ste configure su propio entorno
de desarrollo en base a sus necesidades.
Software que funcione es ms importante que documentacin exhaustiva.
Desarrollar software que funciona ms que conseguir una buena
documentacin.
La regla a seguir es no producir documentos a menos que sean necesarios de
forma inmediata para tomar una decisin importante. Estos documentos deben ser
cortos y centrarse en lo fundamental.
VALORES DE LA METODOLOGA XP
Los Valores originales de la programacin extrema son: simplicidad,
comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue
aadido en la segunda edicin de Extreme Programming Explained. Los cinco
valores se detallan a continuacin:
SIMPLICIDAD:
La simplicidad es la base de la programacin extrema. Se simplifica el diseo
para agilizar el desarrollo y facilitar el mantenimiento.
Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de
diferentes desarrolladores hace que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la
manera de mantener el cdigo simple a medida que crece.
Tambin se aplica la simplicidad en la documentacin, de esta manera el
cdigo debe comentarse en su justa medida, intentando eso s que el cdigo est
auto-documentado. Para ello se deben elegir adecuadamente los nombres de las
variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del
cdigo ni el tiempo de desarrollo gracias a las herramientas de autocompletado y
refactorizacin que existen actualmente.
Aplicando la simplicidad junto con la autora colectiva del cdigo y la
programacin por parejas se asegura que cuanto ms grande se haga el proyecto,
todo el equipo conocer ms y mejor el sistema completo.
COMUNICACIN:
La comunicacin se realiza de diferentes formas. Para los programadores el
cdigo comunica mejor cuanto ms simple sea.
PASOS DE LA METODOLOGA XP
Los Pasos fundamentales inmersos en las fases del mtodo son:
Desarrollo iterativo e incremental: Pequeas mejoras, unas tras otras.
Pruebas unitarias continuas: Son frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el
cdigo de la prueba antes de la codificacin.
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 compartido: 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 del 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.
La simplicidad y la comunicacin son extraordinariamente complementarias.
Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe
hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste,
lo que lleva a una comunicacin ms completa, especialmente si se puede reducir
el equipo de programadores.
FASES DE LA METODOLOGA XP
Segn Kent Beck 1999
Fase II - Diseo
Diseos Simples:
La metodologa XP sugiere que hay que conseguir diseos simples y sencillos.
Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseo fcilmente entendible e implemntable que a la larga costar menos tiempo
y esfuerzo desarrollar.
Glosarios de Trminos:
Usar glosarios de trminos y una correcta especificacin de los nombres de
mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores
ampliaciones y la reutilizacin del cdigo.
Riesgos:
Si surgen problemas potenciales durante el diseo, XP sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al mximo el riesgo
que supone ese problema.
Funcionabilidad extra:
Nunca se debe aadir funcionalidad extra al programa aunque se piense que
en un futuro ser utilizada. Slo el 10% de la misma es utilizada, lo que implica
que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar:
Refactorizar es mejorar y modificar la estructura y codificacin de cdigos ya
creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos
cdigos para procurar optimizar su funcionamiento. Es muy comn rehusar
cdigos ya creados que contienen funcionalidades que no sern usadas y diseos
obsoletos.
Fase IV - Pruebas
Uno de los pilares de la metodologa XP es el uso de test para comprobar el
funcionamiento de los cdigos que vayamos implementando. El uso de los test en
XP es el siguiente:
Se deben crear las aplicaciones que realizarn los test con un entorno de
desarrollo especfico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los
mtodos ms triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos;
en el apartado anterior se explic la importancia de crear antes los test que
el cdigo.
Un punto importante es crear test que no tengan ninguna dependencia del
cdigo que en un futuro evaluar.
Como se coment anteriormente los distintos test se deben subir al
repositorio de cdigo acompaados del cdigo que verifican.
Test de aceptacin. 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 aplicacin no demasiado
extensas, no se harn test que analicen partes de las mismas, sino que las
pruebas se realizarn para las funcionalidades generales que debe cumplir
el programa especificado en la descripcin de requisitos.
Fases de la Metodologa XP
CONCLUSIN
Existen numerosas
metodologas
Se caracteriza por
ser rgida
Se centran en el
control del proceso
Simplicidad
Comunicacin
Retroalimentacin
Coraje o Valenta
1
3
5
7
Desarrollo iterativo
e incremental
Programacin en
parejas
Correccin de todos los
errores antes de aadir
nueva funcionalidad
2
4
6
8
Pruebas unitarias
continuas
Frecuente integracin del
equipo de programacin
con el cliente
Refactorizacin del
cdigo
Simplicidad del
cdigo
1
3
5
Historias de
usuario
Iteraciones
Programacin en
Parejas
2
4
6
Release Planning
La Velocidad del
Proyecto
Reuniones Diarias
1
3
Diseos Simples
Riesgos
2
4
Refactorizar
Glosarios de
Trminos
Funcionabilidad
extra
3
5
4
6
Test de aceptacin
- Programacin organizada
Ventajas de XP
Desventajas de
XP