ITCR. Marn. Preparacin de reportes escritos informativos.

DESARROLLO GUIADO POR PRUEBAS (TEST DRIVEN DEVELOPMENT)

Y PROGRAMACIN EXTREMA (XP)
Eufemia Elizabeth Garca Henrquez
e-mail: egarcia5088@gmail.com
Jonathan Alexander Gmez Ruiz
e-mail: grjonathann@gmail.com
Sofia del Carmen Marroqun Castillo
e-mail: sofymarroca1291@hotmail.com
Lorena Margarita Ordoez Escobar
e-mail: mar.escobar1991@gmail.com
Walter Alexander Quintanilla Ruiz
e-mail: walteralex1992@gmail.com

contexto en el que surgen las metodologas giles, sus

RESUMEN: Las metodologas giles han ganado caractersticas, principios y comparaciones con las
popularidad desde hace algunos aos, ya que metodologas tradicionales. Adems se describe con
constituyen una buena solucin para proyectos a corto mayor detalle Programacin Extrema (eXtreme
plazo, que se basan en la adaptabilidad de cualquier Programming, XP) la metodologa gil ms popular en la
actualidad y el Test Driven Development (TDD).
cambio como medio para aumentar las posibilidades de
xito de un proyecto. Test Driven Development, o TDD
como se lo conoce ms a menudo, es un proceso de
desarrollo de software que se basa en la idea de 2 OBJETIVOS
desarrollar pruebas, codificar y refactorizar el cdigo
construido. TDD establece que primero hay que realizar 2.1 OBJETIVOS GENERALES
una prueba y a continuacin desarrollar el cdigo que la
resuelve. Se abordar TDD en general, y se analizarn
Investigar sobre las metodologas giles
las ventajas de su aplicacin. Programacin Extrema
Extreme Programming (XP) y Test Driven
(eXtreme Programming, XP) es una de las llamadas Development (TDD), utilizadas para el
metodologas giles de desarrollo de software ms desarrollo de software.
exitosas de los ltimos tiempos. El presente trabajo
presenta un resumen de las caractersticas ms 2.2 OBJETIVOS ESPECIFICOS
destacables de esta metodologa, incluyendo las fases
de su ciclo de vida. Diferenciar la metodologa gil con la
metodologa tradicional.

PALABRAS CLAVE: gil, Desarrollo de Software, Proporcionar una visin de las metodologas
agiles Test Driven Development y
Programacin Extrema, Test Driven Development, TDD,
Programacion Extrema para el desarrollo de
XP.
software.
1 INTRODUCCIN Identificar las fases y ciclos de vida que cada
metodologa presenta.
El desarrollo de software no es una tarea fcil.
Prueba de ello es que existen numerosas propuestas Comprender los conceptos y las palabras
metodolgicas que inciden en el proceso de desarrollo. claves de ambas metodologas.
Por una parte tenemos aquellas propuestas ms
tradicionales y las metodologas giles, las cuales dan 3 METODOLOGIA AGIL.
mayor valor al individuo, a la colaboracin con el cliente
y al desarrollo incremental del software con iteraciones
El desarrollo gil de software se ha usado en la
muy cortas. Este enfoque est mostrando su efectividad
toma de decisiones en los proyectos de software,
en proyectos con requisitos muy cambiantes y cuando
tomndolo como un mtodo de ingeniera del software
se exige reducir drsticamente los tiempos de desarrollo
cuya base es el desarrollo iterativo e incremental, donde
pero manteniendo una alta calidad. Las metodologas
los requisitos y soluciones evolucionan con el tiempo
giles estn revolucionando la manera de producir
segn la necesidad del proyecto. Estos modelos son
software. En este trabajo se presenta resumidamente el

1
ITCR. Marn. Preparacin de reportes escritos informativos.
.

creados en respuesta a las debilidades del modelo (o entregas frecuentes), suelen ser especialmente
tradicional de cascada, que no es ms que un conjunto equipos pequeos (< 10 efectivas/usadas en
de tareas agrupadas en pequeas etapas repetitivas integrantes) y trabajando proyectos grandes y con
(iteraciones). En este caso, lo que conlleva la realizacin en el mismo sitio equipos posiblemente
de un software se hace mediante la colaboracin de
equipos auto-organizados y multidisciplinarios, inmersos
dispersos
en un proceso compartido de toma de decisiones a corto La arquitectura se va Se promueve que la
plazo. definiendo y mejorando a arquitectura se defina
lo largo del proyecto tempranamente en el
Los mtodos agiles enfatizan las comunicaciones proyecto
cara a cara en vez de la documentacin. La mayora de nfasis en los aspectos nfasis en la definicin
los equipos agiles estn localizados en una simple humanos: el individuo y del proceso: roles,
oficina abierta, a veces llamadas bullpen. La oficina el trabajo en equipo actividades y artefactos
debe incluir revisores, diseadores de iteracin,
escritores de documentacin y ayuda y directores de Basadas en heursticas Basadas en normas
proyecto. Los mtodos agiles tambin enfatizan que el provenientes de prcticas provenientes de
software funcional es la primera medida del progreso. de produccin de cdigo estndares seguidos por el
Combinado con la preferencia por las comunicaciones entorno de desarrollo
cara a cara, generalmente los mtodos agiles son Se esperan cambios Se espera que no ocurran
criticados y tratados como indisciplinados por la falta durante el proyecto cambios de gran impacto
de documentacin tcnica. durante el proyecto

3.2 PRINCIPIOS DEL MANIFIESTO GIL

El trmino "gil" se aplic a esta coleccin de

metodologas a principios de 2001 cuando 17 expertos
en desarrollo de software se reunieron en Utah, para
discutir sus ideas compartidas y diversos enfoques para
el desarrollo de software. El Agile Alliance se form
poco despus de esta reunin para alentar a los
profesionales a explorar y compartir ideas y
experiencias. Esta conjunto de valores y principios se
expres en el Manifiesto para el desarrollo gil de
software y las correspondientes doce principios .

1. Nuestra mxima prioridad es satisfacer al

cliente a travs de entregas tempranas y continuas de
software valioso.

2. Los requisitos cambiantes son bienvenidos,

