"UNIVERSIDAD SAN PEDRO

ING. DE SOFTWARE II



Villafuerte Barboza
Julio



METODOLOGA XP

1. Programacin Extrema (Extreme Programming)

1.1. Introduccin

Elegir un proceso gil de desarrollo es uno de los mayores
problemas en un proyecto de software. Una metodologa que permita
lograr un cdigo sin errores, con alta funcionabilidad, manteniendo al
cliente al tanto del proyecto y en plazos de tiempo cmodos, siempre
han sido objetivos ideales que en todo proyecto se pretende
alcanzar. La Metodologa de Programacin Extrema (XP) propone
la manera de alcanzar esos objetivos.
Esta Metodologa consiste en un conjunto de prcticas,
fundamentadas en valores que deben de mantener los participantes
de proyecto que, a manera de trabajo en grupo, pretende
lograr como producto final un software con un muy alto grado
de calidad.
A los largos de los aos la aplicacin de esta metodologa ha dado
los mejores resultados, las etapas que plantea han sido llevadas al
extremo, en muchos lugares del mundo, y en diversos mbitos de la
actividad humana donde se ha necesitado disear un sistema
informtico.
Pero las etapas que recomienda seguir esta metodologa se plantean
de manera sencilla pero a la vez son estrictas, y se inspiran en la
total participacin de los involucrados.




1.2. Conclusiones de introduccin

Metodologa para un gil desarrollo de software.

Programacin basada en los deseos del cliente.

El equipo lo conforman los jefes de proyecto, desarrolladores y
el cliente.

Se rige por valores y principios.


1.3. Objetivos

1.3.1. Objetivo General

Garantizar la Calidad del Software desarrollando, haciendo que
este supere las expectativas del cliente y de su empresa (Mejorar
la productividad), y el proceso de elaboracin de un determinado
sistema informtico.

1.3.2. Objetivos Especficos
Recabar informacin clara, precisa y veraz acerca de la
Metodologa XP.
Plantear ventajas y desventajas de la metodologa.



2. MARCO TERICO


2.1. Caractersticas



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.
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, rescribir 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.
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.








2.2. Roles


Programador

Pieza bsica en desarrollos XP
Ms responsabilidad que en otros
modos de desarrollo
Responsable sobre el cdigo
Responsable sobre el diseo
(refactorizacin, simplicidad)
Responsable sobre la integridad
del sistema (pruebas)
Capacidad de comunicacin
Acepta crticas

Cliente
Pieza bsica en desarrollos XP
Define especificaciones
Influye sin controlar
Confa en el grupo de desarrollo
Define pruebas funcionales

Encargado de
Pruebas

Apoya al cliente en la
preparacin/realizacin de las
pruebas funcionales
Ejecuta las pruebas funcionales y
publica los resultados

Encargado de
Seguimiento(Tracker)

Recoge, analiza y publica
informacin sobre la marcha del
proyecto sin afectar demasiado
el proceso
Supervisa el cumplimiento de la
estimaciones en cada iteracin
Informa sobre la marcha de la
iteracin en curso
Controla la marcha de las pruebas
funcionales, de los errores
reportados, de las
responsabilidades aceptadas y de
las prueba aadidas por los
errores encontrados

Entrenador (Coach)
Experto en XP
Responsable del proceso en su
conjunto
Identifica las desviaciones y
reclama atencin sobre las
mismas
Gua al grupo de forma indirecta
(sin daar su seguridad ni
confianza)
Interviene directamente si es
necesario
Atajar rpidamente el problema

Consultor
Apoya al equipo XP en cuestiones
puntuales

Jefe del Proyecto
Favorece la relacin entre
usuarios y desarrolladores
Confa en el equipo XP
Cubre las necesidades del equipo
XP
Asegura que alcanza sus
objetivos



















2.3. Funcionamiento






















