Documente Academic
Documente Profesional
Documente Cultură
UNIVERSIDAD NACIONAL DE
TRUJILLO
ESCUELA ACADMICO PROFESIONAL DE INGENIERA DE
SISTEMAS
TEMA:
PROGRAMACIN EXTREMA
ALUMNOS:
Alcalde Moncada Jhonatan
Campos Cabanillas Walter Wilmer
De Pirola Chvez Luis Alberto
Ulfe Isla Jos Alberto
CURSO:
Ingeniera de Software Aplicada a Objetos
CICLO:
VIII
Guadalupe Per
2015
Contenido
Captulo I Introduccin y Resea Histrica..................................................................7
Introduccin....................................................................................................... 8
Resumen.......................................................................................................... 11
Abstract........................................................................................................... 12
1.
Resea Histrica......................................................................................... 13
2.
Conceptos Generales.................................................................................... 15
3.
Definicin.................................................................................................. 15
4.
5.
Principios Bsicos........................................................................................ 16
5.1.
5.2.
5.3.
Entendimiento compartido......................................................................19
5.4.
Proceso de desarrollo.................................................................................... 23
2.
3.
Historia de Usuario...................................................................................... 23
3.1.
En la primera fase................................................................................. 23
3.2.
En la segunda fase................................................................................. 24
4.
5.
6.
Metfora.................................................................................................... 27
7.
8.
7.1.
7.2.
Fase: Diseo......................................................................................... 31
7.3.
Fase: Codificacin................................................................................. 32
7.4.
Fase: Pruebas....................................................................................... 32
Simplicidad.......................................................................................... 34
8.2.
Comunicacin....................................................................................... 35
8.3.
Retroalimentacin................................................................................. 35
METODOLOGOGA XP
8.4.
9.
Coraje o valenta................................................................................... 36
10.
Inconvenientes......................................................................................... 36
11.
11.1.
JAVA............................................................................................... 37
11.2.
NETBeans........................................................................................ 37
11.3.
JUnit............................................................................................... 37
11.4.
JasperReport e IReport.......................................................................37
11.5.
PostgreSQL...................................................................................... 38
12.
12.1.
Semejanzas....................................................................................... 38
12.2.
Diferencias........................................................................................ 39
13.
Conclusiones........................................................................................... 55
ndice de tablas
TABLA 1. PUNTOS A FAVOR Y EN CONTRA......................................................................16
TABLA 2. PRUEBAS DE ACEPTACIN..............................................................................17
TABLA 3. HISTORIA DE USUARIO...................................................................................25
TABLA 4. VENTAJAS Y DESVENTAJAS DE LA METODOLOGA XP.....................................36
TABLA 5. COMPARACIN ENTRE METODOLOGAS........................................................39
ndice de figuras
FIGURA 1....................................................................................................................... 21
FIGURA 2....................................................................................................................... 21
FIGURA 3....................................................................................................................... 28
FIGURA 4....................................................................................................................... 33
FIGURA 5....................................................................................................................... 34
Captulo I
Introduccin y Resea Histrica
Introduccin
En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas
pretendieron ser las "balas de plata" para el xito en el desarrollo de software, sin embargo,
las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante
elemento, la metodologa de desarrollo, haba sido postergado. De nada sirven buenas
notaciones y herramientas si no se proveen directivas para su aplicacin. As, esta dcada
ha comenzado con un creciente inters en metodologas de desarrollo. Hasta hace poco el
proceso de desarrollo llevaba asociada un marcado nfasis en el control del proceso
mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y
documentacin detallada. Este esquema "tradicional" para abordar el desarrollo de software
ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y
recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin
embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos
actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir
drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las
dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y
flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la
ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las
metodologas giles emergen como una posible respuesta para llenar ese vaco
metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
metodologas giles constituyen una solucin a medida para ese entorno, aportando una
elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para
asegurar la calidad del producto.
Las metodologas giles son sin duda uno de los temas recientes en ingeniera de software
que estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio
destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Es tal
Proceso Pesado :
* Fuerte dependencia de planificaciones
* Se establecen actividades
* Se establecen artefactos
* Se establecen herramientas y notaciones
* ESTAMOS MUY CONTROLADOS
Caractersticas:
Resumen
* Estamos menos controlado
* Preparados para el cambio
* Cliente forma parte del equipo
* Pocos artefactos
* Ms importante software funcionando que documentacin
Coraje:
Implica saber tomar decisiones difciles.
Reparar un error cuando se detecta
Mejorar el cdigo siempre que tras el feedback y las sucesivas iteraciones se
manifieste susceptible de mejora
Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y
cundo se van a entregar
Resumen
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas
propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo.
Por una parte tenemos aquellas propuestas ms tradicionales que se centran especialmente
en el control del proceso, estableciendo rigurosamente las actividades involucradas, los
artefactos que se deben producir, y las herramientas y notaciones que se usarn. Estas
propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, pero
tambin han presentado problemas en otros muchos. Una posible mejora es incluir en los
procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndose en
los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de desarrollo
ms complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el
proyecto. Otra aproximacin es centrarse en otras dimensiones, como por ejemplo el factor
humano o el producto software. Esta es la filosofa de las metodologas giles, las cuales
dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental
del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en
proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Las metodologas giles estn
revolucionando la manera de producir software, y a la vez generando un amplio debate
entre sus seguidores y quienes por escepticismo o convencimiento no las ven como
alternativa para las metodologas tradicionales. En este trabajo se presenta resumidamente
el contexto en el que surgen las metodologas giles, sus valores, principios y
comparaciones con las metodologas tradicionales. Adems se describe con mayor detalle
Programacin Extrema (eXtreme Programming, XP) la metodologa gil ms popular en la
actualidad.
Palabras Clave:
(eXtreme Programming)
Abstract
The development of software is not an easy task. The proof for that is the fact that there are
many methodological proposals that affect different dimensions of the development
process. On one hand, we can find more traditional proposals, which are specially centred
in the control of the process by rigorously setting the involved activities, the devices that
are due to produce, and the tools and annotations that will be used. These proposals have
demonstrated to be effective and necessary in a great number of projects, but also they have
presented problems in others. A possible improvement for that is to include more activities,
devices and restrictions in the development processes, which is based on the weak points
that were detected. Nevertheless, the final result would be a more-complex process of
development which can even limit the own ability of the equipment to develop the project.
Another approach is focusing in other dimensions, for example the human factor or the
software product. This is the philosophy of the agile methodologies, which give greater
value to the individual, to the collaboration with the client and the incremental development
of software with very short iterations. This approach is presenting its effectiveness in
projects with changing requirements and when it is demanded to reduce drastically the
times of development but maintaining a high quality. The agile methodologies are
revolutionizing the way to produce software and, at the same time, they are generating an
considerable debate between their followers and the ones that, by scepticism or conviction,
do not see them as an alternative for traditional methodologies. In this work it is briefly
presented the context in which the agile methodologies emerge, their values, principles and
comparisons with traditional methodologies. In addition, it is described in detail the most
popular agile methodology at the present time: eXtreme Programming.
Key-words: Software process; agile methods; eXtreme Programming
1. Resea Histrica
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 esta aplicacin 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 que acomodar al cambio a
realizar.
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 Repository y 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.
Beck invit a Ron Jeffries al proyecto para ayudar a desarrollar y perfeccionar estos
mtodos. Jeffries partir de entonces actu como un entrenador para inculcar las
prcticas, hbitos en el equipo C3.
La informacin sobre los principios y prcticas detrs de XP se difundi al resto del
mundo a travs de discusiones en el wiki original, WikiWikiWeb de Cunningham.
Varios colaboradores discuten y se expandieron en las ideas, y algunas metodologas
spin-off resultado. Adems, se han explicado los conceptos XP, desde hace varios aos,
con
un
mapa
del
sistema
de
hipertexto
en
el
sitio
web
en
XP
2. Conceptos Generales
Las metodologas giles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc.) forman
parte del movimiento de desarrollo gil de sotfware, que se basan en la adaptabilidad de
cualquier cambio como medio para aumentar las posibilidades de xito de un proyecto.
De forma que una metodologa gil es la que tiene como principios que:
Los individuos y sus interacciones son ms importantes que los procesos y las
herramientas.
El software que funciona es ms importante que la documentacin exhaustiva.
La colaboracin con el cliente en lugar de la negociacin de contratos.
La respuesta delante del cambio en lugar de seguir un plan cerrado.
Se puede decir que, este movimiento empez a existir a partir de febrero de 2001,
cuando se reunieron los representantes de cada una de estas metodologas y terminaron
poniendo en comn sus ideas en una declaracin conjunta.
3. Definicin
La programacin extrema es una metodologa de desarrollo ligera (o gil) basada en
una serie de valores y de prcticas de buenas maneras que persigue el objetivo de
aumentar la productividad a la hora de desarrollar programas.
Este modelo de programacin se basa en una serie de metodologas de desarrollo de
software en la que se da prioridad a los trabajos que dan un resultado directo y que
reducen la burocracia que hay alrededor de la programacin.
Una de las caractersticas principales de este mtodo de programacin, es que sus
ingredientes son conocidos desde el principio de la informtica. Los autores de XP han
seleccionado aquellos que han considerado mejores y han profundizado en sus
relaciones y en cmo se refuerzan los unos con los otros. El resultado de esta seleccin
ha sido esta metodologa nica y compacta. Por esto, aunque no est basada en
principios nuevos, s que el resultado es una nueva manera de ver el desarrollo de
software.
En contra
X.P. slo funcionar con gente buena, es Los programadores tienen un acusado
decir, profesionales que son capaces de sentimiento de posesin del cdigo y esta
hacer un buen diseo, sencillo y a la vez postura no encaja con la filosofa de X.P.
fcilmente ampliable.
Tambin se ve un fuerte sentimiento para
Por otro lado se ha de recalcar que XP no respectar las 40 horas semanales, y X.P. no
ha
inventado
ningn
mtodo
nuevo, lo garantiza.
recelo
con
este
mtodo
tan
poco
tradicional.
Fuente: (Elaboracin propia, 2014)
5. Principios Bsicos
La programacin extrema se basa en 12 principios bsicos agrupados en cuatro
categoras:
5.1. Retroalimentacin a escala fina
5.1.1. El principio de pruebas
Se tiene que establecer un periodo de pruebas de aceptacin del programacin
(llamada tambin periodo de caja negra) donde se definirn las entradas al
sistema y los resultados esperados de estas entradas. Es muy recomendable
automatizar estas pruebas para poder hacer varias simulaciones del sistema del
sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se
puede utilizar Ambientes de Prueba (Unit testing frameworks).
Condiciones de ejecucin:
Entradas:
Resultado esperado:
Evaluacin:
Fuente: (Elaboracin propia, 2014)
5.1.2. Proceso de planificacin
En esta fase, el usuario tendr que escribir sus necesidades, definiendo las
actividades que realizar el sistema. Se crear un documento llamado Historias
del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la
complejidad del problema) se consideran suficientes para formar el llamado
Plan de Liberacin, el cual define de forma especfica los tiempos de entrega
de la aplicacin para recibir retroalimentacin por parte del usuario.
Son muy importantes y tienen que ser una constante las reuniones peridicas
durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo
de desarrollo para identificar problemas, proponer soluciones y sealar
aquellos puntos a los que se les ha de dar ms importancia por su dificultad o
por su punto crtico.
5.1.3. El cliente en el sitio
Se le dar poder para determinar los requerimientos, definir la funcionalidad,
sealar las prioridades y responder las preguntas de los programadores. Esta
fuerte interaccin cara a cara con el programador disminuye el tiempo de
comunicacin y la cantidad de documentacin, junto con los altos costes de su
creacin y mantenimiento.
5.1.4. Programacin en parejas
Uno de los principios ms radicales y en el que la mayora de gerentes de
desarrollo pone sus dudas. Requiere que todos los programadores XP escriban
5.3.2. Metfora
Desarrollada por los programadores al inicio del proyecto, define una historia
de cmo funciona el sistema completo. XP estimula historias, que son breves
descripciones de un trabajo de un sistema en lugar de los tradicionales
diagramas y modelos UML (Unified Modeling Language). La metfora
expresa la visin evolutiva del proyecto que define el alcance y propsito del
sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin
ayudarn al equipo a definir actividades durante el diseo del sistema. Cada
tarjeta representa una clase en la programacin orientada a objetos y define sus
responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases
(cmo se comunica con ellas).
5.3.3. Propiedad colectiva del cdigo
Un cdigo con propiedad compartida. Nadie es el propietario de nada, todos
son el propietario de todo. Este mtodo difiere en mucho a los mtodos
tradicionales en los que un simple programador posee un conjunto de cdigo.
Los defensores de XP argumentan que mientras haya ms gente trabajando en
una pieza, menos errores aparecern.
5.3.4. Estndar de codificacin
Define la propiedad del cdigo compartido as como las reglas para escribir y
documentar el cdigo y la comunicacin entre diferentes piezas de cdigo
desarrolladas por diferentes equipos. Los programadores las han de seguir de
tal manera que el cdigo en el sistema se vea como si hubiera estado escrito
por una sola persona.
5.4. Bienestar del programador
5.4.1. La semana de 40 horas
La programacin extrema sostiene que los programadores cansados escriben
cdigo de menor cualidad. Minimizar las horas extras y mantener los
programadores frescos, generar cdigo de mayor calidad.
Fuente: (Elaboracin propia, 2014)
Figura
Figura21
Captulo II
Fases de la metodologa XP
1. Proceso de desarrollo
La programacin extrema parte del caso habitual de una compaa que desarrolla
software, normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o
diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo,
los que desarrollan el software y clientes es totalmente diferente al que se ha producido
en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos
previa al desarrollo, y de una fase de validacin posterior al mismo.
2. Interaccin con el cliente
En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de
desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en
efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el
equipo de programadores, sobre todo despus de cada cambio, y de cada posible
problema localizado, mostrando las prioridades. En este tipo de programacin existirn
pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms
provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se
elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se
vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se
posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio
han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo.
3. Historia de Usuario
En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista
de caractersticas que el cliente necesita que existan en el producto final. Estas constan
de dos fases.
3.1. En la primera fase
El cliente describe con sus propias palabras las caractersticas y, es el responsable
del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de
ellas y de su coste. A consecuencia de este dilogo, el cliente deja por escrito un
conjunto de historias y las ordena en funcin de la prioridad que tienen para l. De
esta manera ya es posible definir unas fechas aproximadas para ellos.
(Alta/Media/Baja)
Riesgos en Desarrollo:
Descripcin
Puntos Reales:
Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los
autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de
contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al
autor de contacto con un userid y password para que el autor pueda posteriormente
acceder al artculo.
Observaciones:
Fuente: (Elaboracin propia, 2015)
4. Planificacin del proyecto
En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn
diferentes iteraciones. Para hacerlo ser necesaria la existencia de reglas que se han de
seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se
sientan realmente partcipes de la decisin tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha
de recibir una nueva versin. Cuanto ms tiempo se tarde en introducir una parte
esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja muchas
entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene
ms posibilidades de detectarse rpidamente.
Una de las mximas a aplicar es, los cambios, no han de suponer ms horas de
programacin para el programador, ya que el que no se termina en un da, se deja para
el da siguiente.
Se ha de tener asumido que en el proceso de planificacin habrn errores, es ms, sern
comunes, y por esto esta metodologa ya los tiene previstos, por lo tanto se establecern
mecanismos de revisin. Cada tres o cinco iteraciones es normal revisar las historias de
los usuarios, y renegociar la planificacin.
Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin
iterativa, en la que se anotarn las historias de usuarios que se consideren esenciales y
las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin se harn
en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das.
Es por esto que el diseo se puede clasificar como continuo. Aade agilidad al proceso
de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que
an no han estado programados.
Este tipo de planificacin en iteraciones y el diseo iterativo, hace que aparezca una
prctica que no exista en la programacin tradicional. Se trata de las discusiones diarias
informales, para fomentar la comunicacin, y para hacer que los desarrolladores tengan
tiempo de hablar de los problemas a los que se enfrentan y de ver cmo van con sus
trabajos.
5. Diseo, desarrollo, pruebas
El desarrollo es la parte ms importante en el proceso de la programacin extrema.
Todos los trabajos tienen como objetivo que se programen lo ms rpidamente posible,
sin interrupciones y en direccin correcta.
Tambin es muy importante el diseo, y se establecen los mecanismos, para que ste
sea revisado y mejorado de manera continuada a lo largo del proyecto, segn se van
aadiendo funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicacin. La mayora de los
problemas en los proyectos son por falta de comunicacin en el equipo.
6. Metfora
En XP, aparece un nuevo concepto llamado Metfora. Su principal objetivo es mejorar
la comunicacin entre todos los integrantes del equipo, al crear una visin global y
comn de lo que se quiere desarrollar. La metfora tiene que ser expresada en trminos
conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se
desarrollar con alguna cosa de la vida real.
Figura 3
Fuente: (Elaboracin propia, 2015)
7. Fases de la metodologa XP
7.1. Fase: Planificacin del proyecto
7.1.1. Historias de usuario
El primer paso de cualquier proyecto que siga la metodologa X.P es definir las
historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso pero con algunas diferencias:
que describen.
Tambin se utilizan en la fase de pruebas, para verificar si el programa
Los objetivos que se deben cumplir (que son principalmente las historias
programa.
El nmero de personas que trabajarn en el desarrollo.
Y Cmo se evaluar la calidad del trabajo realizado. (*Release plan:
Planificacin de publicaciones).
7.1.3. Iteraciones
Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los
clientes deben seleccionar las historias de usuario definidas en el "Release
planning" que sern implementadas. Tambin se seleccionan las historias de
usuario que no pasaron el test de aceptacin que se realiz al terminar la
iteracin anterior. Estas historias de usuario son divididas en tareas de entre 1 y
3 das de duracin que se asignarn a los programadores.
7.1.4. La velocidad del proyecto
Es una medida que representa la rapidez con la que se desarrolla el proyecto;
estimarla es muy sencillo, basta con contar el nmero de historias de usuario
que se pueden implementar en una iteracin; de esta forma, se sabr el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la
velocidad del proyecto controlaremos que todas las tareas se puedan
desarrollar en el tiempo del que dispone la iteracin. Es conveniente reevaluar
esta medida cada 3 o 4 iteraciones y si se aprecia que no es adecuada hay que
negociar con el cliente un nuevo "Release Plan".
7.1.5. Programacin en Parejas
La metodologa X.P. aconseja la programacin en parejas pues incrementa la
productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo
equipo; mientras uno codifica haciendo hincapi en la calidad de la funcin o
mtodo que est implementando, el otro analiza si ese mtodo o funcin es
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.
Figura 4
Figura 4 Fases de la Metodologa
XP
Fuente: (Elaboracin propia, 2015)
8. 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:
8.1. 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 autodocumentado. 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.
8.2. Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores el
cdigo comunica mejor cuanto ms simple sea.
Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo
autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto
quedan desfasados con el cdigo a medida que es modificado.
Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una
clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra forma de
comunicacin ya que describen el diseo de las clases y los mtodos al mostrar
ejemplos concretos de cmo utilizar su funcionalidad.
Desventajas
Es recomendable
emplearlo
solo
en
JAVA
NETBeans
11.3.
JUnit
Es un API para realizar pruebas que fue diseado para ser empleado en JAVA. Un
aspecto importante es que cumple con la mayora de las recomendaciones realizadas por
XP en lo que a pruebas se refiere, de las cuales se destaca el permitir hacer pruebas
autnomas. Por otro lado, algunos autores lo recomiendan para desarrollar aplicaciones
en JAVA empleando XP.
11.4.
JasperReport e IReport
PostgreSQL
Se caracteriza por estar entre los motores de base de datos ms estables y robustos,
razones que motivaron su eleccin.
12. Tablas Comparativas de las Metodologas SCRUM y XP
12.1.
Semejanzas
Es un Agile Manifiesto.
Existen una Interaccin de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de Tiempo.
Trabajan en Equipo.
12.2.
Diferencias
Tabla 5. Comparacin entre Metodologas
SCRUM
XP(Programacin Extrema)
Las iteraciones de entregas son de 2 a 4 Las iteraciones de entrega son a 1 a 3
semanas.
Lo que se termina, funciona y este bien, se
semanas.
Las tareas q se van entregando a los
aparta y ya no se toca.
modificaciones.
Los miembros del programan en pareja en
forma individual.
El Scrum Team trata de seguir el orden de
un proyecto XP.
El equipo de desarrollo sigue estrictamente
por el cliente.
Se centra ms en la propia programacin o
proyecto.
recoge las necesidades del cliente. El equipo de desarrollo intentara entonces implementar
ese escenario en una entrega futura del software.
La participacin del cliente se lleva a cabo a travs del compromiso a tiempo completo del
cliente en el equipo de desarrollo. Los representantes de los clientes participan en el
desarrollo y son los responsables de definir las pruebas de aceptacin del sistema.
Practicas Bsicas del XP
De forma aislada, cualquier prctica individual de Xp tiene poco sentido, pero en conjunto,
unas compensan las carencias que las otras puedan tener.
Nos dice que para evaluar Xp hay que mirar la gran foto, es decir, todo el conjunto de
prcticas:
El objetivo del juego es maximizar el valor del software producido, La estrategia es poner
en produccin las caractersticas ms importantes lo antes posible, Las Piezas clave son las
Story Cards, Los Jugadores son los desarrolladores y el cliente y las Movidas son
Exploracin, Seleccin y Actualizacin.
Cada Proyecto es guiado por una historia simple de cmo funciona el sistema en general,
reemplaza a la arquitectura y debe estar en lenguaje comn, entendible para todos (Cliente
y Desarrolladores), esta puede cambiar permanentemente.
El sistema se disea con la mxima simplicidad posible (YAGNY - "No vas a necesitarlo"),
Se plasma el diseo en tarjetas CRC (Clase Responsabilidad - Colaboracin), no se
implementan caractersticas que no son necesarias, con esta tcnica, las clases descubiertas
durante el anlisis pueden ser filtradas para determinar qu clases son realmente necesarias
para el sistema.
Los casos de prueba se escriben antes que el cdigo. Los desarrolladores escriben pruebas
unitarias y los clientes especifican pruebas funcionales.
Refactorizacin (Refactoring)
El cdigo es escrito por dos personas trabajando en el mismo computador. "Una sola
maquina con un teclado y un mouse"
Nadie es dueo de un modulo. Cualquier programador puede cambiar cualquier parte del
sistema en cualquier momento, siempre se utilizan estndares y se excluyen los
comentarios, Los test siempre deben funcionar al 100% para realizar integraciones con todo
el cdigo permanentemente.
Los cambios se integran en el cdigo base varias veces por da. Todos lo casos de prueba se
deben pasar antes y despus de la integracin, se dispone de una maquina para la
integracin y se realizan test funcionales en donde participa el cliente.
Cada Trabajador trabaja no ms de 40 Horas por semana. Si fuera necesario hacer horas
extra, esto no debera hacerse dos semanas consecutivas. Sin hroes, esto hace que se
reduzca la rotacin del personal y mejora la calidad del producto.
El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual esta disponible para
responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy
Junior no sirve y un cliente muy Snior no es disponible. "Lo ideal es un cliente Analista".
Ciclo de Vida
Ahora nos describen cada una de las fases en las que se subdivide el 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
Cliente (Customer)
Entrenador (Coach)
Rastreador (Tracker)
Metric Man
Observa sin molestar
Conserva datos histricos
Probador (Tester)
Artefactos
A continuacin describimos los artefactos de Xp, entre los que se encuentran: Historias de
Usuario, Tareas de Ingeniera y Tarjetas CRC.
Historia de usuario
Representan una breve descripcin del comportamiento del sistema, emplea terminologa
del cliente sin lenguaje tcnico, se realiza una por cada caracterstica principal del sistema,
se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan
un gran documento de requisitos y presiden la creacin de las pruebas de aceptacin.
Historia de usuario
Numero:
Usuario
Iteracin Asignada :
Prioridad en negocio
Puntos estimados :
Riesgo en desarrollo :
(Alto / Medio / Bajo )
Descripcin:
Observaciones:
Puntos Reales:
Descripcin :
Condiciones de Ejecucin:
Resultado esperado:
Evaluacin de prueba:
Task Card
Tarea de Ingeniera
Nmero tarea
Nombre Tarea:
Tipo de Tarea:
Desarrollo
Puntos Estimados:
Correccin
Mejora
/Otra(especificar)
Fecha Inicio:
Fecha Fin:
Programador Responsable:
Descripcin
Estas tarjetas se dividen en tres secciones que contienen la informacin del nombre de la
clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cmo se
distribuye esta informacin.
Nombre de la Clase
Responsabilidades
Colaboradores
Encontrar clases
Encontrar responsabilidades
Definir colaboradores
Disponer las tarjetas
Para encontrar las clases debemos pensar qu cosas interactan con el sistema (en nuestro
caso el usuario), y qu cosas son parte del sistema, as como las pantallas tiles a la
aplicacin (un despliegue de datos, una entrada de parmetros y una pantalla general, entre
otros). Una vez que las clases principales han sido encontradas se procede a buscar los
atributos y las responsabilidades, para esto se puede formular la pregunta Qu sabe la
clase? y Qu hace la clase? Finalmente se buscan los colaboradores dentro de la lista de
clases que se tenga.
Captulo III
Conclusiones y Recomendaciones
14. Conclusiones
No existe una metodologa universal para hacer frente con xito a cualquier proyecto de
desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto
(recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Histricamente,
las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de
contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en
proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una
solucin casi a medida para una gran cantidad de proyectos que tienen estas caractersticas.
Una de las cualidades ms destacables en una metodologa gil es su sencillez, tanto en su
aprendizaje como en su aplicacin, reducindose as los costos de implantacin en un
equipo de desarrollo. Esto ha llevado hacia un inters creciente en las metodologas giles.
Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su
aplicacin, tales como: estn dirigidas a equipos pequeos o medianos (Beck sugiere que el
tamao de los equipos se limite de 3 a 20 como mximo, otros dicen no ms de 10
participantes), el entorno fsico debe ser un ambiente que permita la comunicacin y
colaboracin entre todos los miembros del equipo durante todo el tiempo, cualquier
resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede
llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la relacin contractual
son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no
soporten fcilmente el cambio, etc.
Falta an un cuerpo de conocimiento consensuado respecto de los aspectos tericos y
prcticos de la utilizacin de metodologas giles, as como una mayor consolidacin de los
resultados de aplicacin. La actividad de investigacin est orientada hacia lneas tales
como: mtricas y evaluacin del proceso, herramientas especficas para apoyar prcticas
giles, aspectos humanos y de trabajo en equipo. Entre estos esfuerzos destacan proyectos
como NAME12 (Network for Agile Methodologies Experience).
15. Recomendaciones
Debe hacerse lo posible por no realizar modificaciones a XP demasiado drsticas ya que se
corre el riesgo de alterar la esencia de la metodologa.
Debe plantearse una estrategia para afrontar el diseo de datos en XP.
Se deben afijar una serie de reglas generales en la comunicacin con el cliente ya que por el
grado de informalidad que la metodologa presenta puede surgir diferencias que pongan en
peligro la culminacin exitosa del proyecto.
Debe hacerse una capacitacin al cliente sobre XP antes de iniciar el proyecto debido que
este hace parte del equipo de desarrollo.
Plantear una estrategia especial de refactoring para las bases de datos.
Tener un buen conocimiento de las herramientas para la implementacin antes de iniciar
dicha etapa.
Plantear como unidad de tiempo horas en lugar de das para la asignacin de tareas.
Considerar el internet y herramientas basadas en l como mecanismos de comunicacin
vlidos dentro de XP y discutir la necesidad de un nico sitio geogrfico de trabajo.
Hacer una experiencia realizando un mismo proyecto por dos grupos de desarrollo
independientes empleando una metodologa pesada y XP con el fin de comparar los
resultados obtenidos.
Emplear XP en un proyecto de mayor envergadura con el fin de evaluar el desempeo de la
metodologa en ese tipo de proyectos.
Bibliografa
Beck, Kent. 2002. Una explicacin de la Programacin extrema: aceptar el cambio. s.l. :
Addison-Wesley Iberoamericana Espanya, S.A., 2002.
James Newkirk, Robert C. Martin. 2002. La Programacin Extrema en la prctica. s.l. :
Addison-Wesley Iberoamericana Espanya, S.A., 2002.
Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. 2000. Extreme
Programming Installed. s.l. : Addison-Wesley Pub Co; 1 edicin, 2000.