3.1 COMPARACION DE METODOLOGIAS
TRADICIONAL VS GILES
Tabla 1. Diferencias entre metodologas tradicionales y giles
Desarrollo Tradicional
Pocos Artefactos. El
modelado es prescindible,
modelos desechables.
Pocos Roles, ms
genricos y flexibles
No existe un contrato
tradicional, debe ser
bastante flexible
Cliente es parte del equipo
de desarrollo (adems in-
situ)
Orientada a proyectos
pequeos. Corta duracin
Desarrollo gil
Ms Artefactos. El
modelado es esencial,
mantenimiento de
modelos
Ms Roles, ms
especficos
Existe un contrato
prefijado
El cliente interacta con el
equipo de desarrollo
mediante reuniones
Aplicables a proyectos de
cualquier tamao, pero
incluso en las etapas finales del desarrollo. Los procesos
giles aprovechan al cambio para ofrecer una ventaja
competitiva al cliente.
3. Entregamos software que funciona
frecuentemente, entre un par de semanas y un par de
meses. De hecho es comn entregar cada tres o cuatro
semanas.
4. Las personas del negocio y los desarrolladores
deben trabajar juntos diariamente a lo largo de todo el
proyecto.
5. Construimos proyectos en torno a individuos
motivados. Dndoles el lugar y el apoyo que necesitan y
confiando en ellos para hacer el trabajo.
6. El mtodo ms eficiente y efectivo de
comunicar la informacin hacia y entre un equipo de
desarrollo es la conversacin cara a cara.

2
ITCR. Marn. Preparacin de reportes escritos informativos.
.

7. La principal medida de avance es el software

que funciona.
8. Los procesos giles promueven el desarrollo
sostenible. Los patrocinadores, desarrolladores y
usuarios deben poder mantener un ritmo constante.
9. La atencin continua a la excelencia tcnica y
el buen diseo mejora la agilidad.
Obviamente la gracia de ejecutar la prueba
despus de crearla es ver que esta falla y que ser
necesario hacer algo en el cdigo para que este pase.
A continuacin, solo es necesario volver a aplicar el
proceso descrito anteriormente hasta haber resuelto la
funcionalidad o funcionalidades que se deban
implementar.

10. La simplicidad es esencial. A dems una vez pasada la prueba es necesario

revisar el cdigo, por si requiere refactorizar. Si es el
11. Las mejores arquitecturas, requisitos y diseos caso, se revisar, corregir y se ejecutaran las pruebas
emergen de la auto-organizacin de los equipos. unitarias, de nuevo.

12. A intervalos regulares, el equipo reexiona
sobre cmo ser ms eficaces, a continuacin mejoran y
ajustan su comportamiento en consecuencia
4 DESARROLLO GUIADO
PRUEBAS (TDD).
Es importante tener presente que solo se crea un
test por iteracin y solo se implementa el cdigo mnimo
necesario para resolver ese caso. No es bueno que se
emocione implementando y desarrollando ms de lo
POR necesario para resolver el caso de prueba. Si se va por
las ramas desarrollando ms casos, se perder una gran
parte de la eficacia de este mtodo.

El Desarrollo Dirigido por Tests (Test Driven

Development), al se le llama TDD, es una tcnica de
diseo e implementacin de software incluida dentro de
la metodologa XP.
TDD es una tcnica para disear software que se
centra en tres pilares fundamentales:
La implementacin de las funciones
justas que el cliente necesita y no ms.
La minimizacin del nmero de defectos
que llegan al software en fase de
produccin.
4.2 CICLOS DE DESARROLLO DE TDD
Elegir un requisito a desarrollar.
Crear la prueba o test.
Ejecutar los tests: falla (ROJO).
Crear cdigo especfico para resolver el test.
Ejecutar de nuevo los tests: pasa (VERDE).
Refactorizar el cdigo.
Ejecutar los tests pasa (VERDE).

La produccin de software modular,

altamente reutilizable y preparado para el
cambio.

Cuando se empieza a leer sobre TDD se cree que

se trata de una buena tcnica para que el cdigo tenga
una cobertura de tests muy alta, algo que siempre es
deseable, pero es realmente una herramienta de diseo
que convierte al programador en un oficial de primera.
O, sin muchas metforas, convierte al programador en
desarrollador. TDD es la respuesta a las grandes
preguntas de:

Cmo lo hago?, Por dnde empiezo?, Cmo s

qu es lo que hay que implementar y lo que no?, Cmo
escribir un cdigo que se pueda modificar sin romper
funcionalidad existente?
4.1 COMO AFRONTAR TDD
El mtodo a seguir es sencillo, consiste en elegir
uno de los requisitos a implementar, buscar un primer
ejemplo sencillos del requisito, crear una prueba unitaria,
ejecutar la prueba para, implementar el cdigo mnimo
para superar la prueba y ejecutar de nuevo la prueba
para ver que se supera.
4.2.1 TEST
Las pruebas se escriben antes de escribir el propio
cdigo, y las mismas son escritas por los propios
desarrolladores, esto busca que los mismos logren un
entendimiento de lo que deben desarrollar mediante la
construccin del cdigo que lo va a probar.
4.2.2 CODIGO
Las pruebas deben ser escritas en cdigo, y esto
permite que se ejecuten automticamente las veces que

