programingxtrema rup

7/21/2019 ProgramingXtrema RUP

1/33

UNIVERSIDAD NACIONAL DE TRUJILLOFACULTAD DE INGENIERA

E.A.P INGENI ERIA DE SISTEMASSede Valle Jequetepeque

METODLOGIAS GILES PARA EL DESARROLLO DE SOFTWARE:PROGRAMACIN EXTREMA XP (EXTREME PROGRAMMING)

AUTORES:

CEDRON FLORIAN, Alessandra Mirella

CHOLAN CABANILLAS, Maguin AlfredoDAVILA VICENCIO, Mara Raysa

NORIEGA CHAFLOQUE, Cesar Gustavo

TERAN CRUZ, Juan Gerardo

DOCENTE:

Ing. Mg. JUAN PEDRO SANTOS FERNNDEZ

GUADALUPE- PER

2015


2/33

1

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS Cedrn, Choln, Dvila, Noriega & Tern

Dedicamos este trabajo al esfuerzo de nuestros

padres para darnos la mejor educacin, y hacen

posible que nosotros seamos mejores personas

en la sociedad.


3/33

2



INTRODUCCION

Las metodologas agiles tienen un origen reciente en el entorno de la ingeniera de software

comparada con las mitologas pesadas. Su origen est ligado a los constantes inconvenientes

que se presentaban en proyectos con algunas caractersticas, en los cuales la utilizacin de

las metodologas pesadas era motivo de fracaso.

En la dcada de los 90, surge Xtreme Programming, mejor conocida como XP, una nueva

metodologa catalogada entre las agiles por sus aportes al manifiesto gil. Su creador, Kent

Beck se convirti en el padre de la programacin extrema.


4/33

CAPTULO I:

MARCO TERICO


5/33

2



1.1.METODOLOGA GIL

Aprincipios de la dcada del 90, surgi un enfoque que fue bastanterevolucionario

para su momento ya que iba en contra de toda creencia de que mediante procesos

altamente definidos se iba a lograr obtener software en tiempo, costo y con larequerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a

conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid

Application Development. RAD consista en un entorno de desarrollo altamente

productivo, en el que participaban grupos pequeos de programadores utilizando

herramientas que generaban cdigo en forma automtica tomando como entradas

sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos

en pos de la agilidad en los procesos de desarrollo.

La historia de las Metodologas giles y su apreciacin como tales en la comunidad

de la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas

utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente de Kent

Beck, tomando ideas recopiladas junto a Ward Cunningham.

Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler

Comprehensive Compensation (C3) payroll system. Dada la poca calidad del sistemaque se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero

utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema,

que administra la liquidacin de aproximadamente 10.000 empleados, y consiste de

2.000 clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi

respetando el calendario propuesto. Como consecuencia del xito de dicho proyecto,

Kent Beck dio origen a XP iniciando el movimiento de metodologas giles al que se

anexaran otras metodologas surgidas mucho antes que el propio Beck fueraconvocado por Chrysler.

Es as como que este tipo de metodologas fueron inicialmente llamadas

metodologas livianas, sin embargo, an no contaban con una aprobacin pues se

le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el


6/33

3



pasar de los aos, en febrero de 2001, tras una reunin

celebrada en Utah-EEUU, nace formalmente el trmino gil aplicado al desarrollo

de software. En esta misma reunin participan un grupo de 17 expertos de la industria

del software, incluyendo algunos de los creadores o impulsores de metodologas de

software con el objetivo de esbozar los valores y principios que deberan permitir a

los equipos desarrollar software rpidamente y respondiendo a los cambios que

puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los

procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y

dirigidos por la documentacin que se genera en cada una de las actividades

desarrolladas.

Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro,dedicada a promover los conceptos relacionados con el desarrollo gil de software y

ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida

fue el Manifiesto gil, un documento que resume la filosofa gil.

1.2.DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES

La Tabla N 1 recoge esquemticamente las principales diferencias de las

metodologas giles con respecto a las tradicionales (no giles). Estas diferencias

que afectan no slo al proceso en s, sino tambin al contexto del equipo as como a

su organizacin.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se

desarrolle resulta una idea interesante. Estas metodologas pueden involucrar

prcticas tanto de metodologas giles como de metodologas tradicionales. De esta

manera podramos tener una metodologa para cada proyecto, la problemtica sera

definir cada una de las prcticas, y en el momento preciso definir parmetros para

saber cul usar.


7/33

4



Es importante tener en cuenta que el uso de un mtodo

gil no es para todos. Sin embargo, una de las principales ventajas de los mtodos