Planeacin
La actividad de planeacin (tambin llamada juego de planeacin) comienza
escuchando actividad para recabar requerimientos que permiten que los
miembros tcnicos del equipo XP entiendan el contexto del negocio para el
software y adquieren la sensibilidad de la salida y caractersticas principales y
funcionalidad que se requieren. Escuchar lleva a la creacin de algunas
historias (tambin llamadas historias del usuario) que describen la salida
necesaria, caractersticas y funcionalidad del software que se va a elaborar.
Los miembros del equipo XP evalan cada historia y le asignan un costo, y un
determinado tiempo. Si se estima que la historia requiere ms tiempo de
desarrollo, se pide al cliente que la descomponga en historias ms chicas y de
nuevo se asigna un valor y costo.
Se llega a un compromiso sobre la entrega (acuerdo sobre las historias por
incluir, la fecha de entrega y otros aspectos del proyecto).
Despus de la primera entrega del proyecto (tambin llamada implemento de
software) el equipo XP calcula la velocidad de ste. La velocidad del proyecto
se usa para ayudar a estimar las fechas de entrega y programar las actividades
para las entregas posteriores, y determinar si se ha hecho un gran compromiso
para todas las historias durante todo el desarrollo del proyecto. Si esto ocurre,
se modifica el contenido de las entregas o se cambian las fechas de entrega
final
A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el
valor de una ya existente, descomponerlas o eliminarlas. Entonces, el equipo
XP reconsidera todas las entregas faltantes y modifica sus planes en
consecuencia.
Diseo
El diseo XP sigue rigurosamente el principio MS (mantenlo sencillo). Un
diseo sencillo siempre se prefiere sobre una representacin ms compleja.
Adems, el diseo gua la implementacin de una historia conforme se escribe.
XP estimula el uso de tarjetas CRC como un mecanismo eficaz para pensar en
el software en un contexto orientado a objetos. Las tarjetas CRC (Clase
Responsabilidad Colaborador) identifican y organizan las clases orientadas a
objetos que son relevantes para el incremento actual de software. Las tarjetas
CRC son el nico producto de trabajo de diseo que se generan como parte
del proceso XP.
Sin el diseo de una historia se encuentra un problema de diseo difcil, XP
recomienda la creacin inmediata de un prototipo operativo de esa porcin del
diseo. Entonces, se implementa y evala el prototipo del diseo, llamado
solucin en punta. El objetivo es disminuir el riesgo cuando comience la
implementacin verdadera y validar las estimaciones originales para la historia
que contiene el problema de diseo.
XP estimula el rediseo, tcnica de construccin que tambin es un mtodo
para la optimizacin del diseo. Fowler describe el rediseo del modo
siguiente:
Rediseo es el proceso mediante el cual se cambia un sistema de
software en forma tal que no altere el comportamiento externo del cdigo,
pero si mejore la estructura interna. Es una manera disciplinada de
limpiar el cdigo que minimiza la probabilidad de introducir errores. En
esencia, cuando se redisea, se mejora el diseo del cdigo despus de
haber sido escrito.
Un concepto central en XP es que el diseo ocurre tanto antes como despus
de que comienza la codificacin. Redisear significa que el diseo se hace de
manera continua conforme se construye el sistema. En realidad, la actividad de
construccin en s misma dar al equipo XP una gua para mejorar el diseo.
Codificacin
Despus de que las historias han sido desarrolladas y de que se ha hecho el
trabajo de diseo preliminar, el equipo no inicia la codificacin, sino que
desarrolla una serie de pruebas unitarias a cada una de las historias que se
van a incluir en la entrega en curso. Una vez creada la prueba unitaria, el
desarrollador est capacitado para centrarse en lo que debe implementarse
para pasar la prueba. Una vez que el cdigo est terminado, se le aplica de
inmediato una prueba unitaria, con lo que se obtiene retroalimentacin
instantnea para los desarrolladores.
Un concepto clave durante la actividad de codificacin (y uno de los aspectos
de los que ms se habla en la XP) es la programacin por parejas. XP
recomienda que dos personas trabajen juntas en una estacin de trabajo con el
objeto de crear cdigo para una historia. Esto da un mecanismo para la
solucin de problemas en tiempo real y para el aseguramiento de la calidad
tambin en tiempo real.
A medida que las parejas de programadores terminan su trabajo, el cdigo que
desarrollan se integra con el trabajo de los dems. En ciertos casos, esto lo
lleva a cabo a diario un equipo de integracin. En otros, las parejas de
programadores tienen la responsabilidad de la integracin. Esta estrategia de
integracin continua ayuda a evitar los problemas de compatibilidad e
interfaces y brinda un ambiente de prueba de humo que ayuda a descubrir a
tiempo los errores.
Pruebas
La creacin de pruebas unitarias antes de que comience la codificacin es un
elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben
implementarse con el uso de una estructura que permita automatizarlas (de
modo que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula
una estrategias de pruebas de regresin, siempre que se modifique el cdigo
(lo que ocurre con frecuencia, dada la filosofa del rediseo en XP).
Esto da el equipo XP una indicacin continua del envase y tambin lanza
seales de alerta si las cosas marchan mal. corregir pequeos problemas
cada cierto nmero de horas toma menos tiempo que resolver problemas
enormes justo antes del plazo final.
Las pruebas de aceptacin XP, tambin llamadas pruebas del cliente son
especificadas por el cliente y se centran es las caractersticas y funcionalidad
generales del sistema que son visibles y revisables por parte del cliente. Las
pruebas de aceptaciones derivan de las historias de los usuarios que se han
implementado como parte de la liberacin del software.







2.4. Ventajas y desventajas

Ventajas Desventajas
Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Solucin de errores de
programas
Versiones nuevas
Implementa una forma de
trabajo donde se
adapte fcilmente a las
circunstancias
Es recomendable emplearlo
solo en proyectos a corto
plazo
Altas comisiones en caso de
fallar
Imposible prever todo antes de
programar
Demasiado costoso e
innecesario



3. CASO PRACTICO

3.1. Descripcin del caso
Tomare el caso de la empresa donde laboro, se trata de la
Empresa Agraria Azucarera Andahuasi S.A.A.
Esta empresa dedicada a la produccin de azcar, cuenta con
diversas reas para su funcionamiento:
rea administrativa
rea de fbrica
rea de campo

Estas reas operan el trabajo de oficina con un sistema llamado
SIGERP, el cual esta implementado en visual net





3.2. Herramientas empleadas de solucin
Se opt por actualizar el sistema

3.3. Planeacin
En la planeacin se tom en cuenta varios elementos:

Historias de usuario
Velocidad del proyecto
Divisin de interacciones
Entregas pequeas
Plan de entregas

3.3.1. Historias de Usuario
Los historiales de usuarios estn divididos de acuerdo al
departamento que laboran, cada departamento desempea
diversas funciones a su cargo.
El usuario es asignado por el Dpto. Sistema los mdulos que van
a tener a su cargo de acuerdo al rea que labore.
Mencionare diversos mdulos que desarrollan laboralmente en
la Empresa:
Mdulo de Ventas
Mdulo de Relaciones Pblicas
Mdulo Recursos Humanos
Mdulo de Saneamiento
Mdulo Auditorio Interna
Mdulo de Contabilidad
Mdulo de Logstica
Mdulo de Cosecha
Mdulo de Mantenimiento
Mdulo de Almacn
Mdulo de Servicio Social
Mdulo Fbrica
Mdulo de Caja
Mdulo de Tesorera
Mdulo de Seguridad Industrial
Mdulo de Campo
Mdulo de Seguro
Mdulo Asesora Legal
Mdulo de Servicios
Mdulo de Trafico


3.3.2. Velocidad del proyecto
El nmero de historias de usuario realizadas por iteracin no fue
una buena medida de la velocidad del proyecto debido que no
todas tenan el mismo nivel de dificultad y por tanto el mismo
requerimiento de horas de desarrollo, adems que la empresa
viene afrontando problemas judiciales.
El horario que labora el personal de oficina es:
Lunes-Viernes Sbados
Horarios
7:00am-12:00pm
2:00pm-5:00pm
7:00-1:00pm

3.3.3. Divisin en interacciones

El proyecto fue dividido en 1 iteraciones que fue de un ao, por
consiguiente se obtuvo un total de cuatro entregas para las
cuales se desarrollaron partes de la aplicacin completamente
funcionales. Este tiempo no fue el adecuado para el trmino del
proyecto.
Esta planeacin de interaccin fue extendida y coordinada con el
jefe del Departamento de Sistemas.
3.3.4. Entregas Pequeas
En el plazo de 1 ao se entregaron los siguientes mdulos:
Mdulo de Recursos Humanos
Mdulo de Cosecha
Mdulo de Logstica
Mdulo de Venta
3.3.5. Plan de Entregas
Se realizaron constantes reuniones.
La tarea de escoger las historias o mdulos a desarrollarse con
mayor prioridad fue realizada por el grupo en conjunto,
incluyendo al cliente, lo cual no gener problemas en las
entregas de los mdulos funcionales.

3.4. Codificacin
Entre los elementos ms importantes que menciona XP referentes
a la codificacin estn:
Cliente siempre presente
El cdigo se escribe siguiendo estndares
Toda la produccin de cdigo debe ser hecha en parejas
Codificar primero la prueba

Cliente siempre presente
En el caso de este proyecto, el cliente no poda desplazarse a
ninguno de los lugares de trabajo de los desarrolladores dado que
deba estar al frente de su negocio.
Comunicacin entre programadores y analistas.
El cdigo se escribe siguiendo estndares
La estandarizacin del cdigo fue asumida desde el mismo
momento en que se inici la codificacin
En el caso de este proyecto se aplicaron todos los estndares con
gran xito debido a dos motivos. En primer lugar, la herramienta
empleada para desarrollar facilitaba el aplicar dichos estndares y
en segundo, que los mismos venan siendo empleados desde
antes por el equipo de desarrollo.
Codificar primero la prueba
Se trata de codificar siempre una prueba antes que el cdigo final,
de la misma manera conforme se avance la codificacin es
recomendable hacer constantes pruebas.
Toda la produccin de cdigo debe ser hecha en parejas
Se debe de trabajar en constante unin de parejas, tanto como los
programadores, analista, y el cliente.

3.5. Pruebas
Las pruebas fueron hechas en los mdulos mencionados de las
Entregas pequeas:

Mdulo de Recursos Humanos
Mdulo de Cosecha
Mdulo de Logstica
Mdulo de Venta
Estos mdulos estn activos y puestos en marchas.
El trabajo sigue ejercindose en la Empresa hasta el trmino del
nuevo y actualiza sistema que permita realizar los procesos
administrativos sin ningn error ni malestar.

























Conclusiones

En la prctica es un poco complicado aplicar al pie de la letra los
postulados de la Metodologa XP si los involucrados no cuentan con
total disponibilidad de tiempo.

La metodologa XP es de uso comn desde hace varios aos de
manera que adquirir informacin acerca de ella resulto sencillo, ya
que la mayora de textos tcnicos y de proyectos realizados por otras
personas hablan de esta metodologa.

La principal ventaja de la metodologa XP est en su alto grado de
adaptabilidad, y su principal desventaja es su elevado costo en caso
de no cumplir las metas.