3
ITCR. Marn. Preparacin de reportes escritos informativos.
.
sea necesario, y el solo hecho de ejecutar las pruebas
debe mostrar si la ejecucin fue correcta o no.
4.2.3 REFACTORIZAR
Permite mantener la calidad de la arquitectura, se
cambia el diseo sin cambiar la funcionalidad,
manteniendo las pruebas como reaseguro.
La refactorizacin permite mantener el diseo del
cdigo limpio, mejorando su mantenibilidad. Otro
aspecto que posibilita la refactorizacin es la eliminacin
de la duplicacin de cdigo, lo cual trae como
consecuencia reducir la dependencia en el cdigo.
En palabras de Kent Beck: Nunca escribas una
nueva funcionalidad sin escribir primero una que falle
[1]. Por otra parte Dave Chaplin expresa Si no se
puede escribir una prueba para el nuevo cdigo,
entonces no se debera estar pensando en incorporar el
nuevo cdigo [2].
Estos dos axiomas de TDD implican que ninguna
nueva funcionalidad se debe escribir por adelantado,
sino que es necesario previamente contar con las
pruebas que permiten verificar que es correcta. Y como
se deben escribir las pruebas de a una a la vez,
tenemos de esta manera un proceso de desarrollo
incremental extremo. Es por esto ltimo que Kent Beck
defini a TDD como el corazn de la metodologa XP
(que se ver ms adelante).
4.3 VENTAJAS DEL TDD
4.3.1 Mayor calidad
.
Garantiza que las pruebas se ejecutan (no sean
omitidas), evitando que las aplicaciones tengan fallas la
primera vez que el usuario las ejecuta o que el usuario
encuentre los errores, en lugar de ser encontrados por el
equipo de desarrollo.
Asimismo, el hacer pruebas en etapas tempranas
del desarrollo es una forma de incorporar la calidad al
proceso, resultando en menos errores (bugs) en las
etapas finales del proyecto.
4.3.2 Diseo enfocado en las necesidades
El escribir las pruebas primero que el cdigo, obliga
a que las necesidades reales del cliente sean
consideradas primero, obligando a analizar primero qu
es lo que realmente se necesita que el cdigo haga y no
al contrario. Como resultado, habr menos trabajo
despus.
4.3.3 Mayor simplicidad en el diseo
Bajo TDD, en lugar de enfocarse en realizar
diseos extensos y complejos, el equipo se enfocar en
la necesidad o requerimiento del cliente, agregando
solamente la funcionalidad que el cliente necesita. Esto
4
es muy importante, pues es la complejidad la que
produce los errores.
Esto obliga a escribir cdigo enfocado en las
necesidades del usuario, evitando anti patrones como
los objetos multipropsito (clase gorda) o el
acoplamiento del cdigo, dado que desarrollarn
cdigos especficos a los requerimientos que se estn
atendiendo en esa iteracin
4.3.4 El diseo se va adaptando al entendimiento del
problema
A medida que se realizan iteraciones de probar y
programar, el entendimiento del problema se
incrementa, de esta forma, sucesivas iteraciones
cuentan con un mayor entendimiento, lo que reduce los
malos entendidos de la funcionalidad al final del
desarrollo, resultando en menos trabajo.
4.3.5 Mayor productividad
.
En un proyecto tradicional, generalmente lo que
sucede es que al principio se es muy productivo, sin
embargo, esa productividad cae hacia el final del
proyecto, cuando empiezan a encontrarse errores en
todas partes, se encuentran malentendidos en lo que el
cliente quera, o cuando el cliente hace un par de
cambios desestabilizadores.
En contraposicin a este esquema, una de las
principales ventajas de TDD es que se obtiene
retroalimentacin (feedback) inmediato sobre el software
desarrollado.
Trabajando bajo TDD, al principio es algo
improductivo, pues se necesita escribir una serie de
casos de prueba que fallaran al primer intento, sin
embargo, los beneficios se hacen evidentes cuando se
ha probado constantemente la aplicacin, se han
corregido los errores de forma temprana y de han
aclarado de forma temprana las dudas en la
funcionalidad.
4.3.6 Menos tiempo invertido en debugging de
errores
El cdigo se va desarrollando por piezas pequeas,
por ende, cuando surge un error, los esfuerzos se
enfocan en la pequea pieza de cdigo que fue
modificada, por lo que se le pueden llegar a los
problemas de forma ms directa.
4.4 POSIBLES PROBLEMAS DEL TDD Y
SUS SOLUCIONES
4.4.1 Interfaz de usuario
TDD es difcil de implementar en la capa de interfaz
de usuario (presentacin), debido a que est actividad
contiene elementos que contienen a alargar el ciclo de
ITCR. Marn. Preparacin de reportes escritos informativos.
.
prueba y desarrollo. En su lugar, TDD encaja ms
fcilmente en los desarrollos en las capas de lgica de
negocios (objetos y dominio) y acceso a datos. Por
ende, pueden existir reservas respecto a aplicar TDD en
una aplicacin con alto grado de interaccin con el
usuario.
Sin embargo, esto no es necesariamente algo
malo, dado que la metodologa obliga a separar las
capas y a no implementar lgica de negocio en la capa
de presentacin, lo cual sera un anti patrn.
4.4.2 La base de datos
Uno de los principales problemas de usar TDD en
aplicaciones con bases de datos, es que una vez que se
ha ejecutado una prueba, la base de datos puede
quedar en un estado distinto al que se necesita para
hacer la siguiente prueba (por ejemplo, si la aplicacin
necesita cambiar el valor de un campo de A a B, cuando
la prueba termina el valor queda en B, por lo que no se
puede ejecutar una siguiente prueba).
Una forma de abordar este problema es escribir
cdigo para inicializar la base de datos en el estado
previo, sin embargo, esto aade carga de trabajo
adicional.
Otra solucin es utilizar objetos para representar la
base de datos, por medio de objetos cascaron,
respuestas predefinidas o dummies que emulen las
respuestas de la base de datos.
4.4.3 Errores no identificados
Slo por el hecho de pasar todas las pruebas en la
herramienta que se utilice (JUNIT por ejemplo), no
significa que no se tengan errores, slo significa que las
pruebas que se han ejecutado no han encontrado
errores. El utilizar TDD podra llevar a un falso
sentimiento de seguridad, por ende, se necesita
enfocarse en que las pruebas sean detalladas y cubran
todos los escenarios posibles.
4.4.4 Perder la visin general
TDD es un enfoque de abajo hacia arriba (Bottom-
Up), y se debe estar al tanto que podra perderse
visibilidad general del proyecto y del aplicativo. Es una
buena idea mantener un modelo general (bajo un
enfoque tradicional como UML) y revisarlo de vez en
cuanto, quizs se encuentren oportunidades para re
factorizar y hacer que la aplicacin se le pueda dar
mantenimiento en el tiempo.
4.4.5 Pronunciada curva de aprendizaje
TDD es difcil de adoptar, por lo que puede
esperarse un descenso en la productividad durante los
primeros dos meses de implementacin. Lo
recomendable para enfrentar esto es buscar ayuda, por
5
medio de formacin (cursos) y consultoras que apoyen
en la adopcin de la nueva forma de trabajo
5 PROGRAMACION EXTREMA (XP)
Al igual que TDD, la programacin extrema es un
enfoque de la ingeniera de software formulado por Kent
Beck, autor del primer libro sobre la materia, Extreme
Programming Explainned: Embrace Change (1999). Es
el ms destacado de los procesos agiles de desarrollo
de software.
Se centra en potenciar las relaciones
interpersonales como clave para el xito en desarrollo
del software, promoviendo el trabajo en equipo,
preocupndose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo.
La programacin extrema se basa en la
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.
Entonces, Qu es programacin extrema?
Bsicamente la programacin extrema se base en
cuatro valores:
Comunicacin
Comunicacin total a todos los niveles de trabajo.
Se trabaja en grupos de dos personas por ordenador
pero con total comunicacin en todos los momentos
entre todos los grupos.
Al trabajar en pareja, se suele efectuar rotaciones
de puesto regularmente, lo que implica que el cdigo es
propiedad de todos y no solo de una pareja, promueve
tambin la comunicacin de conocimiento tcnico
entorno al equipo. Cuando haya un problema tcnico,
aparece entonces todo el equipo para formar parte de la
solucin de este.
La programacin en pareja es excelente para las
personas con diversas habilidades, permitiendo as que
las personas que cuenten con menos nivel, sean
guiadas por personas con una mayor experiencia, as el
riesgo de aadir cdigo de personas menos
experimentadas se reduce drsticamente.
Simplicidad
Lo ms simple est en mente. El cliente es que
tiene la ltima palabra en XP. Hacer lo que el cliente
necesite, tan simple como sea posible y nada ms.
Este valor se basa en el hecho de que el futuro, a
nivel de requerimientos, no forma parte del proyecto.
Solo nos debemos de ocupar de cubrir las necesidades
inmediatas, partiendo de que los supuestos carecen de
ITCR. Marn. Preparacin de reportes escritos informativos.
.
fiabilidad, lo que conlleva a una posible prdida de
dinero.
Feedback
Bsicamente el continuo contacto con el usuario, al
irle entregando las versiones, en funcionamiento del
producto, permite que ste nos de su valoracin y nos
comunique, cada vez mejor, lo que realmente quiere en
el producto.
Al hacer test, se busca encontrar un error y
arreglarlo al mismo tiempo en que es introducido por el
equipo. Las unidades de test son escritas por la mayora
de los mdulos del cdigo, dichos test deber ser
ejecutados en totalidad para que nuestro modulo sea
registrado en nuestro proyecto.
Al escribir estas pruebas de aceptacin con el
cliente para verificar la aplicacin, se va haciendo
aquello que el cliente necesita de la aplicacin.
Coraje
Es trabajar muy duro durante las horas dedicadas a
ello.
En algunas ocasiones, XP adopta la torpe visin de
que todos encuentran fascinante la aplicacin como sus
desarrolladores, pero muchos usuarios finales no
desean que sus aplicaciones luzcan y funcionen de
forma diferente cada vez que se la usan, y prefieren no
recibir pequeos avances.
Aunque la metodologa est basada en las duras
realidades y los inconvenientes del desarrollo del
software, ofreciendo muchas soluciones con sentido
comn, XP puede no ser la palabra final en la evolucin
del desarrollo de software, aunque ciertamente es un
paso a la direccin correcta.
5.1 ANALISIS Y DISEO
Al considerar la programacin extrema como una
metodologa para el desarrollo de software, no debemos
obviar las tareas tpicas previas a la implementacin del
cdigo en s. Tanto el anlisis como el diseo son tareas
muy importantes en la programacin extrema, pero se
realizan con un enfoque ms ligero y transparente.
El anlisis es parte fundamental, que intenta
recoger en l todas las necesidades del usuario. De aqu
surgen las user stories que sirven para empezar a
desarrollar nuestro sistema.
5.1.1 USER STORIES
Las user stories tienen algo que ver con los casos
de usos utilizados en el ciclo incremental de desarro0llo
de software. Pero esta similaridad se base en que su
cometido es el mismo, sirven para hacer las mismas
cosas, pero no son lo mismo. Sustituyen los largos
6
requerimientos por una serie de user stories y adems
permiten hacer una estimacin del tiempo para la
reunin de lanzamientos de las futuras versiones de
nuestro sistema.
5.1.2 PRUEBAS DE ACEPTACION
Luego de que la historia de usuario tenga la
informacin suficiente, el cliente y el programador hayan
discutido la historia para ampliar los detales, se crean las
pruebas de aceptacin. Estas permiten confirmar que las
user stories ha sido implementada y comprendidas
correctamente. Las pruebas de aceptacin aseguran el
comportamiento del sistema, son escritas por el cliente o
usuario y especifican los aspectos a probar cuando una
historia de usuario ha sido correctamente implementada.
5.1.3 TASK CARD (TAREA DE INGENIRIERIA)
Describen las tareas a desempear sobre el
proyecto, manteniendo relacin con una historia de
usuario. Los aspectos de su elaboracin son:
Identificacin y nombre de la tarea.
Tipo de tarea:
desarrollo/correccin/mejora/otros.
Fecha de inicio-fin.
Responsable.
Descripcin.
5.1.4 TARJETA CRC
Su nombre es un acrnimo de Clase,
Responsabilidades y Colaboradores. En esta tarjeta se
expresa el diseo del sistema a partir de sus
componentes:
Clase: Se nombra a cualquier persona,
reporte, evento u objeto del proyecto.
Responsabilidades: se detallan sus
atributos, mtodos.
Colaboradores: clases con las que
interacta para realizar sus
responsabilidades.
Cmo crearlas?
Para ello se utilizara tarjetas de cartulina sin lneas
en ellas, de un tamao determinado, usualmente 4x6 o
5x8. Es conveniente tener muchsimas tarjetas en blanco
para trabajar sobre ellas. Han de ser fsicas, no valiendo
tenerlas almacenadas en el ordenador ni en ningn otro
medio.
A la hora de crearlas, el jefe del proyecto debe
proporcionar una mesa, en general se usa la mesa
dnde se realizan las reuniones de apertura. En esta
mesase sentara el cliente o los clientes (generalmente
dos), un grupo de dos programadores, se dispondrn de
las tarjetas en blanco en la que todos escribirn mientras
dialogan acerca de las necesidades del sistema.
ITCR. Marn. Preparacin de reportes escritos informativos.
.
El proceso se va realizando en cuanto el cliente
anuncia una necesidad y se habla sobre ella, intentando
que no existe ningn punto oscuro. Una vez escritas las
tarjetas, se evaluaran entre todos, refinndolas, para lo
cual se usaran nuevas tarjetas. Es decir, si la tarjeta
presenta una tarea complicada, que requiere un tiempo
mayor, se proceder a la creacin de nuevas tarjetas
que sern el resultado de dividir la tarea inicial en tareas
ms pequeas.
5.2 ROLES
Se concuerda con la informacin que se ha ido
recompilando que los roles de programacin, y de
acuerdo con la propuesta original de Beck son:
Programador.
El programador escribe las pruebas unitarias y
produce el cdigo del sistema. Debe existir
comunicacin y coordinacin 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 cuales se implementan en cada interaccin.
El cliente debe resolver cualquier duda de cualquier
desarrollador acerca de lo que este quiere conseguir con
una determinada tarea.
El cliente es solo uno dentro del proyecto pero
puede corresponder a un interlocutor que est
7
representando a varias personas que se vern afectadas
por el sistema.
Como conclusin, se podra decir que la clave para
un desarrollo correcto al 100% es la coordinacin entre
los programadores y el cliente.
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 en las
estimaciones realizadas y el tiempo real dedicado,
comunicando con 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 cuando es necesario realizar algn cambio
para lograr los objetivos de cada iteracin.
Entrenador (Coach)
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
practicas XP y se siga el proceso correctamente.
Consultor
Miembro externo del equipo con un conocimiento
especfico en algn tema necesario para el proyecto.
Gua al equipo para resolver un problema especfico.
Gestor (Big Boss)
Vnculo entre clientes y programadores, ayuda a
que el equipo trabaje efectivamente, creando las
condiciones adecuadas.
Es el defensor de los derechos del cliente, lo cual
es cierto, ya que debe ser quien controle que se
cumplan ciertos requisitos.
1. Ofrece al cliente una visin global del sistema,
para que ste sepa que es lo que se va a
hacer.
2. Ofrece dinamismo al cliente, para que este vea
un sistema en evolucin.
3. Ofrece al cliente la posibilidad de cambiar los
requerimientos a un coste no exorbitante.
ITCR. Marn. Preparacin de reportes escritos informativos.
.
4. Tener informado constantemente al cliente del
calendario del proyecto, as como de los
posibles retrasos, para que este pueda realizar
las modificaciones que considere oportunas.
El gestor, en primera instancia, su razn de ser es
la de causar, conseguir que las cosas ocurran siendo
el desencadenante de todos los procesos necesarios
para el desarrollo del proyecto. En alguna forma, el
gestor debe ser la chispa que haga que inicie cualquier
tarea en el proyecto.
Es evidente que el gestor debe coordinar a todo el
equipo, pero adems, es el quien debe distribuir en
cierta medida la carga de trabajo, evitar que sea realicen
trabajos ms de una vez. Debe controlar que el equipo
este bien, no exista fisuras internas, intentando arreglar
cualquier problema entre los miembros del equipo.
Aunque en la XP, se propone eliminar todos los
papeleos que sean intiles al 100%, siempre queda una
parte que es necesaria. La ms preciada es la que se
recopila con las user stories, pero adems de esta
documentacin, el gestor tiene que tener presente
reportar la documentacin de terceras partes, bien por
requerimientos del cliente o por otro tipo de
necesidades.
Siempre se debe minimizar la carga de trabajo que
necesiten estas actividades por ser consideradas como
no productivas, pero nunca se deben olvidar.
El gestor debe planificar las recompensas que se
ofrecern en caso de xito, en caso de un xito
absoluto, casos en el que trabajo ha sido excelente.
Otra labor importante del gestor, es eliminar
cualquier obstculo al equipo de desarrollo. Por
obstculos entendemos cualquier cosa que entorpezca
al programador, desde la tozudez del usuario, sus
prioridades, hasta problemas debidos a la
infraestructura, problemas con la red, etc.
5.3 PRINCIPIOS
La programacin extrema como hemos
mencionado, sigue una serie de reglas para la creacin
de software. Estos no son fijos ni obligatorios y por estos
pueden surgir discusiones sobre la necesidad de una o
varias reglas.
Son doce fundamentos principales que se pueden
denominar como los doce mandamientos de la
programacin extrema:
5.3.1 Planificacin
Para realizar un buen trabajo es necesario
planificarse bien. Esto de se traduce como:
No se empieza el anlisis hasta que no se
tiene la user stories.
8
Los programadores nunca debern tomar
decisiones que consten en el diseo y se
debern ajustar solo a l.
Adems, el equipo de trabajo nunca
deber incluir funcionalidades que no
consten en el diseo. Esto es debido a
que son funcionalidades que posiblemente
gusten al cliente pero que puede que en
sucesivas vueltas atrs y en revisiones
por parte del cliente del programa decida
retocarlas o cambiar su funcin, con lo
que har falta retocar un cdigo que en un
principio no debera haber existido hasta
que el cliente lo necesitase. Por otro lado,
puede resultar trabajo intil y no
reconocido por lo que es mejor no salirse
de las especificaciones y no regalar
esfuerzo y trabajo a nadie.
5.3.2 Sistema metafrico
A la hora de desarrollar cdigo, puede surgir el
problema de nombrar mtodos, funciones, variables,
relaciones, etc de un modo coherente y que todos los
componentes del equipo lo entiendan.
No se debe dejar este tema a la improvisacin de
cada uno.
Los identificadores debern ponerse en
arreglo a unas ciertas reglas
preestablecidas con anterioridad por el
grupo.
Con esto conseguimos:
No perder tiempo valioso de programacin
en pensar un nombre para un mtodo
similar. Gracias al sistema metafrico el
nombre viene rodado.
Que el resto del equipo no dude sobre el
nombre de un mtodo de un paquete
desarrollado por otros componentes.
Entonces como puede verse ahorramos tiempo por
dos vas: La de creacin y la de consulta este
fundamento de la XP ayuda a mantener el cdigo limpio
y aumenta su simplicidad.
5.3.3 Programacin en parejas
Aunque la programacin en parejas suele ser
asociado con XP, es una prctica independiente y
aplicable a cualquier metodologa.
As, la programacin del cdigo se realizar en
parejas frente a un solo ordenador. Se hace as todo el
tiempo y no solo cuando un programador necesite ayuda
para realizar tal mtodo o para averiguar la razn de
porqu falle el cdigo.
ITCR. Marn. Preparacin de reportes escritos informativos.
.
Mientras uno desarrolla cdigo el otro
realiza una revisin inmediata.
Se evitarn la mayora de los errores de
programacin debido a que habr en todo
momento una persona dedicada
ntegramente a buscar errores en tiempo
de escritura del cdigo.
La programacin ser ms fluida pues el
desarrollador no tendr que estar al tanto
de encontrar sus errores ya que tendr a
su lado a otro programador que conocer
el diseo de lo que se est programando y
por lo tanto sabr reconocer un error.
El cdigo generado no contendr errores
sintcticos y posiblemente tampoco
errores semnticos y habr sido realizado
en un corto periodo de tiempo.
Los programadores (algo muy importante)
permanecern ms despejados durante el
tiempo de trabajo.
Se aprende a trabajar en equipo.
En cuanto a las exigencias de un cliente, la
programacin en parejas tiene a su favor:
El cliente siempre exige calidad y rapidez.
Quiere las cosas, tpicamente, para ayer.
Eso s, la programacin en parejas presenta como
mayor desventaja en la implementacin. Es decir, la
programacin en parejas es una actividad ventajosa,
pero conseguir su implantacin en un equipo es algo
que puede resultar dificultoso, sobre todo si el equipo no
est acostumbrado a este tipo de tcnica.
5.3.4 40 Horas por semana
Es la dedicacin plena al proyecto, en este punto
no hace falta dedicar largas jornadas de duro trabajo,
pues esto no es garanta de acabar antes. Posiblemente
largas jornadas de trabajo provocaran errores.
La programacin extrema se basa en 40 horas por
semana. De tal forma se evita que los programadores se
fatiguen y que las horas de trabajo sean horas altamente
productivas.
5.3.5 Versiones pequeas
Lo ideal sera que el cliente o usuario tuviese una
imagen clara y concisa de lo que quiere y como lo
quiere, es habitual que este sepa cmo lo quiere pero
carezca del conocimiento para expresas las
funcionalidades.
Las versiones pequeas incluyen funcionalidades
bsicas requeridas por el cliente que forman un conjunto
mnimo de tal forma que la aplicacin funciona. As:
9
El cliente puede ver regularmente cmo
evoluciona el software introduciendo
continuos en los requerimientos.
La vuelta atrs siempre ser ms fcil con
versiones cortas que con versiones que
contienen un gran nmero de
modificaciones que las anteriores.
Evita que el cdigo se descontrole
rpidamente y facilita la claridad y la
sencillez tanto del diseo como del cdigo
del programa.
5.3.6 Diseos simples
El diseo es la base para el buen funcionamiento
del equipo. Un diseo correcto en todo momento es
aquel que cumple los siguientes requisitos reflejados en
el programa resultante.
Ejecuta correctamente todo el diseo de
pruebas.
El programa funciona correctamente y
muestra los resultados esperados.
No contiene cdigo redundante y
aprovecha al mximo las capacidades de
la mquina.
La forma ms simple de aglutinar todos
los requerimientos.
5.3.7 Testeos continuos
No se debe programar nada de cdigo sin haber
realizado antes los diseos de las pruebas. Las pruebas
deber ser capaces de verificar el buen funcionamiento
de todos los requerimientos solicitados por el cliente.
Siempre es ms fcil solucionar un problema
cuando el cdigo no es muy extenso o cuando se hace
cada poco tiempo.
La XP cuenta con programacin en parejas, esta
se realiza por parejas donde un programador pica el
cdigo y el otro va revisando en tiempo real, ideando
mejoras y buscando errores. De esta forma se mejora la
correccin del cdigo en tiempo real, pero sobre todo
favorece al periodo obligado de testeo.
Un buen programador debe hacerse cargo de la
importancia que tienen las pruebas sobre el normal
desarrollo de un proyecto. Todos se equivocan y es
imposible realizar un cdigo de cierta amplitud a la
primera sin cometer errores y por este un buen
programador sabe de la importancia de realizar
continuas pruebas de su cdigo y continuas
depuraciones y mejoras.
Para la XP, los testeos del programa son ms
importantes si cabe que para otras metodologas.
Gracias al testeo continuo, la labor de modularizar y
ITCR. Marn. Preparacin de reportes escritos informativos.
.
empaquetar el proyecto en subprogramas totalmente
funcionales se ve fuertemente favorecida.
Otro punto importante es que el momento perfecto
para encontrar un error en el cdigo. Cualquier momento
sirve, pero como es lgico pensar cuanto antes se den
cuenta de un error cometido, mejor ir en el proyecto.
Esto es debido a que cuanto ms fresco se tenga
el cdigo, ms fcil ser interpretar el error, descubrir
sus causas, sus dependencias y sus consecuencias en
el resto del cdigo.
A parte de las pruebas realizadas en funcin de los
requerimientos funcionales del proyecto, cuando se
acabe de programar el cdigo, posiblemente se ocurra
distintas pruebas en funcin del cdigo realizado y que
ayudaran a que el conjunto de pruebas sea completo.
Realizar pruebas continuas sobre nuestro cdigo
nos reporta para empezar una mayor fiabilidad y
estabilidad en el trabajo de programacin realizado
hasta el momento. Esto significa que al realizar las
pruebas correctamente y con resultados esperados
sobre el cdigo se tendr como resultado un mdulo
entero programado de forma correcta, que funciona
ahora y que funcionara siempre, independientemente de
donde lo incluyamos.
El funcionamiento de un programa realizado en XP,
nunca puede depender del entorno o lenguaje de
programacin usados para su creacin. Tampoco
debera depender en gran medida de la maquina donde
pretende correr. Los programas deberan depender
nica y exclusivamente de los requerimientos
pretendidos por el cliente.
Ahora, no siempre las pruebas pueden ser un
apoyo o ayuda para la realizacin del cdigo, un
conjunto de pruebas es tan importante como el cdigo
que pretende testear. Las pruebas deben estar bien
diseadas y bien redactadas pues es peor lanzar
pruebas errneas sobre el programa, que no lanzar
ninguna.
5.3.8 Refactoring
El cdigo debe ser simple y claro. Esto provoca el
huir del cdigo duplicado.
El cdigo duplicado complica la tarea de
programacin por diversas causas, una de ellas es que
ensucia el programa hacindolo ms largo de lo
estrictamente necesario. Con esto aumenta las
posibilidades de tener errores, y hace incomprensible o
de difcil lectura el programa.
En ocasiones, cuando una nueva historia de
usuario va a ser implementada, es normal que los
objetos existentes deban ser estructuralmente
cambiados o incluso debamos crear nuevos objetos.
Para entonces, se discutir la necesidad de refactorizar
por parte del equipo, que confirme la validez o no de
dicho proceso.
10
El mecanismo es el siguiente:
Una vez se empiece a trabajar en la
nueva estructura del objeto y cuando se
est conforme, ser publicado al equipo
de programacin.
Dada la aprobacin, la pareja comenzara
con la implementacin del nuevo objeto, el
cdigo existente de ese nuevo ser
incluido de nuevo en el objeto, donde la
nueva funcionalidad no est todava
incluida.
Una vez terminada la nueva funcionalidad,
la pareja comenzara con la fase de
pruebas.
Se cambian todas las invocaciones y se
ejecuta todos los mtodos de integracin
de ambos componentes, que sern
analizados por la propia pareja de
creacin de la nueva funcionalidad.
Las nuevas funcionalidades son adheridas
al proyecto y la secuencia de codificacin
y anlisis normal sigue en curso.
En este punto es importante sealar que la
refactorizacin es indispensable en la fase de pruebas,
los cambios que se pueden someter a nuestro cdigo no
son decisiones aleatorias y cualquier fallo podra tener
consecuencias catastrficas de acara a la operatividad
de nuestro software.
5.3.9 Propiedad colectiva del cdigo
El cdigo que el equipo genere para llevar a cabo
un proyecto es propiedad de cada uno de los
componentes del equipo.
Cualquier componente del equipo podr
modificar un mdulo o porcin generada
por otro componente si lo cree
conveniente.
En un equipo no existen derechos de
autor ni prohibiciones de ningn tipo a la
hora de modificar el cdigo de un
compaero.
Todo el cdigo desarrollado por cada
componente del equipo es cedido para el
bien del propio equipo.
Permite al grupo trabajar ms
rpidamente y rendir de una forma ms
eficaz debido a que no producen los
retardos o esperas ocasionados por la
propiedad privada de un cdigo.
5.3.10 Integracin contina
ITCR. Marn. Preparacin de reportes escritos informativos.
.