giles es su peso inicialmente ligero y por eso las personas que no estn

acostumbradas a seguir procesos encuentran estas metodologas bastante agradables.

1.3.EXTREME PROGRAMMING(XP)

XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de

metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo

de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio

comienzo el mismo Beck en. Inclusive Addison-Wesley ha creado una serie de libros

denominada The XP Series.

La imagen mental de Beck al crear XP era la de perillas en un tablero de control. Cada

perilla representaba una prctica que de su experiencia saba que trabajaba bien.

Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As

fue como dio inicio a XP.


8/33

5



XP es una metodologa gil centrada en potenciar las

relaciones interpersonales como clave para el xito en el 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. A

continuacin presentaremos las caractersticas esenciales de XP organizadas en los

tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

1.4.HISTORIA

La Programacin Extrema, como proceso de creacin de software diferente al

convencional, nace de la mano de Kent Beck (gur de la XP y autor de los libros ms

influyentes sobre el tema).

Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de

nminas, pero sin demasiado xito por parte de la gente que tena en el proyecto. El

verano de 1996, Beck entr en nmina en la compaa y se le pidi de hacer estaaplicacin como trabajo. Es en esta aplicacin cuando nace la Programacin Extrema

como tal.

Beck reconoci que el proceso (o metodologa) de creacin de software o la carencia

de este era la causa de todos los problemas y lleg a la conclusin que para

proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en

la estructura o manera de hacer de los programadores, los cuales se tenan queacomodar al cambio a realizar.

l tena varias ideas de metodologas para la realizacin de programas que eran

cruciales para el buen desarrollo de cualquier sistema.


9/33

6



Las ideas primordiales de su sistema las comunic en

la revista C++ Magazineen una entrevista que sta le hizo el ao 1999. En sta deca

que l estaba convencido que la mejor metodologa era un proceso que enfatizase la

comunicacin dentro del equipo, que la implementacin fuera sencilla, que el usuario

tena que estar muy informado e implicado y que la toma de decisiones tena que ser

muy rpida y efectiva.

Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward

Cunningham o Ron Jeffries entre otros) de la Programacin Extrema, fueron a la web

Portland Pattern Repositoryy empezaron a hablar de ella y promocionarla, de lo que

era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin

que tenan y en cada pgina que, poco o mucho hablara de temas de programacin.Este hecho, lleg a molestar a buena parte de la comunidad que intentaba discutir

sobre temas de programacin. Fue tanta esta molestia que naci el fenmeno XP Free

Zone (zona libre de XP) en determinadas webs como peticin de no hablar de

Programacin Extrema en ella.

La discusin sobre temas de diseo de modelos de programacin sobre los cambios

recientes se hizo tema difcil porque la mayora de la actividad fue relacionada con la

Programacin Extrema. Eventualmente, y debido a sto, la mayora de la gente que

sola discutir sobre los temas de diseo de modelos de programacin fue apartndose

de este ambiente para discutir sus ideas en otros ambientes ms "reservados". La

comunidad empez a referirse a estos sitios como a Salas Wiki (Wards Wiki).

1.5.OBJETIVOS DE XP

Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa

trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto,

debemos responder muy rpido a las necesidades del cliente, incluso cuando los

cambios sean al final de ciclo de la programacin.


10/33

7



Potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y

desarrolladores, son parte del equipo y estn involucrados en el desarrollo del

software.

EstablecerlasmejoresprcticasdeIngenieradeSoftwareenlosdesarrollodeproyectos.

Mejorar la productividad de los proyectos.

Garantizarla Calidad del Software desarrollando, haciendo que este supere las

expectativas del cliente.

Asumir que con cierta planificacin, codificacin y pruebas se puede decidir si se est

siguiendo un camino correcto o equivocado, evitando retroceder cuando sea

demasiado tarde.

1.6.CARACTERSTICAS

Metodologa basada en prueba y error para obtener un software que funcionerealmente.

Fundamentada en Principios.

Expresada en forma de 12 Prcticas (conjunto completo, complementndoseunas a otras).Las cuales son conocidas pero su novedades juntarlas.

Est orientada hacia quien produce y usa el software (el cliente participa muyactivamente)

Reduce el coste del cambio en todas las etapas del ciclo de vida del sistema.

Combinalasquehandemostradoserlasmejoresprcticasparadesarrollarsoftware

, y las lleva al extremo.

Cliente bien definido.

Los requisitos pueden cambiar.


11/33

8



1.7.LA FILOSOFA DE XP