Siempre tener versiones simples y manejables del

sistema. Esto tambin se puede aplicar a los cambios Se gana eficacia al decidir de ante mano
que se deben introducir en versiones pasadas. el mejor estndar para satisfacer los
requerimientos propuestos por el cliente.
El cdigo siendo claro y simple es ms
fcil de manejar y de entender, as que los
cambios que se acumulen pueden
convertirse en un obstculo difcilmente
superable.

Los cambios siempre deben ser

integrados continuamente y no
acumularlos e integrarlos de un golpe.

Permite tener conciencia en todo

momento del trabajo que se lleva
desarrollado y tambin permite tener a
mano cuando el cliente solicite una
versin perfectamente funcional y con los
ltimos avances.

La integracin continua es introducir todos

los cambios producidos a lo largo del da a
final de la jornada.
5.3.11 El cliente en su sitio
Las funcionalidades que debe cumplir el proyecto
son dictadas por el cliente, aunque pueden que no
queden claras en un principio. As, se propone que el
propio cliente pase a formar parte del proyecto, que se
involucre en la produccin del software desde sus
posibilidades que no son escasas.
El equipo de produccin debe estar continuamente
en comunicacin con el cliente, que deber aclarar en la
medida de lo posible los requerimientos que necesitara
utilizar.
Se soluciona o al menos se facilita la compresin
de las funcionalidades, que en ciertos casos suele ser la
etapa ms difcil, ms cara y ms lenta del desarrollo del
proyecto.
5.3.12 Estndares de codificacin
Se promueve la codificacin en parejas, la
propiedad colectiva, el testeo continuo, la integracin
continua
5.4 CICLO DE VIDA DE PROGRAMACION
EXTREMA
La filosofa de las metodologas agiles se basan en
una interaccin continua entre el cliente y los
desarrolladores. En XP no se realiza un plan a largo
plazo, sino que se realizan las planificaciones de las
liberaciones de software. Las liberaciones de
software, son entregas de software al cliente que ya
cumplen con cierta o todos los requerimientos de este.
En un proyecto enmarcado en XP puede haber varias
liberaciones de software, las liberaciones de software
se realizan hasta que el software cumpla con el alcance
previamente acordado con el cliente.
Para facilitar la comprensin de las fases en el
desarrollo se ejemplificara cada etapa con el Desarrollo
de un pequeo sistema bibliotecario. Suponga que
tenemos datos bibliogrficos como autor, ttulo y ao de
publicacin; la meta es disear un sistema que pueda
buscar los valores que especificamos. La interfaz grfica
es como la siguiente:

Sin los estndares de codificacin, la

metodologa eficaz de programacin se
vendra abajo.

Se relaciona con el sistema metafrico,

dado que es necesario establecer un
criterio fijo que proporcione reglas para la
creacin de nombre para variables y
mtodos. 5.4.1 Fase de exploracin

Establecer un estndar de codificacin de En esta fase el cliente hace uso de las historias
tal forma que los programadores sigan los de usuarios donde se describen a grandes rasgos las
mismos criterios para desarrollar cdigo. funcionalidades que debe poseer el sistema, de esta

11
ITCR. Marn. Preparacin de reportes escritos informativos.
.

manera las historias de usuario no son lo mismo que

la recoleccin de requerimientos tradicional ya que
XP no profundiza en los detalles por lo ya
mencionado de contar con un cliente que interacta
en todo momento con el equipo de desarrollo.

Paralelamente a la captacin de estas primeras

historias se hace el spike arquitectnico que consta
de una familiarizacin entre el equipo de desarrollo,
la metodologa, herramientas, lenguajes y normas de
codificacin que se usaran en el proyecto.

Ejemplo de historias de usuarios:

Luego el equipo estudia las historias y estima

Historia: Consulta la complejidad de cada una dejando as historias de
Consultar por autor, complejidad media; esto sirve para realizar una reunin
titulo o palabra clave de plan de entregas entre el equipo de trabajo y los
usuarios especificando las funcionalidades del sistema
que se implementaran en cada fase de iteracin,
poniendo mayor cuidado en aquellas funcionalidades
Historia: impresin con una prioridad alta de modo que, si en un momento
Imprimir la lista completa se reducen los alcances del proyecto se vean afectados
de resultados o solamente aquellos requisitos secundarios que no tienen
resultados individuales mayor relevancia en el funcionamiento necesario de la
aplicacin.