XP es una metodologa gil para pequeos y medianos equipos, desarrollandosoftware cuando los requerimientos son ambiguos o rpidamente cambiantes.

A diferencia de los procesos tradicionales para desarrollar software, XP asume el

cambio como algo natural, y que, indefectiblemente, en alguna etapa de un proyecto

sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento

que lo precisa, alentando a los programadores a responder a los requerimientos

cambiantes que plantea el cliente en cualquier momento. Esto es posible porque est

diseado para adaptarse en forma inmediata a los cambios, con bajos costos

asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP abraza el

cambio.

1.8.VALORES EN XP

Para poder implementar las prcticas que presenta XP hay que conocer cules son los

valores principales que hacen a esta mitologa. Estos valores son:

Comunicacin.

Simplicidad.

Feedback.

Coraje.

1.8.1.

Comunicacin

Uno de los valores ms importantes en XP es la comunicacin. La mala comunicacin

no surge por casualidad en un proyecto y pueden aparecer muchas circunstancias que

hagan que esta falle; un programador le da malas noticias al gerente y este lo castiga,

un cliente le dice al programador algo importante y este no le presta atencin.


12/33

9



En cualquiera de los casos la comunicacin es un factor importante en cualquier tipo

de proyecto. En XP se trata de mantener una buena comunicacin mediante un

conjunto de prcticas que no se pueden realizar sin tener una buena comunicacin en

el equipo. Muchas de estas prcticas hacen corto circuito si no hay buena

comunicacin como en el caso de los testing unitarios, programacin por pares, el

uso de estndares o la estimacin de las tareas. Trabajar en espacios abiertos hace que

la comunicacin mejore al contrario de otras metodologas en las cuales los

programadores trabajan en espacios reducidos.

La comunicacin con el cliente es de vital importancia en XP y es por este motivo

que el cliente es integrado al equipo. De esta forma, cualquier duda sobre losrequerimientos puede ser evacuada inmediatamente. Adems, se planifica con el

cliente y este puede estar al tanto del avance del proyecto.

XP ha sido diseada para minimizar el grado de documentacin como forma de

comunicacin, haciendo nfasis en la interaccin personal. De esta manera se puede

avanzar rpidamente y de forma efectiva, realizando solo la documentacin necesaria.

1.8.2. Simplicidad

La simplicidad es el segundo valor que se utiliza en esta metodologa. XP apuesta a

realizar algo simple hoy y destinar un poco ms de esfuerzo para realizar un cambio

en el futuro, a realizar algo ms complicado hoy y no utilizarlo nunca.

XP propone una regla muy simple: hacer algo que funcione de la manera ms

sencilla. En el caso de tener que aadir nueva funcionalidad al sistema se deben

examinar todas las posibles alternativas y seleccionar la ms sencilla. En otras

ocasiones se hace uso del refactoring1 que permite mantener el cdigo en

funcionamiento pero mucho ms simple y organizado.


13/33

10



Otra regla muy importante es: realizar solo lo

necesario. Con esto se pretende agregar nueva funcionalidad que cumpla con los

objetivos actuales sin necesidad de preocuparse por futuros requerimientos. Esto hace

que se progrese de manera ms segura y rpida en el proyecto.

1.8.3. Feedback

Brindar un feedback correcto y preciso hace que se pueda mantener una buena

comunicacin y conocer el estado actual del proyecto.

El feedback trabaja a diferentes escalas de tiempo. Uno es el feedback que se realiza

minuto a minuto. Cuando un cliente escribe sus stories1 los programadores realizan

la estimacin de cada una de ellas y el cliente puede obtener inmediatamente el

feedback sobre la calidad de dichas stories.

El otro tipo de feedback que se realiza es a travs de pequeas entregas del sistema.

De esta manera, el cliente est al tanto del avance del proyecto. Adems, el sistema

es puesto en produccin en menor tiempo, con lo cual los programadores saben si

realizaron un buen trabajo y si sus decisiones fueron acertadas.

1.8.4. Coraje

Obviamente cada uno de los valores antes mencionados tiene una gran interaccin

entre ellos. Como se ve en la siguiente figura la comunicacin, la simplicidad y el

feedback forman el coraje, el cual se convierte en el objetivo de XP. Uno de los lemas

de XP menciona: Si no trabajas al tope de tu capacidad, alguien ms lo est haciendo

y si no llegas a tiempo se comer tu almuerzo.

Esto hace, a que por ejemplo, se tenga el coraje de modificar el cdigo en cualquier

momento por cualquier miembro del equipo sabiendo que no se afectar el correcto