Para el ejemplo de la biblioteca, el cliente

ordnalas historias de acuerdo a la prioridad, el tiempo
El cliente, al estar en comunicacin continua estimado va en parntesis.
con los programadores puede resolver todas las dudas e
interrogantes.
Programador: Qu tipo de configuracin Mayor Menor
Prioridad Media
necesitan? Prioridad Prioridad
Cliente: Muchos clientes usan la misma
biblioteca todo el tiempo, pero otros usan de una Consulta(2) Configuracin (2) Impresin (2)
variedad. Nos gustara que el usuario elija de una lista la
biblioteca deseada. El tiempo estimado se convierte en Puntos de
Programador: Ok. Eso podra estar lleno en 2 Historia. Los programadores establecen una velocidad
semanas. Qu nos puede decir acerca de la de puntos de historia, que es la cantidad de puntos de
compatibilidad con otros sistemas y acerca el historia que pueden hacer por cada iteracin; en este
rendimiento? caso los puntos de historia son de para en todas las
historias. El programador dice: La velocidad del equipo
es de 4 esto significa que pueden realizar (estimando) 4
5.4.2 Fase de planificacin puntos de historia por iteracin.

El cliente entrega al equipo las historias que ha

confeccionado asignndoles una prioridad para el Entrega Planeada
funcionamiento del sistema. Puntos de Historia Nombre de Historia
2 Consulta
2 Configuracin
2 Impresin

Ntese que aqu se encuentran todas las prioridades de

las historias.

Con una velocidad de 4 puntos de historia por iteracin

tomar en total 6/4 = 1.5 iteraciones.
Ahora podemos proceder con el desarrollo.

12
ITCR. Marn. Preparacin de reportes escritos informativos.
.
5.4.3 Fase de Iteraciones
Inicialmente se convoca a una reunin para
establecer cuantas iteraciones se realizaran y de
acuerdo a ello se establece el tiempo de duracin de
cada una.
Para una iteracin determinada se siguen los
pasos a continuacin:
- Se renen las historias asignadas a esa
iteracin, se detallan las tareas a realizar por
cada historia y el grado de dificultad de cada
una; luego se reparten las tareas prioritarias
para dejar el resto en cola.
Siguiendo con el ejemplo, las tareas
necesarias por la historia de Consulta pueden ser crear
las clases necesarias para la consulta (Documento,
Consulta, Resultado, Buscador) y los mtodos
necesarios para su implementacin; para la historia de
configuracin las tareas por realizar son crear la clases
Biblioteca, establecer los protocolos de comunicacin
necesarios entre los sistemas de bibliotecas, adaptar las
configuraciones, etc. ; para la historia Impresin Elaborar
los mecanismos para impresin revisar los protocolos,
establecer las conexiones con impresora, etc.
En XP se usa una programacin de forma
incremental y las pruebas que se efectuarn al cdigo se
hacen antes de escribir el cdigo. Incremental porque se
programa en ciclos, no una clase completa, sino unas
pocas lneas de cdigo o un mtodo a la vez, y las
pruebas se escriben antes de escribir el cdigo para que
el cdigo que escribamos se ajuste al test y no el test al
cdigo que se ha escrito.
Ejemplo de un test:
13
public void testDocument() {
Document d = new Document("a", "t", "y");
assertEquals("a", d.getAuthor());
assertEquals("t", d.getTitle());
assertEquals("y", d.getYear());
}
Este test no funciona (porque no hemos creado
la clase Document todava). Creamos la clase Document
y unos cuantos mtodos para que compile, lo corremos
de nuevo y todava fallar. Parece contradictorio,
queremos hacer pruebas para que pasen, pero al verlas
fallar antes nos da seguridad de que son vlidas.
Creamos el constructor y los mtodos para
pasar el test, y luego funciona.
5.4.4 Fase de Produccin
Esta etapa se fundamenta en pasar la
aplicacin a produccin cuando se alcancen las
funcionalidades mnimas que aporten un valor real al
negocio y una estabilidad confiable; esto nos hace que
nuestra aplicacin aporte sus primeros frutos a la
empresa en an tempranas etapas de lo que es el
proyecto de desarrollo.
Para el ejemplo en desarrollo, esta etapa es despus
de la primera iteracin, al entregar la primera versin;
esta versin es capaz de crear una consulta y entregar
resultados de acuerdo a unos pocos libros ingresados al
sistema. Adems en esta etapa se trabaja en las
historias de menor prioridad (funcionalidades
secundarias del software).
5.4.5 Fase de Mantenimiento
Una vez el alcance del proyecto se ha
completado, y se cuentan con todas las funcionalidades
en produccin, se verifican con el usuario aquellas
nuevas historias de usuario que se han realizado
despus de la puesta en produccin del proyecto; estas
nuevas funcionalidades se van incorporando segn su
valor en el negocio y el presupuesto adicional con que
disponga el usuario. Por ello el equipo de desarrollo se
reduce a la mnima expresin, dejando algunos
miembros para el mantenimiento.
Debido a esto, la velocidad de desarrollo puede
bajar despus de la puesta del sistema en produccin.
La fase de mantenimiento puede requerir nuevo
personal dentro del equipo y cambios en su estructura.
Para esta fase nuestro proyecto ya cuenta con
las funcionalidades solicitadas y las nuevas agregadas al
proyecto. Se realizan las pruebas nuevamente una por
una, y se integra la aplicacin a los sistemas
bibliotecarios correspondientes.
5.4.6 Fase de Muerte del Proyecto
Cuando no se tienen ms historias de usuario
para implementar en el sistema, solo queda que se
ITCR. Marn. Preparacin de reportes escritos informativos.
.