funcionamiento del sistema.


14/33

11



El coraje tambin es poder realizar cambios cuando

algo no funciona del todo bien, disear e implementar solo lo necesario para el

presente, pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza.

Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario

que los otros tres valores estn presentes.

1.9.COSTE DEL CAMBIO

Una de las suposiciones establecidas en la industria del software es que el coste delos cambios en un programa crece exponencialmente con el tiempo. XP propone que

si el sistema que empleas hace que el coste del software aumente con el tiempo debes

de actuar de forma diferente a cmo lo haces. XP propugna que esta curva ha perdido

validez y con una combinacin de buenas prcticas de programacin y tecnologa es

posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto:

Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva,

pero cmo se consigue dicha curva?, no existe una forma mgica desde luego hay

varias medidas que nos ayudan a conseguirla.

Disear lo ms sencillo que sea posible, para hacer slo lo imprescindible en un

momento dado, la simplicidad del cdigo y los test continuos hace que los cambios

sean posibles tan a menudo como sea necesario.

La programacin orientada a objetos es una tecnologa clave para el mantenimiento

del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidadde cambiar el cdigo existente, esto no quiere decir que no puedas tener flexibilidad

sin programar orientado al objeto y el caso contrario que haya programas orientados

a objetos que nadie quera tocar, slo se dice que el programar orientado a objetos

reduce el costo del cambio.


15/33

12



En vez de tomar grandes decisiones al principio y

pocas posteriormente, podemos idear una aproximacin para desarrollar software en

la que se tomen decisiones rpidamente, pero estas decisiones apoyadas por pruebas

y que te preparan para mejorar el diseo del software cuando aprendas una mejor

manera de disearlo.

He odo a muchos programadores (entre los que me incluyo) decir: Hasta que no he

terminado el programa no lo he entendido ahora lo hara con esta jerarqua y que esta

clase herede de esta otra, dejemos pues abierta la puesta a esta posibilidad.

1.10.

CICLO DE VIDA DE XP

El ciclo de vida de XP consiste bsicamente de seis fases: Exploracin, Planificacin,

Iterations to Release, Produccin, Mantenimiento y Muerte.

Exploracin

En esta fase los clientes realizan las story cards que desean que estn para la primera

entrega. Cada story describe una de las funcionalidades que el programa tendr. Al


16/33

13



mismo tiempo el equipo de desarrollo se familiariza

con las herramientas, la tecnologa y las prcticas a ser utilizadas durante el proyecto.

En algunos casos se utiliza un prototipo para testear la nueva tecnologa y explorar

algunos aspectos de la arquitectura a ser implementada. La duracin de esta fase

puede extenderse desde unas pocas semanas a varios meses dependiendo de la

adaptacin del equipo de desarrollo.

Planificacin

El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece

cual va a ser el contenido de la primera entrega. Los programadores estiman cuanto

esfuerzo requiere cada story y se establece el cronograma. La duracin del calendariopara la entrega del primer release no suele superar los dos meses. Duracin de la fase

de planificacin en s no toma ms de dos das.

I teraciones por entr egas

Esta fase incluye varias iteraciones del sistema antes de la entrega del primer relase.

El calendario es dividido en un nmero iteraciones de tal manera de que cada iteracintome de una a cuatro semanas de implementacin. En la primera iteracin se crea un

sistema que abarca los aspectos ms importantes de la arquitectura global. Esto se

logra seleccionando las stories que hagan referencia a la construccin de la estructura

de todo el sistema.

El cliente decide que stories van a ser implementadas para cada iteracin. Adems,

se realizan los test funcionales, realizados por el cliente, al final de cada iteracin. Al

final de la ltima iteracin el sistema est listo para ser puesto en produccin.


17/33

14



Produccin

La fase de produccin requiere realizar muchos ms chequeos y testing antes que el

sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que

decidir si sern incorporados o no en dicha entrega. Durante esta fase suele suceder

que las iteraciones se aceleren de tres a una semana. Las ideas pospuestas y las

sugerencias son documentadas para luego ser implementadas ms adelante, por

ejemplo, en la fase de mantenimiento.

Luego que el primer release es creado, el proyecto debe mantener el sistema en

produccin corriendo mientas se trabaja en las nuevas iteraciones.

Mantenimiento

En esta fase por lo general se necesita un esfuerzo extra de los programadores para

satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo

suele disminuir una vez que el sistema es puesto en produccin. A raz de esto se

requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo.

Muerte

Esta ltima fase se acerca una vez que el cliente no tiene ninguna story a ser

implementada. Los requerimientos del sistema deben ser satisfechos en otros aspectos

como ser la performance o la confiabilidad del mismo. Esta es la etapa en la cual no

hay ms cambios en la arquitectura, el diseo o el cdigo y aqu es cuando se realiza

la documentacin correspondiente. Esta fase aparece tambin, cuando el sistema no

da los resultados deseados o se vuelve demasiado caro para seguir siendo

desarrollado.


18/33

15



1.11.Principios de XP

Los cuatro valores mencionados anteriormente comunicacin, simplicidad,

feedback y coraje nos brindan un estndar para obtener buenos resultados. Sin

embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prcticas

utilizar. Para ello se necesita destilar estos valores en principios que puedan ser

utilizados.

1.11.1.Rpida Retroalimentacin

En la prctica el tiempo transcurrido entre una accin y su feedback es crtico. Tener

una rpida retroalimentacin nos permite interpretarla, aprender de ella y poner enprctica lo asimilado lo antes posible.

1.11.2.Asumir la Simplicidad

Este es uno de los principios ms difciles de llevar a la prctica. Casi siempre se

planifica para el futuro y se disea para poder rehusar. En lugar de esto XP dice que

hay que hacer un buen trabajo para las necesidades actuales y confiar en nuestra

habilidad para solucionar problemas futuros.

1.11.3.Cambios Incrementales

Realizar grandes cambios en una sola oportunidad no es una buena solucin. Cada

problema debe ser resuelto con una serie de cambios pequeos para poder atacar

dicho problema mucho ms en profundidad.


19/33

16



1.11.4.Aceptar el Cambio

En XP el cambio es asimilado como algo habitual e inevitable. La mejor estrategia es

aquella que preserva la mayor cantidad de opciones mientras resuelve los problemas

ms precisos.

1.11.5.Trabajo de Calidad

Uno de los objetivos ms importantes en XP es realizar un producto de buena calidad.

Si cada integrante realiza su trabajo de la mejor manera posible se puede asegurar la

calidad del producto.

1.11.6.Otros Principios

Adems de los principios antes mencionados surgen algunos otros de menor

trascendencia que pueden ayudar a tomar buenas decisiones en situaciones

especficas.

Aceptar la responsabilidad

Adaptacin local

Comunicacin abierta y honesta

Ensear conocimientos

Experimentos concretos

Jugar para ganar

Mediciones honestas

Pequea inversin inicial

Trabajar con los instintos de las personas

Viajar liviano


20/33

17



CAPITULO II:

FACES DE LA

METODOLOGIA

XP


21/33

18



2.1.FASE PLANEACIN

La planeacin es la etapa inicial de todo proyecto en XP. En este punto se comienza

interactuar con el cliente y el resto del grupo de desarrollo para descubrir los

requerimientos del sistema. En este punto se identifican el nmero y tamao de

las iteraciones al igual que se plantean ajustes necesarios a la metodologa segn

las caractersticas del proyecto.

En este apartado se tendrn en cuenta ocho elementos, los cuales son los

siguientes:

Historias De Usuario.

Velocidad Del Proyecto.

Iteraciones.

Entregas Pequeas.

Reuniones.

Roles En XP.

Traslado Del Personal.

Ajuste A XP.

Figura 3. El juego de Planificacin

Fuente: (info-ab.uclm.es, 2002)


22/33

19



2.1.1. Historias de usuario

Las historias de usuario son utilizadas como herramienta para dar a conocer

los requerimientos del sistema al equipo de desarrollo. Son pequeos textos en

los que el cliente describe una actividad que realizar el sistema; la redaccin de

los mismos se realiza bajo la terminologa del cliente, no del desarrollador, de forma

que sea clara y sencilla, sin profundizar en detalles.

Las historias de usuario tambin son utilizadas para estimar el tiempo que el

equipo de desarrollo tomar para realizar las entregas. En una entrega se puede

desarrollar una o varias historias de usuario, esto depende del tiempo que demore

la implementacin de cada una de las mismas.

2.1.2. Velocidad del proyecto

Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las

historias de usuario en una determinada iteracin. Esta medida se calcula totalizando

el nmero de historias de usuario realizadas en una iteracin. Para la iteracin

siguiente se podr (tericamente) implementar el mismo nmero de historias

de usuario que en la iteracin anterior.

2.1.3. Iteraciones

Por lo general, los proyectos constan de ms de tres etapas, las cuales toman el

nombre de iteraciones, de all se obtiene el concepto de metodologa iterativa. Para

cada iteracin se define un mdulo o conjunto de historias que se van a implementar.