cumplan las necesidades del cliente en otros aspectos

como rendimiento y confiabilidad. Se elabora la
documentacin final del sistema y no se realizan ms
cambios en la estructura. La muerte del proyecto
tambin ocurre cuando el sistema no genera los
beneficios esperados por el cliente o cuando no hay
presupuesto para brindarle mantenimiento.

El sistema bibliotecario funcion por varios

aos y se implementa en varias bibliotecas.

5.5 Ventajas y Desventajas de

Programacin Extrema

En la programacin extrema como en todo

nuevo proyecto estuvo en el ojo de la comunidad
desarrolladora de software. En este apartado veremos
las principales observaciones que ha tenido por la
comunidad de desarrollo de software.

5.5.1 Ventajas

Una de las ventajas de la programacin

extrema es que de adapta al desarrollo de sistemas
pequeos y grandes; optimiza el tiempo de desarrollo;
permite realizar el desarrollo del sistema en parejas para
complementar los conocimientos; el cdigo es sencillo y
entendible, adems de la poca documentacin a
elaborar para el desarrollo del sistema.

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

5.5.2 Desventajas

Las desventajas son que no se tiene la

definicin del costo y el tiempo de desarrollo; el sistema
va creciendo despus de cada entrega al cliente y nadie
pude decir que el cliente no querr una funcin ms; se
necesita de la presencia constante del usuario, lo cual
en realidad es muy difcil de lograr.

Otra desventaja es la programacin en parejas,

algunos desarrolladores son celosos del cdigo que
escriben y no les es grato que alguien ms modifique las
funciones que realiz o que su cdigo sea desechado
por no cumplir con el estndar.

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

14
ITCR. Marn. Preparacin de reportes escritos informativos.
.

6 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).

La programacin extrema como metodologa de

desarrollo de software no se ajusta a cualquier proyecto,
es el equipo de trabajo l debe cerciorarse de los
requerimientos que el cliente especifique y sus
funcionalidades; adems el administrador del proyecto
debe permitir un entorno adecuado para la comunicacin
priorizando aspectos importantes como lo es el trabajo
en parejas que disminuye considerablemente la
documentacin pero a su vez simplifica y acelera el
desarrollo.

Algunos aspectos del desarrollo de software se

beneficiarn del enfoque agilista, mientras otros
obtendrn beneficios de un enfoque tradicional.

Las metodologas giles se caracterizan por su

sencillez, tanto en su aprendizaje como en su aplicacin;
sin embargo, gozan tanto de ventajas como desventajas.

7 REFERENCIAS
[1] Kent Beck, Test Driven Development:By Example,
Addison-Wesley Professional, 2002
[2] Dave Chaplin, Test First Programming, Tech Zone,
2001
Manifiesto agil, disponible: http://agilemanifesto.org
Jos Carlos Cortizo Prez, D. E. (s.f.). eXtreme
Programming.
Metodologias agiles, obtenido de Noticias y articulos:
http://ldc.usb.ve/~abianc/materias/ci4713/metodologiasa
giles.pdf
Wells, D. (2009). extremeprogramming. Obtenido de
http://www.extremeprogramming.org/

Programacion Extrema, disponible en:

https://sites.google.com/site/xpmetodologia/
Programacion extrema, articulo disponible en:
https://iswugaps2extremeprogramming.wordpress.com/

Jorge Fernndez Gonzlez. (2013). Introduccin a las

metodologas giles. Barcelona: UOC

15