Al final de la iteracin se obtiene como resultado la entrega del mdulo

correspondiente, el cual debe haber superado las pruebas de aceptacin que

establece el cliente para la verificar el cumplimiento de los requisitos. Las tareas

que no se realicen en una iteracin son tomadas en cuenta para la prxima

iteracin, donde se define, junto al cliente, si se deben realizar o si deben ser

removidas de la planeacin del sistema.


23/33

20



2.1.4. Entregas pequeas

La duracin de una iteracin vara entre una y tres semanas, al final de la cual habr

una entrega de los avances del producto, los cuales debern ser completamente

funcionales. Estas entregas deben caracterizarse por ser frecuentes.

2.1.5. Reuniones

El planeamiento es esencial para cualquier tipo de metodologa, es por ello que XP

requiere de una revisin continua del plan de trabajo. A pesar de ser una metodologa

que evita la documentacin exagerada, es muy estricta en la organizacin del

trabajo.

2.1.6. Roles en XP

Programador

El programador escribe las pruebas unitarias y produce el cdigo del sistema.

Debe existir una comunicacin y coordinacin adecuada entre los

programadores y otros miembros del equipo.

Cliente

El cliente escribe las historias de usuario y las pruebas funcionales para validar

su implementacin. Adems, asigna la prioridad a las historias de usuario y

decide cules se implementan en cada iteracin centrndose en aportar mayor

valor al negocio. El cliente es slo uno dentro del proyecto pero puede

corresponder a un interlocutor que est representando a varias personas que se

vern afectadas por el sistema.


24/33

21



Encargado de pruebas (Tester)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.

Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es

responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentacin al equipo en el

proceso XP. Su responsabilidad es verificar el grado de acierto entre las

estimaciones realizadas y el tiempo real dedicado, comunicando los resultados

para mejorar futuras estimaciones.

Tambin realiza el seguimiento del progreso de cada iteracin y evala si los

objetivos son alcanzables con las restricciones de tiempo y recursos presentes.Determina cundo es necesario realizar algn cambio para lograr los objetivos

de cada iteracin.

Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el

proceso XP para proveer guas a los miembros del equipo de forma que se

apliquen las prcticas XP y se siga el proceso correctamente.

Consultor

Es un miembro externo del equipo con un conocimiento especfico en algn

tema necesario para el proyecto. Gua al equipo para resolver un problema

especfico.

Gestor (Bi g boss)

Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje

efectivamente creando las condiciones adecuadas. Su labor esencial es de

coordinacin.


25/33

22



2.1.8. Traslado del personal

Al mover el personal se evitan problemas relacionados con la prdida de

conocimiento y cuellos de botella. En la medida que todos los programadores

entienden todas las partes del programa se evita que unos tengan una carga de trabajo

muy alta mientras que otros no tengan mucho trabajo por hacer.

La programacin en parejas se convierte en una herramienta muy importante para

lograr el objetivo del traslado de personal sin que se pierda el rendimiento.

Figura 2:rotacin de parejas.

2.1.9. Ajuste a XP

Todos los proyectos tienen caractersticas especficas por lo cual XP puede ser

modificado para ajustarse bien al proyecto en cuestin. Al iniciar el proyecto

se debe aplicar XP tal como es, sin embargo no se debe dudar en modificar

aquellos aspectos en que no funcione. Eso no quiere decir que los desarrolladores

pueden hacer lo que se les antoje. Antes de implementarse un cambio, este debe

ser discutido y aprobado por el grupo.


26/33

23



2.2.FASE DISEO

En XP solo se disean aquellas historias de usuario que el cliente ha seleccionado para

la iteracin actual por dos motivos: por un lado se considera que no es posible tener un

diseo completo del sistema y sin errores desde el principio. El segundo motivo

es que dada la naturaleza cambiante del proyecto, el hacer un diseo muy extenso en

las fases iniciales el proyecto para luego modificarlo, se considera un desperdicio de

tiempo.

Los aspectos que se tratarn a continuacin son:

Simplicidad En El Diseo. Metfora Del Sistema.

Tarjetas Crc.

Spike Solution.

No Solucionar Antes De Tiempo.

Refactoring.

Figura 4. Planificacin y diseo en XP.

Fuente: (info-ab.uclm.es, 2002)


27/33

24



2.2.1.Simplicidad En El Diseo

Una de las partes ms importantes de la filosofa XP es la simplicidad en

todos los aspectos. Se considera que un diseo sencillo se logra ms rpido

y se implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es

que se haga el diseo ms sencillo que cumpla con los requerimientos de las

historias de usuario.

2.2.2.Metfora Del Sistema

Es muy importante dentro del desarrollo de la metfora darle nombres adecuadosa todos los elementos del sistema constantemente, y que estos correspondan

a un sistema de nombres consistente. Esto ser de mucha utilidad en fases

posteriores del desarrollo para identificar aspectos importantes del sistema.

2.2.3.Tarjetas de clase, responsabilidad, colaboracin (CRC cards)

La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento

procedimental para incorporarse al enfoque orientado a objetos.

En el proceso de disear el sistema por medio de las tarjetas CRC como

mximo dos personas se ponen de pie adicionando o modificando las tarjetas,

prestando atencin a los mensajes que stas se transmiten mientras los dems

miembros del grupo que permanecen sentados, participan en la discusin

obteniendo as lo que puede considerarse un diagrama de clases preliminar.

2.2.4.

Soluciones puntuales (Spike Solution)

Se trata de una pequea aplicacin completamente desconectada del proyecto con

la cual se intenta explorar el problema y propone una solucin potencial. Puede ser

burda y simple, siempre que brinde la informacin suficiente para enfrentar el

problema encontrado.


28/33

25



2.2.5.No Solucionar Antes De Tiempo

Los desarrolladores tienden a predecir las necesidades futuras e

implementarlas antes. Segn mediciones, esta es una prctica ineficiente,

concluyendo que tan solo el 10% de las soluciones para el futuro son utilizadas,

desperdiciando tiempo de desarrollo y complicando el diseo innecesariamente.

En XP slo se analiza lo que se desarrollar en la iteracin actual, olvidando por

completo cualquier necesidad que se pueda presentar en el futuro, lo que

supone uno de los preceptos ms radicales de la programacin extrema.

2.2.6.Refactorizacin (Refactoring)

La refactorizacin en el cdigo pretende conservarlo tan sencillo y fcil de

mantener como sea posible. En cada inspeccin que se encuentre alguna

redundancia, funcionalidad no necesaria o aspecto en general por corregir, se

debe rehacer esa seccin de cdigo con el fin de lograr las metas de sencillez

tanto en el cdigo en s mismo como en la lectura y mantenimiento.

2.3. FASE DESARROLLO

El desarrollo es un proceso que se realiza en forma paralela con el diseo y la cual est

sujeta a varias observaciones por parte de XP consideradas controversiales por

algunos expertos tales como la rotacin de los programadores o la programacin en

parejas.

A continuacin una descripcin de los siguientes temas:

Cliente Siempre Presente.

Codificar Primero La Prueba.

Integracin.

Secuencial.

Integraciones Frecuentes.


29/33

26



2.3.1.Cliente Siempre Presente

Uno de los requerimientos de XP es que el cliente est siempre disponible. No

solamente para solucionar las dudas del grupo de desarrollo, debera ser parte de

ste. En este sentido se convierte en gran ayuda al solucionar todas las dudas que

puedan surgir, especialmente cara a cara, para garantizar que lo implementado

cubre con las necesidades planteadas en las historias de usuario.

2.3.2.Codificar Primero La Prueba

Una de las ventajas de crear una prueba antes que el cdigo es que permite

identificar los requerimientos de dicho cdigo. En otras palabras, al escribir

primero las pruebas se encuentran de una forma ms sencilla y con mayorclaridad todos los casos especiales que debe considerar el cdigo a implementar.

De esta forma el desarrollador sabr con completa certeza en qu momento ha

terminado, ya que habrn pasado todas las pruebas.

2.3.3.Programacin En Parejas

Cuando se trabaja en parejas se obtiene un diseo de mejor calidad y un

cdigo ms organizado y con menores errores que si se trabajase solo, adems

de la ventaja que representa contar con un compaero que ayude a solucionar

inconvenientes en tiempo de codificacin, los cuales se presentan con mucha

frecuencia.

Se recomienda que mientras un miembro de la pareja se preocupa del mtodo que

se est escribiendo el otro se ocupe de cmo encaja ste en el resto de la clase.


30/33

27



2.3.4.Integracin Secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene

que ver con la integracin, sobre todo si todos los programadores son dueos de

todo el cdigo. Para saldar este problema han surgido muchos mecanismos,

como darle propiedad de determinadas clases a algunos desarrolladores, los

cuales son los responsables de mantenerlas actualizadas y consistentes. Sin

embargo, sumado al hecho que esto va en contra de la propiedad colectiva el

cdigo no se solucionan los problemas presentados por la comunicacin entre

clases.

2.3.5.

Integraciones FrecuentesSe deben hacer integraciones cada pocas horas y siempre que sea posible

no debe transcurrir ms un da entre una integracin y otra. De esta forma

se garantiza surjan problemas como que un programador trabaje sobre versiones

obsoletas de alguna clase.

Es evidente que entre ms se tarde en encontrar un problema ms costoso ser

resolverlo y con la integracin frecuente se garantiza que dichos problemas se

encuentre ms rpido o an mejor, sean evitados por completo.

2.4. FASE PRUEBAS

Del buen uso de las pruebas depende el xito de otras prcticas, tales como la propiedad

colectiva del cdigo y la refactorizacin. Cuando se tienen bien implementadas las

pruebas no habr temor de modificar el cdigo del otro programador en el sentido que

si se daa alguna seccin, las pruebas mostrarn el error y permitirn encontrarlo. Uno

de los elementos que podra obstaculizar que un programador cambie una seccin

de cdigo funcional es precisamente hacer que esta deje de funcionar. Si se tiene un

grupo de pruebas que garantice su buen funcionamiento, este temor se mitiga en gran

medida.


31/33

28



Segn XP se debe ser muy estricto con las pruebas.

Slo se deber liberar una nueva versin si esta ha pasado con el cien por

ciento de la totalidad de las pruebas. En caso contrario se emplear el resultado

de estas para identificar el error y solucionarlo con mecanismos ya definidos.

2.4.1.Pruebas Unitarias

Estas pruebas se aplican a todos los mtodos no triviales de todas las clases del

proyecto con la condicin que no se liberar ninguna clase que no tenga asociada

su correspondiente paquete de pruebas. Uno de los elementos ms importantes

en estas es que idealmente deben ser construidas antes que los mtodos mismos,

permitindole al programador tener mxima claridad sobre lo que va a programarantes de hacerlo, as como conocer cada uno de los casos de prueba que deber

pasar, lo que optimizar su trabajo y su cdigo ser de mejor calidad.

2.4.2.Pruebas de Aceptacin

Las pruebas de aceptacin, tambin llamadas pruebas funcionales son

supervisadas por el cliente basndose en los requerimientos tomados de las

historias de usuario. En todas las iteraciones, cada una de las historias de usuario

seleccionadas por el cliente deber tener una o ms pruebas de aceptacin, de las

cuales debern determinar los casos de prueba e identificar los errores que sern

corregidos.

Las pruebas de aceptacin son pruebas de caja negra, que representan un

resultado esperado de determinada transaccin con el sistema.

2.4.3.Cuando se Encuentra un Error

Al momento de encontrar un error debe escribirse una prueba antes de intentar

corregirlo. De esta forma tanto el cliente lograr tener completamente claro

cul fue y dnde se encontraba el mismo como el equipo de desarrollo podr

enfocar mejor sus esfuerzos para solucionarlo. Por otro lado se lograr evitar

volver a cometerlo.


32/33

29



CONCLUCIONES

Ninguna prctica funciona bien por si sola (con la excepcin de las pruebas). Requieren las

otras prcticas para equilibrarse.

La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales

como la comunicacin, el trabajo en equipo y disciplina.

En XP la comunicacin es vital tanto entre el grupo de desarrollo como con el cliente, el cual

debe formar parte del equipo para mantener una comunicacin fluida y poder de esta forma,evacuar cualquier tipo de duda que surja con los requerimientos.

La programacin extrema se beneficia de la existencia de un gran nmero de herramientas

de software libre que permiten aplicarla con gran productividad.

XP propone una metodologa gil y concreta, aunque requiere de una nueva menara de

pensar, ver y hacer las cosas, tanto por parte de los gerentes (responsables de la rentabilidad

general del proyecto), como de los desarrolladores y tambin del cliente. La aplicabilidad de

sta metodologa a cada proyecto debera ser analizada en cada caso, teniendo en cuenta el

tamao y tipo de proyecto, as como sus ventajas y desventajas.


33/33



REFERENCIAS

ECHEVERRY TOBN, Luis Miguel y DELGADO CARMONA, Luz Elena. Caso Prctico

de la Mitologa gil XP al Desarrollo de Software: 2007

AMARO CALDERON, Sarah Damaris y VALVERDE REBAZA, Jorge Carlos.

Metodologas giles: 2007

Programacin Extrema

CALERO SOLIS, Manuel. Una Explicacin de la Programacin Extrema (XP): 2003

CALABRIA, Luis y PIRIZ, Pablo. Metodologa XP: 2003

programingxtrema rup

Documents