Modificacion de Metodologia

Metodologas giles en el
Desarrollo de Software
Alicante, 12 de Noviembre de 2003
Organizacin:
Grupo ISSI
(Ingeniera del Software y Sistemas de Informacin)
Colaboradores:
Taller realizado en el marco de las VIII Jornadas de Ingeniera del

Software y Bases de Datos, JISBD 2003.
Alicante, del 12 al 14 de Noviembre de 2003
Actas
Metodologas giles en el
Desarrollo de Software
Alicante Espaa
12 de Noviembre de 2003
Editado Por:
Patricio Letelier Torres
Emilio A. Snchez Lpez
Grupo ISSI
(Ingeniera del Software y Sistemas de Informacin)
Comit organizador
Patricio Letelier Torres
M Carmen Penads
Jos Hilario Cans
Emilio A. Snchez Lpez
Comit Tcnico
Esperanza Marcos, Universidad Rey Juan Carlos
Rafael Corchuelo, Universidad de Sevilla
Mikel Emaldi, European Software Institute (ESI)
Csar Prez-Chirinos, Banco de Espaa
Jos Hilario Cans, Universidad Politcnica de Valencia
Presentacin
En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas han sido las
"balas de plata" para el deseado xito en el desarrollo de software. El proceso de desarrollo asumido en
este contexto llevaba asociada una marcada tendencia hacia el control del proceso mediante una
rigurosa definicin de actividades, artefactos y roles. Este esquema "tradicional" para abordar el
desarrollo de software ha demostrado ser efectivo en proyectos de gran envergadura 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 contexto es muy cambiante, y en donde
se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En la
prctica, para muchos equipos de desarrollo, ante las dificultades para utilizar metodologas
tradicionales, se lleg a la resignacin de prescindir del "buen hacer" de la ingeniera del software con
el objetivo de ajustarse a estas restricciones. Ante esta situacin, las metodologas giles aparecen como
una posible respuesta para llenar este vaco metodolgico. Por estar especialmente orientadas para
proyectos pequeos, las metodologas giles constituyen una solucin a medida, con una elevada
simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del
producto.
El tema es de rabiosa actualidad. La curiosidad que siente la mayor parte de ingenieros de software,
profesores, e incluso alumnos, sobre los mtodos giles hace prever una fuerte proyeccin industrial de
las metodologas giles. Por un lado, para muchos equipos de desarrollo el uso de metodologas
tradicionales les resulta muy lejano a su forma de trabajo actual considerando las dificultades de su
introduccin e inversin asociada en formacin y herramientas. Por otro, las caractersticas de los
proyectos para los cuales las metodologas giles han sido especialmente pensadas se ajustan a un
amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de
desarrollo son pequeos, con plazos reducidos, requisitos voltiles, nuevas tecnologas, etc. Esto ltimo
abrira interesantes canales de cooperacin entre la industria y la universidad.
El objetivo de este taller ha sido constituir un primer punto de encuentro en Espaa para acadmicos y
gentes de industria interesados en metodologas giles.
Esperamos que este taller cumpla con dichas espectativas y genere nuevas iniciativas y vnculos de
colaboracin.
Los editores.
ndice
Metodologas giles en el Desarrollo de Software

Universidad Politcnica de Valencia
Jos H. Cans, Patricio Letelier y M Carmen Penads.............................................................................1
Artculos en programa
Haca un proceso metodolgico dirigido por modelos para el desarrollo gil de sistemas
de informacin Web
Universidad Rey Juan Carlos de Madrid
Paloma Cceres y Esperanza Marcos.........................................................................................................9
Mutacin de casos de prueba de JUnit

Universidad de Castilla-La Mancha
Mara del Mar Jimnez, Macario Polo, Jos Luis Ruiz y Mario Piattini.................................................15
Experiencias de formacin en metodologas giles

Patricio Letelier, Jos H. Cans, M Carmen Penads y Juan Snchez...................................................25
Brief eXPERT Aproach Description

European Software Institute
Teodora Bozheva.....................................................................................................................................31
eXPERT: Result from seven pilot projects

Teodora Bozheva.....................................................................................................................................39
Formal Agility. How much of each?

Universidad politcnica de Madrid
ngel Herranz y Juan Jos Moreno-Navarro...........................................................................................47
Mtodologas giles en el Desarrollo de Software
Jos H. Cans, Patricio Letelier y M Carmen Penads
DSIC -Universidad Politcnica de Valencia
Camino de Vera s/n, 46022 Valencia
{ jhcanos | letelier | mpenades }@dsic.upv.es
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 demo strado 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 des arrollo 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 comparacin con las metodologas tradicionales. Adems se
describen brevemente las principales propuestas, especialmente Programacin Extrema (eXtre me
Programming, XP) la metodologa gil ms popular en la actualidad.
PALABRAS CLAVE. Procesos de Software, Metodologas giles, Programacin Extrema (XP)
1. 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
1
la mayora de conferencias y workshops celebrados en los ltimos aos. Es tal su impacto que
actualmente existen 4 conferencias internacionales de alto nivel y especficas sobre el tema1 .
Adems ya es un rea con cabida en prestigiosas revistas internacionales. En la comunidad de la
ingeniera del software, se est viviendo con intensidad un debate abierto entre los partidarios de
las metodologas tradicionales (referidas peyorativamente como "metodologas pesadas") y
aquellos que apoyan las ideas emanadas del "Manifiesto gil" 2 . La curiosidad que siente la
mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre las metodologas
giles hace prever una fuerte proyeccin industrial. Por un lado, para muchos equipos de
desarrollo el uso de metodologas tradicionales les resulta muy lejano a su forma de trabajo
actual considerando las dificultades de su introduccin e inversin asociada en formacin y
herramientas. Por otro, las caractersticas de los proyectos para los cuales las metodologas
giles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales
de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeos, con
plazos reducidos, requisitos voltiles, y/o basados en nuevas tecnologas.
El artculo est organizado como sigue. En la seccin 2 se introducen las principales
caractersticas de las metodologas giles, recogidas en el Manifiesto y se hace una comparacin
con las tradicionales. La seccin 3 se centra en eXtreme Programming (XP), presentando sus
caractersticas particulares, el proceso que se sigue y las prcticas que propone. En la seccin 4
se citan otros mtodos giles, enumerndose sus principales caractersticas. Finalmente aparecen
las conclusiones.
2. METODOLOGAS GILES
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado
al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su
objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar
software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las
actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance3 , una organizacin, sin nimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo gil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto
gil, un documento que resume la filosofa gil.
2.1. El Manifiesto gil.

Segn el Manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de xito de un proyecto software. Es ms
importante construir un buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es
mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus
necesidades.
Desarrollar software que funciona ms que conseguir una buena documentacin. La
regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata
para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo
fundamental.
1
XP Agile Universe: www.agileuniverse.com. Conference on eXtreme Programming and Agile Processes in Software
Engineering: www.xp2004.org. Agile Development Conference (EEUU): www.agiledevelopmentconference.com.
Agile Development Conference (Australia): www.softed.com/adc2003/
2
agilemanifesto.org
3
www.agilealliance.com
2
La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que
exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin
entre ambos ser la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnologa, en el equipo, etc.) determina tambin e l xito o fracaso del
mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que
diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberan ser capaces de mantener una paz constante.
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y
segn esto ajusta su comportamiento.
2.2. Comparacin
La Tabla 1 recoge esquemticamente las principales diferencias de las metodologas giles con
respecto a las tradicionales (no giles). Estas diferencias que afectan no slo al proceso en s,
sino tambin al contexto del equipo as como a su organizacin.
3. PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)

XP4 [2] es una metodologa gil centrada en potenciar las relaciones interpersonales como clave
para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre
todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y
muy cambiantes, y donde existe un alto riesgo tcnico.
4
www.extremeprogramming.org,www.xprogramming.com,
c2.com/cgi/wiki?ExtremeProgramming
3
Metodologas giles Metodologas Tradicionales
Basadas en heursticas provenientes de prcticas de Basadas en normas provenientes de estndares
produccin de cdigo seguidos por el entorno de desarrollo
Especialmente preparados para cambios durante el Cierta resistencia a los cambios
proyecto
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos principios Proceso mucho ms controlado, con numerosas
polticas/normas
No existe contrato tradicional o al menos es Existe un contrato prefijado
bastante flexible
El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de desarrollo
mediante reuniones
Grupos pequeos (<10 integrantes) y trabajando en Grupos grandes y posiblemente distribuidos
el mismo sitio
Pocos artefactos Ms artefactos
Pocos roles Ms roles
Menos nfasis en la arquitectura del software La arquitectura del software es esencial y se

expresa mediante modelos
Tabla 1. Diferencias entre metodologas giles y no giles
Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su
nombre. Kent Beck, el padre de XP, describe la filosofa de XP en [2] sin cubrir los detalles
tcnicos y de implantacin de las prcticas. Posteriormente, otras publicaciones de experiencias
se han encargado de dicha tarea. A continuacin presentaremos las caractersticas esenciales de
XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.
3.1. Las Historias de Usuario

Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel
en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean
requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy
dinmico y flexible . Cada historia de usuario es lo suficientemente comprensible y delimitada
para que los programadores puedan implementarla en unas semanas [12].
Beck en su libro [2] presenta un ejemplo de ficha (customer story and task card) en la cual
pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin,
mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra
historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la
fecha, estado cosas por terminar y comentarios. A efectos de planificacin, las historias pueden
ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una
iteracin). Las historias de usuario son descompuestas en tareas de programacin (task card) y
asignadas a los programadores para ser implementadas durante una iteracin.
3.2. Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
- Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema.
- Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se
implementan en cada iteracin centrndose en aportar mayor valor al negocio.
- Encargado de pruebas (Tester). 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.
4
- Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el
grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar
futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin.
- Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de
forma que se apliquen las prcticas XP y se siga el proceso correctamente.
- Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto, en el que puedan surgir problemas.
- Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.
3.3. Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos [12]:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de
tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe
presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el
software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de
manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor
de negocio posible con cada iteracin.
El ciclo de vida ideal de XP consiste de seis fases [2]: Exploracin, Planificacin de la Entrega
(Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.
3.4. Prcticas XP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo
evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el
desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas.
El juego de la planificacin. Hay una comunicacin frecuente el cliente y los
programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la
implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo
de las entregas y de cada iteracin.
Entregas pequeas . Producir rpidamente versiones del sistema que sean operativas,
aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un
resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses.
Metfora. El sistema es definido mediante una metfora o un conjunto de metforas
compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia
compartida que describe cmo debera funcionar el sistema (conjunto de nombres que
acten como vocabulario para hablar sobre el dominio del problema , ayudando a la
nomenclatura de clases y mtodos del sistema).
Diseo simple . Se debe disear la solucin ms simple que pueda funcionar y ser
implementada en un momento determinado del proyecto.
Pruebas . La produccin de cdigo est dirigida por las pruebas unitarias. stas son son
establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante
cada modificacin del sistema.
5
Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo
con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplific arlo y
hacerlo ms flexib le para facilitar los posteriores cambios. Se mejora la estructura interna
del cdigo sin alterar su comportamiento externo [8].
Programacin en parejas . Toda la produccin de cdigo debe realizarse con trabajo en
parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor
diseo, mayor satisfaccin de los programadores, ).
Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del
cdigo en cualquier momento.
Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est
lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da .
40 horas por semana. Se debe trabaja r un mximo de 40 horas por semana. No se trabajan
horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un
problema que debe corregirse. El trabajo extra desmotiva al equipo.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el
equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce
constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores
pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms
efectiva que la escrita.
Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a
travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de
programacin para mantener el cdigo legible .
El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto
que se apoyan unas en otras. Esto se ilustra en la Figura 1 (obtenida de [2]), donde una lnea
entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las
prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido
propuestas en ingeniera del software e incluso demostrado su valor en la prctica (ver [1] para
un anlisis histrico de ideas y prcticas que sirven como antecedentes a las utilizadas por las
metodologas giles). El mrito de XP es integrarlas de una forma efectiva y complementarlas
con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.
Figura 1. Las prcticas se refuerzan entre s
6
3. OTRAS METODOLOGAS GILES
Aunque los creadores e impulsores de las metodologas giles ms populares han suscrito el
manifiesto gil y coinciden con los principios enunciados anteriormente, cada metodologa tiene
caractersticas propias y hace hincapi en algunos aspectos ms especfic os. A continuacin se
resumen otras metodologas giles. La mayora de ellas ya estaban siendo utilizadas con xito en
proyectos reales pero les faltaba una mayor difusin y reconocimiento.
SCRUM 5 [16]. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un
marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos.
Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus
principales caractersticas se pueden resumir en dos. El desarrollo de software se realiza
mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada
sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica
importante son las reuniones a lo largo proyecto, entre ellas destaca la reunin diaria de 15
minutos del equipo de desarrollo para coordinacin e integracin.
Crystal Methodologies6 [5]. Se trata de un conjunto de metodologas para el desarrollo de
software caracterizadas por estar centradas en las personas que componen el equipo y la
reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas por Alistair
Cockburn. El desarrollo de software se considera un juego cooperativo de invencin y
comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave,
por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener
polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo,
establecindose una clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y
Crystal Orange (25 a 50 miembros).
Dynamic Systems Development Method7 (DSDM) [17]. Define el marco para desarrollar un
proceso de produccin de software. Nace en 1994 con el objetivo de crear una metodologa
RAD unificada. Sus principales caractersticas son: es un proceso iterativo e incremental y el
equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad,
estudio del negocio, modelado funcional, diseo y construccin, y finalmente implementacin.
Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases.
Adaptive Software Development8 (ASD) [9]. Su impulsor es Jim Highsmith. Sus principales
caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y
tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin,
colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las
caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la
tercera se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve para
aprender de los errores y volver a iniciar el ciclo de desarrollo.
Feature -Driven Development9 (FDD) [3]. Define un proceso iterativo que consta de 5 pasos.
Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e
implementacin del sistema partiendo de una lista de caractersticas que debe reunir el
software. Sus impulsores son Jeff De Luca y Peter Coad.
Lean Development10 (LD) [15]. Definida por Bob Charettes a partir de su experiencia en
proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos
proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si
se manejan adecuadamente se pueden convertir en oportunidades que mejoren la
5
www.controlchaos.com
6
www.crystalmethodologies.org
7
www.dsdm.org
8
www.adaptivesd.com
9
www.featuredrivendevelopment.com
10
www.poppendieck.com
7
productividad del cliente. Su principal caracterstica es introducir un mecanismo para
implementar dichos cambios.
4. 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 NAME11 (Network for
Agile Methodologies Experience) en el cual hemos participado como nodo en Espaa.
Aunque en la actualidad ya existen libros asociados a cada una de las metodologas giles
existentes y tambin abundante informacin en internet, es XP la metodologa que resalta por
contar con la mayor cantidad de informacin disponible y es con diferencia la ms popular.
BIBLIOGRAFIA
[1] Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. Agile software development methods Review and
analysis. VTT Publications. 2002.
[2] Beck, K.. Extreme Programming Explained. Embrace Change, Pearson Education, 1999. Traducido al
espaol como: Una explicacin de la programacin extrema. Aceptar el cambio, Addison Wesley, 2000.
[3] Coad P., Lefebvre E., De Luca J. Java Modeling In Color With UML: Enterprise Components and Process.
Prentice Hall. 1999.
[4] Cockbun, A. Agile Software Development. Addison-Wesley. 2001.
[5] Fowler, M., Beck, K., Brant, J. Refactoring: Improving the Design of Existing Code. Addison-Wesley. 1999
[6] Highsmith J., Orr K. Adaptive Software Development: A Collaborative Approach to Managing Complex
Systems. Dorset House. 2000.
[7] Jeffries, R., Anderson, A., Hendrickson, C. Extreme Programming Installed. Addison-Wesley. 2001
[8] Poppendieck M., Poppendieck T. Lean Software Development: An Agile Toolkit for Software Development
Managers. Addison Wesley. 2003.
[9] Schwaber K., Beedle M., Martin R.C. Agile Software Development with SCRUM. Prentice Hall. 2001.
[10] Stapleton J. Dsdm Dynamic Systems Development Method: The Method in Practice. Addison-Wesley. 1997.
11
name.case.unibz.it/
8
Hacia un proceso metodolgico dirigido por modelos
para el desarrollo gil de sistemas de informacin Web
Paloma Cceres, Esperanza Marcos
Grupo de Investigacin Kybele
Universidad Rey Juan Carlos
Madrid
{p.caceres, e.marcos}@escet.urjc.es
Resumen. En la actualidad existen multitud de plataformas de explotacin para los

sistemas de informacin Web, as como diferentes tecnologas de implementacin
para el desarrollo de dichos sistemas. Con el fin de garantizar una especificacin
independiente de la plataforma de explotacin y de la tecnologa de implementacin,
OMG propone realizar una arquitectura basada en modelos (MDA). En base a esta
arquitectura, se est definiendo un marco metodolgico basado en modelos para el
desarrollo de sistemas de informacin Web, denominado MIDAS. En este trabajo
presentamos el proceso metodolgico dirigido por modelos, de dicho marco de
trabajo, para desarrollar de forma gil sistemas de informacin Web.
Palabras clave: Procesos giles, metodologas giles, metodologas de desarrollo.
1. Introduccin
Hoy en da, el desarrollo de los sistemas de informacin Web (SIW) ha despertado un
gran inters tanto a nivel empresarial como a nivel investigador y docente.
La necesidad de metodologas especficas para el desarrollo de SIW es tambin
conocida (Fraternali, 2000). Las metodologas tradicionales no incorporan mtodos
especficos para contemplar determinadas caractersticas de estos sistemas (Lowe and
Hall, 1999) y son demasiado pesadas y burocrticas puesto que exigen la generacin de
un gran volumen de documentacin, impidiendo as un desarrollo gil y rpido, Fowler
(2001). As han aparecido las metodologas y procesos denominados giles, que
garantizan un proceso de desarrollo suficiente pero no excesivo.
Por otra parte, la creciente aparicin de diferentes tecnologas y plataformas asociadas
al desarrollo de sistemas de informacin, hace demasiado especfico el modelado de un
sistema. En este sentido, OMG ha propuesto la Arquitectura Dirigida por Modelos
(MDA), (Miller y Mukerji, 2001) que garantiza la especificacin completa de un
sistema en base a modelos, independientes y especficos de una tecnologa y plataforma.
Estos motivos nos han llevado a proponer un proceso software dirigido por modelos
para el desarrollo gil de SIW dentro del marco metodolgico de MIDAS1, presentado
en Marcos et al. (2002).
El resto del artculo se organiza de la siguiente forma: la seccin 2 hace una breve
introduccin a MDA; la seccin 3 presenta el proceso metodolgico de MIDAS y por
ltimo, las conclusiones y trabajos futuros se presentan en la seccin 4.
1
Este trabajo se ha llevado a cabo dentro de los proyectos: EDAD (07T/0056/2003 1) financiado por la Comunidad
Autnoma de Madrid y DAWIS (TIC 2002-04050-C02-01) financiado por la Subdireccin General de Proyectos de
Investigacin del MCyT (Ministerio de Ciencias y Tecnologa) y por la Universidad Rey Juan Carlos (GC-2003-12).
9
2. Arquitectura dirigida por modelos
MDA (Miller and Mukerji, 2001) es un marco de trabajo para el desarrollo del software,
definido por OMG (Object Management Group), que define una arquitectura orientada a
modelos y unas guas de transformacin entre los mismos para recoger las
especificaciones de un sistema, donde los productos que se generan son modelos
formales, que incluso pueden llegar a ser comprendidos por ordenadores.
MDA propone la realizacin de: Modelos independientes de computacin (CIM) que
son modelos del ms alto nivel de abstraccin que identifican el contexto del sistema.
Modelos Independientes de la Plataforma (PIM) que proporcionan la especificacin
formal de la estructura y funcin del sistema, sin tener en cuenta aspectos tcnicos e
independientes de cualquier tecnologa de implementacin; Modelos Especficos de la
Plataforma (PSM) que proporcionan modelos en trminos de constructores de
implementacin que estn disponibles en una tecnologa especfica.
Las reglas de transformacin se aplican para transformar: PIM en PIM que van
generalmente asociadas a los pasos que se suceden entre el modelado de la
especificacin, anlisis y diseo; PIM en PSM que se realizan cuando el PIM est
suficientemente refinado y se transforma en un modelo dependiente de la
insfraestructura final de ejecucin; un PIM se transforma en uno o varios PSM; PSM en
PSM que son necesarios para la realizacin y despliegue de componentes; PSM en
PIM que permiten la abstracin de modelos a partir de implementaciones especficas de
una plataforma y dependientes de una tecnologa concreta.
3. Proceso metodolgico de MIDAS

En esta seccin se presenta el proceso metodolgico de MIDAS dirigido por modelos
para el desarrollo gil de sistemas de informacin Web (SIW). En primer lugar y dado
que uno de nuestros objetivos era la agilidad, se estudi la viabilidad de aplicar un
proceso gil para el desarrollo de SIW. Fue presentado en Cceres y Marcos (2001) y se
concluy que era viable la aplicacin de dichos procesos a los desarrollos Web. En
segundo lugar, y debido a las ventajas que tambin aporta MDA, se decidi ver la
posibilidad de integracin entre las prcticas giles y las dirigidas por modelos. Surge
entonces una propuesta de integracin que se presenta en este trabajo, junto con el
proceso metodolgico propuesto en MIDAS.
Propuesta dirigida por modelos
Al comienzo de nuestro trabajo, se apost por el modelado conceptual como uno de los
requisitos fundamentales a incluir en nuestro proceso metodolgico puesto que permita
la representacin de los requisitos y estableca el vnculo entre el espacio del problema -
lo que tratamos de resolver- y el espacio de la solucin -cmo lo vamos a resolver-
(Snchez y Pastor, 2001). Se defini un conjunto de modelos para el desarrollo de SIW,
con dos objetivos concretos: El primero, que el modelado conceptual fuese
independiente de cualquier tecnologa, pero dirigido a entorno Web puesto que ste es
nuestro mbito de estudio. El segundo fue la definicin de guas de transformacin entre
modelos. Se comenz el estudio de MDA y se present una propuesta concreta de
modelado basada en MDA para plataforma Web y tecnologa XML y objeto-relacional
en Cceres et al. (2003).
10
Agilidad en el desarrollo dirigido por modelos
Pero dado que seguamos apostando por un proceso gil, haba que analizar la
viabilidad de un proceso gil y dirigido por modelos. En este sentido nos encontramos
que, segn puede apreciarse en la figura 1, los procesos giles y los procesos dirigidos
por modelos no contemplan igualmente el espacio del problema (qu es lo que hay que
resolver) y el espacio de la solucin (cmo resolverlo), Weneger (2002). Nuestro rea
de inters, parte sombreada de la figura 1, se centr entonces en el acercamiento entre
ambas propuestas, en base al estudio de cinco aspectos diferenciadores entre ambos
procesos, indicados en la tabla 1 (Weneger, 2002).
Solution Domain Abstract Stability

High
Agile, incremental, waterfall

evolutionary
Area of
interest
Model-driven,
Low
Don t do this
generative
Problem Domain Abstract Stability
Low High
Fig. 1.- Relacin entre el espacio del problema y de la solucin
Aspectos Agil Dirigido por modelos

Personas Alta prioridad; se facilita relacin No prioritario; el modelo del espacio del problema
cliente-desarrollador es la base de la discusin entre cliente-desarrollador
Proceso Prioridad media; incremental y Tiende al proceso en cascada, poco incremental
evolutivo
Tecnologa Baja prioridad; slo cobra Es relevante; se usa para la generacin del software
importancia al final. (usando un PSM)
Modelos Artefacto secundario; se producen Artefacto prioritario; fuente de la implementacin
cuando es absolutamente necesario
Software Artefacto prioritario; es la nica Artefacto secundario; depende del espacio de la
medida de progreso solucin
Tabla 1. Aspectos diferenciadores entre los procesos giles y los procesos dirigidos por modelos
Finalmente propusimos lo siguiente:
Personas. Al igual que en los procesos giles, nosotros s apostamos por darle una alta
prioridad a la relacin con el cliente. Aunque en los procesos dirigidos por modelos, el
cliente entra a formar parte del proyecto a partir del modelo del espacio del problema,
para nosotros es fundamental esa relacin desde el principio: para establecer cul es el
espacio del problema, para definirlo y para utilizarlo posteriormente como base de la
discusin entre el cliente-analista, entre el cliente-diseador/arquitecto, entre el cliente-
desarrollador. El cliente es parte fundamental durante todo el proceso, puesto que es la
forma de garantizar que el producto final cumpla sus expectativas.
Proceso. Es una parte muy relevante dentro de nuestra propuesta. El modelo de proceso
propuesto en MIDAS tiene mucho que ver con el de los procesos giles puesto que es
un modelo iterativo, incremental, adaptativo y con prototipado, lejano por tanto del
modelo en cascada indicado en los procesos dirigidos por modelos. El proceso iterativo
e incremental aporta grandes ventajas puesto que permite la obtencin de versiones del
producto software antes de la entrega final del mismo, Jacobson et al. (2000). Ambler
11
(2003) confirma adems, la posibilidad de realizar una implementacin iterativa e
incremental, a travs del desarrollo gil dirigido por modelos.
Tecnologa. Nuestra propuesta en este aspecto se basa en tecnologa XML y objeto-
relacional (Cceres et al., 2003). A diferencia de los procesos giles, este punto lo
consideramos relevante, puesto que los PSM indicados por MDA, son especficos de
una tecnologa concreta; luego es obligatorio identificarla.
Modelos. Este elemento tiene una alta prioridad en nuestra propuesta. Los modelos son
los artefactos que generamos y nuestra nica documentacin junto con el cdigo. Aqu
disentimos respecto a los procesos giles. Nosotros consideramos que el conocimiento
acerca del sistema y del negocio no puede mantenerse exclusivamente en la mente de
los desarrolladores y del cliente. Segn Atkinson y Khne (2003), es conveniente tanto
para satisfaccin del cliente como para el buen desarrollo del proyecto que se deje
constancia de ello por escrito con una notacin concisa; en nuestro caso se deja
constancia a travs de modelos en notacin UML y UML extendido.
Software. El objetivo de cada iteracin propuesta en MIDAS es la obtencin de un
prototipo o versin del producto software a travs de ciclos cortos de desarrollo, con la
finalidad de garantizar el progreso del software. Gracias a que el proceso es adems
incremental, el producto final se obtiene a travs de versiones lo que permite entregas al
cliente de forma rpida, previas a la versin final. Por lo tanto, s que dotamos de una
alta prioridad tambin a este aspecto, tanto a nivel de prototipo, como de versin no
definitiva.
Hay que destacar en este subapartado que, segn afirma Mellor et al. (2003), el hecho
de tener identificado un conjunto de modelos especficos as como sus reglas de
transformacin (Cceres et al., 2003), es tambin una forma gil de desarrollo, puesto
que cada modelo es autnomo, completo y se enlaza con otros modelos.
Proceso metodolgico de MIDAS
En MIDAS se ha combinado la arquitectura de MDA con una arquitectura de capas
donde cada capa representa una vista del sistema (Kulkarni y Reddy, 2003). De esta
forma tenemos una representacin bidimensional de nuestro proceso metodolgico (ver
figura 2).
CIM
DOMINIO NEGOCIO
Proceso
Proceso PIM
FUNCIONALIDAD
HIPERTEXTO
CONTENIDO
PSM
Proceso
Fig. 2.- Dimensiones del proceso metodolgico de MIDAS
La dimensin correspondiente al eje x, representa las diferentes vistas del SIW que en
nuestra propuesta son la vista del hipertexto, la vista del contenido y la vista de la
funcionalidad. La dimensin correspondiente al eje y, representa la parte independiente
12
de computacin primero (CIM) y despus, la parte independiente (PIM) y dependiente
de tecnologa (PSM).
La interseccin de ambas dimensiones ha dado lugar a un conjunto de modelos que
representan, a nivel de CIM el modelado conceptual del contexto o entorno del sistema,
a travs del modelado del dominio y del negocio; a nivel de PIM el modelado del
hipertexto, del contenido y de la funcionalidad del sistema, desde el modelado
conceptual hasta la etapa de diseo (excluido el diseo lgico); y a nivel de PSM
representan tambin el modelado del hipertexto, del contenido y de la funcionalidad del
sistema, desde la etapa de diseo lgico hasta la implementacin.
El proceso de desarrollo de MIDAS, mostrado en la figura 3, comienza siempre en la
definicin de los CIM, y posteriormente evolucionar hacia los PIM y hasta los PSM.
Sin embargo desde el punto de vista del eje x, y una vez completados los CIM, el
proceso puede comenzar en diferentes puntos a nivel PIM. Puede comenzar en la vista
de contenido o bien en la vista de funcionalidad con la definicin del modelo conceptual
de datos o de casos de uso, respectivamente. A continuacin, las guas de
transformacin permiten pasar a definir, bien la vista de hipertexto a nivel de PIM, o
bien continuar dentro de las mismas vistas para definir, ya a nivel de PSM, el modelado
lgico. Esta decisin vendr dada por las necesidades del cliente o bien por una
priorizacin de requisitos realizada la etapa de especificacin de requisitos.
CIM
Modelo Negocio Modelo Dominio
<<Transformacin PIM - PIM>>
<< Transformacin PIM-PSM>>

Modelo Modelo de Modelo de
de Datos Hypertexto Casos de Usos
Modelo de Modelo de
PIM
Presentacin Modelo de
Composicin de
Servicio
Servicio
Modelo Lgico
Modelo Lgico Modelo Lgico Modelo Lgico de Modelo Lgico
de Composicin
de Datos de Presentacin Hypertexto de Servicio
de Servicio
PSM
CONTENIDO HIPERTEXTO FUNCIONALIDAD
<<Transformacin PSM - PSM>>
Fig. 3.- Proceso de desarrollo de MIDAS
4. Conclusiones y Trabajos Futuros

En este artculo se ha descrito el proceso metodolgico de MIDAS, dirigido por
modelos para el desarrollo gil de sistemas de informacin Web. Este proceso
metodolgico combina adems, la arquitectura de MDA con una arquitectura de capas,
tpica de las aplicaciones de negocio. Todo ello ha dado lugar a un conjunto especfico
de modelos y guas de transformacin entre los mismos con la finalidad de realizar un
desarrollo gil de sistemas de informacin Web y que adems se ha concretado para la
tecnologa XML y objeto-relacional.
13
Actualmente se estn refinando las guas de transformacin de los modelos relacionados
con la lgica de negocio. Como trabajos futuros se planea automatizar la
implementacin de los modelos y las transformaciones entre ellos, por medio de una
herramienta CASE.
Referencias
Atkinson, C., Khne, T. Model-Driven Development: A Metamodeling Foundation.
IEEE Software, Vol. 4, pp. 36-41, septiembre-octubre de 2003.
Ambler, S. (2003). Agile Model Driven Development is Good Enough. IEEE Software,
Vol. 4, pp. 71-73, septiembre-octubre de 2003.
Booch, G. (2001). Developing the Future. Software Solutions. Communications of
ACM, vol. 44 (3), pp. 119-121, March 2001.
Cceres, P.; Marcos, E. (2001) Procesos giles para el desarrollo de aplicaciones Web.
Taller de Web Engineering de las Jornadas de Ingeniera del Software y Bases de
Datos de 2001. (JISBD2001). En http://www.dlsi.ua.es/webe01/articulos/s112.pdf
Cceres, P.; Marcos, E.; Vela, B. A MDA-Based Approach for Web Information
System Development. Workshop in Software Model Engineering
(WiSME@UML'2003) in conjunction with UML Conference. Octubre, 2003. San
Francisco, USA. Aceptado.
Fraternali, P. (2000). Tools and Approaches for Developing Data-Intensive Web
Applications: a Survey. Retrieved July 2000 from the World Wide Web:
http://toriisoft.com
Jacobson, I., Booch, G., Rumbaugh, J. (2000). El proceso unificado de desarrollo del
software. Addison Wesley.
Lowe, D.; Hall, W. (1999). Hypermedia & the Web. An Engineering Approach. J.
Wiley and Sons.
Fowler, M. (2001). The New Methodology. Retrieved May 2001 from
http://www.martinfowler.com/articles/newMethodology.html.
Kulkarni, V., Reddy, S. (2003). Separation of Concerns in Model-Driven Development.
IEEE Software, Vol. 4, pp. 64-69, septiembre-octubre de 2003.
Marcos, E., Cceres, P., Vela, B. y Cavero, J.M. MIDAS/DB: a Methodological
Framework for Web Database Design (DASWIS 2001). LNCS-2465. Springer Verlag.
ISBN 3-540-44122-0. Septiembre, 2002.
Mellor, S.J., Clark, A.N., Futagami, T. (2003) Model-Driven Development. IEEE
Software, Vol. 4, pp. 14-18, septiembre-octubre de 2003.
Miller, J. and Mukerji, J. (Eds). (2001) Model Driven Architecture. Document number
ormsc/2001-07-01. Retrieved from: http://www.omg.com/mda, 2003.
Snchez Daz, J., Pastor Lpez, O. (2001). Generacin automtica de prototipos de
interfaz de usuario a partir de modelos de requisitos. Actas de las Jornadas de
Ingeniera de Requisitos Aplicada (JIRA 2001), pp. 83-97, Sevilla (Espaa), Junio de
2001.
Overmyer, S. P. (2000). What's Different about Requirements Engineering for Web
Sites? Requirements Engineering, Vol. 5, pp. 62-65, Springer-Verlag, London.
Weneger, H. (2002). Agility in Model-Driven Software Development? Implications for
Organization, Process and Architecture. Retrieved from
http://www.softmetaware.com/oopsla2002/wenegerh.pdf
14
Mutacin de casos de prueba de JUnit
Mara del Mar Jimnez, Macario Polo, Jos Luis Ruiz, Mario Piattini
Escuela Superior de Informtica
Universidad de Castilla-La Mancha
Paseo de la Universidad, 4; 13071-Ciudad Real (Spain)
Mar.Jimenez@uclm.es
Resumen
En este artculo se presenta un mtodo y una herramienta para generar u ejecutar
de manera automtica casos de prueba similares a los de JUnit, pero aplicando
operadores de mutacin.
1 Introduccin.
Las pruebas mediante mutacin fueron propuestas originalmente por Hamlet (1977)
y DeMillo et al. (1978), y han sido desde entonces muy utilizadas. Dado un programa P
que se va a probar, se genera un conjunto de copias de P, pero introduciendo en cada
copia una pequea alteracin, normalmente sintctica, mediante al aplicacin de un
operador de mutacin. A estas copias levemente alteradas se las llama mutantes de
P.
De acuerdo con Offut et al. (1996), las pruebas mediante mutacin comienzan
generando un conjunto de casos de prueba que son pasados al programa original P; si la
salida de ste es incorrecta para algn caso de prueba, se revisa P hasta que las salidas
sean correctas. Cuando P responde correctamente, se ejecuta el conjunto de mutantes
con todos los casos de prueba. Se dice que el mutante m vive cuando su salida es igual
que la de P para todos los casos de prueba; si su salida es distinta para algn caso,
entonces se dice que m es un mutante muerto. Un mutante puede permanecer vivo por
varias causas: bien porque los casos de prueba no hayan ejercitado la instruccin
mutada (en este caso, es preciso construir ms casos de prueba hasta conseguir matarlo),
bien porque el mutante sea funcionalmente equivalente al programa original (caso en el
que es imposible encontrar un caso de prueba que lo mate, resultando adems muy
dificultoso detectar dicha equivalencia funcional debido al enorme nmero de mutantes
que se generan y a la mayor o menor complejidad del programa).
La Figura 1 muestra en su lado izquierdo un sencillo programa Fortran (tomado de
Offut et al., 1996) y dos mutantes, obtenidos el primero mediante la modificacin del
lado derecho de una asignacin, y el segundo sustituyendo un operador de comparacin
por otro. Si P funciona correctamente para un conjunto grande de casos de prueba,
tendremos una seguridad grande de que est bien construido (pero, como es bien sabido,
nunca podremos garantizarlo al 100%); sin embargo, si no slo P se comporta
correctamente, sino que adems los mutantes dan salidas diferentes a P para todos los
casos de prueba, entonces tenemos an mayor garanta de que P se est comportando
correctamente en cada una de las instrucciones mutadas (con lo que, en cierto modo, nos
aproximamos a la resolucin del problema irresoluble de demostrar que un programa es
totalmente correcto); adems, al ofrecer cada mi una salida distinta de la dada por P,
podemos asegurar que se ha ejecutado la instruccin mutada en el programa original,
15
con lo que podemos conocer la cobertura alcanzada por los casos de prueba. Adems, si
P se comporta correctamente en la instruccin mutada y algn mutante ofrece una salida
distinta, entonces sabemos que la sentencia es correcta para ese caso de prueba; si
obtenemos resultados similares para otros mutantes, entonces tendremos mucha mayor
confianza en la calidad de esa sentencia, de las instrucciones anteriores y posteriores y
del programa completo.
P m1 m2
FUNCTION Min(I,J) FUNCTION Min(I,J) FUNCTION Min(I,J)
Min=I Min=J Min=I
IF (J .LT. I) Min=J IF (J .LT. I) Min=J IF (J .GT. I) Min=J
RETURN RETURN RETURN
Figura 1. Un programa y dos ejemplares de su conjunto de mutantes

La mutacin, por tanto, sirve a dos objetivos: (1) proporciona un criterio de
adecuacin de las pruebas (es decir, de su calidad) y (2) permite detectar fallos en el
programa que se est probando.
En este artculo se presenta una tcnica de prueba totalmente novedosa, basada en la
mutacin de casos de prueba JUnit. Los casos son adems generados de manera
automtica mediante una herramienta que extrae mediante Reflexin la estructura de la
clase que se va a probar.
2 Mutacin de casos de prueba JUnit

Por lo general, para aplicar mutacin es preciso utilizar un generador de mutantes
que debe comprender la gramtica del lenguaje en el que est escrito P, debiendo
adems disponer del cdigo fuente. Existen no obstante excepciones a este punto:
Ghosh y Matur (2001), por ejemplo, aplican diferentes operadores de mutacin a las
operaciones ubicadas en las interfaces de component es para probar la implementacin
de stos: as, por ejemplo, dada una operacin en un interfaz que toma dos parmetros x
e y, ejecutan la funcionalidad ofrecida por el componente mediante su interfaz original
pasando dos valores cualesquiera, y a continuacin los intercambian.
En nuestro trabajo tampoco es preciso disponer de cdigo fuente para aplicar
mutacin. Partiremos de una clase Java compilada en byte code (con extensin .class)
de la que extraemos su conjunto de constructores y mtodos mediante la API Reflection
incluida en java.lang.reflect. A partir de este conjunto, generamos de manera
automtica un conjunto de secuencias de prueba o, por mantener la notacin de
Graham et al. (1999), test scripts, compuestas cada una por una llamada a uno de los
constructores de la clase y una serie de llamadas a sus mtodos. Cada test script se
procesa para generar un conjunto de casos de prueba ejecutables, que consisten en la
llamada al constructor y a los mtodos contenidos en el test script, pero pasando ahora
valores reales a los parmetros de sus operaciones. La Figura 2 muestra un ejemplo de
esto: a partir de la clase Triangulo pueden generarse multitud de test scripts de
diferentes longitudes (nmero de mtodos), pero todas ellas consistentes en la llamada a
un constructor y a uno o ms mtodos de los ofrecidos por la clase. A partir del test
script y de un conjunto de valores de prueba que tenemos previamente almacenados
para cada tipo de dato (para el tipo int, por ejemplo, podemos almacenar valores lmite,
como el 327268 o el +32767, el cero, valores prximos a cero y otros valores
16
aleatorios), generamos un conjunto grande de casos de prueba, pasando las
combinaciones de los valores de prueba como parmetros en cada test case.
Clase que vamos a probar Descripcin del test script n 284
public class Triangulo implements { //TS_284
public Triangulo(){ ... } //public Triangulo()
public void setX(int x) { ... } //public void setY(int x1)
public void setY(int y) { ... } //public void setZ(int x1)
public void setZ(int z) { ... } //public void setX(int x1)
public void calcularTipo(){ ... } //public void calcularTipo()
}
Descripcin del 83 test case del test Descripcin del 84 test case del test
script n 284 script n 284
Triangulo TS_284_83= new Triangulo(); Triangulo TS_284_84= new Triangulo();
TS_284_83.setY((int)12455); TS_284_84.setY((int)32768);
TS_284_83.setZ((int)32768); TS_284_84.setZ((int)32768);
TS_284_83.setX((int)1); TS_284_84.setX((int)1);
TS_284_83.calcularTipo(); TS_284_84.calcularTipo();
Figura 2. Una clase, uno de sus test scriptsy dos de los test cases generados
Los test case que generamos siguen la misma filosofa que los casos de prueba de
JUnit, un entorno para automatizar la realizacin de pruebas de caja negra de programas
Java, que permite el Desarrollo dirigido por las pruebas, propio de las metodologas
giles (en particular, de XP) (Beck, 2003). Para crear casos de prueba de JUnit, debe
crearse una especializacin de Te stCase (Figura 3), y aadir a sta una serie de mtodos
de prueba, cuyo nombre debe comenzar por test para que sean interpretados y
ejecutados (mediante Reflexin) por la herramienta. Cada mtodo aadido constituye
realmente un caso de prueba, en el que, a grandes rasgos, se crea manualmente el objeto
(resultado) esperado, y mediante llamadas a mtodos de la clase que se est probando el
objeto (resultado) obtenido. Entonces, ambos objetos son comparados utilizando una
serie de mtodos assert que estn definidos en la clase Assert, de la que tambin hereda
la clase de prueba que hemos construido.
<<Interface>>
Test
Assert
TestCase TestSiute TestResult
Figura 3. Clases proporcionadas por JUnit para la automatizacin de la fase de pruebas
En nuestro caso, dada una clase que queremos probar, creamos una clase de prueba
a la que aadimos de manera automtica un conjunto de mtodos de prueba del estilo
del mostrado en la Figura 4.
17
public Triangulo testTS_284_23() throws Exception {
Triangulo TS_284_23= new source.Triangulo();
TS_284_23.setY((int)12455);
TS_284_23.setZ((int)32768);
TS_284_23.setX((int)12455);
TS_284_23.calcularTipo();
return TS_284_23;
}
Figura 4. Uno de los casos de prueba generados, contenido en la clase TestTriangulo.java
Como se observa en la figura, dentro de cada mtodo creamos un objeto

(TS_284_3) de la clase que estamos probando (Triangulo), sobre la que ejecutamos una
secuencia de sus operaciones, instancia que es finalmente devuelta por el mtodo.
La herramienta que genera estos casos de manera automtica genera tambin
mutantes de los casos de prueba. As, podemos aplicar el operador eliminacin de
mtodo (que aade un smbolo de comentario antes de la llamada a un mtodo) u otro de
la Tabla 1, en cada una de las llamadas a mtodos que realizamos en el ejemplo de la
Figura 4, obteniendo los mutantes siguientes:
public Triangulo testTS_284_23_m0() public Triangulo testTS_284_23_m1()
throws Exception { throws Exception {
// TS_284_23.setY((int)12455); TS_284_23.setY((int)12455);
TS_284_23.setZ((int)32768); // TS_284_23.setZ((int)32768);
TS_284_23.setX((int)12455); TS_284_23.setX((int)12455);
TS_284_23.calcularTipo(); TS_284_23.calcularTipo();
return TS_284_23; return TS_284_23;
} }
public Triangulo testTS_284_23_m2() public Triangulo testTS_284_23_m3()
throws Exception { throws Exception {
TS_284_23.setY((int)12455); TS_284_23.setY((int)12455);
TS_284_23.setZ((int)32768); TS_284_23.setZ((int)32768);
// TS_284_23.setX((int)12455); TS_284_23.setX((int)12455);
TS_284_23.calcularTipo(); // TS_284_23.calcularTipo();
return TS_284_23; return TS_284_23;
} }
Figura 5. Algunos de los mutantes generados para el caso de la Figura 4

Identificador Nombre Operacin
m0 AltOrd Altera el orden de dos mtodos
m1 CambConst Cambia el constructor
m2 EliMet Comenta un mtodo
m3 AaMet Aade un mtodo
m4 CambPara Intercambia dos parmetros del mismo tipo
m5 CambValPara Cambia el valor de un parmetro
Tabla 1. Operadores de mutacin para casos de prueba
Los mutantes generados con este operador son, en principio, casos de prueba
previamente generados, por lo que estamos repitiendo ejecuciones, sin embargo, lo que
nos interesa es ejecutar versiones mutadas del caso de prueba para observar y comparar
su comportamiento.
Como se observa, tanto el mtodo de prueba original como los mutantes devuelven
un objeto de la misma clase, pero cada uno ha sido construido aplicndole un conjunto
diferente de operaciones. Si, al igual que ocurre en mutacin tradicional, comprobamos
que el mtodo original (Figura 4) ofrece el resultado correcto, podemos ejecutar los
mismos casos de prueba sobre los mutantes con el fin de observar la salida de stos.
18
Entonces, comparamos el resultado ofrecido por el mtodo original con el que ofrece
cada uno de los mtodos de prueba. Esto se realiza tambin mediante la ejecucin de
otro mtodo, generado tambin de forma automtica, que es el ofrecido en la siguiente
figura:
public void comprobarTS_284_23() {

Triangulo TS_284_23=null;
Triangulo TS_284_23_m0=null; Inicializacin de los
Triangulo TS_284_23_m1=null; objetos
Triangulo TS_284_23_m2=null;
Triangulo TS_284_23_m3=null;
try { TS_284_23= testTS_284_23(); }

catch (Exception e) {}
try { TS_284_23_m0= testTS_284_23_m0(); }
Asignacin de los objetos
try { TS_284_23_m1= testTS_284_23_m1(); } mediante llamadas al mtodo
catch (Exception e) {} original y a sus mutantes
try { TS_284_23_m2= testTS_284_23_m2(); }
try { TS_284_23_m3= testTS_284_23_m3(); }
En las siguientes lneas se compara el objeto bueno(el obtenido con la versin no
mutada del test case: testTS_284_23()) con los obtenidos mediante mutacin,
actualizndose las variables que cuentan el nmero de vivos y muertos
if (TS_284_23==null && TS_284_23_m0==null) mVivos++;

else if ((TS_284_23==null && TS_284_23_m0!=null) || !TS_284_23.equals(TS_284_23_m0))
mMuertos++;
else mVivos++;
if (TS_284_23==null && TS_284_23_m1==null)
mVivos++;
mMuertos++;
else mVivos++;
mVivos++;
mMuertos++;
else mVivos++;
mVivos++;
mMuertos++;
else mVivos++;
Por ltimo, se guardan los resultados de forma tabulada en un fichero de texto
String cab="TS_284_23;TS_284_23_m0;TS_284_23_m1;TS_284_23_m2;TS_284_23_m3\n";
String lin=(TS_284_23==null ? "null;" : TS_284_23.toString() + ";") +
(TS_284_23_m0==null ? "null;" : TS_284_23_m0.toString() +";") +
(TS_284_23_m3==null ? "null\n" : TS_284_23_m3.toString() +"\n");
try { mF.write(cab.getBytes()); mF.write(lin.getBytes()); } catch (Exception e) {}
}
Figura 6. Mtodo generado para comparar los objetos creados por el mtodo original y sus
mutantes
19
3 testOO: la herramienta de generacin automtica de casos
de prueba
testOO es una herramienta que extrae mediante Reflexin el conjunto de
operaciones de una clase Java ya compilada, y que genera una clase que contiene una
lista de mtodos test, consistentes cada uno en la construccin de un objeto y una
secuencia de llamadas a sus mtodos (como el mostrado en la Figura 4), un conjunto de
mutantes para cada mtodo de prueba (Figura 5), varios mtodos para comparar los
resultados obtenidos por los mtodos buenos (no mutados) y los mutantes (Figura 6),
as como una funcin main en la que se llama a los distintos mtodos de comparacin
(Tabla 1). Ha sido desarrollada por Jos Luis Ruiz, coautor de este artculo.
public static void main (String [] args){
TestTriangulos2 tc=new TestTriangulos2();
tc.comprobarTS_284_1();
...
String s="Muertos: " + tc.mMuertos + "; Vivos: " + tc.mVivos;
try { tc.mF.write(s.getBytes()); tc.mF.close(); } catch (Exception e) {}
}
}
Figura 7. Funcin main que ejecuta y muestra los resultados de la prueba, aadida a la clase de
prueba
El lado izquierdo de la siguiente figura muestra la ventana inicial de testOO, a partir
de la cual se carga la clase compilada (tambin puede cargarse una clase de un modelo
Rational Rose con el mismo objetivo) y se muestra en un rbol su lista de miembros. El
usuario selecciona la longitud de los test cases que desea generar. testOO genera todas
las secuencias posibles de llamadas (test scripts) de longitudes desde 1 hasta la
especificada, y las muestra en la ventana que se muestra en el lado derecho.
Obviamente, se genera un nmero muy grande de test scripts que no ocurrirn en la
ejecucin real de la clase (como la mostrada en la figura), por lo que el usuario puede
eliminar manualmente las que no desee en la ventana que aparece a la derecha de la
Figura 8 (Doong y Frankl, 1994, proponen un mtodo de filtrado de test scripts mucho
ms elegante, que modela las secuencias de llamadas vlidas mediante expresiones
regulares; estamos trabajando en un mtodo similar, que acepte o rechace secuencias
segn el diagrama de estados que describe la clase que se est probando).
20
Figura 8. Aspecto de la herramienta testOO
Tras pulsar el botn Continue en la ventana del lado derecho de la figura anterior, la
herramienta genera un fichero de prueba que contiene el cdigo que ejecutar las
pruebas. Para ello, toma los test scripts aceptados por el usuario y, para cada uno,
genera un conjunto de test cases ejecutables dando a los parmetros valores reales
(recurdese el ejemplo mostrado en la Figura 2). Cuando el tipo de los parmetros es
primitivo no hay problema en la asignacin de los valores; cuando el tipo de alguno de
ellos es complejo (por ejemplo: en la clase Tarjeta de una aplicacin bancaria hay una
operacin transferir(Cuenta destino, double importe, String concepto), en donde Cuenta
es una clase de la propia aplicacin), el objeto usado para dar valor al parmetro debe
existir previamente, haber sido serializado y haber sido salvado en un directorio
especfico en el que testOO busca valores de prueba.
La herramienta incluye un editor/visor manual de objetos, que permite crear y
serializar instancias. En la Figura 8, el usuario est creando una instancia de Tarjeta,
que tiene dos campos de tipo String (mNumero y mTitular) y otro de tipo Account. Para
dar valor a los dos primeros, el usuario utiliza la caja de texto que hemos resaltado con
una elipse; el tercer campo no es asignable de esta manera, sino que debe asignarse
mediante un objeto que ya debe estar creado y guardado en disco, lo que se hace con la
caja de texto de debajo, que muestra un cuadro de dilogo para que el usuario navegue y
cargue el objeto que quiere asignar. La creacin manual de objetos es desde luego
bastante costosa, pero los objetos quedan archivados para ser reutilizados cuando sea
necesario; esto se consigue utilizando la serializacin automtica, que me permite
guardar objetos en tie mpo de ejecucin.
21
Figura 9. Editor manual de objetos.
4 Conclusiones y trabajo futuro

La tcnica y herramienta presentadas ayudan al ingeniero de pruebas a generar de
manera automtica casos de prueba adecuados para probar programas Java. El coste de
los algoritmos de generacin es muy elevado, dependiendo fundamentalmente del
nmero de test scripts aceptados por el usuario y del nmero de valores de prueba de
cada tipo de dato, por lo que estamos trabajando con ahnco en este sentido.
Igualmente, tenemos pendiente la realizacin de experimentos (que ser sencilla,
gracias a la gran cantidad de cdigo abierto existente) para comprobar la validez de la
estrategia de generacin de casos de prueba y la utilidad del mtodo. Por ltimo, y tras
haber comprobado las caractersticas de Reflexin ofrecidas por la plataforma .NET.
Con ello ampliaremos las posibilidades de la herramienta para realizar pruebas no slo
sobre byte code de Java, sino para poder realizar pruebas a partir de la estructura de las
clases contenidas en una .dll, un .exe o un .class, adaptaremos testOO para que pueda
funcionar en esta plataforma.
5 Agradecimientos
Este trabajo est parcialmente financiado por el proyecto MS (Mantenimiento
gil del Software), TIC2003-02737-C02-02, Ministerio de Ciencia y Tecnologa.
22
6 Referencias
Beck K. (2003). Test-drive development: by example. Addison-Wesley. Boston,
MA, EE.UU.
DeMillo RA, Lipton RJ y Sayward FG. (1978). Hints on test data selection: help for
the practicing programmer. IEEE Computer, 11(4), 34-41.
Doong RK. y Frankl PG. (1994). The ASTOOT approach to testing object-oriented
programs. ACM Transactions on Software Engineering and Methodology, 3(2):101-130.
Fewster M y Graham D. (1999). Software Test Automation. Addison-Wesley, ACM
Press Book. Boston, MA, EE.UU.
Ghosh S y Mathur AP. (2001). Interface mutation. Software Testing, Verification
and Reliability, 11, 227-247.
Hamlet, RG. (1977). Testing programs with the aid of a compiler. IEEE
Transactions on Software Engineering, 3(4).
Offut AJ, Rothermel G, Untch RH y Zapf C. (1996). An experimental determination
of sufficient mutant operators. ACM Transactions on Software Engineering and
Methdology, 5(2), 99-118.
23
24
Experiencias de formacin en metodologas giles
Patricio Letelier, Jos Hilario Cans, M Carmen Penads y Juan Snchez

Departamento de Sistemas Informticos y Computacin
{letelier, jhcanos, mpenades, jsanchez}@dsic.upv.es
Resumen
Las metodologas giles estn acaparando gran inters en la industria del software generando una clara
necesidad de formacin en este enfoque. El trmino gil est estrechamente asociado a un conjunto de
ideas pragmticas para la produccin de software, con un marcado nfasis en los aspectos humanos
del trabajo en equipo. Por estas caractersticas, la formacin en metodologas giles supone la
bsqueda de estrategias innovadoras que permitan motivar al alumno y escenificar los aspectos claves
de la filosofa que conlleva una metodologa gil. En este trabajo se describe nuestra experiencia de
formacin en metodologas giles realizada en los dos ltimos aos con alumnos de informtica en la
Universidad Politcnica de Valencia. Se explica el esquema de trabajo establecido, fruto de una serie
de refinamientos, incluyendo el mtodo docente y el mtodo de evaluacin aplicados.
1. Introduccin
Es indudable el inters que han despertado las metodologas giles para el desarrollo de software.
Despus de ser vistas en un comienzo como una moda o una mera corriente radical, han pasado a ser
un atractivo medio para mejorar el proceso de produccin de software, con bastante afinidad respecto
de las necesidades actuales de muchos equipos de desarrollo en la industria del software. Este inters
industrial ha ido acompaado del reconocimiento en entornos acadmicos y de investigacin,
demostrado por el espacio conseguido en conferencias internacionales y revistas de prestigio.
Acompaado de esta situacin surge la necesidad de contar con estrategias de formacin en
metodologas giles. Sin embargo, los esquemas tradicionales utilizados para llevar a cabo la
formacin en notaciones de modelado y en herramientas no son apropiados, principalmente porque la
formacin en una metodologa debe orientarse a la aplicacin efectiva de los conocimientos en
notaciones y herramientas, enfatizando el marco de proyecto de ingeniera y el trabajo en equipo. Los
trabajos realizados en este mbito son escasos y suelen estar ms orientados a la evaluacin de
prcticas giles mediante experimentos.
El objetivo de este trabajo es presentar una estrategia de formacin en metodologas giles y los
resultados de nuestra experiencia en su aplicacin, llevada a cabo durante los aos acadmicos 2002-
2003 y 2003-2004 en la Escuela Tcnica Superior de Informtica Aplicada (ETSIA) y en la Facultad
de Informtica (FI) de la Universidad Politcnica de Valencia (UPV). Nuestra iniciativa se enmarca
dentro del contexto de programas de ayuda a la mejora de la enseanza del Proyecto EUROPA [6].
Las asignaturas objeto de la experiencia son: El proceso del software (PSW) y Laboratorio de
Desarrollo de sistemas de informacin (LDS), ambas optativas de tercer ao en la intensificacin en
Ingeniera del Software de la ETSIA, y Laboratorio de Sistemas de Informacin (LSI), optativa de
quinto curso en la FI. El trabajo aqu presentado es la continuacin natural de otros previos de los
autores [3, 4, 5].
Debido a que eXtreme Programming (XP) [1] es la metodologa gil ms popular y que cuenta con
abundante informacin en libros e internet decidimos centrar en ella nuestro estudio.
25
El resto de este artculo est organizado como se describe a continuacin. En la seccin 2 se presenta
el contexto de aplicacin donde se est realizando la formacin en metodologas giles. En la seccin
3 se describen el mtodo docente y de evaluacin utilizados. Finalmente en la seccin 4 se establecen
las conclusiones y el trabajo futuro.
2. Contexto de aplicacin
Dado que la enseanza de una metodologa exige que el alumno tenga cierta madurez en cuanto a
conocimientos y experiencia en construccin de software, decidimos abrir un espacio a las
metodologas giles en los contenidos de los ltimos cursos, tanto en la titulacin de Ingeniero
Tcnico en Informtica (en la ETSIA) como en Ingeniero en Informtica (en la FI). Comenzamos el
perodo 2002-2003 en la FI con la asignatura LSI. Este segundo ao de aplicacin hemos definido
tambin un esquema para la ETSIA, aprovechando la implantacin del nuevo plan de estudios que
inclua la Intensificacin Ingeniera del Software, a la cual pertenecen las asignaturas PSW y LDS.
Las clases de laboratorio se imparten en un aula que dispone de 20 puestos de trabajo acondicionados
para 40 alumnos. Las clases de teora y problemas se realizan en un aula tradicional.
LSI es una asignatura optativa de quinto ao con una asignacin de 6 crditos, todos ellos son crditos
de laboratorio. La matrcula en LSI ha ido en aumento en los ltimos aos hasta llegar actualmente a
copar el mximo establecido de 60 alumnos. LSI viene impartindose desde el perodo 1997-1998 y
sus contenidos han evolucionado desde prcticas con notaciones de modelado y herramientas CASE
hacia el trabajo en equipo para desarrollar un sistema de informacin. Hasta hace tres aos, slo
utilizbamos Rational Unified Process (RUP) [2] como metodologa en LSI. Al introducir XP en LSI
nos pareci apropiado mantener tambin RUP para ofrecer una visin ms global en el mbito de las
metodologas. Este ao se han definido 8 equipos de trabajo de 6 a 8 integrantes. As, 4 equipos
utilizan RUP y los otros 4 trabajan con XP. Cada alumno asiste a dos sesiones semanales, de 2 horas
cada una.
PSW es una asignatura de tercer ao de la ETSIA que cuenta con 4.5 crditos de teora y problemas, y
1.5 de laboratorio. PSW se imparte en el primer cuatrimestre. En los contenidos tericos, PSW aborda
los modelos de proceso para desarrollo de software, metodologas (XP, RUP, Mtrica) y estndares en
ingeniera de software. En su parte prctica se realiza un caso de estudio aplicando el Juego de la
Planificacin de XP.
LDS se impartir en el segundo cuatrimestre de tercer ao en la ETSIA y dispone de 1.5 crditos de

teora y problemas, y 4.5 crditos de laboratorio. LDS estar dedicada ntegramente a la realizacin de
un proyecto de desarrollo de software trabajando en equipos y utilizando XP como metodologa.
Hay que considerar que en tercer ao en la ETSIA los alumnos en otras asignaturas comienzan a
trabajar con el modelo orientado a objetos y aprenden modelado conceptual de bases de datos. Con lo
cual, para PSW y LDS no se haca recomendable utilizar una metodologa tradicional, al menos en la
parte prctica, puesto que se presentaran problemas de sincronizacin difciles de resolver respecto de
los conocimientos y madurez necesaria en notaciones y herramientas. As, el esquema que hemos
depurado en LSI lo aprovechamos y adaptamos para la ETSIA distribuyndolo en parte en PSW (la
parte terica de metodologas giles y un caso prctico aplicando el Juego de la Planificacin) y en
LDS (el formato de proyecto de desarrollo trabajando en equipos).
26
3. Mtodo docente y de evaluacin
En esta seccin nos centraremos en describir el esquema que hemos establecido en LSI para la
enseanza de metodologas giles, en particular XP.
LSI se imparte por dos profesores, de los cuales uno desempea el rol de cliente y el otro de
entrenador para todos los equipos XP. Cada equipo XP tiene un jefe, un tester/tracker y entre 4 a 6
programadores. La composicin de los equipos y la asignacin de los roles se efecta de forma
aleatoria.
Planificacin XP
1 2 3 4 5 6 7 8 9 10 11 12
Fin Fase de Exploracin Fin de la Fin de la Fin de la

y de Planificacin 1ra iteracin 2da iteracin 3ra iteracin
de la Entrega
Figura 1: Hitos en la planificacin de la entrega
En la Figura 1 se muestra la planificacin global de la entrega, preestablecida de acuerdo con las

restricciones temporales de las asignaturas LSI y LDS. En base a las 12 semanas con que suele contar
un cuatrimestre (podran ser un par ms que se dejaran para otras actividades despus del trmino del
proyecto), se definen 4 iteraciones de 3 semanas cada una. La primera cubre las fases XP de
Exploracin y de Planificacin de la Entrega. Durante esta primera iteracin en LSI se tiene la
oportunidad de introducir RUP y XP de forma muy breve, con lo cual el trabajo del entrenador es
fundamental sobre todo al comienzo del proyecto. En LDS no se presenta este inconveniente puesto
que la introduccin a metodologas giles y XP, junto con una prctica del Juego de la Planificacin,
se imparten en el primer cuatrimestre en PSW.
Al trmino de cada iteracin los equipos realizan una presentacin del resultado obtenido, incluyendo
una demo del producto y comentarios de las incidencias en la planificacin y otras aparecidas durante
el trabajo de la iteracin. Se hace hincapi en la deteccin (encargada al tracker) y resolucin
inmediata de desviaciones en la planificacin mediante negociacin con el cliente.
Durante todo el desarrollo del proyecto se dedica una sesin semanal exclusiva al trabajo en equipo en
el laboratorio. En estas sesiones est presente el cliente. La otra sesin semanal se utiliza para las
presentaciones de seguimiento y actividades complementarias trabajando slo con el entrenador.
Adems, tanto el cliente como el entrenador estn disponibles para los equipos en los horarios
establecidos para tutoras u otros que de comn acuerdo puedan establecerse. Los equipos se renen
segn sus disponibilidades. Sin embargo, para conseguir la aplicacin del equivalente a la prctica de
las 40 horas semanales se estableci un lmite de 12 horas de trabajo semanal para cada alumno,
incluyendo las 4 horas de trabajo en laboratorio.
Los artefactos con los cuales se trabaja son: Historias de Usuario, Tareas, Casos de Prueba, Plan de la
Entrega y Cdigo. Adems se deja como opcional el utilizar cualquier tcnica de modelado.
Normalmente los equipos al menos utilizan un modelo lgico relacional para el diseo de la base de
datos.
27
En la pgina web de la asignatura (http://www.dsic.upv.es/asignaturas/facultad/lsi/), en el apartado
contenidos, puede verse el detalle de las actividades que se realizan, el mtodo docente para cada
una de ellas, el material de apoyo proporcionado al alumno y el tipo de evaluacin.
En LSI se aplica un sistema de evaluacin continua. Coincidiendo con cada presentacin de

seguimiento del proyecto se otorgan 3 calificaciones a cada integrante del equipo. El cliente otorga
una nota igual para todos los integrantes del equipo basndose en los objetivos establecidos en el plan
para el producto, as como en la negociacin para resolver las incidencias. El entrenador comunica al
jefe un nmero que debe ser repartido entre los integrantes del equipo; dicho nmero corresponde a
una nota global multiplicada por el nmero de integrantes. Esta nota global est basada en la
presentacin de seguimiento, en la dinmica de colaboracin que muestre el equipo y en a
constatacin de cmo se estn aplicando las prcticas de XP. Finalmente, cada integrante debe otorgar
una calificacin al resto de sus compaeros de equipo; estas calificaciones se promedian para dar
como resultado una tercera evaluacin. Adems de estas 12 evaluaciones se realizan otras
correspondientes a actividades de apoyo o fuera del contexto del proyecto. Todas estas calificaciones
tienen un peso de 80% sobre la nota final. Por ltimo, se realiza un examen escrito que se pondera con
un 20%.
En PSW el trabajo de laboratorio se evala de acuerdo con una presentacin del resultado del la
exploracin y de la planificacin de la entrega. Los equipos deben presentar las Historias de Usuario,
Plan de la Entrega, Tareas para la primera iteracin y prototipos desarrollados. Este caso de estudio se
pondera con un 30% de la nota final. El otro 70% corresponde al examen que cubre los contenidos
tericos de la asignatura.
4. Conclusiones y trabajo futuro

Los alumnos han acogido muy favorablemente la estrategia de trabajo implantada; prueba de ello es su
participacin, la evaluacin positiva que hacen de la asignatura en las encuestas, la masiva asistencia a
clases y a tutoras, y el considerable incremento en la matrcula (hasta agotar el cupo mximo). En este
sentido la experiencia ha sido gratificante, compensando el esfuerzo adicional que ha supuesto en la
dedicacin de los profesores.
En cuanto a la recreacin eficaz de una situacin real de proyecto, pensamos que hay algunos aspectos
claves que han contribuido positivamente, entre los que destacaron: a) se cuenta con dos instructores
que realizan de forma separada el rol de cliente y el de entrenador; b) se efectan presentaciones de
seguimiento del proyecto y se comenta desde distintas perspectivas (como cliente y como entrenador)
el trabajo realizado; c) la utilizacin de un mtodo de evaluacin diversificado en el cual cada
integrante tiene una evaluacin como parte del equipo desde la perspectiva del cliente, como
integrante del equipo evaluado pblicamente por el jefe, y como participante, evaluado secretamente
por sus compaeros de equipo; y d) la eleccin de un buen caso de estudio en el cual el cliente pueda
desenvolverse con naturalidad y ofrecer material de apoyo como por ejemplo documentos con datos
utilizados por el sistema actual. Con respecto a esto ltimo hemos obtenido los mejores resultados
trabajando con un sistema de informacin que exista y haba sido desarrollado por el profesor que
desempeaba el rol de cliente.
En XP se han presentado conflictos entre miembros del equipo. Esto tiene su clara explicacin en el
hecho que los diferentes ritmos de trabajo y capacidades quedan ms rpidamente en evidencia en el
esquema de trabajo XP, que exige una mayor interaccin, participacin y protagonismo de los
integrantes. Sin embargo, en todos estos casos la situacin se apacigu o al menos se llegaron a
28
acuerdos prcticos de cara a los objetivos. Esto le dio una perspectiva de realismo no esperada al caso
de estudio y como tal fue asumida y aprovechada como experiencia.
En LSI al principio se tiene un gran inconveniente: los alumnos no conocen la metodologa y no se

dispone de mucho tiempo para dedicar sesiones a desarrollar un ejemplo guiado. Para solventar en
parte este problema se realiza una presentacin introductoria de mtodos giles y XP, describiendo
cada una de sus prcticas y aportando guas para que se pueda comenzar a trabajar. Sin embargo, el
comienzo del proyecto conlleva una carga considerable de trabajo para el entrenador. De manera
similar, el cliente durante las fases de exploracin y de planificacin tiene alta carga de trabajo, puesto
que a los alumnos no se les entrega un enunciado del problema, sino que deben comenzar desde cero a
establecer los requisitos.
Con las asignaturas PSW y LDS se ha comenzado este ao una experiencia similar a la implantada en
LSI. En este caso las condiciones parecen incluso ms apropiadas para la incorporacin de
metodologas giles. Los alumnos en tercer curso de la ETSIA comienzan a aprender notaciones de
modelado (E-R para diseo de bases de datos y UML en orientacin a objetos). En segundo curso slo
llegan a ver el enfoque estructurado (DFDs y Diagramas de Estructura) y diseo lgico relacional. As,
la incorporacin de una metodologa tradicional tendra muchos inconvenientes para ser exitosa. Por
otra parte, la sencillez de una metodologa gil como XP permite dar al alumno una visin del trabajo
en equipo en un proyecto de desarrollo de software utilizando un enfoque disciplinado, todo ello
dentro de las restricciones de tiempo que tiene una asignatura.
Para las estimaciones y el seguimiento de la planificacin result efectiva la utilizacin de puntos. Un

punto de esfuerzo en una Historia de Usuario equivala a una semana ideal de trabajo (12 horas en
nuestro caso). De esta forma se facilitaba el trabajo de planificacin al separarlo del efecto de la
dedicacin parcial de los alumnos.
Respecto de las prcticas XP, su grado de aplicacin vara y es uno de los aspectos que pensamos que
se debera intentar mejorar. Entre las prcticas que ms dificultades de aplicacin presentaron estn:
pruebas, refactoring e integracin continua. Estas prcticas requieren experiencia y mucha disciplina,
lo cual es difcil de conseguir sin un entrenamiento previo. En el caso de las pruebas, no basta con
herramientas del tipo XUnit puesto que particularmente en sistemas de informacin de gestin gran
parte de las pruebas se asocian a probar interfaces grficas de usuario. La integracin continua y el
trabajo en grupo necesitan disponer de herramientas adecuadas, que permitan control de versiones y
automatizacin en la integracin y pruebas asociadas. Por otra parte, aunque el cliente in-situ es sin
lugar a dudas importante, para efectos de formacin la disponibilidad que establecimos para el cliente
result suficiente. Similarmente, en un comienzo pensamos que la configuracin del espacio de trabajo
que ofrecan nuestros laboratorios poda constituir un inconveniente, pero no fue as. La programacin
en parejas tampoco present problemas destacables, aunque por problemas de coincidencias horarias
entre los integrantes no toda la programacin se hizo en parejas. El resto de las prcticas de XP fueron
aplicadas en un alto grado, particularmente Entregas Pequeas y Juego de la Planificacin.
Como trabajo futuro, adems de la continua mejora en el plan de trabajo y en el material de las
asignaturas, nos planteamos las siguientes tareas:
- Continuar con la iniciativa de dejar disponible todo el material en la pgina web de las asignaturas,
tal como ya se hace con LSI.
- Hemos comenzado un proyecto para dotar de infraestructura para el trabajo de los equipos. Se trata
de la implantacin de un servidor de contenidos va Web que permitir a los miembros de un
equipo de desarrollo de software (alumnos y profesores) colaborar en la realizacin de un proyecto.
Dicho servidor proporcionar un repositorio compartido para los artefactos generados durante el
29
proyecto y una serie de servicios tales como: administracin de usuarios, control de acceso, carga y
descarga de artefactos, discusin entre los miembros del equipo, material de apoyo para la
realizacin del proyecto (plantillas, ejemplos, etc.). Adems la informacin resultante del proyecto
quedar disponible para cursos posteriores. Tambin se incorporar la evaluacin continua del
alumno, pudiendo cada alumno conocer sus calificaciones hasta el momento, as como estadsticas
de evaluacin de su equipos y de los otros equipos. Para la implementacin se seleccionarn
herramientas Open Source y se desarrollarn las extensiones necesarias para ajustarlas a las
necesidades requeridas.
- Estamos realizando trabajos en control de versiones para historias de usuario y en herramientas

para integrar patrones de diseo y refactoring.
- Finalmente, estamos preparando un seminario en metodologa giles para desarrolladores de

software y que ser ofertado a travs del Centro de Formacin de Postgrado de nuestra universidad.
Este taller tendr una orientacin muy prctica siguiendo el esquema de las asignaturas en las
cuales hemos experimentado.
Referencias
[1] Beck K.. Una Explicacin de la Programacin Extrema, Aceptar el Cambio. Addison-Wesley,
2002.
[2] Jacobson I., Booch G and Rumbaugh J. The Unified Software Development Process. Addison-
Wesley, 1999.
[3] Letelier P., Cans J.H. Incorporando Extreme Programming como Metodologa de Desarrollo en
un Laboratorio de Sistemas de Informacin. Thomson, Actas de las IX Jornadas de Enseanza
Universitaria de la Informtica (JENUI 2003), pp. 257-264, Cdiz, Julio 2003.
[4] Letelier P., Cans J.H. An Experiment Comparing RUP and XP. Springer-Verlag, Lecture Notes
in Computer Science, Proceedings of IV International Conference on Extreme Programming, XP
2003, pp. 41-46. Gnova, Italia, Mayo 2003.
[5] Letelier P., Cans J.H. Working with Extreme Programming in a Software Development
Laboratory. Proceedings Fifteenth International Conference on Software Engineering and
Knowledge Engineering , SEKE 2003, pp. 612-615. San Francisco, Julio 2003..
[6] Proyecto EUROPA: Una Enseanza Orientada al Aprendizaje. Vicerrectorado de Coordinacin

Acadmica y Alumnado. Especficamente se trata de los programas AME2: Nuevos Mtodos de
Enseanza-Aprendizaje y AME3: Mejora de los Sistemas de Evaluacin. Universidad
Politcnica de Valencia, 2001. www.upv.es/europa
30
Brief eXPERT Approach Description
Teodora Bozheva
Parque Tecnolgico
48170 Zamudio, Bizkaia
Spain
Teodora.Bozheva@esi.es
Abstract: This document introduces a light method for software development

applicable to small teams developing projects characterised with often changing
requirements, tight schedules, and high quality demands. The method is called
eXPERT and builds on the principles of eXtreme Programming (XP) and the Personal
Software Process (PSP).
eXPERT APPROACH
Development Guidelines
All SME developing e-commerce and e-business software have similar business
objectives, namely Faster-Better-Cheaper. Reports from the field show that
productivity and software quality increase by applying XP principles. However, even
projects that have adopted several or all XP practices meet project management
problems, namely related to estimating and planning the project, both in terms of time
and costs.
To overcome this obstacle eXPERT focuses on combining XP and PSP practices. In
particular PSP principles are added to provide the development teams a means to
measure their effectiveness, use it to better plan and manage the projects, and as a
consequence increase the customer satisfaction. The combination considered the
following objectives:
o To maintain the approach comprehensive
o To maintain the approach easy to apply. Calculation of the additional
measurements is essential for making the method practical, however the
approach has to remain applicable by software developers.
o To provide all data necessary to perform good estimations, project planning
and management activities.
o To retain the people motivated to use the approach.
31
eXPERT approach architecture
The eXPERT approach builds on XP and PSP principles. The activities described into
the eXPERT approach are based on the XP practices. Certain modifications to the
pure PSP principles are introduced mainly related to measuring the effectiveness of
the activities and the defect rates in order to identify problem causes and to eliminate
them in the future. The logs for collecting project data follow the templates and the
principles of PSP, but are adjusted as to fit the XP method, in particular to reflect the
fact that developers work in pairs and the design, testing and coding process are
strongly interrelated and executed in parallel. The PROBE method used for
estimating time necessary to develop a given customer requirement considers
requirement complexity, which is a slight modification of the PROBE method used
in PSP.
The eXPERT approach is described in terms of processes. There are several reasons
for selecting this manner of representation, namely:
o Software development companies, influenced by the well-known models for
software process improvement like CMM, ISO and SPICE, are used to think
in terms of processes, and it will be easier for them to understand and
implement a process-oriented approach.
o A description in terms of processes facilitates the comparison between a
current state of the software development activities performed into an
organization with their state after the new approach has been implemented and
adopted.
o Companies who later will want to assess and/or increase their maturity
following models like CMM, ISO or SPICE, will be able to do it easier.
The eXPERT approach consists of the following processes, as shown on fig.1:
o Customer Requirements Management (CRM)
o Project Management (PM)
o Design (DS)
o Code (CD)
o Test (TS)
The processes are described in terms of
o Activities,
o Tasks that have to be done to complete an activity, and
o Responsible role for performing a task.
For the sake of brevity the processes are described herein only at the level of
activities. The complete description of the eXPERT approach also provides guidelines
for its application, definition of the probe method, data recording logs and a set of
tools supporting the usage of the method.
32
Customer requirements
Customer Iteration
Project Iteration
Requirements Estimated CR plan
plan
Management Management
Project planning
Testing Estimations
scenarios Communication
Design
Test-before-
code
Code Coding
standardTest
software product
Figure 1 eXPERT Process Architecture
eXPERT Organisational Structure (Roles)

eXPERT organisational structure is very simple. The roles defined are similar to those
in XP with some additional responsibilities related to the application of the PSP
practices. Of course, one person may execute more than one role in a project, but it is
important that this person has the necessary knowledge, skills and time for
performing all the responsibilities. In particular, eXPERT defines the following roles:
Customer
The customer chooses what will deliver business values, chooses which customer
requirements to do first and which ones to defer, and defines the tests to show that the
system does what it has to.
It is highly recommended that the Customer stays on-site, and be present with the
team full-time.
Customers responsibilities:
o To determine what will have business value, and the order of building that
value
o To express what must be done in terms of customer requirements.
o To prioritise the customer requirements that can be accomplished by the
desired delivery date.
o To define releases based on requirements prioritisation and complexity, and
considering project velocity.
33
o To specify tests that prove whether the requirements have been correctly
implemented. These acceptance tests are later implemented by developers to
validate the application.
o To perform the acceptance test before accepting the product from the
development team.
Project leader
The Project Leader supervises and guides the application of the eXPERT approach.
Project Leaders responsibility:
o To lead the everyday work: the day-to-day process of planning, designing,
testing, coding, releasing.
o To ensure that the entire team takes part into the release and iteration
planning. To coordinate the project activities.
o To take measures: project velocity, developers productivity, defect removal
efficiency
o To look for things that slow the team, and to resolve them.
o To resolve scheduling conflicts.
o To keep up-to-date stakeholders which are not directly involved in the
project.
o To tune the approach to the project and organisations needs.
Developer
The developers analyse, design, test, code, and integrate the system. The developers
estimate the difficulty of all requirements, and the time they need to develop and
deliver the product to the customer.
Developers responsibilities:
o To estimate requirements complexity
o To split requirements to tasks small enough
o To base the program on simple, clear design, to produce quality software
quickly.
o To improve the design using refactoring.
o To keep the system integrated at any time, so that there is a good working
version to look at.
o To share the ownership of the code, so everyone feels able to make everything
better.
o To follow the accepted coding standards.
o To make sure that the system always works, writing and using comprehensive
unit tests, and using customers acceptance tests.
o When necessary and appropriate to code in pairs, for maximum speed and cross
training, in support of shared code ownership and rapid progress.
o To support the Customer in implementing the acceptance tests.
34
EXPERT Processes
Customer Requirements Management

Overview: This process includes all activities related to eliciting, analysing and
controlling the customer requirements for a software product. It builds on the XP
practices related to handling user stories. The concept customer requirements is used
as a synonym of user stories from XP. The process is called customer requirements
management to convey the meaning of organizing, performing and controlling the
related activities and taking the responsibility for bringing them to an end.
Process Input: Customer needs and expectation
Activity1: Elicit Customer Requirements
Activity2: Analyse Customer Requirements (CR)
Activity3: Estimate Customer Requirements
Activity4: Measure the process
Process Output: Prioritised CR with complexity and time estimations
Completion criteria: Customer requirements are granulated to such an extent that

each of them is estimated to be developed in less than a week
The whole team understands well the customer requirements
Measurements: Effort spent on Customer Requirements Management
Project Management
Overview: The project management process encompasses activities related to
planning, tracking and controlling the software development. Project management
includes activities that ensure the delivery of a high-quality system on time and within
budget.
Estimation of the customer requirements is made into the Customer Requirements
Management process because it is a prerequisite for prioritising the customer
requirements and deciding which ones of them to include in the following iteration,
which is a responsibility of the Customer.
Process Input: Documented customer requirements
Activity1: Define the Project
Activity2: Create Release Plan
Activity3: Create Iteration Plan
Activity4: Monitor and Control the Project
Activity6: Conclude Project
Activity7: Measure the Process
Activity8: Tune process
35
Process Output: Iteration and release plans
Completion criteria: Project maintained on track, i.e. iterations and releases

executed as planned
Measures: Effort spent on Project Management, Project costs. Project velocity
Design
Overview: During the design process the customer requirements are decomposed to
product components. The design process is highly interrelated with the Code and Test
processes.
Process input: Documented customer requirements
Activity1: Prepare for design
Activity2: Design
Activity3: Document design
Activity4: Make Design Inspection
Activity5: Measure process
Process output: Coding standard, Design document
Completion criteria: simple design well understood by the whole team
Measures: Overall designing effort, Defects found during Design Inspection
Code
Overview: The objective of the Code process is to produce the code of the software
product that satisfies the customer requirements. The code is permanently maintained
in good condition, i.e. in reusable, testable and working state. The coding process is
highly interrelated with the Design and Test processes.
Process input: Documented CR, Design document, Coding standard
Activity1: Implement the product
Activity2: Integrate the code
Process output: Software product
Completion criteria: Customer requirements and acceptance tests satisfied
Measurement: Implementation effort
36
Test
Overview: The purpose of the Test process is to validate that the software product
produced meets the requirements and satisfy the acceptance criteria defined by the
customer. The Testing process is highly interrelated with the Code and Design
processes.
Process input: Documented CR, Design document, Coding standard
Activity1: Prepare for testing
Activity2: Implement acceptance tests
Activity3: Perform unit testing
Activity4: Perform regression testing
Activity5: Perform acceptance testing
Process output: Code without defects
Completion criteria: The test cases defined cover all typical, boundary, and specific
cases described by the customer requirements
Measures: Defects rate, Effort spent on acceptance testing
REFERENCES
eXPERT approach description and guidelines for its application, www.esi.es/Expert
Case studies about the 7 trials of the eXPERT approach: www.esi.es/Expert
L. Williams, The Collaborative Software Process, PhD dissertation
Ron Jeffries, Ann Anderson, Chet Hendrickson, The XP Series: EXTREME
PROGRAMMING Installed; Addison Wesley
Watts S. Humphrey, A Discipline for Software Engineering; Addison Wesley (1995)
37
38
eXPERT: Results from seven pilot projects
Teodora Bozheva
European Software Institute (ESI)
Parque Tecnolgico #204
48170 Zamudio (Bizkaia)
Teodora.Bozheva@esi.es
1. Introduction
For the past several years, business has been evolving into e-business, commerce into e-
commerce, education into e- learning, work into e-work, and the projects related to them
all are naturally called e-projects. This development of the e-era requires large amounts
of software development with specific requirements and constraints. If in software
development projects cost is usually the most important control criteria, in e-project
development time-to-market is in most cases the most critical, overriding cost, quality
or any other criteria; the reason is that often getting to the marketplace soon would
provide a very significant market opportunity.
Several agile methodologies appeared recently whose goal is to serve the needs of e-
service providers. They all aim at customer satisfaction, adaptability to changes,
delivering high quality products quickly and within an agreed budget frame. They look
promising but little actual experience still exists using them in real e-project
development (or any other development).
This article presents the results of seven pilot projects, which have applied an agile
method based on the principles of extreme programming (XP) and the Personal
Software Process (PSP) 1 , named eXPERT. The goal of combining XP and PSP is
twofold: (a) to improve developers productivity and product quality, and (b) to
facilitate the integration of beginner programmers into real software development
projects, namely to help them start working in a disciplined manner, to correctly define
and estimate their tasks, as well as to provide means for a smoother and more efficient
software development.
2. eXPERT
The eXPERT project 2 was established with two main objectives:
To define a practical combination of XP[3] and PSP[4] practices, named eXPERT
approach;
To experiment the eXPERT approach in 7 pilot projects in order to validate its
usability, benefits and pitfalls, and to collect and disseminate best practices and
lessons learned.
1
PSP is developed at the Software Engineering Institute (SEI), Carnegie Mellon University.
2
The eXPERT project (http://www.esi.es/Expert) is partially funded by the European Commission
through the IST programme (ref. IST-2001-34488) and by the Spanish Ministry of Science and
Technology (TIC-2001-5254).
39
The eXPERT approach includes all the XP practices, and three PSP practices: time and
effort recording, defect recording, task estimation by means of the Probe method,
modified as to reflect customer requirements complexity instead of LOC.
The eXPERT approach is described in terms of 5 processes: Customer Requirements
Management, Project Management, Design, Test, and Code. This allows software
development companies, influenced by models and standards like CMM(I) and ISO,
and used to think in terms of processes, to understand and implement the approach. A
description in terms of processes makes it easier to compare the state of the software
development activities performed in an organization at different times.
Despite the process-oriented description of the method it preserves the individual
orientation of XP and PSP, remains comprehensive and easy to apply, and at the same
time provides all the data necessary to perform good estimations, project planning and
management activities
3. Experiment approach
The eXPERT approach was defined after a thorough study of both models. Two of the
piloting teams had little experience in software development, and only one of the other
teams had previously applied some XP practices. Every team defined a Baseline project,
developed with the companies traditional approach and a comparable Pilot one, in
which the eXPERT approach was experimented. All the projects were real ones in the
area of e-commerce.
All the pilot projects had the following business goals:
o G1: To increase productivity of the developers by 20%
o G2: To reduce the defect rate by 30%
o G3: To decrease schedule and cost deviations by 15%.
Several metrics (see Table 1) were defined to show goal achievement. Companies, who
did not have available data, used part of the ir Pilot projects as a Baseline. In particular
they developed certain modules of the Pilot Project with the ir traditional approach in
order to obtain data and be able to see if there was an improvement or not. To decrease
the influence of the experience gained in the domain, different developers took part in
the implementation of the Baseline and the Pilot projects. The teams selected, however,
had relatively the same professional level. The duration of the pilot projects ranged from
6 to 9 months and they all were in the e-service area.
Three reviews were performed to all the pilot projects. They were realised according to
a predefined procedure. After each review lessons learnt by all the experimenting
companies were described and documented. Additionally, it was checked, if the project
objectives and the additional business goals defined by the companies were reached.
The collection of metrics, though tedious in the beginning as mentioned by the
companies, has proved to be useful, clearly showing whether the project objectives were
fulfilled, and the organisations keep applying them in their following projects.
40
Metric Calculation Unit Measured Possible degree of detail
Productivity Size / Effort Work/Time Size [KLOC] Measure Productivity

Effort [Man month] for the team
Velocity/Effort - Velocity for each pair
Effort [Man month] for each programmer
Defect Rate Number of defects Number Number of defects Make measurements for different types of defects
Measure Defect Rate both for the team and for each programmer
Measure Defect Rate for the whole project and for each release and/or iteration
(Effort spent for bug fixing / Effort) x % Effort spent for bug fixing Measure Defect Rate both for the team and for each programmer
100 [Man month] Measure Defect rate for the whole project and for each release and/or iteration
Effort [Man month]
Relative ((Real time - Planned time) / Planned % Real time [months] Measure the times planned and real for
Schedule time) *100 the whole project
Deviation Planned time [months] a release
an iteration
each user story/ feature/
Relative cost ((Real costs - Planned costs)/Planned % Real costs [K ] Measure the costs planned and real for
deviation costs) *100 the whole project
Planned costs [K ] a release
an iteration
each user story/ feature/
Relative project (1-Cost pp /Cost bp)x100 % Costpp [K ] Measure Relative project cost change
cost change Costbp [K ] For the overall project
For selected modules
Customer Customer satisfaction rated between % Questionnaire Measure the customer satisfaction with the whole project and/or during the project with each
satisfaction 0-100% release, iteration etc., depending of the company
Developer Developer satisfaction rated between % Questionnaire Measure the developer satisfaction with the whole project and/or during the project with each
satisfaction 0-100% release, iteration etc., depending of the company
Table 1: Metrics
41
4. Main results
The following results were obtained within the pilot projects with respect to the project
goals:
o G1: Productivity increased up to 73%. One company decreased its productivity
by applying eXPERT
o G2: Defect rates reduced between 10% and 83%.
o G3.1: Schedule deviation reduced between 7% and 38%.
o G3.2: Cost deviation decreased up to 31%. Only one company increased its cost
deviation.
As a consequence of the
Percentage of companies who achieved the following
achievement of the results results
with respect to G1-G3, the
companies software products 100%
are now at higher quality and 80%
developed in a shorter time 60%
that is their competitiveness %
40%
increased too. The diagram
20%
on the right shows the
0%
percentage of companies, who Increased Reduced Reduced sche- Reduced cost
productivity defect rate dule deviation deviation
achieved the defined
objectives.
The following correlation between the achievement of the business goals and the
application of the XP and PSP practices incorporated in the eXPERT approach was
observed:
o The factors that mostly influenced the productivity of the developers were
the improved discipline, which the eXPERT approach established in the
pilot projects, in particular the improved responsibility with respect to
the team mates, and the effort and defect tracking practices;
the maintenance of the code in working state due to the test-driven
development, the frequent integration and the small releases;
the better task estimations based on the PSP PROBE method and the
more effective time spending impacted by the metrics collection.
The team, which decreased its productivity had been postponing refactoring,
which resulted in re-design of a big part of the system implemented.
o The defect rate was mainly reduced due to the application of the test-before-code
principles and the requirement to integrate the code at least once a day and to
maintain it working.
o The schedule and cost deviations, although not completely removed, were
significantly reduced. Key contribution for this had the PSP practices included
42
in the eXPERT approach, namely the estimation with the PROBE method and
the effort tracking procedure.
All the teams applying the method found different ways to adopt it with benefits. For
the sake of brevity we are going to point out only the most important ones here. Case
studies about all the experiments, lessons learnt and a detailed analysis of the trials can
be found at the project web site, http://www.esi.es/Expert.
With respect to the work with the customer, since none of the companies managed to
have customer-on-site, three alternatives of this XP practice were found:
o Developer-on-site: Sending regularly a developer to the customers office to
present the latest state of the developed software and discuss modifications to
existing as well as new features.
o Web-demo: Develop a web site with restricted access to it providing the
customer possibility to see the current status of the development and provide
feedback about it.
o Excellent communication: the key difference from the traditionally
recommended good communication with the customer is that eXPERT advices
to achieve and apply an agreement with the customer that he/she is reachable
any time for development-related questions and is going to provide useful
feedback.
The software engineering practices have to be adjusted to the customs of the developers
and the organisational culture.
All the teams found pair programming difficult to apply all day long, but especially
useful when resolving key problems in the project. One of the experimenting companies
investigated deeper the relationship between the effectiveness of a pair and the
qualification of the buddies. The results showed that for difficult tasks, e.g. designing
the software architecture, experienced developers have to be paired, while the beginners
have to be paired for simpler tasks.
Test-before-code implies a New, Fixed and Closed Bugs Trend
change in the manner
programmers are used to 140
develop software and a is 120

100
key success factor for New
80
implementing error- free Fixed
60
products (see the diagram Closed
40
on the right).
20
eXPERT recommends 0
different approaches to
08 02
22 002
06 02
04 003
18 03
03
20 02
10 02
24 03
21 03
07 03
07 03
21 03
.20
.20
.20
.20
.20
.20
.20
.20
.20
.20
.20
.2
.2
introduce this practice.

.10
.11
.11
.03
.04
.04
.11
.12
.01
.02
.02
.01
.03
25
One possibility is to begin with implementing test cases for key functionality, e.g. the
business logic of the software, and gradually extend the test cases framework to cover
more software features. An alternative is to implement the test cases before code
43
integration. Although this approach is controversial to the principle to write the tests
before the code, the experience shows that conscious and continuous testing of recently
implemented small pieces of code leads to the same result as testing before coding.
Two ISO-certified organisations took part in the project. It showed up that the
application of eXPERT increased significantly the agility of their processes and
shortened the time-to-market with 30%. Apart from this about 80% of the effort is
devoted to Implementation and less than 10% is dedicated to Project Management (see
the diagram bellow).
Weekly efforts % ratio
90,0
80,0
70,0 PM
60,0
Design
50,0
Implementation
40,0
Bugs Fix
30,0
20,0 Testing
10,0
0,0
02
03
02
02
02
03
03
03
03
02
03
02
.20
.20
.20
.20
.20
.20
.20
.20
.20
.20
.20
.20
.11
.03
.10
.12
.01
.01
.02
.03
.04
.11
.02
.12
22
07
25
06
10
24
07
21
04
08
21
20
All the alternative approaches to implement eXPERT, found during the pilot projects,
are generalised in Guidelines for Applying the eXPERT Approach, which can be also
found at the project web site. Additionally, tools facilitating the method application are
recommended in the document.
5. Conclusion
The eXPERT approach proved to be helpful and effective for small software teams
developing business-critical projects cha racterised with often changing requirements,
exploration and application of new technologies, and need of fast integration of new
staff. It is relatively easy to implement and is well accepted by the developers. After
successful adoption it decreases the deviations from the schedule and the budget, and
improves customers satisfaction with the final product.
Unlike other agile methods, eXPERT offers a set of practices for collection of data,
which support the estimation of the projects with respect to time and effort needed for
their working out. Additionally guidelines for its application and a list of supporting
tools are provided, which make it a very useful and practical package necessary for
every team interested in implementing software faster, better, and cheaper.
References
1. Case studies about the 7 trials of the eXPERT approach: http://www.esi.es/Expert
2. L. Williams, The Collaborative Software Process, PhD dissertation
44
3. Ron Jeffries, Ann Anderson, Chet Hendrickson, The XP Series: Extreme Programming Installed;
Addison Wesley
4. Watts S. Humphrey, A Discipline for Software Engineering; Addison Wesley (1995)
45
46
Formal Agility. How much of each?
Angel Herranz and Juan Jose Moreno-Navarro
Univ. Politecnica de Madrid

Campus de Montegancedo s/n, Boadilla del Monte 28660, Spain
+34 9133674{52,58}
{aherranz,jjmoreno}@fi.upm.es
Abstract. Agile Processes and Formal Methods (FM), water and oil, impossi-
ble mixture? Yes at first sight. Nevertheless, being formal methods weight pro-
cesses and being agile processes informal approaches to software development,
it is worth to study how much formal can be an agile process like Extreme Pro-
gramming (XP) and how much agile can be a formal method. On our view, some
XP practices are suitable for a formal approach.
1 Motivation
At first sight, XP [1] and FM [10, 8] are water and oil: an impossible mixture. Maybe
the most relevant discrepancy is that while one of the strategic motivation of XP is
spending later and earning sooner FM require spending sooner and earning later.
However, a deeper analysis reveals that FM and XP can benefit their selves.
The use of formal specifications is perceived as improving reliability at the cost of
lower productivity. XP and other agile processes focus on productivity so, in principle,
using FM following XP practices could improve its efficiency. In particular, pair pro-
gramming, daily build, the simplest design or the metaphor are XP practices that in our
view are independent of the concrete development technology used to produce software
and the declarative technology and FM is just a different development technology.
On the other hand, one criticism to XP is that it has been called systematic hack-
ing and, probably, the underlying problem is the lack of a formal or even semi-formal
approach. What XP practices are liable to incorporate a formal approach? We think
that unit testing, incremental development and refactoring are three main XP practices
where FM can be successfully applied:
When you write a formal specification you are saying what your code must do,
when you write a test you are doing the same so one idea is to use formal specifi-
cations as tests.
Incremental development is in some sense similar to the refinement process in FM:
specifications evolve to code maintaining previous functionality.
Finally FM can help to remove redundancy, eliminate unused functionality and
transform obsolete designs into new ones, and this is refactoring.
After all, it might be possible to dilute FM in XP. We would like to point out that
we are not claiming to formalise XP, but just to study how the declarative technology
can be integrated in XP and how XP can take advantages of this technology.
47
2 Formal XP? How?
Most XP practices are technology independent. In our opinion, the XP process could be
adopted by using a formal method tool (an specification language and a verified design
process) instead of an ordinary programming tool. In other words, we propose to write
formal specifications instead of programs. A number of advantages appear:
Instead of the code is the documentation, the specification is the documentation
and business and development would have a high level description through a formal
specification of the intended semantics of the future code.
FM tools (theorem provers, model checkers, etc.) help to maintain the consistency
of the specification and the correctness of the implementation.
Important misunderstandings and errors can be captured in the early stages of the
development but close enough to code generation.
While in XP emphasis is on staying light, quick, and under a low ceremony process,
the introduction of FM might make XP sometimes heavier, sometimes not. Even in the
first case we would have that: i) it can still be considered a light method in the FM area,
and ii) the benefits should compensate in many cases the increase of work.
Writing specifications can be perceived as improductive because programmers have
to do their work anyway. In order to be productive enough a code synthesiser from
specifications is needed. In section 3 we discuss briefly this issue.
The introduction of FM in XP would not impact in all the practices, mainly because
most of them are technology independent. What XP practices would be more affected?
On our view, Testing, Refactoring an Continuous Integration. Other practices seem to
be easily adapted.
2.1 Unit Testing

In XP the role of writing the tests in advance is similar to the role of writing a precise
requirement: it is used to indicate what the program is expected to do. Tests in XP solves
two different problems:
The detection of misunderstandings in the intended specifications.
The detection of errors in the implementation.
The perspective under both problems is completely different when using FM. The
detection of inconsistencies in formal specifications are supported by formal tools,
mainly by a generator of proof obligations and by a theorem prover assistant. With
both tools the user get information about possible inconsistencies.
The detection of errors in the implementation is absolutely unneeded thanks to the
verified design process: a process that ensures that the code obtained from an original
specification is correct with respect to it. Notice that the use of tests do not ensure that
requirements are satisfied, just convince the programmer that it happens. The FM
approach overcome this limitation.
Anyway, writing formal specification is not an error free activity. These means that
tests can be lifted to the specification level by introducing formulas that are, at least,
proof obligations. The proof of such formulas allows detecting inconsistencies or mis-
understandings.
48
2.2 Incremental Development
During the Planning Game new customer stories are added in every iteration, these
means, in many cases, that those requirements are added incrementally. Most valuable
stories are then specified and new logical properties must be added to the system and
previous properties must still hold.
The formal meaning of a specification can be understood as a theory, a set of formu-
las. Let us say that the specification of the system after step i is i , a new story appears
at step i + 1 and the specification of the new story is the set of formulas i+1 . The the
specification at step i + 1 is then i+1 . We call the combination property at step i + 1
to the following property:
i+1 |= i , i+1
Theorem 1. Proved the combination property at every step i {1, . . . , n 1} the

following property holds:
n |= i
The proof would proceed by induction on i.
Informally: if after every iteration a new story is correctly specified the system will
implement correctly all the customer stories.
The most important consequence of paragraphs above is that we have a method
for proving that the specification entails every customer story. Is this method practical
enough? To be honest, the answer is no, it is not, it is a heavy method. But we would
like to point out that the prover technology will help a lot: a great amount of proofs can
be automatically done and the rest can be manually proved by guiding the prover.
2.3 Refactoring
With respect to Refactoring we think that FM can help in two different ways. First,
the system is restructured but the meaning cannot be changed. If the system has been
specified, to prove that the behaviour has not changed is possible. Second, declarative
technology makes easier to find and remove redundancy, eliminate unused functionality
and transform obsolete designs into new ones.
An open possibility is to specify generic patterns and then, whether a specification
is an instantiation of such a generic pattern can be proved. The idea is having a rele-
vant collection of generic patterns trust the prover technology of FM are able to match
specifications with specifications in those patterns. Some works in formalising design
patterns [2] have been done using SLAM-SL [3].
3 What FM?
We would like to finish with a brief discussion about which FM would be more suitable
for XP. From our point of view, the method should be close to the programming stage,
these means that high level languages like Z are not a good choice. A better one is VDM.
The VDM abstract syntax is close to the abstract syntax of a programming language.
49
Since 2001 our group is working in the design and implementation of a specification
language that, modestly, we think that it would be a good option: SLAM-SL [6, 9]. The
most relevant features of SLAM-SL for this work are:
It is an object-oriented specification language valid for the design and programming
stages in the software construction process (a non alien notation).
It has been designed as a trade-off between the expressiveness of its underlying
logic and the possibility of code synthesis. From a SLAM-SL specification the
user can obtain code in a high level programming language (let us say Java), a code
that is readable and, of course, correct with respect to the specification.
Because the code is readable, it can be modified and, we expect, improved by hu-
man programmers.
In [7] SLAM-SL was presented as a useful formal tool for AP. The reader can find
a deeper explanation of features above and its relationship with XP practices seen in
this work. Other, on our view, interesting autors work have todo with the synthesis of
asssertions for debugging from specifications: [4, 5].
4 Conclusions
We have presented how some XP practices can admit the integration of Formal Meth-
ods. In particular, unit testing, refactoring, and, in a more detailed way, incremental
development have been studied from the prism of FM. Probably there is more room for
FM ideas helping agile methodologies and XP, and we will study this as a future work.
One of the goals of the SLAM system is to make FM and their advantages closer
to any kind of software development. Obviously FM are specially needed for critical
applications but combining it with rapid prototyping and agile methodologies could
make them affordable for any software construction. Up to know we have not equipped
SLAM with an automatic interface generator that precludes the use of our system for
heavy graphical interface applications. The automatic generation of graphical interfaces
is another matter of future work.
References
1. K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, Pearson
Education, 2000. ISBN 201-61641-6.
2. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable
Object Oriented Software. Addison-Wesley, 1995.
3. A. Herranz, J. Moreno, and N. Maya. Declarative reflection and its application as a pattern
language. In M. Comini and M. Falaschi, editors, 11th. International Workshop on Func-
tional and Logic Programming (WFLP02), Grado, Italy, June 2002. University of Udine.
4. A. Herranz and J. J. Moreno. Generation of and debugging with logical pre and post condi-
tions. In M. Ducasse, editor, Workshop on Automated and Algorithmic Debugging 2000. TU
Munich, 2000.
5. A. Herranz and J. J. Moreno. On the role of functional-logic languages for the debugging of
imperative programs. In Workshop on Functional and Logic Programming 2000. Universi-
dad Politecnica de Valencia, 2000.
50
6. A. Herranz and J. J. Moreno. On the design of an object-oriented formal notation. In Fourth
Workshop on Rigorous Object Oriented Methods, ROOM 4. Kings College, London, March
2002.
7. A. Herranz and J. Moreno-Navarro. Formal extreme (and extremely formal) programming.
Fourth International Conference on eXtreme Programming and Agile Processes in Software
Engineering (XP03), May 2003.
8. C. B. Jones. Systematic Software Development Using VDM. Prentice Hall, 1986.
9. The SLAM website. http://lml.ls.fi.upm.es/slam.
10. J. B. Wordsworth. Software Development with Z. Addison-Wesley, 1992.
51
Diseo de una Metodologa gil de
Desarrollo de Software.
Schenone Marcelo Hernn.

mscheno@fi.uba.ar
Tesis de Grado en Ingeniera en Informtica.

Facultad de Ingeniera.
Universidad de Buenos Aires.
- 2004 -
Diseo de una Metodologa gil de Desarrollo de Software 1 Cuatrimestre 2004 FIUBA
Tema: Diseo de una Metodologa gil de Desarrollo de Software.
Alumno: Schenone Marcelo Hernn. Padrn: 75563.
Tutor: Villagra Sergio.
Fecha de Examen:
Informe Final Aprobado por:
Autor
Tutor
Marcelo Schenone Pgina 2 de 184

Abstract
Esta tesis tiene como propsito la construccin de una Metodologa gil de

Desarrollo de Software la cual utiliza UML como notacin. Si bien podr ser empleada
en proyectos de distinto tamao y complejidad, su aplicacin tendr como objetivo
proyectos de pequea escala y riesgo limitado. Tambin ser independiente del lenguaje
o la arquitectura utilizada, as como del tipo de software que se est construyendo.
Para desarrollar esta metodologa se comenzar por un relevamiento de las

metodologas y notaciones actualmente empleadas (Rational Unified Process, UML,
SCRUM, OPEN, Extreme Programming, etc), un posterior refinamiento de las mismas
y el desarrollo paulatino de un proceso que incorpore las mejores y ms avanzadas
prcticas existentes en cada etapa del desarrollo.
Finalmente, se describe la realizacin de dos casos prcticos resueltos con la

metodologa propuesta. El primer caso prctico estar basado en un sistema de
integracin de servicios para ONGs, y el segundo en un sistema de administracin de
recursos de hardware y software.

Tabla de Contenidos
Diseo de una Metodologa gil de Desarrollo de Software.____________________ 1

Abstract _________________________________________________________________ 3
Tabla de Contenidos____________________________________________________ 4
Tabla de Contenidos Detallada ___________________________________________ 5
Prefacio______________________________________________________________ 8
Captulo I - Introduccin _______________________________________________ 10
Captulo II - Descripcin del Problema____________________________________ 39
Captulo III - Solucin Propuesta ________________________________________ 53
Patrones de Desarrollo Recomendados _______________________________________ 93
Enfoque Sistmico _______________________________________________________ 118
Aportes de AgEnD al Espectro Metodolgico_________________________________ 134
Capitulo IV - Resultados Experimentales de las Prcticas de AgEnD __________ 137
Capitulo V - Conclusiones _____________________________________________ 166
Anexo A - Templates de Artefactos ______________________________________ 169
Anexo B - Tabla de Lenguajes de Programacin ___________________________ 170
Anexo C - Glosario ___________________________________________________ 175
Referencias Bibliogrficas _____________________________________________ 177
Links en Internet sobre Metodologas giles ______________________________ 184

Tabla de Contenidos Detallada

A. Diseo de una Metodologa gil de Desarrollo de Software
a. Abstract
B. Tabla de Contenidos
C. Tabla de Contenidos Detallada
D. Prefacio
a. Organizacin de la Tesis
b. Agradecimientos
E. Captulo I - Introduccin
a. Breve Introduccin a la Ingeniera de Software
b. Evolucin de los Modelos de Proceso de Desarrollo
i. Modelo en Cascada
ii. Modelo en Espiral
iii. Modelo Iterativo
iv. Modelo Incremental
v. Modelo Basado en Prototipos
c. Surgimiento de las Metodologas giles
i. XP
ii. Scrum
iii. Crystal Clear
iv. DSDM
v. FDD
vi. ASD
vii. XBreed
d. Estandarizacin de las Metodologas giles
i. Manifesto for Agile Software Development
F. Captulo II - Descripcin del Problema
a. Por qu elegir un proceso
b. Orientado al proceso vs. Orientado a las personas
c. Consideraciones Humanas
d. Orientado a los productos vs. Orientado a las tareas
e. Desarrollo Iterativo

G. Captulo III - Solucin Propuesta

a. Descripcin de Aspectos a Incluir en una Metodologa gil
i. Caractersticas de la Metodologa
ii. Roles
iii. Fases e Hitos
1. Concepcin
2. Elaboracin
3. Construccin
4. Transicin
iv. Disciplinas dentro de las Fases
1. Factibilidad
2. Requerimientos Anlisis
3. Diseo
4. Implementacin Testing
5. Despliegue
v. Disciplinas de Soporte
1. Administracin de Proyecto
2. Administracin de la Configuracin
3. Administracin del Proceso
4. Administracin de Personas
5. Administracin del Conocimiento
vi. Artefactos
1. Visin
2. Plan de Proyecto
3. Lista de Riesgos
4. Modelo de Casos de Uso y Especificaciones de Casos
de Uso
5. Documento de Especificacin de Requerimientos de
Software (SRS)
6. Descripcin de la Arquitectura
7. Casos de Prueba
8. Scripts de Despliegue
9. Planilla de Incidentes
10. Repositorio del Proyecto

11. Nota de Entrega

b. Patrones de Desarrollo Recomendados
i. Mxima Comunicacin
ii. Comunicacin Interna al Equipo
iii. Participacin Activa del Cliente
iv. Estimaciones giles
v. Enfoque en la Arquitectura
vi. Integracin Continua
vii. Peopleware
c. Enfoque Sistmico
i. Ambiente del Desarrollo de Software
ii. Implementacin del Proceso
1. Adaptacin Metodolgica
2. Adaptacin de las personas
a. La Organizacin
b. El rea de Desarrollo
c. El Individuo
d. Aportes de AgEnD al Espectro Metodolgico
H. Captulo IV - Resultados Experimentales
a. Overview
b. Experimentos de Prcticas recomendadas en AgEnD
i. Primer Ejemplo: Aplicacin en FIDoNET
ii. Segundo Ejemplo: Aplicacin en CONEST
I. Captulo V - Conclusiones
J. Anexo A Templates de Artefactos
K. Anexo B Tabla de Lenguajes de Programacin
L. Anexo C Glosario
M. Referencias Bibliogrficas
N. Links en Internet sobre Metodologas giles

Prefacio
Esta Tesis de Grado fue realizada durante el perodo que va desde Agosto de
2001 hasta Abril de 2004.
La eleccin del tema surgi a partir de la investigacin del autor en relacin a los
Modelos de Proceso de Desarrollo observados en diversas materias de la carrera. A
medida que comenzaba la exploracin lleg a su conocimiento la metodologa eXtreme
Programming (XP) desarrollada por Kent Beck a las cuales se incorporaron muchas
cuales que conformaran el universo de metodologas giles. Dado el nfasis de las
mismas en cuestiones de Peopleware, Dinmica de Equipos, Psicologa Social, Calidad
del Proceso, el tema fue elegido como base para la construccin de una metodologa que
analizara estos aspectos, basndose en las mejores practicas de la industria e
incorporando aspectos interdisciplinarios tomados de la Psicologa, Sociologa,
Relaciones de Trabajo y Administracin. La idea de la misma era que pudiera ser
utilizada dentro de la realidad de la informtica en nuestro pas. As nace la presente
tesis que describe en detalle AgEnD, la metodologa gil que es motivo del presente
trabajo.
A fines del 2000, manteniendo conversaciones con el docente Sergio Villagra

en ese momento jefe de trabajos prcticos de la ctedra de Proyectos Informticos I de
la FIUBA quien mostr gran inters en el tpico elegido, se plante el ofrecimiento de
ste de trabajar como Tutor de la Tesis. Mediante la formalizacin del trmite de inicio
de la Tesis, comenz el arduo desarrollo que finalizara en el ao 2004.
Organizacin de la Tesis
La Tesis est organizada de la siguiente forma.
Prefacio, contiene informacin relevante a los orgenes y el desarrollo

del trabajo
Introduccin, describe brevemente los temas a los que se har

referencia durante el trabajo
Descripcin del Problema, describe sintticamente la necesidad de

contar con un proceso de desarrollo y como las Metodologas giles

intentan resolver distintos problemas surgidos de la complejidad

inherente al software
Solucin Propuesta, describe detalladamente la Metodologa propuesta,

AgEnD, destacando los valores propuestos y analizndola en relacin
al universo de Metodologas giles
Resultados Experimentales, narra las experiencias realizadas con las

diversas prcticas propuestas en AgEnD, junto con los resultados
derivados de estas
Conclusiones, plantea las conclusiones obtenidas del desarrollo as

como futuras lneas de investigacin a seguir
Anexos, detallan temas que si bien no son centrales para la Tesis,

sirven para profundizar en aspectos mencionados en esta
Bibliografa, contiene la totalidad del material utilizado para

confeccionar el trabajo
Agradecimientos
Quisiera agradecer a las siguientes personas que han contribuido de una u otra
forma durante la elaboracin de la Tesis. Mis agradecimientos son para: Anbal Calligo,
Germn Boccoleri, Alejandro Oliveros, Elvio Nabot, Enrique Vetere, ngel Prez
Puletti, Adriana Yecha, Pablo Sametband, Adrin Lasso, Pablo Cosso. A mi Tutor,
Sergio Villagra.
Finalmente quisiera agradecer a mis padres, Olga y Jorge, quienes me ayudaron

incondicionalmente a que pudiera completar la misma. Asimismo hago extensivo el
agradecimiento a toda mi familia y dems personas que olvido en este momento
mencionar.

Captulo I - Introduccin
Propsito detrs de esta Tesis

Para empezar a hablar de Ingeniera de Software daremos una definicin
aceptada por la industria, esta ha sido tomada de la IEEE Computer Society:
(1) La aplicacin de un enfoque sistemtico, disciplinado y

cuantificable al desarrollo, operacin y mantenimiento del
software; esto es, la aplicacin de la ingeniera al software
(2) El estudio de los enfoques como en (1)
Como podemos observar esta definicin apunta a la profesionalizacin de la

disciplina de la informtica dentro del mbito de las dems ingenieras. Al respecto
debemos mencionar los constantes esfuerzos realizados por la comunidad informtica
para generar este cambio. El objetivo ulterior radica en que la disciplina pase de ser un
conjunto de buenas prcticas y folklore a un conjunto de patrones y estndares a ser
aplicados en cada situacin.
Sobre la naturaleza catica del software encontramos una importante referencia

en el artculo No Silver Bullet de Frederick Brooks [Brooks, 1987] en el cual se
analizaban las caractersticas intrnsecas del software. En el mismo, el autor tomaba la
realidad de la disciplina mencionando los grandes problemas que planteaba el desarrollo
de software. Las caractersticas esenciales descritas en dicho paper eran las siguientes:
Complejidad, las entidades de software son ms complejas por su tamao

que cualquier construccin humana
Conformidad, mucha de la complejidad deviene de la necesidad de

conformar con mltiples interfaces, heterogneas entre s ya que
involucran a distintas personas
Maleabilidad, las entidades de software estn sujetas a cambios

constantemente; dado que el software es materia puramente intelectual y
que su cambio es percibido como algo sencillo el mismo suele sufrir este
efecto

Invisibilidad, lo que genera dificultades en la comunicacin para el

modelado de los sistemas
Teniendo en cuenta la bibliografa de las dcadas pasadas se observa que si bien

se han desarrollado diversos enfoques para mitigar la complejidad inherente al software,
el mismo sigue presentando un gran desafo en su desarrollo. De ah la conclusin de
Brooks respecto a la construccin de software que citamos en forma verbatim.
No existe ningn desarrollo, ya sea en tecnologas como en

management, que por si solo prometa siquiera una mejora de un
orden de magnitud en la prxima dcada en lo referido a
productividad, confiabilidad, simplicidad.
Podemos decir que la prediccin de Brooks se mantiene hasta el da de hoy,

diecisiete aos despus del paper. Sin embargo podemos afirmar que se ha avanzado en
muchos frentes dentro de la informtica al punto que se est en camino de llegar a la
profesionalizacin de la disciplina.
Como en todas las dems ingenieras que han tenido un mayor tiempo de
maduracin surge la necesidad de la estandarizacin. Es decir, abandonar la aplicacin
de tcnicas y buenas prcticas en forma ad hoc a favor de un proceso disciplinado, que
est definido por normas, que resulte predecible y provea una adecuada visibilidad para
los stakeholders. Estas ideas son las que impulsan el desarrollo de esta tesis.
Historia de los procesos de desarrollo

Uno de los grandes pasos dados en la industria del software fue aquel en que se
plasm el denominado modelo en cascada. Dicho modelo sirvi como base para la
formulacin del anlisis estructurado, el cual fue uno de los precursores en este camino
hacia la aplicacin de prcticas estandarizadas dentro de la ingeniera de software.
Propuesto por Winston Royce en un controvertido paper llamado "Managing the
Development of Large Software Systems" [Royce, 1970] este modelo intentaba
proponer una analoga de lnea de ensamblaje de manufactura para el proceso de

desarrollo de software, queriendo forzar predictibilidad en una entidad como el software

que como fue mencionado es algo complejo y que esta ms relacionado con el
desarrollo de nuevos productos.
Se debe tener en cuenta el momento de la historia cuando aparece este modelo.

El mismo surge como respuesta al modelo codificar y probar que era el que
predominaba en la dcada de los 60. En esa poca ya existan modelos iterativos e
incrementales pero no eran disciplinados ni estaban formalizados. A consecuencia de
esta realidad, la idea de tener un modelo que ordenara el proceso de desarrollo y que
pareca bastante sencillo de llevar a la prctica y de comunicar hizo que el modelo en
cascada tuviera una gran promocin. Esto resulta irnico ya que como aos ms tarde
explic su hijo, Walker Royce, Winston Royce en realidad abocaba por los modelos
iterativos y solo propuso el modelo en cascada como la descripcin ms simple de un
proceso la cual solo servira para proyectos muy predecibles y sin grandes riesgos
[Larman, 2003].
Este modelo se basaba en el desarrollo de etapas las cuales tenan un input y un

output predefinido. El proceso era desarrollado en forma de cascada ya que se requera
la finalizacin de la etapa anterior para empezar la siguiente. Esto degeneraba en un
congelamiento temprano de los requerimientos, los cuales al presentar cambios
requeran gran esfuerzo en retrabajo. Otra opcin era no permitir cambio alguno a los
requerimientos una vez que se iniciara el desarrollo lo que traa aparejado que el usuario
no vea la aplicacin hasta que ya estaba construida y una vez que interactuaba no
cubra sus necesidades.
Asimismo, dadas las caractersticas inherentes del modelo, la fase de

implementacin del mismo requera el desarrollo de los mdulos en forma
independiente con las correspondientes pruebas unitarias, y en la siguiente fase, se
realizaba la integracin de los mismos. Esto traa aparejados grandes inconvenientes
debidos a que todo estaba probado en forma unitaria sin interaccin con los dems
mdulos. Las sorpresas llegaban cuando se integraban estas piezas para formar la
aplicacin; lo cual inevitablemente desembocaba en un retraso del proyecto,
sacrificando la calidad del mismo.
De esta forma y en forma bastante temprana en algunos casos, fueron surgiendo

diversos procesos denominados iterativos que proponan lidiar con la impredictibilidad

del software (subsanando muchas de las falencias del modelo en cascada) mitigando los
riesgos en forma temprana. Los procesos iterativos de los cuales se desprenderan
diversas instancias, como son el modelo iterativo e incremental, el modelo en espiral, el
modelo basado en prototipo, el modelo SLCD, el MBASE, el RUP, etc.
Bsicamente, la postura de estos modelos es la de basar el desarrollo en

iteraciones e ir construyendo la aplicacin en forma progresiva, agregando
funcionalidad sucesivamente. Las iteraciones representan un mini-proyecto auto-
contenido el cual est compuesto por todas las fases del desarrollo (requerimientos,
diseo, implementacin, testing). Los incrementos estn dados por la funcionalidad que
se va agregando al software en forma iterativa. Gracias a estas iteraciones se logra entre
otras cosas obtener el feedback necesario del cliente que era frenado en el modelo en
cascada una vez se finalizaba la fase de requerimientos. Consecuentemente podemos
argumentar que los modelos iterativos fomentan el cambio en forma temprana y
proponen un control de cambio disciplinado que permita que el usuario ajuste sobre el
desarrollo sus requerimientos. Esto se contrapone a la intolerancia del modelo en
cascada para lidiar con dichos cambios.
Del modelo en espiral desarrollado por [Boehm, 1988] surgi una de las ideas
fundamentales que las metodologas posteriores adoptaran: el temprano anlisis de
riesgos. Como muestra la Figura 001 este modelo de carcter iterativo en sus primeras
fases, plantea la necesidad de realizar al principio diversas iteraciones dirigidas a
mitigar los riesgos ms crticos relevados en el proyecto mediante la realizacin de
prototipos o simulaciones de tipo desechables tendientes a probar algn concepto. Una
vez que esos prototipos son validados se suceden iteraciones del tipo: determinar
objetivos, evaluar, desarrollar, planear. Mediante estas iteraciones se procuraba el
feedback del que se hablaba anteriormente, en forma temprana. Una vez que se tena el
diseo detallado y validado por el cliente, se implementaba el software siguiendo las
etapas de un modelo en cascada. Esta es una falla importante del modelo ya que no se
acomoda a la posibilidad de cambios una vez que se inicia la construccin. Todas las
crticas que se le hacan al modelo en cascada se aplican a estas fases del modelo en
espiral.

Figura 001. Descripcin de las iteraciones del Modelo en Espiral. Tomada de [Calligo, 2003]
Fue el mismo Barry Boehm, autor de este modelo, quien en su artculo [Boehm,
1995] describe tres hitos crticos a ser utilizados en cualquier proyecto de forma de
poder planificar y controlar el progreso del mismo, dando visibilidad a los stakeholders.
Estos hitos estn relacionados con las etapas de avance que se van dando a lo largo de
un proyecto de acuerdo al pasaje que ocurre de las actividades de ingeniera (que
componen los espirales del modelo en espiral) a las actividades de produccin (que
componen la construccin en cascada del software). Su impacto en la industria del
software ha sido tan importante que uno de los procesos mas utilizados en la actualidad,
el [RUP, 2002], los incorpora. Estos hitos son:
Objetivos del Ciclo de Vida
Arquitectura del Ciclo de Vida
Capacidad Operacional Inicial

El primer hito finaliza con la definicin del alcance del software a construir, la
identificacin de los stakeholders, y el delineamiento del plan de desarrollo del sistema.
El mismo ocurre al final de la fase de Concepcin segn el RUP.
El segundo hito finaliza con el delineamiento de la arquitectura del sistema, la

resolucin de todos los riesgos crticos del proyecto, y el refinamiento de los objetivos y
el alcance del sistema. A partir de este hito, se comienza la construccin en forma
masiva del sistema, llegndose a utilizar el mximo de recursos en el proyecto.
Asimismo, comienzan las fases ms predecibles en cierta medida del desarrollo. El
mismo corresponde al hito final de la fase de Elaboracin segn el RUP.
El ltimo de los hitos corresponde a la entrega del primer release del software,
que incorpora la funcionalidad definida en la correspondiente iteracin. Tambin se
espera el tener material de entrenamiento, como un Manual del Usuario y Manual de
Operaciones. Este hito se corresponde con el hito final de la fase de Construccin segn
el RUP.
Lo que result interesante de estos hitos propuestos por Boehm es que los
mismos son independientes del proceso de desarrollo elegido. Permiten una
estandarizacin de entregas a ser realizadas en un proyecto, la cual tiene ventajas para
ambas partes comprometidas. Para los clientes, los hitos otorgan visibilidad sobre el
proyecto pudiendo medir el progreso con artefactos que les son de utilidad. Para el
equipo de desarrollo, los hitos proveen una gua de las fases del proyecto orientada a los
entregables necesarios para cada hito as como la posibilidad de recibir feedback de los
clientes/usuarios sobre los productos que son entregados en el tiempo.
Como fue mencionado en los ltimos prrafos, uno de los procesos con ms
influencia en la comunidad del software ha sido el RUP. El mismo, derivado y refinado
por Rational a partir de la absorcin del Objectory de Jacobson tiene diferencias
radicales en comparacin con los procesos que lo han precedido. El RUP es uno de los
primeros procesos que es vendido como un producto1 y que es altamente customizable a
las circunstancias en que es adoptado. La idea de los creadores del RUP es que el
mismo fuera un repositorio de todas las ideas vigentes y las denominadas Best Practices
de la Ingeniera de Software. Dada la complejidad del mismo se presenta mediante los

denominados roadmaps que son simplemente formas de customizar el RUP para

resolver tipos de problemas especficos. Sin embargo, al intentar abarcar proyectos de
envergaduras tan dispares como podran ser la construccin de un sistema de radares
para portaviones versus la construccin de un registracin de usuarios para una pequea
consultora, el RUP pierde la granularidad necesaria para describir en detalle uno de los
factores ms trascendentes de cualquier desarrollo de software: las personas.
Esta es una de las razones principales del advenimiento de las denominadas

Metodologas giles.
Metodologas giles de Desarrollo

A principios de la dcada del 90, surgi un enfoque que fue bastante
revolucionario para su momento ya que iba en contra de la creencia de que mediante
procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la
requerida calidad. El enfoque fue planteado por primera vez por [Martin, 1991] y se dio
a conocer en la comunidad de ingeniera de software con el mismo nombre que su libro,
RAD o Rapid Application Development. RAD consista en un entorno de desarrollo
altamente productivo, en el que participaban grupos pequeos de programadores
utilizando herramientas que generaban cdigo en forma automtica tomando como
entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros
hitos en pos de la agilidad en los procesos de desarrollo como mencionaremos a
continuacin. Cabe mencionar que las metodologas giles no inventaron la nocin de
los procesos iterativos e incrementales, los cuales eran usados desde dcadas pasadas
inclusive en momentos en que el modelo en cascada era el estndar.
La historia de las Metodologas giles y su apreciacin como tales en la

comunidad de la ingeniera de software tiene sus inicios en la creacin de una de las
metodologas utilizada como arquetipo: XP - eXtreme Programming. XP surge de la
mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham, y utilizando
conceptos como el de Chief Programmer creado por IBM en la dcada de los 70.
Durante 1996 Beck es llamado por Chrysler como asesor del proyecto Chrysler
Comprehensive Compensation (C3) payroll system. Dada la pobre calidad del sistema
1
De hecho, Rational que fue adquirida por IBM en el ao 2003 vende el RUP junto con templates y documentacin anexa para uso
comercial a empresas.

que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero
utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, que
administra la liquidacin de aproximadamente 10.000 empleados, y consiste de 2.000
clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi respetando el
calendario propuesto [C3, 1998] [Williams, 2000]. Como consecuencia del xito de
dicho proyecto, Kent Beck dio origen a XP iniciando el movimiento de metodologas
giles al que se anexaran otras metodologas surgidas mucho antes que el propio Beck
fuera convocado por Chrysler.
Entre las metodologas giles ms destacadas hasta el momento podemos

nombrar:
XP Extreme Programming
Scrum
Crystal Clear
DSDM Dynamic Systems Developmemt Method
FDD Feature Driven Development
ASD Adaptive Software Development
XBreed
Extreme Modeling
A continuacin, daremos un breve resumen de dichas metodologas, su origen y

sus principios. La idea es poder observar las similitudes entre las mismas y aquellas
bases que unifican los criterios con los que fueron creadas y desembocaron en el
Manifiesto descrito posteriormente.
XP Extreme Programming
La primera metodologa ya ha sido comentada y es la que le dio conciencia al

movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha
conformado un extenso grupo de seguidores en todo el mundo, disparando una gran
cantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive
Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma
gente del proyecto C3 la que produjo tambin otro de los libros importantes de XP

[Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en prctica en un

proyecto.
La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un

tablero de control. Cada perilla representaba una prctica que de su experiencia saba
que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver
que ocurra. As fue como dio inicio a XP.
Los principios de XP citados verbatim de Beck:

El juego de PlaneamientoRpidamente determinar el alcance del prximo
release mediante la combinacin de prioridades del negocio y estimaciones tcnicas. A
medida que la realidad va cambiando el plan, actualizar el mismo.
Pequeos ReleasesPoner un sistema simple en produccin rpidamente,
luego liberar nuevas versiones en ciclos muy cortos.
MetforaGuiar todo el desarrollo con una historia simple y compartida de
cmo funciona todo el sistema.
Diseo SimpleEl sistema deber ser diseado tan simple como sea posible en
cada momento. Complejidad extra es removida apenas es descubierta.
TestingLos programadores continuamente escriben pruebas unitarias, las
cuales deben correr sin problemas para que el desarrollo contine. Los clientes escriben
pruebas demostrando que las funcionalidades estn terminadas.
RefactoringLos programadores reestructuran el sistema sin cambiar su
comportamiento para remover duplicacin, mejorar la comunicacin, simplificar, o
aadir flexibilidad.
Programacin de a ParesTodo el cdigo de produccin es escrito por dos
programadores en una mquina.
Propiedad Colectiva del CdigoCualquiera puede cambiar cdigo en
cualquier parte del sistema en cualquier momento.
Integracin ContinuaIntegrar y hacer builds del sistema varias veces por da,
cada vez que una tarea se completa.
Semana de 40-horasTrabajar no ms de 40 horas semanales como regla.
Nunca trabajar horas extras durante dos semanas consecutivas.
Cliente en el lugar de DesarrolloIncluir un cliente real en el equipo,
disponible de forma full-time para responder preguntas.

Estndares de CodificacinLos programadores escriben todo el cdigo de

acuerdo con reglas que enfatizan la comunicacin a travs del mismo.
Como se observan, muchas de las prcticas propuestas contribuyen a maximizar

la comunicacin entre las personas, permitiendo de esa forma una mayor transferencia
de conocimiento entre los desarrolladores y con el cliente, quien tambin es parte del
equipo. Esto es logrado en la prctica gracias a la disposicin fsica del lugar de trabajo.
La idea es reunir a todas las personas en una misma oficina manteniendo una
distribucin denominada cavernas y comn ver Figura 002. En la misma se
observan escritorios dispuestos en el centro con varias computadoras, cada una con dos
sillas dispuestas de forma de permitir la programacin de a pares. En las paredes se
observan pequeos boxes o escritorios con sillas, los cuales pueden ser usados por los
programadores en forma privada, para realizar llamados, consultar mail, o simplemente
descansar la mente. Consecuentemente se logra el objetivo mencionado al inicio del
prrafo de maximizar la comunicacin y la transferencia de informacin en el rea
comn, mientras que se mantiene la individualidad de las personas en las mencionadas
cavernas.
Figura 002. Disposicin fsica de las oficinas bajo la distribucin cavernas y comn. Tomada de [Cockburn, 2001a]
Asimismo, XP impone un alto nivel de disciplina entre los programadores. El

mismo permite mantener un mnimo nivel de documentacin, lo cual a su vez se traduce

en una gran velocidad en el desarrollo. Sin embargo, una desventaja que deviene de esta
falta de documentacin es la incapacidad de persistir la arquitectura y dems cuestiones
de anlisis, diseo e implementacin, an despus de que el proyecto haya concluido.
El nfasis que pone en XP en las personas se manifiesta en las diversas prcticas

que indican que se deben dar ms responsabilidades a los programadores para que
estimen su trabajo, puedan entender el diseo de todo el cdigo producido, y mantengan
una metfora mediante la cual se nombra las clases y mtodos de forma consistente. La
prctica denominada Semana de 40 horas indica la necesidad de mantener un horario
fijo, sin horas extras ya que esto conlleva al desgaste del equipo y a la posible desercin
de sus miembros. Beck afirma que como mximo se podra llegar a trabajar durante una
semana con horas extras, pero si pasando ese tiempo las cosas no han mejorado
entonces se deber hacer un anlisis de las estimaciones de cada iteracin para que estn
acordes a la capacidad de desarrollo del equipo.
Si bien XP es la metodologa gil de ms renombre en la actualidad, se

diferencia de las dems metodologas que forman este grupo en un aspecto en
particular: el alto nivel de disciplina de las personas que participan en el proyecto. XP
ser tratada en detalle ms adelante en relacin a algunas prcticas que comparte con
AgEnD.
Scrum
Scrum define un proceso emprico, iterativo e incremental de desarrollo que

intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos,
etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la
utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles
aceptables. El mismo surge de un artculo de 1986 de la Harvard Business Review
titulado The New New Product Development Game de Takeuchi y Nonaka, que
introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente
innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y
Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995.

Uno de los anlisis ms importantes de la metodologa desemboc en un libro

escrito por dos de sus creadores, Ken Schwaber y Mike Beedle [Schwaber, 2001]. Este
libro ser tomado para el anlisis de Scrum.
Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de

project management por sobre las dems disciplinas del desarrollo. Al principio del
proyecto se define el Product Backlog, que contiene todos los requerimientos
funcionales y no funcionales que deber satisfacer el sistema a construir. Los mismos
estarn especificados de acuerdo a las convenciones de la organizacin ya sea mediante:
features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product
Backlog ser definido durante reuniones de planeamiento con los stakeholders. A partir
de ah se definirn las iteraciones, conocidas como Sprint en la juerga de Scrum, en las
que se ir evolucionando la aplicacin evolutivamente. Cada Sprint tendr su propio
Sprint Backlog que ser un subconjunto del Product Backlog con los requerimientos a
ser construidos en el Sprint correspondiente. La duracin recomendada del Sprint es de
1 mes.
Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto)

llevar a cabo la gestin de la iteracin, convocando diariamente al Scrum Daily
Meeting que representa una reunin de avance diaria de no ms de 15 minutos con el
propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se
presentan. Al final de cada Sprint, se realizar un Sprint Review para evaluar los
artefactos construidos y comentar el planeamiento del prximo Sprint.
Como se puede observar en la Figura 003 la metodologa resulta sencilla

definiendo algunos roles y artefactos que contribuyen a tener un proceso que maximiza
el feedback para mitigar cualquier riesgo que pueda presentarse.

Roles Key Artifacts Key Meetings Development Process

Product Backlog Sprint Planning Meeting Product Increment
List of requirements & issues Hosted by ScrumMaster; 1 day Backlog
PO Owned by Product Owner In: Product Backlog, existing
Anybody can add to it product, business & technology
Product Owner: Only Product Owner prioritizes conditions
1. Select highest priority items in
Set priorities Product Backlog; declare Sprint Goal Sprint:
2. Turn selected items into Sprint 30 days each
Sprint Goal Sprint Planning Meeting
Backlog
One-sentence summary
Out:: Sprint Goal, Sprint Backlog
SM Declared by Product Owner Sprint
Accepted by team Goal
Daily Scrum
ScrumMaster: Hosted by ScrumMaster Sprint
Daily Scrum Backlog
Manage process, Sprint Backlog Attended by all, but Stakeholders
remove blocks List of tasks dont speak Blocks
Owned by team Same time every day Daily Work List
Only team modifies it Answer: 1) What did you do
yesterday? 2) What will you do Product
today? 3) Whats in your way?
T
ScrumMaster updates Sprint
Blocks List Backlog and Blocks List
List of blocks & unmade Increment
Team: Develop decisions
product Owned by ScrumMaster Sprint Review Meeting
Updated daily Hosted by ScrumMaster Sprint Review Meeting
Attended by all
Informal, 4-hour, informational
SH Team demos Increment
Increment Product
Version of the product All discuss
Hold retrospective Backlog
Stakeholders: Shippable functionality (tested,
documented, etc.) Announce next Sprint Planning
observe & advise Meeting
Figura 003. Descripcin de roles, artefactos, reuniones y proceso de desarrollo de Scrum. Cortesa de William C. Wake,
William.Wake@acm.org, www.xp123.com
La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo

pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est
extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo
combinado con otras como XP para completar sus carencias. Cabe mencionar que
Scrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo,
es habitual emplearlo como un framework gil de administracin de proyectos que
puede ser combinado con cualquiera de las metodologas mencionadas.
Crystal Clear
Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Las

mismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta
tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida
por XP. Crystal Clear es la encarnacin ms gil de la serie y de la que ms
documentacin se dispone. La misma se define con mucho nfasis en la comunicacin,

y de forma muy liviana en relacin a los entregables [Cockburn, 2001b]. Crystal maneja
iteraciones cortas con feedback frecuente por parte de los usuarios/clientes,
minimizando de esta forma la necesidad de productos intermedios. Otra de las
cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de
forma part time para realizar validaciones sobre la Interfase del Usuario y para
participar en la definicin de los requerimientos funcionales y no funcionales del
software.
Una cuestin interesante que surge del anlisis de la serie Crystal es el

pragmatismo con que se customiza el proceso. Las personas involucradas escogen
aquellos principios que les resultan efectivos y mediante la aplicacin de la metodologa
en diversos proyectos agregan o remueven principios en base al consenso grupal del
equipo de desarrollo.
Aunque al momento de preparar este trabajo an no se dispone de bibliografa

oficial de Crystal, Cockburn reporta su uso exitoso en diversos proyectos.
DSDM Dynamic Systems Development Method
DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio,

formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del
Consorcio era producir una metodologa de dominio pblico que fuera independiente de
las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid
Application Development). El Consorcio, tomando las best practices que se conocan en
la industria y la experiencia trada por sus fundadores, liber la primera versin de
DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la
industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores
de DSDM. Debido a este xito, el Consorcio comision al Presidente del Comit
Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de
implementar el mtodo. Dicho libro [Stapleton, 1997] es tomado como gua para el
anlisis posterior de DSDM.
Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa

encuadra perfectamente en el movimiento de metodologas giles. La estructura del
mtodo fue guiada por estos nueve principios:

1. El involucramiento del usuario es imperativo.
2. Los equipos de DSDM deben tener el poder de tomar decisiones.
3. El foco est puesto en la entrega frecuente de productos.
4. La conformidad con los propsitos del negocio es el criterio esencial

para la aceptacin de los entregables.
5. El desarrollo iterativo e incremental es necesario para converger hacia

una correcta solucin del negocio.
6. Todos los cambios durante el desarrollo son reversibles.
7. Los requerimientos estn especificados a un alto nivel.
8. El testing es integrado a travs del ciclo de vida.
9. Un enfoque colaborativo y cooperativo entre todos los interesados es

esencial.
DSDM define cinco fases en la construccin de un sistema ver Figura 004. Las
mismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional,
iteracin del diseo y construccin, implantacin. El estudio de factibilidad es una
pequea fase que propone DSDM para determinar si la metodologa se ajusta al
proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma
temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este
estudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivel
que deber contener el software. Posteriormente, se inician las iteraciones durante las
cuales: se bajar a detalle los features identificados anteriormente, se realizar el diseo
de los mismos, se construirn los componentes de software, y se implantar el sistema
en produccin previa aceptacin del cliente.

Figura 004. Fases del proceso de desarrollo DSDM. Tomada de [Highsmith, 2002].
Descontando la primera fase que es realizada una nica vez al principio del
proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo,
las dems fases presentan las caractersticas del modelo iterativo e incremental ya
tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principios
alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en
el feedback con el cliente, en las entregas frecuentes de productos.
Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr

responder las siguientes preguntas:
Ser la funcionalidad razonablemente visible en la interfase del usuario?
Se pueden identificar todas las clases de usuarios finales?
Es la aplicacin computacionalmente compleja?
Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en

componentes funcionales ms pequeos?
Est el proyecto realmente acotado en el tiempo?
Son los requerimientos flexibles y slo especificados a un alto nivel?

Las mismas refieren a las caractersticas que se deben cumplir en los proyectos
para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos
que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes
caractersticas que refieren a la aplicabilidad de DSDM:
Son proyectos interactivos con la funcionalidad visible en la interfase de

usuario
De baja o media complejidad computacional
Particionables en componentes de funcionalidad ms pequeos si la

aplicacin es de gran tamao
Acotados en el tiempo
Con flexibilidad en los requerimientos
Con un grupo de usuarios bien definidos y comprometidos al proyecto
De esta forma observamos que DSDM deja las bases sentadas para el anlisis
sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin
embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser
usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico
funciona tanto para el modelo de orientacin a objetos como para el modelo
estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de
modelos necesarios para la sana progresin de la entrega del software y facilidad en el
mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el
desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su
contenido.
El concepto de timebox es algo que est embebido en DSDM y en todas las

metodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo.
La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a los
stakeholders para que verifiquen el progreso y puedan tomar acciones correctivas a
tiempo. Tambin permiten controlar la calidad de los productos intermedios que se van
generando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox
esta compuesta por actividades definidas en relacin a entregables en vez de tareas.

Cada entregable generado durante el mismo es testeado/revisado dentro del mismo

timebox.
En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento

y Consolidacin. Durante la Investigacin se chequean que las actividades que
componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de
carcter exploratorio, en la que se fijan los objetivos de la iteracin, los entregables a ser
producidos, efectundose revisiones sobre las iteraciones anteriores a la actual. La
siguiente fase, Refinamiento, consiste en la produccin propiamente dicha de los
artefactos planificados. DSDM destaca la necesidad de colocar componentes de distinta
prioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones
aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos.
Finalmente, la fase de Consolidacin consiste en completar los entregables, verificando
la calidad de los mismos. En esta fase que posee el hito de finalizacin del timebox se
demostrar que se satisficieron los requerimientos de calidad definidos durante la
Investigacin.
DSDM incluye roles claves en relacin al management del proyecto. Identifica

al visionario como el encargado de asegurar que se satisfacen las necesidades del
negocio; el usuario embajador que equivaldra al on-site customer de XP, que brinda el
conocimiento del negocio y define los requerimientos del software; el coordinador
tcnico que es la persona encargada de mantener la arquitectura y verificar la
consistencia de los componentes construidos respecto a esta y al cumplimiento de los
estndares tcnicos.
Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar los
requerimientos del software y la realizacin de prototipos para descifrar aquellas
ambigedades que se presentan en el relevamiento y tambin para derribar las barreras
comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la
utilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacin
deseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cada
etapa: negocio, usabilidad, performance y capacidad, y diseo.
En resumen, encontramos en DSDM una metodologa gil creada en el Reino

Unido a partir de un consorcio con participacin de empresas de primera lnea. El
mismo contiene las caractersticas principales de las metodologas giles y contiene

prcticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su

aceptacin en la industria y su refinamiento continuo actualmente, se encuentra en su
versin 4.0 lo que indica que las metodologas giles no son solo dominio de
pequeos grupos de desarrollo sino que estn siendo adoptadas por pesos pesados en
las industrias.
FDD Feature Driven Development
Peter Coad es considerado uno de los referentes ms importantes dentro de la

ingeniera de software. Coad ha sido uno de los principales pioneros detrs del
movimiento de la orientacin a objetos y empez a trabajar con Ed Yourdon (uno de los
creadores del Anlisis Estructurado) a principios de los noventa, cuando este ltimo
pidi ayuda a alguien de la comunidad de objetos para desarrollar una nueva
metodologa, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De
Luca y otros, participara en la creacin de FDD, una metodologa desarrollada
alrededor del ao 1998 que presenta las caractersticas de un proceso gil [Coad, 1998].
La misma deriv del trabajo de Coad sobre las Feature Lists (Listas de
Funcionalidades).
FDD se estructura alrededor de la definicin de features que representan la

funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto
como para ser implementadas en un par de semanas. FDD posee tambin una jerarqua
de features, siendo el eslabn superior el de feature set que agrupa un conjunto de
features relacionadas con aspectos en comn del negocio. Por ltimo, establece el major
feature set como el ms alto nivel de agrupacin de funcionalidad que abarca diferentes
feature sets que contribuyen a proveer valor al cliente en relacin a un subdominio
dentro del dominio completo de la aplicacin. Una de las ventajas de centrarse en las
features del software es el poder formar un vocabulario comn que fomente que los
desarrolladores tengan un dilogo fluido con los clientes, desarrollando entre ambos un
modelo comn del negocio. Este tema ser tratado ms adelante en relacin al enfoque
de las metodologas giles en los productos entregados.
La jerarqua de los features utiliza los siguientes formatos:

Para features: <accin> el <resultado> <de | para | sobre | por>

un <objeto>
Para feature sets: <accin><-endo> un <objeto>
Para major feature sets: administracin de <accin>
Ejemplos:
Calcular el total de la facturacin de Noviembre (feature)
Modificar el estado de las facturas de produccin (feature)
Administrar el perfil de los proveedores (feature)
Haciendo una venta a un cliente (feature set)
Cargando la facturacin de los proveedores (feature set)
Administracin de Bancos (mayor feature set)
El ciclo de vida propuesto por FDD se puede observar en la Figura 005 y est
compuesto por cinco procesos, dos de las cuales se realizan tantas veces como
iteraciones se planifiquen en el desarrollo.
Figura 005. Los cinco procesos dentro de FDD. Tomada de [Coad, 2000].

La primera actividad consiste en Desarrollar un Modelo Global, que sugiere un

cierto paralelismo con la construccin de la arquitectura del software. En la creacin de
este modelo participan tanto los expertos en el dominio como los desarrolladores.
Mediante el esfuerzo de ambas partes se intenta lograr lo que el modelo en espiral
propona con sus primeras iteraciones: un conocimiento global de la aplicacin a
construir, el entendimiento del negocio en que esta embebida, un primer bosquejo de las
features del software, y la definicin de restricciones y cuestiones no funcionales. Para
esto, se desarrollarn: diagramas de los paquetes, con las clases esenciales y las
responsabilidades de las mismas; un documento similar al de Visin en donde se
plasmen los objetivos del proyecto y como el mismo ayuda al negocio; un documento
con los requerimientos no funcionales detectados; por ltimo, el documento que
podramos llamar arquitectura y en el que figuran las opciones de modelado surgidas
durante esta actividad.
La segunda actividad, Construir una Lista de Features, comienza tomando el

bosquejo de features formulado durante la actividad anterior para refinar las
funcionalidades incluidas. Una vez que se han identificado las mismas se las agrupa
jerrquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorizacin
de las mismas basndose en la satisfaccin al cliente las prioridades sugeridas para las
features por FDD son: A (debe tener), B (sera til tener), C (agregar si es posible), o D
(futuro); finalmente, se pondera la importancia de cada una para su posterior
implementacin en caso que existan features que requieran ms de dos semanas de
desarrollo en esta actividad se particionarn para lograr ubicarlos en iteraciones.
La tercera actividad, Planificar por Feature, toma como input la lista priorizada
de la fase anterior y establece los tiempos las futuras iteraciones. En esta actividad
participan el lder de proyecto, el lder de desarrollo y el programador jefe. A medida
que se realiza la planificacin se delinean los hitos de finalizacin de las iteraciones,
dejando asentado cuales son los features y features sets que estarn construidos en
dichos hitos. Parte de tambin incluye la delegacin de responsabilidades a los
programadores jefe que sern dueos de los features, estos a su vez asignarn las clases
a dueos de clases seleccionados del equipo.
Las ltimas dos actividades, Disear por Feature y Construir por Feature, estn
relacionadas con la parte productiva del proceso en que se construye la aplicacin de
manera incremental. Empezando por el diseo que toma los features correspondientes a

la iteracin, el equipo de programadores liderado por el programador jefe identifica las

clases, atributos y mtodos que realizan la funcionalidad requerida. Mediante la
utilizacin de diagramas de secuencia de UML, se verifica que el diseo pueda ser
implementado. Se realizar tambin una inspeccin del diseo en los casos en que la
complejidad de la funcionalidad lo requiera. Posteriormente, en la fase de Construir por
Feature, se procede a desarrollar las clases definidas en la actividad anterior. Cada
programador implementar los mtodos de las clases por las que este es responsable,
extendiendo las clases base de prueba para construir las pruebas unitarias. Una vez que
la clase pasa todas las pruebas, se inspecciona el cdigo. Esta actividad ser realizada
por el equipo asignado al feature en cuestin, y una vez que finaliza se promueve el
cdigo al Build correspondiente, siendo entregado a Administracin de la
Configuracin.
En relacin a las actividades de management en FDD se recomienda una reunin

semanal entre el Lder de proyecto y los programadores jefe; la misma debe ser breve,
de no ms de 30 minutos, y en la cual se reporta el status de los features que estn
siendo construidos por cada grupo. Por cada feature set que es implementado se tendr
la informacin como indica la Figura 006 para medir el avance del proyecto, dndole
visibilidad al management superior y al cliente.
Figura 006. Reportando el progreso al management y al cliente en FDD. Tomada de [Coad, 2000].
En conclusin, encontramos en FDD un proceso gil orientado a la

funcionalidad del software por sobre las tareas, sobre las cuales da guas mnimas. El

proceso sugiere organizar bloques de features a ser construidos en forma incremental

mediante iteraciones de dos semanas; provee estrategias de planeamiento para el lder
de proyecto; fomenta la colaboracin mediante la creacin de equipos dirigidos por un
programador jefe.
ASD Adaptive Software Development
Jim Highsmith en su libro [Highsmith, 1999] es la mente detrs de este proceso

gil. ASD consiste en un cambio de filosofa en las organizaciones pasando de la
transicin del modelo Comando-Control al modelo Liderazgo-Colaboracin. Basado en
los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia
Artificial, Highsmith lleva los mismos al campo de la Ingeniera de Software en
particular. Dada la complejidad inherente al software concluye que la aplicacin de esta
teora es esencial para el nuevo escenario que plantea la economa global.
Comenzando por un cambio en el modelo de desarrollo determinista, tomado del

ciclo de Deming, en que se aplica la secuencia Planificar-Ejecutar-Evaluar. Dicho
esquema es llevado a la prctica con el modelo en cascada, en que se realiza una precisa
planificacin inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar
en detalle, luego se tiene las fases de construccin, y finalmente, se tiene el testing que
brinda el feedback en relacin al producto construido.
ASD propone utilizar en cambio el ciclo de vida de la Figura 007, Especular-

Colaborar-Aprender. El proyecto comienza con una fase de especulacin en que en que
se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se
irn realizando. La utilizacin del verbo Especular demuestra el inters de Highsmith en
demostrar la naturaleza impredecible de los sistemas complejos. En esta etapa se fija un
rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que
no ser el lugar en que finalizar el proyecto. En cada iteracin, se aprendern nuevas
funcionalidades, se entendern viejas cuestiones, y cambiarn los requerimientos.
Gracias a centrarse en la especulacin, ASD permite administrar estos proyectos de alto
cambio y rpido desarrollo que se encuentran en el borde del caos. Respecto a la
especulacin, se recomienda realizar un component breakdown structure en vez del
muy conocido y tradicional work breakdown structure (WBS) en el cual mediante una
grilla u hoja de clculo se pueda conocer la funcionalidad a ser liberada en cada ciclo.

Sin embargo, no es ms que una especulacin ya que el carcter adaptativo del proceso
permite pequeas desviaciones en un sentido por lo que Highsmith sugiere que cada
ciclo se componga de un mix entre funcionalidades crticas, tiles, y opcionales,
previendo los posibles retrasos que puedan existir mediante el movimiento de las
funcionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro,
las cuales son utilizadas para la exploracin del dominio y de la aplicacin, que puede
llevar a cambiar el rumbo del proyecto estos desvos est representado por las flechas
de divergencia en la Figura 007.
Figura 007. El ciclo de vida adaptativo. Tomada de [Highsmith, 2000].
La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye

la funcionalidad definida durante la especulacin. ASD define un Componente como un
grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo.
Durante cada iteracin el equipo colabora intensamente para liberar la funcionalidad
planificada. Tambin, existe la posibilidad de explorar nuevas alternativas, realizar
pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto
profundamente. ASD no propone tcnicas ni prescribe tareas al momento de llevar a
cabo la construccin simplemente mencionando que todas las prcticas que sirvan para
reforzar la colaboracin sern preferidas, siguiendo de esta forma la lnea de las
metodologas giles respecto a la orientacin a componentes. El nfasis se ubica en la
relaciones entre las personas que deben estar lo suficientemente lubricadas para generar
una propiedad imprescindible de los organismos complejos: emergencia. La emergencia

es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad ms
grande del todo (comportamiento del sistema) a partir de la interaccin entre las partes
(comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los grupos
de desarrollo logran sacar lo mejor de si en la el borde del caos.
La fase final de ASD, Aprender, consiste en la revisin de calidad que se realiza

al final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender
[Highsmith, 2000]:
Calidad del resultado de la desde la perspectiva del cliente
Calidad del resultado de la desde la perspectiva tcnica
El funcionamiento del equipo de desarrollo y las prcticas que este utiliza
El status del proyecto
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar
grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la
aplicacin y se anotan los requerimientos de cambio del cliente.
Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre la

calidad de los mismos. En este caso, el nfasis estar puesto en aprender cuales han sido
los errores o desvos y poder resolverlos, y no en encontrar culpables. Asimismo, est es
la etapa en que se evaluarn las exploraciones que se hayan realizado dando la
capacidad de poder modificar la arquitectura del sistema si se ha encontrado algn
camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los
requerimientos.
El tercer proceso de feedback est relacionado con la interaccin entre las partes,
la dinmica de grupo, y las tcnicas empleadas. Para medir la performance y el grado de
cohesin del mismo, se podrn realizar al final de cada ciclo pequeas reuniones de
postmortem. En las mismas se discuten los aspectos del proceso que contribuyen al
desarrollo y aquellos que deben ser descartados por su influencia negativa.
En relacin al status del proyecto, se realizarn revisiones para determinar el

estado del mismo en relacin a lo planificado. En este momento, se detectarn posibles
diferencias que pueden surgir de la exploracin y que cambiarn el rumbo a que
apuntaba el proyecto.

En la Figura 008 se puede ver el detalle interno de cada fase como ya fue
explicado, mostrndose con una flecha que trasciende las tres fases en sentido inverso,
el bucle de aprendizaje. Este bucle es algo crtico para ASD ya que denota un cambio en
el esquema tradicional de la vista de un sistema en que se tena un bucle de control para
detectar diferencias y corregirlas. Es decir, en las metodologas tradicionales las
diferencias respecto a lo planificado eran vistas como errores que deban ser
enmendados para que cumplieran lo pautado. ASD y las metodologas giles plantean la
necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de
entender ms respecto al dominio y construir la aplicacin que mejor satisfaga las
necesidades del cliente. Highsmith lo expone claramente en la siguiente frase:
En ambientes complejos, el seguir un plan al pie de la letra
produce el producto que pretendamos, pero no el producto que
necesitamos.
Figura 008. Actividades del ciclo de vida adaptativo. Tomada de [Highsmith, 2000].
En conclusin, tenemos en ASD un marco filosfico basado en la teora de

Sistemas Adaptativos Complejos que nos permite encarar la construccin de software en
forma gil utilizando las prcticas que nos resulten convenientes en cada caso. En este
sentido resulta similar a Scrum.
XBreed Scrum wrapper for XP

XBreed ofrece una de las primeras fusiones exitosas entre metodologas giles.
Tomando las fuerzas en el management de Scrum y unindolas con las prcticas de XP
nace una de las ms modernas metodologas alrededor del 2000. Mike Beedle es la
mente detrs de XBreed y su objetivo es tomar las mejores prcticas del universo gil y
unificar estas en un marco de trabajo que permita el desarrollo concurrente de mltiples
proyectos usando metodologas giles.
Al momento de escritura de esta tesis, existe muy poca informacin de XBreed,

salvo el sitio web oficial del mismo.
Manifesto for Agile Software Development
El Manifiesto para el Desarrollo gil de Software es de suma importancia dentro

del movimiento de las metodologas giles. El mismo representa una iniciativa conjunta
entre los principales responsables de los procesos giles mencionados anteriormente
para lograr unificar principios compartidos por las diversas metodologas de manera de
crear un framework de trabajo que contribuya al mejoramiento del desarrollo gil.
Uno de los principales objetivos del encuentro en que se gener el Manifiesto

fue el de extraer un factor comn de los principios esenciales que serviran de gua para
cualquier metodologa que se identifique como gil. Esto concluy en la declaracin de
lo que podramos denominar el prlogo del Manifiesto [Manifesto, 2001]:
Estamos descubriendo mejores maneras de desarrollar software

mediante su construccin y ayudando a que otras personas lo
construyan.
A travs de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y personas
Software funcionando sobre documentacin comprensiva
Colaboracin del cliente sobre negociacin de contrato
Responder al cambio sobre seguir un plan

Esto es, mientras que existe valor en los tems de la derecha,

valoramos ms los tems de la izquierda.
Analizando los factores mencionados en detalle vemos que los mismos forman
parte esencial de las metodologas descriptas. En los mismos se plasman aquellas
razones que impulsaron a Beck, Highsmith, y otros, a construir metodologas giles. El
nfasis sobre las personas esta emblematizado en la primer oracin respecto a los
valores de las metodologas. El nfasis en el cdigo por sobre los documentos es una
propuesta eficaz para lograr el rpido feedback requerido por la agilidad. La
participacin del cliente es fundamental para el xito de los proyectos ya que ellos
definen la funcionalidad a construir y guan el desarrollo de las pruebas funcionales. La
importancia de responder al cambio indica que el desarrollo de software no es ms que
un proceso de aprendizaje en que cada cambio nos permite conocer ms en detalle el
dominio de la aplicacin.
El autor entiende que para que se pueda definir a AgEnD como una metodologa
gil, la misma deber estar completamente circunscripta a los valores detallados en el
Manifiesto. Es por esto que se harn continuas referencias al mismo para comentar la
conformidad del proceso a los principios y valores.
Con esto, damos por concluida la introduccin de este documento. A partir de

ahora, nos centraremos en la descripcin de AgEnD, su aplicabilidad en el desarrollo de
software, sus valores, principios, y toda la informacin necesaria para poder utilizarla en
la prctica; posteriormente, plantearemos un caso de estudio de AgEnD en donde se
pueda observar y analizar sus fuerzas y sus debilidades; finalmente, se llevaran a cabo
aquellas conclusiones relevantes al desarrollo de la AgEnD, analizndose las
limitaciones y alcances de la misma, previendo posibles lneas de trabajo que se puedan
desprender en relacin a las metodologas giles y el Manifiesto que las nuclea.
Presentacin de AgEnD

Como se ha mencionado en el Abstract, el propsito de esta tesis es construir

una metodologa que rena aquellas mejores prcticas del universo gil unindolas con
un framework que ayude a las organizaciones a implantar este tipo de metodologas.
El nombre de la metodologa es AgEnD que significa en ingls Agility Enhanced

Development (Desarrollo Mejorado Por Agilidad). En otras palabras, la idea es
configurar un proceso de desarrollo que resulte fcil de implementar y basar el mismo
en la aplicacin de prcticas giles para contribuir a la construccin del software,
lidiando con la impredictibilidad de la disciplina.
En esta tesis se comentar el porqu de la necesidad de un proceso, y de cmo

AgEnD llena ese hueco que surge al querer implementar una metodologa gil en una
organizacin.

Captulo II - Descripcin del Problema

A continuacin se describirn las razones por las cuales hoy en da se debe
contar con un proceso de desarrollo. Tambin se explicar como las metodologas giles
intentan resolver distintos problemas que se plantean en el desarrollo de software.

Por qu elegir un proceso

Cuando una empresa encara proyectos de desarrollo de software, que la
impulsa a seleccionar un proceso? No alcanza con dejar que el conocimiento y el
esfuerzo de los involucrados sea aplicado en forma uniforme, y simplemente que se
junten los frutos del trabajo de las personas al final del proyecto?
Estas simples preguntas no poseen una nica respuesta, pero s se puede

argumentar la siguiente afirmacin que indica las posibles opciones en relacin a la
eleccin de un proceso.
La eleccin respecto a la utilizacin o no de un proceso depende

principalmente del grado de predictibilidad que se desee tener en
el desarrollo.
Es decir, si una empresa est interesada en que cada proyecto sea como una
aventura, en que se desconozca el resultado y existan una gran cantidad de riesgos, no
necesitar proceso alguno. Simplemente dejar en manos de los profesionales de
sistemas el desarrollo de proyectos mediante las tcnicas que utilice cada individuo en
su trabajo. La aleatoriedad de cada proyecto ser una caracterstica inherente. Se
realizarn planificaciones a muy corto plazo, ya que no existe visibilidad para las
personas externas al equipo de desarrollo. En conclusin, estamos hablando de todas las
organizaciones que se encuentran en el nivel 1 del CMM, el denominado nivel Inicial.
Indudablemente, cualquier organizacin que se precie de ser tal jams elegira este
enfoque como primera instancia ya que uno de los objetivos de la misma sera
maximizar ganancias a largo plazo y para esto debera mantener procesos que aseguren
el xito en todos los sectores en que est compuesta. Sin embargo, como veremos ms
adelante la mayora de las empresas termina eligiendo esta opcin sin ser plenamente
conciente de la eleccin y de los resultados que esta acarrea.
Por otro lado, encontramos organizaciones que poseen manuales de

procedimientos para cada una de las tareas relacionadas con el desarrollo de software.
Cada actividad realizada por cada persona est descripta en detalle en forma escrita y en
cualquier momento esta documentacin podr ser consultada si tienen dudas respecto a
algn punto del proceso. En general, estas organizaciones poseen una estructura

tradicional de management en donde el modelo Comando-Control es utilizado en todos

los niveles jerrquicos. De caractersticas deterministas, relacionadas muchas veces con
la manufactura de productos de alguna clase, conducen el departamento de sistemas de
la misma forma en que conducen el departamento de finanzas, utilizando rgidos
procesos que generan hitos y entregas bien definidos. Bajo esta perspectiva es lgico
concluir que una organizacin que posee procedimientos predecibles en todas sus reas,
intente llevar los mismos al desarrollo de software. Sin embargo, como hemos notado
en la introduccin esto resulta una tarea imposible dadas las caractersticas esenciales
del software mencionadas por Brooks.
Analizando estos dos enfoques de desarrollo de software nos encontramos con

dos extremos bien definidos por [Highsmith, 1999] que son el de Burocracia,
representado por las organizaciones con procesos rgidos y definidos hasta el ms
mnimo nivel de detalles, y el de Adhocracia, que representa el desarrollo catico sin
ningn proceso ni visibilidad sobre el estado y el rumbo de los proyectos. En un
extremo, estamos en la claridad cegante de un proceso tan pautado que termina sin
satisfacer las necesidades de los usuarios, y en el otro estamos en la oscuridad completa
y aleatoriedad total que deviene del caos permitiendo nicamente beneficios o prdidas
a corto plazo.
Si trazramos una lnea uniendo la Burocracia con la Adhocracia podramos

utilizarla para ubicar el grado de formalidad dado por las metodologas que ya fueron
tratadas en la introduccin. Es decir, si tenemos una organizacin que se identifique con
uno de estos enfoques, cules seran las metodologas que elegira para el desarrollo de
software. En la Figura 009 observamos la disposicin que surge de colocar al Modelo
en Cascada, el RUP, las Metodologas giles, el Modelo en Espiral, el Modelo por
Prototipos, y el Modelo Iterativo en la recta correspondiente. En la misma observamos
que el Modelo en Cascada es el que ms contribuye a un rgimen burocrtico en el que
los proyectos son planificados en base a tareas a realizar por los recursos; fomenta el
orden de la organizacin mediante la clara divisin en etapas con sus inputs/outputs
correspondientes. Asimismo, encontramos otro de los procesos ms utilizados en la
actualidad como es el RUP, en una forma completa, construyendo todos los artefactos
especificados y realizando todas las actividades planteadas. En otras palabras, estos
procesos pretenden definir todas las actividades, roles, entregables, y dems aspectos
relacionados en un proyecto de software, para generar resultados predecibles a lo largo

del tiempo. Mediante la clara definicin de aquellas cuestiones involucradas y la

posibilidad de controlar el proceso para ajustarlo ante posibles desvos, se llega a la
Burocracia. El Modelo en cascada ejemplifica este enfoque al ser un modelo orientado
a documentos, en donde el progreso se mide en base a un conjunto de fases bien
definidas y al grado de avance de la documentacin correspondiente. Las personas son
partes reemplazables en este esquema, y como tales alcanza con definir los roles y las
actividades que estas realizan para completar el marco de desarrollo.
A medida nos alejamos de la Burocracia encontramos los Modelos con un

enfoque principal hacia los entregables y hacia el rpido feedback de los clientes. El
RUP Agilizado no es otra cosa que una versin del RUP customizada para grupos
pequeos y con feedback frecuente de los interesados.
RUP
Completo Codificar
RUP y Probar
Modelo en Agilizado
Cascada
RAD
Burocracia Metodologas Adhocracia

~ Orden Modelo en giles ~ Caos
Espiral
Modelo por
Prototipos
Figura 009. Ubicacin de las metodologas en relacin al nivel de formalidad requerido.
Como observamos, todas estas metodologas se encuentran hacia la izquierda del

punto medio entre Burocracia y Adhocracia. Si nos movemos desde ese punto hacia el
Caos nos encontramos con el tema central de esta tesis, las Metodologas giles, entre
las que encontramos todas aquellas descriptas en la Introduccin, incluidas AgEnD.
Estas metodologas reconocen las caractersticas inherentes de complejidad del
software, y el carcter emprico que debe tener un proceso de desarrollo del mismo. En

estas, las personas son de primera magnitud y se prefiere sacrificar el proceso en pos de
darles libertad a las personas. Sin embargo, esto no significa que se termina en un
proceso de Codificar y Probar, liderado por programadores rebeldes que se pasan el da
generando cdigo. Es por esto que el punto en que se ubican las mismas est bastante
alejado del Caos en que la aleatoriedad es la norma. Otra cuestin que diferencia estos
procesos de los anteriores es el cambio existente entre un proceso emprico y un proceso
determinista o definido. Como mencionbamos antes, los procesos ms burocrticos
tienden a tener definidos todos los aspectos del desarrollo. Esto se contradice con la
naturaleza compleja del software, para lo cual se adaptara con mayor eficiencia un
proceso emprico. Por esto nos referimos a un proceso en que se desconocen muchos
aspectos, se reconocen a las personas como componentes de primer orden totalmente
impredecibles, y simplemente se intenta guiar el desarrollo hacia un objetivo que puede
no permanecer constante en el tiempo a medida que aumenta el conocimiento de la
aplicacin a ser construida. En los procesos empricos se conocen las buenas prcticas
probadas con la experiencia, y los resultados u outputs que surgen generalmente de
tomar ciertos inputs o de realizar ciertas actividades. Estos modelos surgen de la
observacin y la experiencia obtenida a lo largo de los aos, sin basarse en leyes de la
naturaleza o principios tericos fundamentados. Es por esto que se los asocia a un
enfoque pragmtico para desarrollar software.
Siguiendo por la recta nos encontramos con el enfoque RAD propuesto por
[Martin, 1991] en el que se tena un lenguaje de alto nivel lo suficientemente poderoso
como para permitir generar cdigo de forma rpida, un pequeo equipo trabajando en
conjunto con buenos canales de comunicacin, y un plan de entregas de funcionalidad
en forma iterativa. El mismo no posea pautas claras en relacin a la calidad del
producto, la satisfaccin de los requerimientos de los usuarios, la clara definicin de la
arquitectura del sistema. Por estas causas termin siendo asociado con la generacin
rpida de aplicaciones con bajos niveles de calidad, y que resultaban en pesadillas de
mantenimiento. Sin embargo, debemos reconocer el aporte que hicieron a la ingeniera
de software ya que gracias a estas resurgieron las herramientas CASE y comenz el uso
masivo de lenguajes de alto nivel, sirviendo como base para el posterior advenimiento
de las metodologas giles.
Finalmente, nos encontramos justo en las cercanas del Caos, al modelo

Codificar y Probar. Esto modelo, catico por excelencia, se basa en el siguiente flujo de

actividades: un programador trabajando en su computadora, genera cdigo fuente; una

vez que termina, lo compila, corrige los errores y lo vuelve a compilar; cuando ya no
tiene ms errores, genera el ejecutable y lo corre; ah prueba el correcto funcionamiento
del mismo, debuggeando el cdigo al instante hasta corregir aquellos errores que
detecta; cuando este proceso iterativo finaliza, contina con el siguiente
componente/mdulo/programa. El mismo es totalmente impredecible y la visibilidad
para las personas involucradas en el mismo es inexistente. Es este modelo el que se trata
de evitar a toda costa al formular una metodologa, incluidas las metodologas giles.
Corolarios
Del anterior anlisis deberemos tener en cuenta ciertos aspectos inherentes a los
proyectos de desarrollo, que incidirn en forma directa en el grado de predictibilidad de
la metodologa. Es decir, que dadas ciertas variables deberemos movernos en uno u otro
sentido por la recta de la Figura 009.
Una variable muy importante a tener en cuenta es la cantidad de personas

involucradas. Es algo natural pensar que a medida que aumenta la cantidad de personas
asignadas a un proyecto deberemos contar con metodologas ms pesadas tendientes a
suplir la falta de canales anchos de comunicacin entre los integrantes del equipo de
desarrollo. Es por esto que la mayor parte de las metodologas giles dejan claro un
tamao mximo del equipo de desarrollo para utilizarlas exitosamente (en caso de tener
equipos de desarrollo ms grandes se recomienda particionarlos en equipos ms
pequeos). Alistair Cockburn [Cockburn, 2000] muestra este aspecto esencial a la hora
de elegir una metodologa mediante la Figura 010.

Figura 010. Relacin entre cantidad de personas, criticidad, y tamao de la metodologa. Tomada de [Cockburn, 2001a].
AgEnD en particular est enfocada a pequeos grupos de desarrollo, de no ms

de 15 personas involucradas en el proyecto, las cuales deben compartir un ambiente de
trabajo comn, con mnima separacin fsica. Cabe mencionar que en caso de contar
con una mayor cantidad de recursos se debern particionar en subgrupos del tamao
antes indicado, trabajando en forma paralela.
Otra variable a tener en cuenta, es el grado de criticidad de la aplicacin. A

medida que aumenta el perjuicio para el negocio ante una posible falla en el sistema, se
deber utilizar una metodologa ms pesada, con procesos de revisin bien pautados, de
forma de asegurarse la calidad del producto. No es lo mismo construir una aplicacin
empaquetada para bajar archivos de internet automticamente, que el software utilizado
en un equipo de resonancia magntica. En el primer caso, una prdida solo causa la
posible prdida de informacin para un usuario ocasional. En el segundo caso, una falla
podra resultar en anomalas en los resultados obtenidos con la posibilidad de realizar
diagnsticos errneos. Existe un riesgo de vida en relacin a esta aplicacin!
Aqu vemos la otra magnitud provista en la Figura 010 en la cual observamos

que a medida que aumenta la criticidad, desde la prdida de Comfort hasta la prdida de

Vida, debemos agregarle ms rigor a la metodologa para estar seguros de entregar un

software lo ms confiable posible.
Es as que se postula AgEnD como una metodologa para ser utilizada en

proyectos de caractersticas C3, C10, D3, que tienen como mximo 20 personas en el
equipo de desarrollo y que presentan un grado de criticidad bajo, de prdida de Comfort
o prdida Econmica Discrecional. Esta es la realidad de la mayora de las pequeas
consultoras de desarrollo localizadas en Buenos Aires, que trabajan para los sectores de
IS/IT.
Orientado al proceso vs. Orientado a las personas

Un par de dcadas atrs, en el campo de la Ingeniera de Software solo existan
los denominados procesos tradicionales. Comenzando por el modelo en cascada con su
divisin en etapas y roles bien definidos, continuando por el modelo en espiral, donde
se mitigaban los riesgos en forma temprana, todos estos procesos proponan un enfoque
secundario en relacin a las personas. Consideraban que teniendo un proceso
predecible, con etapas y tareas bien definidas, el xito estaba garantizado
independientemente de las personas que cubrieran los roles. Estos modelos de procesos
estn orientados al proceso en si, y suponen que al seguir los principios propuestos por
los mismos en cualquier organizacin y con cualquier equipo de desarrollo, se
obtendrn los resultados predichos en la teora. El resultado de aplicar un proceso de
calidad, ser la calidad en el producto.
Actualmente nos encontramos con esta visin orientada al proceso en muchas

organizaciones con altos niveles de burocracia y en organizaciones basadas en el
modelo Codificar y Probar. Es decir, en ningn momento existen consideraciones
respecto a como la productividad se ve afectada por la gente que trabaja y por las
condiciones laborales existentes. Existen referencias en mltiples libros respecto a como
el factor humano es fundamental al xito del proyecto [DeMarco, 1987][Weinberg,
1998][McConnell, 1996][McConnell, 2003][Glass, 2002]. Para evaluar la importancia
de este elemento podemos tomar uno de los frameworks de estimacin ms importantes
en la actualidad COCOMO II desarrollado por Barry Boehm entre otros [Boehm, 2000].

El mtodo en cuestin propone siete factores de personal que ajustan la estimacin de

un proyecto. Los mismos estn relacionados con:
Experiencia en aplicaciones
Factores comunicacionales
Experiencia en el lenguaje y las herramientas
Continuidad del personal
Experiencia en la plataforma
Capacidad de los programadores
Capacidad de los analistas
Es decir que dependiendo de factores exclusivamente humanos nuestro proyecto

puede variar en una relacin de hasta un 24,6 es decir un proyecto con todos los
factores humanos negativos puede llegar a tardar hasta 24,6 veces ms que un proyecto
con un equipo de desarrollo adecuado y sin deficiencias. De ah el nfasis de las
metodologas giles en este tipo de cuestiones.
Contando con la experiencia de Alistair Cockburn en estos temas recolectada a

lo largo de varios proyectos relevados en su mayora en IBM, el paper denominado
Characterizing People as Non-Linear, First-Order Components in Software
Development [Cockburn, 1999] demuestra que las personas son componentes de
primera magnitud en cualquier desarrollo. De esto surge uno de los principios
fundamentales de todas las metodologas giles que se ve plasmado en uno de los
primeros valores del [Manifesto, 2001]:
Individuos e Interacciones por sobre procesos y herramientas
El nfasis de todas las metodologas giles esta centrado en los individuos y sus
interacciones, a diferencia de las metodologas tradicionales en que impera el proceso y
las herramientas como propulsores de la calidad. AgEnD no es ninguna excepcin a
estos principios y propone destacar en cada una de sus prcticas que las personas son las

que indudablemente decidirn sobre la mejor forma de trabajo para ellas. Tambin de
las personas depender la adopcin de AgEnD o cualquier proceso de desarrollo gil. Es
por esto, que ms adelante se define un rol en particular, el Coordinador, que se encarga
de mantener las prcticas de AgEnD en armona, durante las primeras iteraciones en que
se utiliza el proceso.
Consideraciones Humanas
El hecho que AgEnD base sus principios en las personas no significa que se han
resuelto todos los problemas del desarrollo y que teniendo un buen equipo el xito est
garantizado. Todo lo contrario, el nfasis propuesto requiere tomar ciertas
consideraciones en relacin a la naturaleza de las personas que no son necesarias en las
metodologas tradicionales. Partimos de la base formulada por [Cockburn, 1999] que las
personas son organismos vivientes impredecibles, inconsistentes pero con buena
voluntad y un sentido de hacer las cosas bien. De esto concluimos que la Figura 010
extrada del [RUP, 2002]2 establece ciertas suposiciones que han sido esenciales en las
prcticas tradicionales de management basadas en la ideologa de Command and
Control.
Figura 011. Descripcin de un workflow dentro del RUP. Tomada de [RUP, 2002].
2
La seleccin de la figura del RUP y el comentario posterior no intenta realizar ninguna referencia a la naturaleza de dicho
framework.

Como se observa el Desarrollador del Curso, toma como inputs la

Especificacin de Requerimientos Suplementarios, la Gua de Estilo del Manual, el
Prototipo de la Interfase de Usuario y el Build correspondiente. Con esto realiza la
tarea Desarrollo de Materiales de Entrenamiento, y genera el output Materiales de
Entrenamiento. En el segundo caso, es el Escritor Tcnico el que toma los mismos
inputs, pero esta vez realiza la tares Desarrollo de Materiales de Soporte, generando el
output Material de Soporte para el Usuario Final.
Es en esta figura en que se puede analizar la ideologa de las metodologas

tradicionales. Uno parte de ciertos artefactos como entrada, define los roles
involucrados, define la tarea a ser realizada, y finalmente, se obtienen los artefactos
deseados. La definicin de las tareas es realizada en bastante detalle, y se suele utilizar
la tcnica del WBS para particionar un proyecto en las tareas que lo componen. Si bien
las metodologas giles parten de figuras similares, tienen en cuenta la naturaleza de las
personas y consecuentemente analizan formas en que las personas obtienen el mejor
output a partir de dichos inputs.
Uno de los elementos fundamentales asociados a las personas y las interacciones

es el Equipo de Desarrollo. Dado el incremento continuo en la complejidad del
software, no alcanza con esfuerzos individuales para tener xito. Se deben contar con
equipos productivos que pueden construir software en forma iterativa, en los que exista
un alto grado de comunicacin y donde cada integrante se sienta parte de una
comunidad de personas con un inters en comn: construir software de calidad. Estos
equipos de desarrollo debern cubrir dos aspectos que segn [Royce, 1998] definen la
excelencia de un equipo: balance y cobertura.
Orientado a los productos vs. Orientado a las tareas

Otro punto de inflexin que se gener con el movimiento de las metodologas
giles parte de la importancia de los denominados timeboxes o iteraciones. Los mismos
indican una clara tendencia a focalizarse en los productos a ser entregados en cada
iteracin, restando importancia a las tareas necesarias para obtener los correspondientes
entregables.

Realizando una analoga con el testing, se podra considerar que AgEnD aplica
lo que denominaremos desarrollo de caja negra mientras que las metodologas
tradicionales utilizan el desarrollo de caja blanca. El primero refiere a la nocin de
tomar ciertas entradas y verificar las correspondientes salidas. El segundo refiere a
tomar ciertas entradas, analizar el proceso interno y verificar las correspondientes
salidas. Las metodologas tradicionales al considerar a las personas como partes
reemplazables de un desarrollo, definen en detalle entradas, salidas y tareas necesarias
para llevar a cabo la correspondiente transformacin. Consecuentemente, estas
metodologas proponen que basta con tener una clara definicin de las tareas en un
proyecto para garantizar el xito del mismo. Un WBS nos provee la seguridad necesaria
para avanzar en las sucesivas etapas, en el cual describiremos que tareas son necesarias,
que necesita cada una para comenzar, y con que artefactos finalizan. Considerando a las
personas como componentes predecibles y reemplazables, engranajes de una
maquinaria, el desarrollo de caja blanca se convierte en la forma ms adecuada de
llevar un proyecto al xito en organizaciones orientadas al proceso. Ejemplos de esto se
observan en los proyectos de software encarados por el departamento de defensa y
aquellas grandes organizaciones en las que se tienen niveles de madurez certificados por
el CMM.
Una de las razones principales por la que las metodologas giles son Orientadas
a los Productos es el principio de Mxima Comunicacin descrito en ms detalle en
las Caractersticas de AgEnD. Dada la necesidad de tener un feedback continuo por
parte del cliente, el nfasis de cualquier iteracin esta puesto en los artefactos que esta
genera. Las actividades necesarias para la transformacin de entradas en salidas queda a
discrecin del equipo de desarrollo pudiendo utilizar las tcnicas provistas por AgEnD
que proporcionan agilidad al proceso. Para lograr que el desarrollo de caja negra tenga
xito deberemos tener un equipo integrado, balanceado y altamente motivado. De estos
tres factores, es la motivacin la que nos permitir lograr mejores resultados en la
adopcin de un proceso gil. Es la motivacin la que logra sacar lo mejor de un equipo
de desarrollo; la que nos permite saber que las personas involucradas utilizarn las
tcnicas que les sean ms efectivas para llegar al final de la iteracin con los artefactos
ms crticos construidos de acuerdo a las estimaciones. La motivacin es por lejos la
mayor contribuyente a la productividad [Boehm, 1981].

Desarrollo Iterativo
Dado el avance de la tecnologa, los tiempos en que se manejan los negocios han
ido reducindose abismalmente. Lo que una dcada atrs demoraba una semana de
procesamiento computacional, hoy se resuelve en cuestin de minutos. Los tiempos de
procesamiento han ido disminuyendo, mientras que los sistemas han ido creciendo en
complejidad teniendo cada vez necesidades mayores de distributibilidad, seguridad,
mantenibilidad, flexibilidad, etc.
En el panorama actual en que se encuentra la industria de IS/IT los sistemas

deben contar con atributos jams pensados en sistemas tiempo atrs. Palabras como:
multiprocesamiento, sistemas distribuidos, middleware, web services, modelo en tres
capas, tolerancia 24x7, multiplataforma, Virtual Machine, son requerimientos no
funcionales tpicos de sistemas de software/hardware en la actualidad. Los nuevos
clientes de los actuales sistemas esperan tener su sistema en el menor tiempo posible,
con la mxima calidad y conforme a los requerimientos no funcionales necesarios para
la operatoria diaria del negocio.
Una de las tareas ms complejas en el desarrollo de sistemas representa la

determinacin del alcance de lo que se va a construir. Es decir, qu es lo que recibir el
cliente en cada release del producto. Que funcionalidad estar incluida? Cmo
asegurarnos que es esa la funcionalidad que resuelve las necesidades del cliente?
Existen innumerable cantidad de ejemplos en la industria de sistemas de proyectos con
extensos perodos de relevamiento, que fueron seguidos por tambin extensos perodos
de oscurantismo durante los que el cliente no tena feedback alguno del desarrollo. En
general, el resultado de estos proyectos era el fracaso ya que la aplicacin no cumpla
con las necesidades del usuario. El sndrome del IKIWISI (Ill Know It When I See It)
entraba en juego, y al no tener feedback alguno del lado del cliente la construccin se
llevaba a cabo sobre las especificaciones definidas en forma temprana.
Si tomamos la teora existente detrs del Modelo en Cascada, la misma no haca

ms que reflejar las teoras encontradas en las otras ingenieras. En estas ltimas, los
proyectos comenzaban con fases de ingeniera en que se constataba la factibilidad de los
proyectos, se sentaban las bases para la produccin y se mitigaban los posibles riesgos
que podan ocurrir. Una vez que se tena una cierta masa crtica de conocimiento, se

realizaba una transicin a la fase de produccin. En la misma, se ejecutaban todas las

tareas analizadas y diseadas en las fases anteriores, las cuales eran de carcter
predecibles y contaban con mayor cantidad de RRHH de menor nivel de capacitacin, y
menores ingresos.
Dadas las caractersticas de dichas ingenieras (Civil, Industrial, Hidrulica,

Qumica, etc.) las mismas se prestaban a procesos de desarrollo de caractersticas
predecibles. Tenan un conjunto de requerimientos, los cuales se mantenan estticos
durante la ejecucin y no se modificaban en forma considerable hasta el ltimo da de
produccin. En estos principios se basa la industria manufacturera, en la cual una fase
de desarrollo inicial prescribe todas las actividades a realizarse en la ejecucin. La
predictiblidad es alta y la variabilidad es mnima.
Sin embargo esto mismo no aplica al dominio del software el cual tiene
correlatos ms fuertes con el desarrollo de nuevos productos. En la dcada del 70 ya se
proponan enfoques que mitigaban los problemas de intentar encajar el desarrollo de
software bajo un esquema de lnea de produccin. Los problemas con la integracin
realizada al final del proyecto fueron solventados mediante el desarrollo iterativo.
Mientras que la curva de costos del software demostraba que a medida que se
avanzaba en el desarrollo iban aumentando los costos de cambiar e incluir nuevas
funcionalidades en forma exponencial, fue solventado mediante el nfasis de las
metodologas del momento en la ingeniera de requerimientos, el anlisis funcional y el
diseo de componentes.
El nfasis de los mismos plantea la necesidad de una continua priorizacin de

funcionalidad a ser desarrollada en cada iteracin. El mantener fija una de las variables
del proyecto permite jugar con las dems variables en forma dinmica.

Captulo III - Solucin Propuesta

Se ha descrito en captulos anteriores en qu consiste un modelo de proceso de
desarrollo de software, cul es su propsito y las ventajas que trae aparejada la
definicin y utilizacin de uno dentro de una organizacin. Ms an, se ha realizado una
extensa investigacin en relacin a las metodologas giles ms destacables en la
actualidad presentando un resumen de cada una y analizando el contexto de aplicacin
en que son utilizadas.
En este captulo se ver en detalle cmo est estructurada AgEnD, la

metodologa gil que da una solucin al problema del desarrollo de software de alta
calidad. En particular la misma fue concebida con la idea de ser aplicada en pequeos
grupos de desarrollo, sin necesidad de invertir en costosas herramientas o de capacitar
en forma extensiva a las personas involucradas.
Por tratarse de una metodologa gil se intenta minimizar la burocracia que

subyace en la utilizacin de complejos procesos determinsticos que son utilizados en
proyectos con gran cantidad de recursos. Es por esto que se han anexado en este
captulo aquellos templates que pueden ser utilizados para que el equipo de desarrollo
estandarice los entregables que generar. Esto permitir que la transicin hacia la
metodologa sea lo menos dolorosa posible, logrando disminuir la curva de aprendizaje
inherente a un cambio de proceso.
Caractersticas de la Metodologa
Para dar una primera aproximacin a AgEnD nos basaremos en la propuesta de
Alistair Cockburn [Cockburn, 1998] que desglosa una metodologa en 10 elementos,
como mnimo, enumerados a continuacin:
1. Roles las descripciones a los trabajos que se solicitan en las bsquedas

laborales cuando se necesitan tomar gente; por ejemplo: moderador JAD, project
manager, arquitecto, escritor, tester.

2. Destrezas las destrezas que presupone poseen los recursos que llevan a cabo el
proyecto. Por ejemplo: social, proactivo, hbil en el manejo de herramientas,
3. Entregables lo que se quiere que cada persona o equipo entregue a otra

persona o equipo: casos de uso, especificaciones de diseo, documentacin de
framework, diagramas de secuencia.
4. Actividades las actividades e hitos de los diferentes equipos, como se integran

para producir los entregables finales.
5. Valores los valores del equipo y de la propia metodologa.
6. Equipos la forma en que se agrupan a las personas.
7. Asignacin de Tareas cmo son asignadas las tareas a los mltiples roles.
8. Tcnicas las tcnicas que se espera que las personas utilicen en su trabajo
diario. Por ejemplo: sesiones JAD, programacin en Java, modelado de
componentes.
9. Herramientas las herramientas que las personas usan a diario, ya sea dentro
de una tcnica o para producir un entregable de acuerdo al estndar.
10. Estndares lo que est o no permitido en el diseo y los entregables. Esto

incluye notacin, convenciones del proyecto y cuestiones de calidad.
En particular en este captulo nos referiremos a los primeros siete puntos de la

lista mencionada por tratarse de cuestiones estructurales que permiten describir el
conocimiento asociado con AgEnD. Respecto a los dems puntos podemos decir que:
AgEnD no prescribe tcnicas salvo en algunos casos en particular en que

son mencionadas en conjunto con las actividades correspondientes. Esto
est dado por la Orientacin a las Personas y a los Productos ya
descrita.
AgEnD no prescribe ningn tipo de herramienta para llevar a cabo las

actividades. Sin embargo, en algunos casos se mencionarn ciertas
herramientas de carcter Open Source pero meramente como
ejemplificacin, sin ninguna connotacin comercial asociada.

AgEnD no prescribe estndares de ningn tipo para los entregables. La

nica referencia a esto es el Anexo de Templates al final de la tesis, que
solo intenta ser una gua respecto a cmo se pueden construir ciertos
artefactos.
Roles definidos
Una de las razones principales de la adopcin de una metodologa para
desarrollo consiste en la definicin de las tareas que sern llevadas a cabo por los
individuos que participan del proyecto. Los roles definen ese conjunto cohesivo de
actividades realizadas y artefactos mantenidos que son llevados a cabo por personas o
por grupos de personas. No slo se refieren a personas internas al desarrollo del
software, sino que tambin involucran a los usuarios u otras personas que se vean
afectadas por el proyecto, cualquiera de los denominados stakeholders.
Los roles recin mencionados no son roles exclusivos asociados a una nica
persona, aunque en algunos casos pueden serlo (Patrocinante). Algunos roles podrn ser
abarcados por ms de una persona (Desarrollador). Asimismo, una persona podr cubrir
ms de un rol (Arquitecto/Escritor Tcnico).
Las asignaciones sern llevadas a cabo por el Lder, el cual en base a las
aptitudes de los recursos que dispone repartir las tareas a ser realizadas en cada
iteracin.
Como punto de partida en la definicin de roles dentro de AgEnD,

enumeraremos brevemente cada uno, con una descripcin concisa de las actividades que
abarcan:
Patrocinante (Executive Sponsor)
Actividades: tiene a su cargo el soporte gerencial del proyecto; es el

encargado de proveer, comunicar y mantener actualizada la Visin del
proyecto; provee el presupuesto para la viabilidad econmica del
desarrollo; es responsable por la consecucin del proyecto del lado del
cliente.

Importancia del rol: es esencial para el xito del mismo, ya que un

software que no tiene aceptacin dentro de la organizacin que lo
financia jams llegar a ser construido en tiempo, forma y con
consentimiento de los usuarios, no siendo utilizado eventualmente si se
concreta el proyecto.
Lder de Proyecto (Project Manager)
Actividades: tiene a su cargo la planificacin del proyecto, a lo largo de

todo el ciclo de vida, incluida la planificacin en detalle de cada
iteracin; asigna recursos y delega responsabilidades en los mismos;
fomenta la cohesin del grupo y lleva a cabo actividades destinadas a
eliminar fricciones; organiza las reuniones a ser realizadas; monitorea el
progreso del proyecto y establece estrategias para mitigar los riesgos que
se puedan presentar.
Importancia del rol: el Lder de Proyecto representa la cara visible del

equipo de desarrollo, es el nexo existente entre la gerencia y el equipo de
desarrollo como se observa en la Figura 012.
Experto en el Dominio (Domain Expert)
Actividades: tiene a su cargo brindar su conocimiento del negocio

contribuyendo al modelado del sistema que llevan a cabo los Analistas
durante la disciplina de Requerimientos-Anlisis; participar junto con
los Testers en la definicin del contenido de las pruebas funcionales a ser
realizadas; ser el responsable de la aprobacin de las pruebas de
aceptacin por cada release entregado.
Importancia del rol: el Experto en el Dominio permite al Equipo de

Desarrollo aprender sobre el negocio para el cual est siendo construida
la aplicacin; son encargados de resolver cualquier cuestin relacionada
con la funcionalidad de la aplicacin junto con los Analistas.

Destrezas: el Experto en el Dominio deber conocer en detalle el negocio

para prestar respuesta a cualquier duda que pueda surgir del mismo. En
general ser un miembro de la empresa Cliente.
Experto en
Patrocinante
el Dominio
Lder de
Proyecto
Equipo de
Desarrollo
Administrador
del
Conocimiento
Figura 012. Flujos de comunicacin durante el proyecto entre los roles propuestos.
Coordinador (Mentor)
Actividades: tiene a su cargo la supervisin del proceso, y cualquier

actividad orientada al mejoramiento del mismo. Durante las primeras
etapas de utilizacin de AgEnD supervisar la implementacin del
proceso.
Importancia del rol: en las metodologas giles este rol permite reforzar
la adherencia al proceso en aquellos momentos en que se el tiempo
apremia y se suele caer en el modelo Codificar y Probar.
Destrezas: el Experto en el Dominio deber conocer en detalle el negocio

para prestar respuesta a cualquier duda que pueda surgir del mismo.
Analista (Functional Analyst):

Actividades: tiene a su cargo el relevamiento, mediante el cual se

obtienen los requerimientos de la aplicacin a ser construidos en cada
iteracin; realiza la especificacin de los requerimientos; prepara el
documento de Visin.
Importancia del rol: el aprendizaje del dominio de la aplicacin y de los

requerimientos que deber tener la misma son claves para el xito del
proyecto y la aceptacin del mismo por parte del usuario.
Destrezas: el Analista deber tener amplio conocimiento de tcnicas de

relevamiento, as como aptitudes sociales que le permitan vencer el
Sndrome del Usuario y el Desarrollador [Leffingwell, 2001].
Arquitecto (Architect):
Actividades: tiene a su cargo la definicin de la arquitectura que guiar el

desarrollo, y de la continua refinacin de la misma en cada iteracin;
deber construir cualquier prototipo necesario para probar aspectos
riesgosos desde el punto de vista tcnico en el proyecto; definir los
lineamientos generales del diseo y la implementacin.
Importancia del rol: la arquitectura es imprescindible en los proyectos de

software actuales en donde cada vez existe mayor complejidad; el
arquitecto puede ser considerado como el Experto en la parte tcnica del
desarrollo y debe mantener a todo el equipo en conocimiento de los
lineamientos fundamentales de la construccin.
Destrezas: el Arquitecto deber tener una buena formacin tcnica,

contar con experiencia en las herramientas y tcnicas utilizadas; aptitudes
comunicacionales son deseadas para que la arquitectura sea comunicada
a todos los miembros del equipo; tambin deber ser perseverante en
conseguir los hitos tcnicos planteados mediante entregables para
asegurar el progreso de la construccin.
Programador o Desarrollador (Designer-Programmer):

Actividades: tiene a su cargo la codificacin de los componentes a

desarrollar en la iteracin; debe crear y ejecutar los tests unitarios
realizados sobre el cdigo desarrollado; es responsable de las clases que
ha desarrollado debiendo documentarlas, actualizarlas ante cambios y
mantenerlas bajo el control de configuracin de las mismas mediante la
herramienta de SCM utilizada.
Importancia del rol: el Programador es la persona que tiene los

materiales y lleva a cabo la implementacin de los casos de uso en el
lenguaje de programacin elegido; como en general, es el paradigma de
objetos3 el que est imponindose en la industria de IS/IT, el
Programador definir las clases y mtodos que realicen los
correspondientes casos de uso.
Destrezas: el Analista deber tener amplio conocimiento de las

herramientas de desarrollo, del lenguaje de programacin, de los aspectos
tcnicos involucrados.
Tester:
Actividades: tiene a su cargo la generacin de pruebas funcionales a

partir de los requerimientos extrados por los Analistas.
Importancia del rol: la importancia del Tester radica en la necesidad de

construir un software de calidad que cumpla con los requerimientos del
usuario; mediante la utilizacin de un proceso y el armado de un grupo
cohesivo de desarrollo, se tienen prcticas para garantizar la calidad en el
producto desde el punto de vista tcnico. Sin embargo, para asegurarnos
de que la aplicacin satisface las necesidades del usuario deberemos
realizar todo tipo de pruebas de carcter funcional. Es ah en que entra en
juego el Tester, quien crea, ejecuta, analiza y mantiene el conjunto de
pruebas automatizadas y manuales que son utilizados.
Destrezas: el Tester deber tener amplio conocimiento de tcnicas de

testing, deber conocer a fondo la aplicacin que testear. Asimismo,

deber tener conocimientos de programacin para trabajar con las

pruebas automatizadas.
Administrador del Conocimiento (Knowledge Manager):
Actividades: tiene a su cargo la captura, refinamiento, empaquetamiento,

y transferencia del conocimiento, ya sea tcito o explcito, en la
organizacin. En particular, AgEnD recomienda que este rol sea llevado
a cabo por una persona del equipo de desarrollo con dedicacin part-time
esto puede depender del tamao de la organizacin y de otros factores.
Importancia del rol: el Administrador del Conocimiento es uno de los

pilares sobre los que se establece AgEnD. Su importancia consiste en la
capacidad del equipo de desarrollo de aprender de la experiencia que ste
y que otros equipos dentro de la organizacin generan a diario durante el
transcurso de los proyectos. Mediante esta disciplina se logra el reuso de
dicho conocimiento. Este tema se trata con ms detalle en la seccin
Administracin del Conocimiento.
Destrezas: el Administrador del Conocimiento debe poseer aptitudes en

comunicacin para poder capturar el conocimiento de aquellas personas
que lo generan.
Aptitudes Requeridas
Uno de los principios esenciales que mencionamos al principio de esta tesis, era
el de Mxima Comunicacin. Este principio estableca la necesidad de un continuo
aprendizaje del equipo de trabajo, que deba ser transmitido en forma rpida a todos los
involucrados.
Ahora bien, algo que estaba implcito en la enunciacin del principio era el
hecho de disponer de recursos dispuestos y capacitados para aprender. No alcanza con
sentar a todas las personas en una misma habitacin para lograr la fluida comunicacin
3
Como se observa por estudios diversos de Gartner, Forrester, entre otros. Las dos plataformas que eventualmente comprendern el
mayor porcentaje de los futuros desarrollos, Java y .NET, estn construidos sobre lenguajes orientados a objetos los cuales basan su

tpica de los procesos giles. Tambin es necesario que esas personas estn dispuestas a
sacrificar su individualidad en pos de un grupo cohesivo de desarrollo. De esta forma,
se logra un entendimiento que abarca extensamente el alto grado de complejidad
inherente al software.
Suponiendo una situacin hipottica en la que una empresa ha conseguido un

proyecto a ser implementado utilizando AgEnD, y debe contratar a todos los recursos
para el mismo, mencionaremos qu aptitudes seran necesarias segn los roles
propuestos por la metodologa.
Patrocinante
En relacin al Patrocinante, deberemos requerir simplemente un total e

incondicional apoyo al proyecto, debiendo negociar siempre a favor de la construccin
del software y su implantacin en la empresa. En este sentido, no se agrega nada en
particular al conocimiento planteado por la bibliografa existente sobre Ingeniera de
Software.
Experto en el Negocio
El Experto en el Negocio debe ser una persona con amplio conocimiento del
dominio de la aplicacin que pueda concebir una visin lo suficientemente amplia del
producto a ser entregado para poder guiar el proceso de desarrollo. No ser necesario
que el experto en el dominio sepa en detalle toda posible operatoria del sistema; sin
embargo, deber contar con el suficiente conocimiento para poder resolver cualquier
duda o dificultad que tengan los miembros del equipo de desarrollo respecto a los
requerimientos. Tambin deber contar con la autoridad requerida para definir
prioridades respecto a los casos de uso a ser implementados en cada iteracin, pudiendo
agregar funcionalidad que no estaba contemplada o descartando funcionalidad que
perdi valor para el negocio.
Existir una estrecha relacin entre el Experto en el Negocio y los Analistas,

encargados de realizar los casos de uso. Durante las iteraciones del desarrollo, se
necesitar una total disponibilidad del Experto para la redaccin de los casos de uso as
como una frecuente predisposicin a contribuir en el desarrollo subsecuente.
comportamiento en clases, atributos y mtodos.

Ser necesario capacitar al Experto en la metodologa para que se pueda ajustar

mejor al ritmo del desarrollo y contribuya reforzar la cohesin del grupo de trabajo.
Para esto, ser necesario que no tenga problemas en relacionarse con las dems
personas involucradas.
Lder
En el caso del Lder, deberamos contratar a una persona que:
explote las aptitudes individuales de los integrantes del equipo, de forma

de sacar lo mejor del grupo
tenga muy en claro las caractersticas de los procesos iterativos
confe en el grupo de trabajo y delegue sin ningn tipo de temor
comprenda que se encuentra en un proceso de aprendizaje continuo, y

que los errores son parte del trabajo
trate de minimizar las fricciones existentes en el grupo
confe plenamente en la metodologa y no la deseche a la primer seal de

desviacin
no sufra de omnipotencia, tratando de regir estrictamente el trabajo de las

personas bajo su cargo
Teniendo en cuenta las estructuras organizacionales de las grandes empresas,

observaremos que el Lder requerido para los proyectos realizados utilizando AgEnD
corta con el estereotipo del tpico Lder de Proyecto. No slo estamos hablando de
cambios de actitud y comportamiento, se plantea un cambio de mentalidad radical que
consiste en dejar de lado el aspecto determinstico del software y convencerse de la
complejidad esencial que posee. Se debe pensar en el cambio como una fase ms del
software, la cual sobreviene en forma dispersa durante las iteraciones, y que nos sirve
para aprender ms sobre lo que estamos construyendo y para poder cubrir mejor las
necesidades de los usuarios.
Si bien estas caractersticas deben ser comprendidas por toda persona que
participe en el proceso, es esencial que sean asimiladas por el Lder ya que ste deber
encauzar nuevamente al equipo para que no ceda al caos total en el desarrollo.

Coordinador
El Coordinador es aquella persona que esta ntimamente ligada con el proceso,

que conoce todas las prcticas involucradas y entiende el porqu de los principios de la
misma. AgEnD propone que el nfasis debe centrarse en las personas en vez del
proceso, lo cual parecera contradecir la existencia del Coordinador. Pero esto no es as
ya que en caso que no exista un responsable del proceso, dada la naturaleza gil del
mismo, se puede terminar fcilmente en el modelo de codificar y probar.
Su tarea consiste en reforzar la conviccin de la necesidad de continuar con las

prcticas y principios de AgEnD aun en los momentos ms crticos del proyecto. El
equipo de desarrollo debe estar convencido plenamente de que las prcticas optimizan
el desarrollo, y no que resultan un obstculo del que deben deshacerse rpido. Es en
estos momentos en que se ve la importancia del Coordinador. Otra circunstancia en la
que resulta til su presencia, es ante la incorporacin de nuevos recursos, a los que el
Coordinador capacitar para que puedan ajustarse rpidamente sin que esto perjudique
el normal funcionamiento del grupo. Una vez que el grupo de trabajo se siente ya
cmodo con la metodologa, el Coordinador puede desaparecer como tal y ser
reemplazado por algn miembro del equipo.
Analista
El Analista cumple un rol similar a la figura de Analista Funcional con la que se

define este empleo en la industria del software. Es el encargado de realizar el
relevamiento, identificando previamente a los actores stakeholders que deber relevar
para entender el dominio del problema. En dicho relevamiento se incluir al Experto en
el Negocio, los Usuarios y dems stakeholders del proyecto, y posteriormente se
plasmarn los requerimientos funcionales y no funcionales en especificaciones de casos
de uso.
Una de las aptitudes necesarias del Analista es la de entender a los Usuarios, la

de ser una persona lo suficientemente humilde como para reconocer que no tiene
experiencia en el dominio y que debe pedir que se le explique cmo es la normal
operatoria del negocio para poder capturar su esencia. El Analista es una persona
versada en tpicos de Ingeniera de Software, con amplios conocimientos de tcnicas de
relevamiento, especificacin de requerimientos, y manejo de cambios, que posee
bastante conocimiento sobre el negocio en el que opera el Cliente, quien financia el

proyecto4. En respuesta a esto AgEnD mantiene con firmeza un principio que consiste
en uno de los pilares de las metodologas giles, el de Mxima Comunicacin.
Los requerimientos cambiarn antes, durante e inclusive una vez

finalizado el proyecto.
Esta es una dimensin caracterstica al software: a medida que se avanza en el

desarrollo, el Cliente va teniendo una nocin ms definida de qu es lo que quiere, lo
que produce un gradual cambio de visin que se traduce en una continua mutacin de
requerimientos. El Autor propone identificar esta situacin como el Sndrome de la
Meta Difusa (Fuzzy Goal Syndrome). Dado que la meta no es conocida de antemano,
no tiene sentido empear gran cantidad de recursos al principio del desarrollo en metas
difusas.
Esta aptitud se deber ver reflejada en el Analista, y en el mejoramiento

continuo de su entendimiento. El anlisis iterativo contribuir a que el producto
entregado satisfaga los requerimientos que tena el usuario hasta ese momento,
pudiendo incluirse cambios en sucesivos releases.
Arquitecto
El arquitecto es aquella persona encargada de dirigir y coordinar los aspectos

tcnicos del desarrollo, proveyendo de coherencia a los diversos artefactos generados en
relacin al anlisis, diseo, implementacin, testing y despliegue. Deber estar
comunicado con el resto del equipo para transferir los conceptos arquitectnicos ms
relevantes a aquellos que los necesiten, y al mismo tiempo para absorber los detalles
tcnicos que debern ser incluidos en la arquitectura. No ser necesario que conozca en
detalle cada componente construido, o documento generado, ya que para ello estn las
personas responsables de los mismos. Si deber mantener una visin general de las
partes tcnicas del desarrollo, permitiendo de esta forma ir ajustando la arquitectura
candidata de acuerdo a lo que la implementacin de los casos de uso revele.
Algunas aptitudes bsicas que se pediran son:
pleno conocimiento de las tecnologas disponibles
manejo de notaciones estndar (UML) para comunicacin entre las partes
4
Cabe mencionar que si esta condicin no se da, implicar un alto riesgo para el proyecto ya que la persona encargada de
especificar lo que el sistema debe realizar no conoce los procesos del negocio. Una forma de mitigar este riesgo es mediante la
realizacin de una disciplina de Modelado del Negocio [RUP, 2002].

buena capacidad de comunicacin con las personas del equipo
contar con experiencia en el dominio del problema
liderazgo para conducir a el o los equipos involucrados transmitiendo las

decisiones tcnicas tomadas, trabajando conjuntamente con el Lder
Programador
El Programador es aquella persona que tiene a su cargo la codificacin de los

componentes en cdigo fuente en algn lenguaje de alto nivel, y la correspondiente
prueba unitaria de los servicios que los mismos proveen. Para esto deber tener un
profundo conocimiento del lenguaje, las herramientas utilizadas en la construccin, los
estndares de codificacin, el framework de testing utilizado, patrones de diseo a
aplicar y nociones de refactoring.
El Programador es la persona encargada de la construccin del sistema

propiamente dicha. Deber ser capaz de estimar la duracin de las tareas que le son
asignadas, incluyendo el testing unitario de las clases que genera. Si bien al principio
pueden resultar imprecisas las estimaciones dentro de AgEnD, con el tiempo los
Programadores se acostumbrarn al ritmo gil que imprime el proceso pudiendo lograr
gran precisin en las mismas.
Tester
Dada la importancia del testing en el proceso como forma de asegurarse que la

calidad forme parte del producto, deberemos contar con una persona dedicada a
verificar los requerimientos del usuario mediante casos de prueba que debern ser
creados en forma paralela con el desarrollo.
Si bien una parte del testing de AgEnD ser realizada por los Programadores en
forma de pruebas unitarias sobre el cdigo construido, la porcin de testing ms
relevante para las partes involucradas se refiere a las pruebas funcionales. Y estas
debern ser construidas por el Tester que deber tener una estrecha comunicacin con el
Cliente ya que ser ste quien defina el contenido de las mismas.
Entre otras cosas el Tester deber contar con el suficiente conocimiento tcnico
como para poder entender la arquitectura del sistema, de forma de generar el cdigo
fuente de las pruebas funcionales necesarias para el sistema. Tomando como base los
casos de uso generados por los Analistas su funcin ser la de transformarlos en casos

de prueba. Estos casos de prueba estarn compuestos por dos componentes principales:
cdigo fuente y documentacin. Para el primer enfoque se llevarn a cabo programas
que verificarn la correcta realizacin de los casos de uso va la interaccin de las clases
que lo realizan. El segundo enfoque refiere a documentar procedimientos de prueba, que
consisten en instrucciones tcnicas necesarias para probar un componente.
Administrador del Conocimiento
El Administrador del Conocimiento deber tener conocimiento sobre las

distintas reas de la ingeniera de software de manera de poder empaquetar el
conocimiento en forma estructurada.
Este rol deber contar aptitudes de sntesis y claridad de en la especificacin de

la informacin consolidada. Tambin deber ser capaz de capturar el conocimiento
generado por el equipo durante el desarrollo sin influenciar negativamente en la
productividad de la gente.
Tcnicas
Las tcnicas propuestas por AgEnD son tcnicas que han sido adoptadas por la
industria para atacar la complejidad de las distintas fases del desarrollo. Las mismas
sern mencionadas brevemente; en caso que el lector desee profundizar en alguna podr
hacerlo a travs de la bibliografa propuesta al final de la tesis.
Dadas las caractersticas de los proyectos giles, definiremos las tcnicas que
ms se ajustan a esta filosofa y que colaboran al desarrollo de las tareas que son
encaradas en cada iteracin. Debido a esto, no se mencionarn en este resumen tcnicas
que si bien han sido probadas durante los aos son de dudosa trazabilidad en relacin a
las dems fases, o bien generan un overhead demasiado costoso para proyectos de estas
magnitudes.
Las tcnicas propuestas sern mencionadas en relacin a las fases en que se

divide AgEnD.
Fases e Hitos

Como cualquier metodologa AgEnD se compone de un conjunto de fases que

son realizadas a lo largo del tiempo, las mismas conforman un perodo de tiempo
encuadrado entre hitos significativos para el proyecto. Las mismas indican el nfasis ya
propuesto por Barry Boehm en relacin a la divisin en dos perspectivas de desarrollo.
La primera perspectiva ocurre en las primeras iteraciones del proyecto, cuando se
analiza la factibilidad de la ejecucin del mismo y se termina con la obtencin de la
arquitectura con los riesgos ms crticos mitigados. La segunda perspectiva ocurre en
fases iterativas de construccin en donde el nfasis esta en el cdigo fuente generado.
Esto significa que el grado de creatividad requerido en el proceso disminuye con el
tiempo, tornndose en un ciclo ms predecible. En relacin a la definicin de fases e
hitos de AgEnD se han tomado dos fuentes importantes [Boehm, 1995] y [RUP, 2002].
De acuerdo a la Figura 013, se observa la primera fase denominada Concepcin

que consiste en la definicin de los features que tendr la aplicacin, el alcance de la
misma, la identificacin de los stakeholders, la customizacin del proceso a ser usado y
llevar a cabo la planificacin general del proyecto. Esta fase provee la fundacin en que
todo el posterior trabajo es basado. Es crtico en esta fase llevar a cabo los primeros
relevamientos que se realizan con el Cliente de forma de adquirir conocimiento del
dominio y analizar si los costos del proyecto estarn justificados o bien conviene
comprar algn software empaquetado o cancelar la ejecucin. La fase de Concepcin
finaliza con un hito mayor denominado Objetivos del Ciclo de Vida en el que se
evala lo realizado contra las expectativas del Cliente y del Equipo de Desarrollo.

Kick-off
Concepcin
Elaboracin
Objetivos
Arquitectura
Iteracin
Iteracin con Release

Construccin
Transicin
Release
Figura 013. Fases que componen AgEnD.
La siguiente fase denominada Elaboracin, se refiere a la exploracin de los

requerimientos ms crticos (funcionales y no funcionales) que involucra el proyecto,
as como las decisiones tcnicas ms importantes que quedarn plasmadas en el
documento de Arquitectura. El objetivo principal consiste en asegurar la factibilidad
tcnica respecto a la realizacin del proyecto. Es a partir de la prxima fase cuando se
comienza con la construccin a gran escala del software, en donde se comprometen la
totalidad de los recursos necesarios para que el desarrollo se complete en las iteraciones
planificadas. Asimismo, se podrn incorporar recursos en forma limitada tratando de no
obstaculizar el normal transcurso del proyecto debido a la capacitacin que estos
ltimos requerirn. La fase de Elaboracin finaliza con un hito mayor denominado
Arquitectura del Ciclo de Vida en el que se evala lo realizado contra las expectativas
del Cliente y del Equipo de Desarrollo.
Una vez que pasamos a las etapas de produccin tenemos dos fases
concatenadas que se realizan en forma repetitiva por cada release de la aplicacin. Estas
fases son Construccin y Transicin. Durante la Construccin se terminan de
especificar los casos de uso correspondientes a la iteracin, se disean los mismos bajo

la arquitectura candidata presentada, y se codifican todos los componentes definidos por

los casos de uso, ejecutndose el testing correspondiente y la integracin. Cuando se
quiera pasar un cierto conjunto de componentes al entorno productivo se tendr una fase
de Transicin en la cual se llevarn a cabo las actividades de despliegue necesarias (ver
Figura 013 con Iteracin con Release). La fase de Transicin finaliza con un hito mayor
denominado Release del Producto en el que se evala lo realizado contra las
expectativas del Cliente y del Equipo de Desarrollo.
Cabe mencionar que dentro de las iteraciones de construccin se llevan a cabo

actividades relacionadas con Requerimientos, Diseo, Testing, etc., ya que se trata de
un proceso iterativo e incremental es que se va llevando a cabo tareas en paralelo y la
aplicacin va evolucionando hasta cumplir los casos de uso definidos.
Disciplinas dentro de las Fases

Para planificar un proyecto y permitir tener visibilidad sobre el progreso y el
grado de avance del mismo, AgEnD propone dividir el proceso en disciplinas que
conforman agrupaciones de actividades en las cuales se produce un conjunto particular
de artefactos. Las disciplinas cubiertas son las que se muestran en la Figura 014 y se
irn realizando dentro de cada fase con diversos grados de paralelismo entre ellas.

Kick-off
Factibilidad
Requerimientos
Anlisis
Iteracin
Iteracin con Release

Diseo Implementacin
Testing
Despliegue
Figura 014. Disciplinas que componen AgEnD.
Factibilidad
Durante la disciplina de Factibilidad se produce el primer contacto entre el

equipo de desarrollo y el cliente. Esta disciplina permite al equipo de desarrollo adquirir
todo el conocimiento posible acerca del dominio, las necesidades de los usuarios, los
objetivos y expectativas que debe cumplir el software que est siendo construido.
Mediante las actividades incluidas en esta disciplina, seremos capaces de responder las
siguientes preguntas: Es conveniente construir la aplicacin? Es conveniente para el
cliente el desarrollar un sistema con todas las complejidades inherentes para satisfacer
las necesidades del usuario? Cules son las posibles soluciones que se pueden
plantear?
A medida que se ejecuta esta disciplina, se va realizando el Modelado del

Dominio tendiente a entender las operaciones que forman parte del dominio del
problema, el dominio manejado por el cliente. En forma conjunta, los analistas
comenzarn a entender el problema planteado comenzando a bosquejar cules son los
features que tendr el sistema y el arquitecto comenzar a realizar modelos y diagramas

planteando una arquitectura preliminar que pueda servir de solucin al problema en

cuestin.
Durante esta disciplina el nfasis est puesto en la exploracin tanto del

problema como de la solucin. Es esencial el aprendizaje del dominio del cliente, de
cmo el sistema puede solucionar los problemas que se presentan, de cmo esta
solucin puede ser realizada con las herramientas disponibles, de las restricciones
impuestas sobre el sistema.
Como se observa en la Figura 015, el entendimiento del negocio permite al

equipo de desarrollo conocer explorar soluciones adecuadas a las necesidades de los
usuarios; este conocimiento puede ser plasmado en un documento de Modelo del
Dominio que debe ser construido conjuntamente con los usuarios y validados por estos.
Mientras se va desarrollando el Modelo del Dominio, se van explorando las

distintas posibilidades en relacin al dominio de la solucin. La solucin tcnica
propuesta deber ajustarse a los estndares que posea el cliente, y el equipo de
desarrollo deber asegurarse de la factibilidad de su implementacin. Para este punto se
puede tener un documento de Descripcin de Arquitectura que detalle las decisiones
tcnicas tomadas a lo largo de la Factibilidad.
Exploracin del Exploracin de la

Problema Solucin
Modelado del Arquitectura

Dominio Preliminar
Aceptacin
del Cliente
Ejecucin
Planificacin
de Iteraciones
Figura 015. Factibilidad en detalle.

Como se observa en el detalle, una vez que se finaliza la exploracin y se han

creado los documentos que comuniquen el resultado de la misma al cliente, se deber
tener concurrencia de este y de los dems stakeholders en relacin al compromiso para
que el proyecto sea continuado o cancelado. Es de gran importancia el contar con el
soporte ejecutivo necesario para proseguir esta disciplina, ya que segn lo reportado por
[Standish, 1994] la segunda razn por la cual un proyecto puede alcanzar el xito es
Soporte de la Gerencia Ejecutiva. El momento para garantizar este soporte es
posteriormente a la exploracin de los dominios ya mencionados, justo antes de la
planificacin de las iteraciones en que ser construido el sistema.
La Factibilidad finaliza con la planificacin del contenido funcional que ser

desarrollado en cada una de las iteraciones en que se construir la aplicacin. En dicho
plan, se determinarn cuales sern las iteraciones con release, las cuales servirn como
hitos del progreso del proyecto tanto para el cliente como para el equipo de desarrollo.
Dicha planificacin reviste un carcter preliminar ya que los requerimientos

pueden presentar cambios que alteren el contenido de las funcionalidades a ser
implementadas en cada iteracin. Est planificacin contendr los elementos ms
importantes y ser plasmada en un artefacto denominado Plan de Proyecto, el cual ser
mostrado en detalle en la seccin de entregables.
Requerimientos-Anlisis
Una vez completadas las actividades dentro de la disciplina de Factibilidad,

comienza el desarrollo netamente iterativo. Las iteraciones se suceden mediante la
realizacin de actividades relacionadas con las subsiguientes disciplinas. A
continuacin, explicaremos en detalle la primera disciplina con que comienzan las
iteraciones de AgEnD.
En la disciplina de Requerimientos-Anlisis se realizan actividades tendientes a

capturar las necesidades de los stakeholders, transformar las mismas en features de alto
nivel y especificarlas posteriormente en casos de uso. Como se observa en la Figura 016
se deber especificar el espectro funcional el cual servir para que los desarrolladores
diseen e implementen los casos de uso y tambin el espectro no funcional que

posteriormente utilizar el arquitecto para construir la arquitectura de la aplicacin y el

prototipo.
Espectro Espectro No
Funcional Funcional
Captura de Requerimientos
Requerimientos No Funcionales
Restricciones
Modelado de
Casos de Uso
Reglas del
Negocio
Diagramas de Documento de
Anlisis/Diseo Requerimientos
Suplementarios
Figura 016. Requerimientos-Anlisis en detalle.
Dadas las caractersticas de AgEnD tendientes a seguir un proceso gil que

puede administrar requerimientos altamente voltiles se sugiere utilizar el patrn
denominado Orientacin al Cliente, el cual consiste en maximizar la comunicacin
directa con las personas que terminarn utilizando el sistema para asegurarnos de estar
construyendo lo que estas necesitan. En otras palabras el proceso ser ms efectivo si se
tiene a un Cliente al menos trabajando como parte integral del equipo de desarrollo
[Beck, 2000]. Su principal funcin ser la de instruir y transferir su conocimiento al
resto del equipo a medida se transcurre el proyecto. Muchas veces esto resulta
imprctico en cuyo caso se deber asegurar el involucramiento de los usuarios y una
frecuente validacin por los mismos de los artefactos construidos en cada fase.
Para llevar a cabo esta transferencia de conocimiento desde los usuarios y

stakeholders que forman parte del proyecto a los analistas del equipo de desarrollo, se
utilizan diversas tcnicas las cuales han sido tratadas extensivamente en la bibliografa
del tema; se puede ver en [Leffingwell, 2001][Kulak, 2003] una descripcin de las ms
relevantes. De estas tcnicas que se observan, AgEnD recomienda utilizar aquellas que

no demanden gran cantidad de recursos o una significativa infraestructura. Una de las

tcnicas ms utilizadas en los procesos giles son las entrevistas, las cuales tendrn un
carcter ms informal ya que se podrn dar en cualquier momento que el analista deba
aclarar cuestiones respecto a los requerimientos, detallar aspectos de un caso de uso,
etc. En caso que se necesite hacer participar a un nmero importante de stakeholders en
el relevamiento, se recomiendan sesiones de brainstorming dirigidas por el Lder de
Proyecto a las cuales asisten los analistas documentando todo las decisiones tomadas.
Posteriormente a la Captura de Requerimientos se realiza la primera

aproximacin de los mismos en una forma estructurada que consiste en los casos de uso,
propuestos por Ivar Jacobson a principios de los 90. Los mismos se han transformado
en un estndar en la industria de la informtica y han trascendido ms all de la
comunidad de objetos de donde surgieron para ser utilizados ampliamente en proyectos
de todo tipo en el marco de IS/IT. La principal ventaja de los mismos es que son
escritos en el lenguaje del cliente y no demandan tener conocimientos tcnicos para ser
entendidos. Son esenciales en los procesos giles en que se intenta que exista
comunicacin constante y fluida entre los miembros del equipo y el Cliente.
Para escribir los casos de uso se recomienda utilizar un formato predefinido

como el que se encuentra en el Anexo a esta tesis. Esto permitir que los analistas del
equipo de desarrollo sincronicen el nivel de ambigedad de la narracin, los atributos a
ser escritos y las convenciones que se utilizarn. Ms material respecto al nivel de
detalle con el que se puede realizar un caso de uso y todo aquello relacionado con su
construccin ha sido estudiado por [Cockburn, 2000a].
Diseo
La disciplina de Diseo consiste en plasmar el problema planteado (que se halla

en forma de casos de uso o requerimientos contenidos implcitamente por Analistas o
Clientes) en el dominio de la solucin. Asimismo, tambin se realiza la definicin de la
arquitectura siendo validada mediante algn prototipo (conocidos como Proof Of
Concept).

Espectro Espectro No
Funcional Funcional
Modelo de Casos Documento de

de Uso Requerimientos
Suplementarios
Definicin de la
Arquitectura
Diseo Casos de Prototipo Proof Of

Uso Concept
Figura 017. Diseo en detalle.
Durante las primeras iteraciones cabe destacar la necesidad de disear la

infraestructura sobre la cual ser construido el software. Para esto el arquitecto tomar
del conjunto de casos de uso relevados hasta el momento aquellos que considere ms
importantes desde un punto de vista tcnico y tambin analizar los requerimientos
suplementarios que debern ser satisfechos por la arquitectura propuesta. Con esto
construir un modelo de arquitectura documentado que especificar los elementos a
partir del cual ser construido el sistema, las interacciones entre dichos elementos, los
patrones que se usaron para su composicin, y las restricciones sobre dichos patrones.
Finalmente, para probar la factibilidad de la arquitectura el Arquitecto construir un
prototipo ejecutable utilizado para verificar la conformancia a los requerimientos de la
aplicacin.
Dentro de AgEnD, el Diseo es realizado tomando como input los casos de uso
escritos en la disciplina anterior y detallando los mismos en un esquema de clases,
atributos y mtodos del lenguaje elegido. Los miembros del equipo adaptan su modelo
mental para cerrar la brecha que existe del dominio del problema, el qu, al dominio de
la solucin, el cmo. Este proceso es plasmado mediante la generacin de Diagramas de
Secuencia para aquellas interacciones significativas desde un punto de vista tcnico las
cuales podrn ser anexadas al Documento de Arquitectura. El nivel de ceremonia estar
acorde a la criticidad del sistema que se desarrolla. En casos minimalistas y donde se
desee tener un mnimo overhead metodolgico el diseo podr ser realizado en papel o

en un pizarrn, en casos de mayor ceremonia se utilizarn herramientas de modelado

visual que ayuden en este proceso.
Una funcin esencial es la de asignacin de funcionalidad en que el Lder de

Proyecto o el Arquitecto se encargarn de nombrar a un responsable por cada unidad de
funcionalidad especificada. Puede tratarse de un caso de uso, de un grupo de clases, de
un paquete. Lo importante es que exista un responsable para cada artefacto que
mantenga actualizada la trazabilidad requerida por AgEnD pudiendo realizar cualquier
tipo de modificacin sobre el mismo y manteniendo un adecuado control de cambios.
Una vez finalizado el proceso de diseo detallado de las clases a ser construidas
durante la iteracin, se procede a la siguiente disciplina que es la de Implementacin-
Testing.
Implementacin - Testing
En la disciplina de Implementacin-Testing se lleva a cabo la produccin del

software. El equipo de desarrollo se encarga de implementar la funcionalidad
especificada en los casos de uso mediante el lenguaje de programacin elegido.
Dado el nfasis que AgEnD propone en reducir la brecha comunicacional entre

las personas que forman el equipo, esto mismo repercute en la preferencia de elegir para
proyectos de esta envergadura aquellos lenguajes de programacin que minimicen la
brecha entre la realidad y la realizacin de la misma en un lenguaje. Idealmente, AgEnD
fomenta el uso de frameworks o tecnologas bajo el paradigma de orientacin a objetos,
como Java, MS. NET o Smalltalk, los cuales permiten el mximo de eficiencia por lnea
de cdigo para aplicaciones de IS/IT. Segn se observa en la Tabla de Lenguajes de
Programacin incluida dentro de la seccin de Anexos de esta tesis y relevada por
[Jones, 1997], los lenguajes de este tipo permiten una menor cantidad de lneas de
cdigo por puntos de funcin, maximizando as la productividad del desarrollador.
En paralelo a la construccin de los componentes se realiza la revisin de los

mismos mediante el testing, el cual tiene una gran relevancia en AgEnD. Siendo est
una de las maneras en que se llevan a cabo los mecanismos de SQC (Software Quality

Control), la metodologa define diversas pruebas que podrn ser realizadas en las
iteraciones. Las mismas incluyen:
Pruebas Unitarias:
Definicin: las Pruebas Unitarias son pruebas realizadas a nivel de las

clases y mtodos construidos para la aplicacin. Estas pruebas son
implementadas por los mismos programadores en el lenguaje de
programacin utilizando clases de prueba encargadas de verificar el
comportamiento correcto de los mtodos en una clase. Para ello es
conveniente contar con algn framework de testing unitario que le
facilite al equipo de desarrollo la creacin, mantenimiento y ejecucin de
una suite de pruebas automatizadas. Ejemplos de esto pueden leerse en
[Beck, 2002][Crispin, 2002][JUnit, 2001].
Alcance: las mismas son utilizadas para controlar la calidad del cdigo
construido y son ideales para testing de integracin y de regresin.
Pruebas Funcionales:
Definicin: las Pruebas Funcionales verifican el flujo de interaccin de la

funcionalidad definida en los casos de uso. Esta funcionalidad que est
escrita en forma narrativa en los casos de uso y es plasmada mediante la
interaccin de objetos envindose mensajes entre s en los diagramas de
secuencia debe ser especificada en pruebas automatizadas que sern
creadas por el Usuario en conjuncin con la ayuda tcnica del Tester y
sern ejecutadas por el Tester durante cada iteracin. Cabe remarcar que
debe ser el Usuario el que define el contenido de las mismas ya que de
esta forma proveen el feedback que permite al equipo de desarrollo
continuar las iteraciones asegurndose de la calidad del producto
construido.
Alcance: las mismas son utilizadas durante todo el desarrollo y su

alcance est definido por el conjunto completo de requerimientos
funcionales definidos en los casos de uso.

Pruebas de Aceptacin:
Definicin: el objetivo de las Pruebas de Aceptacin es la verificacin

que el software construido en las iteraciones cumple con las
funcionalidades solicitadas por el usuario y est listo para ser utilizado en
el ambiente del Cliente. Estas pruebas revisten gran relevancia porque
implican que el Cliente da conformidad respecto al sistema desarrollado
y lo acepta
Alcance: las mismas son realizadas durante las Iteraciones con Release
en las que se lleva a cabo la transicin de la aplicacin al ambiente de
produccin en el Cliente.
Despliegue
La disciplina de Despliegue permite que el sistema construido sea transferido al

ambiente de produccin para ser utilizado por el usuario. Esto no significa que el
software debe estar implementado en su totalidad, cubriendo el 100% de los aspectos
funcionales y no funcionales sino que en una iteracin determinada se desee liberar una
versin con un porcentaje de los casos de uso implementados. Dado el esquema de
desarrollo iterativo e incremental, durante las iteraciones ya mencionadas se va
agregando funcionalidad y se hace crecer al sistema hasta que cumpla con los
requerimientos que se especificaron al principio, sumados a los cambios surgidos a lo
largo del desarrollo.
Durante esta disciplina, se deben realizar actividades tendientes a hacer una

entrega completa con una funcionalidad previamente determinada la cual ser
desplegada en produccin. Las actividades incluidas dentro de esta disciplina son:
Generar Manuales del Usuario, de Operacin, etc.
Realizar un empaquetamiento de componentes junto con scripts de

instalacin que el Cliente utilice para instalar la aplicacin en su entorno.
Ejecutar el conjunto completo de pruebas funcionales creadas durante el

desarrollo, hasta obtener la aceptacin del Cliente.

En caso de ser necesario, definir las actividades de migracin al nuevo

sistema.
Capacitar a los Usuarios que utilizarn el nuevo sistema.
Generar la Nota de Entrega con la totalidad de los artefactos que se le

entregan al Cliente (con su correspondiente versionado) al final de la
disciplina.
El Lder de Proyecto deber encargarse de lograr el consenso de todos los

involucrados en una fecha de entrega del sistema. Para esto coordinar las fechas de
forma que el Cliente tenga la oportunidad de verificar el correcto funcionamiento del
sistema, mediante las pruebas de aceptacin que se han generado hasta el momento. Es
conveniente, que se planifique una reunin formal entre las dos partes (Cliente y Equipo
de Desarrollo) para que todos estn en conocimiento de los resultados obtenidos, se
puedan realizar comentarios respecto a las cuestiones que se deberan mejorar en el
proceso para las siguientes iteraciones. En otras palabras, esta reunin servira como
una revisin Post-Mortem en la que se evaluaran todas las iteraciones de desarrollo que
precedieron a la actual, y cules fueron las actividades que funcionaron exitosamente y
cules fueron las dificultades encontradas en el camino.
Iteracin Iteracin Iteracin Iteracin

1 2 3 N
Reuniones de
Entrega de
Versin
Figura 018. Esquema cronolgico de reuniones de entrega de una versin del sistema.

Como se observa en la Figura 018, las Reuniones de Entrega de Versin se

realizan al final de cada iteracin de release. En este caso, la Iteracin 2 va a ser la
primera entrega de funcionalidad en el proyecto. Toda la funcionalidad desarrollada a lo
largo de las dos primeras iteraciones ser liberada al Cliente al fin de la Iteracin 2. Por
ello, se planifica la Reunin de Entrega de Versin al final de la misma. Este caso es
equivalente a lo que ocurre en la Iteracin N.
Disciplinas de Soporte
Las disciplinas de soporte ocurren a lo largo de todo el ciclo de vida del proyecto
y dan soporte a las actividades relacionadas con la construccin del software. Las
mismas son tan importantes como las disciplinas ya mencionadas pero la diferencia es
que sirven propsitos organizacionales no directamente relacionados con la produccin
de sistemas. Entre estas nuevas disciplinas mencionaremos cuatro como muestra la
Figura 019.
Iteracin Iteracin Iteracin Iteracin

1 2 3 N
Administracin de Proyectos
Administracin de la Configuracin
Administracin del Proceso
Administracin de Personas
Administracin del Conocimiento
Figura 019. Disciplinas de Soporte de AgEnD.
Administracin de Proyecto

La disciplina de Administracin de Proyecto engloba todas las actividades

relacionadas con la gestin del emprendimiento. Dentro de AgEnD esto refiere a las
tareas que el Lder de Proyecto lleva a cabo para garantizar un ambiente saludable de
trabajo, una medicin del grado de avance del proyecto, un continuo monitoreo y
mitigacin de riesgos. Estas actividades permiten que el proyecto llegue a su xito,
entregando la aplicacin en tiempo, forma y dentro de los costos presupuestados.
Dentro de AgEnD el rol del Lder de Proyecto es bastante distinto a las

metodologas tradicionales basadas en la idea del control jerrquico. Bajo este
paradigma el Lder era quien reparta el trabajo a las personas y quien estimaba el
tiempo que llevaran todas las actividades mediante la realizacin de un WBS detallado
y continuamente monitoreaba el trabajo en relacin a sus estimaciones para aplicar
correcciones. Bajo AgEnD el Lder no es ms que la persona que habilita al equipo de
desarrollo para que pueda trabajar cmodamente, sin obstculos, resolviendo las
necesidades que esta tenga. Tiene el carcter y las responsabilidades de un facilitador.
Asimismo, es la cara visible del equipo hacia los stakeholders del proyecto salvando
los stakeholders claves que mencionaremos posteriormente. Deber reportar y conocer
el status del grupo y cmo el desarrollo se va dando en relacin a la planificacin
establecida.
AgEnD recomienda que se establezca una planificacin inicial del proyecto que
permita tener objetivos claros respecto a los grandes hitos para obtener feedback del
cliente respecto al avance realizado. Se armar un plan de proyecto con las fases y las
iteraciones durante las que se ir construyendo el sistema. Dadas las caractersticas de
este proceso gil, no se debera realizar un plan ultra detallado con un WBS que
presente todas las tareas a realizarse. Simplemente, se fraccionar la funcionalidad
relevada hasta el momento en iteraciones en las cuales se irn liberando versiones al
cliente para obtener el tan valioso feedback (ver en esta tesis la seccin de Estimaciones
giles y la de Orientado a los Productos vs. Orientado a las Tareas).
Es importante destacar que el plan es armado consultando al equipo de

desarrollo; la nica tarea del Lder de Proyecto es armarlo en algn formato presentable
al cliente, como por ejemplo un diagrama Gantt o una planilla Excel, dependiendo del
nivel de formalidad requerido. El equipo de desarrollo ser el que estimar la duracin
de las tareas a este nivel, entendiendo que la estimacin ser de una precisin muy

limitada, ya que no se cuenta con mucha informacin de la funcionalidad a desarrollar.

En cada iteracin el plan ser actualizado para reflejar la realidad.
Una de las prcticas importantes es la de llevar a cabo una reunin diaria de no

ms de 15 minutos emulando a la Scrum Daily Meeting recomendada por Scrum. La
misma refuerza el patrn de Mxima Comunicacin (ver ms adelante en esta tesis) que
describe la necesidad de que el flujo de interaccin sea frecuente; en este caso para que
el Lder de Proyecto pueda medir el avance realizado diariamente, resolviendo cualquier
problemtica del equipo que este a su alcance y eliminando obstculos. El cliente podr
participar de la misma pero sin poder esgrimir comentarios, slo como un oyente
pasivo.
La disciplina de Administracin de la Configuracin contiene las actividades

relacionadas con la administracin del repositorio que almacena los tems de
configuracin generados en un proyecto. Esta es un rea de conocimiento dentro de la
Ingeniera de Software en la que mayores avances se han realizado y que ha estado
presente en los proyectos de software desde aproximadamente 1980. Actualmente la
mayor parte de los desarrollos incluyen alguna herramienta de manejo de SCM que
automatiza todas las operaciones sobre el versionado.
AgEnD recomienda colocar todos los artefactos generados o consumidos en un

proyecto bajo control de configuracin. Esto permitir que en cualquier momento se
pueda recuperar una versin determinada de un tem o tems de configuracin para
recrear la cronologa del proyecto o volver cambios atrs, o llevar a cabos registros de
trazabilidad y/o auditorias entre otras cosas.
En particular, el uso de una herramienta de SCM le da la posibilidad al equipo

de desarrollo de tener prcticas eficientes al momento de realizar las actividades en un
proyecto. Entre estas prcticas cotidianas presentadas en cualquier desarrollo podemos
mencionar:
Los desarrolladores pueden trabajar en un mismo proyecto, compartiendo

todos los tems de configuracin.

Los desarrolladores pueden compartir el esfuerzo en el desarrollo de

cualquier artefacto, sea una clase, un documento, etc.
Los desarrolladores pueden acceder la versin estable actual del sistema

para verificar si el cdigo que generaron seguir funcionando cuando sea
integrado.
Los desarrolladores pueden volver a una versin anterior del sistema para
hacer pruebas contra esta.
Los desarrolladores pueden trabajar en distintas ramas en paralelo sobre

los artefactos del sistema, permitiendo tener una rama estable, otra para
experimentar, y as sucesivamente.
Es importante que las herramientas sean usadas consistentemente y que todo el

equipo tenga el conocimiento para trabajar con ellas. Esto podr requerir capacitacin a
las personas que lo utilizarn.
Dentro del marco gil de AgEnD la prctica utilizada dentro de esta disciplina
deriva de una prctica propuesta por XP denominada Collective Code Ownership. Est
prctica recomienda que no existan dueos de los tems de configuracin subidos al
repositorio sino que cada persona podr interactuar con cualquier tem, pudiendo
modificarlo y subir una nueva versin. En cierto sentido el equipo de desarrollo es
responsable por todo el sistema por lo tanto todos los miembros de este son dueos de
todos los tems. Esto es posible gracias a la fluida comunicacin existente entre las
personas que fomenta AgEnD y al grado de responsabilidad que tienen las personas.
Dentro de esta disciplina incluiremos aquellas actividades relacionadas con la

Administracin de Cambio. Es decir, un proceso formal que nos permita controlar la
forma en que los cambios son implementados durante el desarrollo. Dadas las
caractersticas de AgEnD, los cambios son tomados como una posibilidad de tener un
mejor entendimiento de la aplicacin a construir por lo cual sern priorizados por el
Cliente de acuerdo a su valor del negocio e implementados segn corresponda en una
iteracin determinada. Dependiendo del costo asociado a los mismos el Cliente puede
decidir descartarlos. Es de suma utilidad disponer de una herramienta que automatice el

seguimiento de los cambios a lo largo de su ciclo de vida, notificando al equipo de

desarrollo de los cambios de estado de cada uno a lo largo del proyecto.
Administracin del Proceso
La disciplina de Administracin del Proceso permite que AgEnD sea adaptado a

las necesidades de las personas y del proyecto en cuestin. Se decidi incluirla como
una disciplina separada5 dado que reviste gran importancia dentro de un proceso gil; en
la seccin titulada Enfoque Sistmico de esta tesis se procede a un anlisis sobre los
cambios inherentes a una implementacin metodolgica.
Una vez que la organizacin ya posee una metodologa como AgEnD

estandarizada en sus proyectos y conocida por todas las personas, la misma deber ser
adaptada de acuerdo al contexto de cada proyecto en que se utiliza. Es decir, habr
distintos proyectos con caractersticas dispares en cuanto a tamao del equipo, grado de
criticidad del sistema, stakeholders involucrados. Todos estos factores darn como
resultado una necesidad metodolgica nica, con ciertos roles, ciertos artefactos, ciertas
actividades, etc. Consecuentemente AgEnD dispone de una disciplina que permite
adaptarla a las necesidades de la instancia de proceso en que se est.
Ser clave en esta disciplina la figura del Coordinador quien empezar con un
anlisis del proyecto, tomando la planificacin original, la funcionalidad, el equipo de
trabajo, el perfil del cliente, y con todo esto definir como se emplear AgEnD en dicho
proyecto. El Coordinador deber tener un amplio conocimiento del espectro
metodolgico existente para poder extraer aquellos elementos de AgEnD que considere
que no apliquen y para poder agregar elementos que no estn contemplados y que
formen parte de otros procesos. En este sentido se puede recomendar una profunda
capacitacin en el RUP que muchas veces cumple la funcin de un metaproceso
sirviendo como base de conocimiento para los ingenieros de software. Tambin
conviene estar informado sobre las novedades de la Alianza gil
(http://www.agilealliance.com) que est compuesta por los principales creadores de
metodologas giles mencionadas en la introduccin de esta tesis.
5
El Proceso Unificado de Rational [RUP, 2002] incluye a las actividades de customizacin de proceso dentro de la disciplina de
Ambiente en la que tambin aparecen todas las consideraciones humanas. En AgEnD decidimos dividirla en dos partes:
Administracin de Proceso y Administracin de Personas.

Cabe remarcar que la tarea de adaptacin del proceso es llevada a cabo por el
Coordinador en cooperacin con el equipo de desarrollo. Esto resulta muy relevante ya
que ser este ultimo el usuario final de la metodologa por lo cual el Coordinador
consultar con los miembros ms especializados para entender los mecanismos de
desarrollo involucrados.
Una vez que la metodologa haya sido configurada para un proyecto, se harn
reuniones espordicas (una buena prctica consiste en coordinarlas con el fin de cada
iteracin) en las que se evaluar la adecuacin de AgEnD a las caractersticas del
proyecto. Se analizarn los resultados positivos y negativos, pudiendo el Coordinador
hacer cambios sobre la marcha para mejorar la forma de trabajo.
Finalmente, cuando el proyecto est llegando a su fin, el Coordinador, con la

ayuda del Administrador de Conocimiento, almacenar la informacin acerca de cmo
el proceso fue usado, con el propsito de mantener un historial de adaptaciones
realizadas por tipo de proyecto.
La ltima de las disciplinas recomendadas por AgEnD es la de Administracin

de Personas que agrupa todas aquellas actividades relacionadas con los aspectos
humanos del desarrollo. Nuevamente la figura clave de esta disciplina ser el
Coordinador, con una importante cooperacin del Lder de Proyecto.
Una de las primeras actividades dentro de esta disciplina es la de nivelar a los

miembros del equipo de desarrollo. Es importante que cada uno tenga todos los
conocimientos necesarios para encarar las actividades por las que es responsable. El
Coordinador deber llevar a cabo talleres de capacitacin y mentoring hasta asegurarse
de que las personas han aprendido. Esta capacitacin refiere tanto a aspectos tcnicos
como a los relacionados con las dems disciplinas de AgEnD, incluyendo la descripcin
del proceso.
Otra de las actividades que ser realizada en forma conjunta con el Lder de
Proyecto es mantener la salud del equipo de desarrollo. En otras palabras velar porque
la motivacin del equipo sea alta, garantizar relaciones interpersonales positivas,
minimizar las fricciones debidas a distintos tipos de personalidad, entender a cada

individuo para poder sacar lo mejor de s mismo. Existe un solapamiento entre esta
disciplina y la de Administracin de Proyectos en este punto. Se destaca que el mismo
no es tan importante desde un punto de vista conceptual pero la diferencia est marcada
en que las actividades de esta disciplina tienen como objetivo el bienestar de las
personas en el proyecto mientras que el management se relaciona con la consecucin
exitosa del proyecto.
La prctica recomendada para esta disciplina tiene que ver con el patrn de
Mxima Comunicacin que ser descrito ms delante. Es decir, si tenemos canales de
comunicacin suficientemente ricos las dificultades podrn ser resueltas, en la mayora
de los casos, utilizando el sentido comn y la buena predisposicin de la gente.
Un proceso de desarrollo de software debe proveer un mecanismo que permita

que el conocimiento generado en un proyecto sea mantenido dentro de la organizacin.
En la industria de software moderna es vital poseer mecanismos para reutilizar el
conocimiento que se va generando a medida que la organizacin va ejecutando distintos
tipos de proyectos.
Para ello definimos los tres niveles de refinamiento hasta llegar al conocimiento;
son: datos, informacin y conocimiento. Comenzando con el nivel inferior, los datos
consisten en valores discretos y objetivos acerca de eventos, pero sin ningn contenido
acerca de su importancia o relevancia; a partir de stos podremos generar informacin.
La informacin son datos organizados de forma de servir de utilidad para las personas
que mediante el contexto la utilizan para encarar tareas o tomar decisiones. Finalmente,
el conocimiento requiere entender la informacin y tiene que ver con la relacin entre
tems de informacin, su clasificacin y su meta-dato (informacin de la informacin).
La experiencia es conocimiento aplicado.
Se propone la utilizacin de una fbrica de conocimiento gil siguiendo la lnea

de teora de Victor Basili [Basili, 1990]. La misma consiste en una estructura paralela al
equipo de desarrollo, la cual tiene personas de dedicacin exclusiva dedicadas a
capturar, empaquetar, almacenar y distribuir a lo largo de la organizacin.

A partir de esta idea y su adecuacin dentro de una metodologa gil en que

tendremos pequeos grupos de trabajo, AgEnD define un rol especfico que es el
Administrador del Conocimiento. ste podr ser desempeado en forma rotativa por
diferentes personas dentro del equipo de trabajo. Su tarea consiste en documentar todo
aquel conocimiento novedoso que haya sigo generado durante el proyecto para que
pueda ser reutilizado por otras personas. Ser necesario algn tipo de soporte de
herramientas, el cual puede ser algo bastante sencillo como un Swiki6 o algn producto
de administracin de contenidos.
Dado que nos manejamos en un contexto gil, es imperativo que este patrn no
genere una extrema burocracia dentro de la organizacin del proyecto. Por eso se
defini un rol particular como ya fue mencionado el cual deber entender la arquitectura
del sistema y los aspectos funcionales ms importantes para poder capturarlos en
documentos que puedan ser recuperados y consumidos en el futuro. Esto es de suma
importancia y tiene que ver con el aprendizaje organizacional sugerido por Tom
DeMarco [DeMarco, 1999]. Asimismo se recomienda capturar todas aquellas
experiencias humanas positivas y negativas que se tuvieron en el proyecto para poder
agruparlas en formato de patrones y anti-patrones que puedan ser dispersados y
aprendidos por todas las personas.
Un comentario muy importante en relacin a la Administracin del

Conocimiento es la necesidad de invertir en la gente y en abocar por la motivacin de
los equipos de desarrollo. Si una organizacin no valora a las personas que la
conforman, nunca podr aprender. Si en una organizacin la gente trabaja poco tiempo
y se va, habiendo mucho nivel de rotacin, el aprendizaje ser escaso. Puesto de otra
forma por Tom DeMarco:
El aprendizaje est limitado por la habilidad de una

organizacin de mantener a su gente.
Artefactos
6
Herramienta de administracin de contenido, desarrollada por Ward Cunningham. Permite de manera sencilla la carga, edicin,
borrado y visualizacin de cualquier tipo de contenido a travs de la web. Ms informacin en http://www.swiki.org

Las metodologas giles en su mayora tienden a minimizar la cantidad de

artefactos generados en un proyecto. El nfasis est puesto en el cdigo entregado y
cualquier documento construido es visto como un overhead. Sin embargo, existen
muchos artefactos necesarios para propsitos de comunicacin, diseo, gestin sin los
cuales un proyecto no llegara al xito. AgEnD enumera algunos artefactos que
considera requisitos mnimos para tener madurez en el proceso de desarrollo. En la
seccin de Anexos de esta tesis se han colocado templates para la mayor parte de los
artefactos aqu descritos.
Documento de Visin:
Definicin: el Documento de Visin es realizado durante la fase de

Concepcin y sirve como contrato entre el Cliente y el Equipo de
Desarrollo respecto a lo que se va a construir. En la Visin debern
identificarse los stakeholders del proyecto, la totalidad de features del
sistema a ser construido y los requerimientos suplementarios que se
detectaron en forma temprana. En forma optativa podr incluirse un
resumen de los casos de uso crticos del aplicativo.
Responsable: la Visin es construida por un Analista Funcional en

conjunto con el Lder de Proyecto. La misma debe ser mantenida para
reflejar los cambios al alcance durante el proyecto.
Plan de Proyecto:
Definicin: el Plan de Proyecto es un documento mantenido por el Lder

de Proyecto con toda la informacin de gestin. El mismo suele incluir
un Gantt con el cronograma y las tareas del proyecto. Dependiendo del
nivel de formalidad se generar un WBS y/o algn otro tipo de plan a
incluirse dentro de este (plan de testing, de comunicaciones, de
administracin de requerimientos, de administracin de cambios, etc.). El
Plan de Proyecto es creado en forma temprana durante la Concepcin y
actualizado durante las fases posteriores.

Responsable: el Lder de Proyecto es el responsable de este documento y

deber mantenerlo actualizado hasta la terminacin del proyecto.
Lista de Riesgos:
Definicin: la Lista de Riesgos se utiliza para capturar los riesgos ms

relevantes que se presentan en el proyecto, y para poder monitorearlos,
asignarles prioridad, impacto y probabilidad de ocurrencia. Sirve para
planificar las iteraciones y para tener en vista aquellos riesgos que, por su
criticidad, debern ser mitigados lo ms tempranamente posible.
Responsable: el Lder de Proyecto es el responsable y el principal

consumidor de este documento y deber mantenerlo actualizado hasta la
terminacin del proyecto.
Modelo de Casos de Uso y Casos de Uso:
Definicin: los Casos de Uso se utilizarn para especificar los

requerimientos funcionales de la aplicacin. Los mismos servirn para
guiar los dems artefactos y para la construccin de los componentes de
la aplicacin. Asimismo, AgEnD recomienda la generacin del Modelo
de Casos de uso para tener una visualizacin grfica del universo
funcional de la aplicacin y poder comunicarla tanto internamente como
al Cliente para su validacin. Los Casos de Uso y el Modelo sern
creados en las primeras fases del proyecto, aunque podrn tambin ser
especificados en las iteraciones de construccin.
Responsable: los Analistas son responsables de la creacin y el

mantenimiento de estos artefactos, los cuales sern consumidos por el
resto del equipo de desarrollo.
Documento de Especificacin de Requerimientos de Software (SRS):
Definicin: el documento de SRS se utilizara para especificar los

requerimientos funcionales de carcter ms tcnico de la aplicacin.

Tambin en este se incluiran los requerimientos no funcionales, las

reglas de negocio, y las restricciones que se aplicarn a la solucin. En
este documento se pondrn todos los requerimientos que queden fuera de
los casos de uso. La idea es tener algn tipo de constancia documental de
todos aquellos requerimientos de carcter tcnico que debe contemplar la
solucin.
Responsable: los Analistas son responsables de la creacin y el

mantenimiento de este artefacto, el cual ser consumidos por el resto del
equipo de desarrollo.
Descripcin de la Arquitectura:
Definicin: el documento de Descripcin de la Arquitectura tambin

conocido como SAD especifica los aspectos tcnicos de la solucin
propuesta por el equipo de desarrollo. Sirve como medio de
comunicacin entre el Arquitecto y el equipo en relacin a cmo debern
ser implementados los casos de uso de la aplicacin.
Responsable: el Arquitecto es el principal responsable por la realizacin

de este artefacto, as como la creacin de un prototipo ejecutable (Proof
of Concept) que valide que la misma cumpla los requerimientos no
funcionales y las cualidades sistmicas que hacen a los atributos de
calidad no relacionados directamente con las necesidades del usuario.
Casos de Prueba:
Definicin: los Casos de Prueba contienen la especificacin de cmo ser

validado el sistema. Estos son realizados basndose en los casos de uso y
planteando todos los escenarios posibles que stos pueden contener.
Dado que puede ser bastante burocrtico realizar la totalidad de Casos de
Prueba existentes en un sistema, se recomienda generar los ms
importantes y despus anotar las variantes en un Caso de Prueba
Estndar.

Responsable: el Tester es el principal responsable por la realizacin de

este artefacto. El Tester ser el encargado del diseo y la ejecucin de los
Casos de Prueba.
Scripts de Despliegue:
Definicin: los Scripts de Despliegue son necesarios para la instalacin

del producto en un entorno determinado. El mismo automatiza las tareas
de empaquetamiento, versionado, compilacin, etc. Un ejemplo muy
utilizado baja la plataforma J2SE es la herramienta ANT, que permite
generar scripts de despliegue con bastantes funcionalidades.
Responsable: algn Programador ser responsable de la generacin y

mantenimiento de estos scripts.
Planilla de Incidentes:
Definicin: la Planilla de Incidentes ser utilizada para registrar y tener

seguimiento de aquellos bugs, mejoras, tareas que el Tester o alguna
persona de aseguramiento de la calidad necesite reportar. Son los
denominados sistemas de Issue Tracking que pueden ser
implementados manualmente o mediante alguna herramienta.
Responsable: la Planilla de Incidentes ser utilizada por todos los

miembros del equipo. En particular ser muy utilizada por los Testers
quienes cargarn todos los bugs encontrados durante la ejecucin de los
Casos de Prueba los cuales sern ledos y corregidos por los
Programadores.
Repositorio del Proyecto:
Definicin: el Repositorio es la herramienta fundamental para cubrir la

disciplina de Administracin de la Configuracin. En el repositorio se
almacenan todas las versiones de todos los archivos y directorios del
proyecto. AgEnD recomienda que todo artefacto generado durante un

proyecto sea puesto bajo control de versiones y no slo el cdigo fuente

de la aplicacin. Esto permitir en cualquier momento poder comparar
versiones, volver a recuperar versiones anteriores, y generar ramas de
desarrollo paralelo.
Responsable: algn Programador o alguna persona de Infraestructura de

la organizacin ser responsable de la creacin, mantenimiento y
eliminacin (en casos que se desee dar de baja el proyecto) del
repositorio.
Nota de Entrega:
Definicin: la Nota de Entrega sirve para especificar aquello que se le

entrega al Cliente en un release determinado de la aplicacin. En la
misma se constatar el nmero de versin, los cambios de la versin
anterior, los bugs conocidos y las mejoras efectuadas.
Responsable: cualquier miembro del equipo de desarrollo que vaya a

entregar algn artefacto al Cliente deber crear la correspondiente Nota
de Entrega.

Patrones de Desarrollo Recomendados

Los patrones surgieron del universo de la arquitectura del trabajo de Christopher
Alexander durante los aos 1977-1979. En su primer libro de esta serie [Alexander,
1977] el autor escribe: Cada patrn describe un problema que ocurre una y otra vez en
nuestro ambiente, y despus describe la base de la solucin a dicho problema de una
forma que se puede utilizar dicha solucin un milln de veces sin realizarla dos veces de
la misma manera. Posteriormente Alexander simplifico la definicin teniendo en
cuenta que un patrn plantea un problema y despus propone una solucin al mismo.
Tambin nos da un contexto para entender cundo la solucin debe ser aplicada. Los
patrones de Alexander no tuvieron una influencia muy importante en la comunidad de
arquitectura, pero s tuvieron un gran impacto en la industria del software alrededor de
1995, cuando se edit el libro de Gang Of Four [Gamma, 1995]. Se tomarn estos
conceptos para definir los patrones que AgEnD recomienda en el desarrollo de software.
Dichos patrones son los mencionados a continuacin:
1. Mxima Comunicacin
2. Comunicacin Interna al Equipo
3. Participacin Activa del Cliente
4. Estimaciones giles
5. Enfoque en la Arquitectura
6. Integracin Continua
7. Peopleware

Mxima Comunicacin
Las metodologas giles solo tienen sentido si existe comunicacin entre las
personas. Esto no solo refiere a las personas del equipo de desarrollo, sino a todas las
personas que se vean afectadas en distinta medida por la ejecucin del proyecto; los
denominados durante esta tesis como stakeholders.
Bajo el patrn de Mxima Comunicacin se encuentra uno de los principios

esenciales de AgEnD. Relacionado estrechamente con una de las actividades ms
comunes de los seres humanos: la comunicacin que representa las diversas formas de
transmisin de datos/informacin/conocimiento/experiencia entre individuos.
El software se encuentra entre los elementos de mayor complejidad creados por

el hombre. Dada esta complejidad inherente a su esencia, el software presenta una gran
dificultad en su construccin caracterizada por la aleatoriedad de las posibilidades en el
desarrollo de cualquier sistema y la incapacidad de concebir procesos repetibles como
ocurre en las dems ingenieras. Si bien se han logrado muchos avances en cuanto al
manejo de dicha complejidad, la misma an persiste y genera resultados no deseados
como cronogramas excedidos, baja calidad o funcionalidad incompleta.
Existen dos tipos de comunicaciones que este proceso toma en cuenta para
mejorar el desarrollo. Estas comunicaciones difieren en relacin a las personas
involucradas en las mismas. La primera es la comunicacin interna, es decir la
comunicacin entre todos los integrantes del equipo de desarrollo desde el lder del
proyecto hasta el programador. La segunda comunicacin a la que nos referiremos es la
comunicacin entre los integrantes del equipo de desarrollo y el cliente o usuario del
sistema. Es decir, todas las comunicaciones que el equipo mantenga con los
stakeholders. En la figura 020, tenemos una representacin grfica de los niveles
presentados en este prrafo.

Figura 020. Comunicaciones existentes en un proyecto.
Esta divisin nos permite concentrarnos en las prcticas que podrn ser aplicadas
en cada caso. Analizaremos las formas de atacar el desarrollo de manera de maximizar
la comunicacin entre las partes involucradas acorde al contexto en que se plantean.
Tomando los principios que guan a AgEnD, continuamente se priorizan las

personas sobre el proceso. La metodologa debe proveer mecanismos que fomenten las
interacciones ayudando a mejorar la motivacin y la productividad del equipo de
desarrollo. De esta forma el flujo de informacin entre las mentes de los desarrolladores
ser maximizado permitiendo mayor progreso en el proyecto. Alistair Cockburn
[Cockburn, 2001a] analiz este fenmeno en detalle evaluando el impacto de distintos
modelos comunicacionales. La Figura 021 muestra la influencia en la efectividad de la
comunicacin de acuerdo al canal que se utiliza para establecer la misma.

Figura 021. Efectividad de distintos modos de comunicacin. Tomada de [Cockburn, 2001a].
Acorde a los resultados reportados en dicha investigacin AgEnD recomienda

diversas prcticas que estimulen canales de comunicacin ms abiertos tanto
internamente al equipo como externamente con los stakeholders del proyecto.
Comunicacin Interna
La primera recomendacin que podemos tomar tiene que ver con el patrn de
Mnima Dispersin Fsica. Segn este patrn el equipo de desarrollo debe estar
colocado fsicamente en una nica oficina que tenga una distribucin centralizada al
momento de trabajo con lugares privados para cuestiones extra laborales. Esta es la
propuesta de XP la cual no hace ms que obedecer al canal de comunicacin ms rico
que es ver a las personas cara a cara para interactuar con ellas.
Asimismo otro patrn denominado Interrupciones Mnimas que refiere a la

necesidad de liberar al equipo de desarrollo de interrupciones referidas a otros mbitos.
En principio, se recomienda que la oficina del equipo de desarrollo este separada
mediante paredes del resto de la organizacin. Si esto no se logra, se tendrn flujos de
informacin que no refieren al desarrollo y que empeorarn la calidad del ambiente
diseado para maximizar la comunicacin como planteaba el primer patrn
mencionado. Tom DeMarco [DeMarco, 1987] indaga bastante sobre los efectos nocivos
de mantener entornos de trabajo con mucho ruido e informacin innecesaria que atenta
contra el trabajo de las personas.

Tambin este patrn aplica a la necesidad de que las personas no estn

continuamente interrumpindose entre s, esto es evidente en los casos de una persona
que juega un rol clave y que constantemente debe resolver dudas. La idea subyacente es
la de tratar primero de evacuar las dudas mediante lectura de algn documento, si esto
no funciona, se podr pedir auxilio a los pares. Como ltimo recurso se debera
convocar a esta persona, en algunos casos se pueden juntar un nmero importante de
dudas e ir anotndolas y preguntarlas todas de una nica vez. Sin embargo, dado que la
comunicacin es fomentada AgEnD recomienda una interrupcin antes que guardarse la
pregunta y hacer alguna suposicin al respecto.
Un tercer patrn que se recomienda es el que Cockburn describe como

Radiadores de Informacin. Segn este patrn se recomienda tener las paredes de la
oficina totalmente libres dispuestas para que se cuelguen en ellas pizarrones, hojas
grandes, diagramas, notas post-it, etc. Estos actan como radiadores de informacin ya
que permiten que cualquier miembro del equipo pueda tener acceso a esa informacin
constantemente sin necesidad de andar indagando a las dems personas. Ms an, los
radiadores sirven para mantener informacin crtica a la vista de todos la cual puede ser
discutida, analizada, modificada y comunicada continuamente. Ejemplos de
informacin que se puede plasmar en estos es:
Diagramas de Arquitectura
Avance del proyecto en funcin de los casos de uso implementados
Resultado de la ejecucin de los casos de prueba
Diagrama de casos de uso
Una implementacin alternativa es tener un sitio web que disponga

continuamente de informacin del proyecto. Adicionalmente, puede servir como base
de conocimientos del proyecto y de la organizacin.
Comunicacin Externa
Tan importante como la comunicacin interna resulta la comunicacin con los
stakeholders del proyecto. Primero debemos dividir a los stakeholders en dos franjas:
stakeholders claves para el xito del proyecto y stakeholders normales. Los stakeholders

claves sern aquellos que poseen conocimiento del dominio del sistema a construir. Son
aquellos que aceptarn el sistema en cuestin si el mismo se adeca a sus necesidades.
Por otro lado, tenemos los stakeholders normales con los que el equipo interacta
ocasionalmente para algn propsito del proyecto. Estos ltimos juegan un rol que
puede tener importancia para la salud del proyecto pero que no impacta directamente
sobre la funcionalidad de la aplicacin construida.
AgEnD recomienda maximizar la comunicacin con los stakeholders claves del

proyecto. En el caso ideal se recomienda utilizar el patrn On-Site Customer derivado
de XP que establece que durante todo el proyecto habr un cliente real sentado en la
misma oficina con el equipo de desarrollo, dispuesto a responder preguntas, resolver
disputas, y priorizar las tareas llevadas a cabo. Cabe destacar que en este caso un
cliente real refiere a una persona que utilizar el sistema una vez puesto en
produccin y que conozca la aplicacin en su extensin para resolver distintas
cuestiones que puedan darse.
Ocurre que en la mayora de los casos los clientes tienen que hacer sus propios
trabajos y no disponen de tiempo para estar continuamente formando parte del equipo
de desarrollo. Dadas las realidades impuestas en la mayor parte de los proyectos,
AgEnD propone disponer de un cliente designado con el rol de Experto en el Dominio
mencionado anteriormente. El mismo debe estar dispuesto a contestar cualquier
pregunta del equipo de desarrollo ya sea mediante algn canal de comunicacin ms
fro de acuerdo a la Figura 021 (ej.: telfono, videoconferencia, mail, etc.) en un tiempo
razonable que no debera superar algunas horas. En caso de que el problema requiera de
una comunicacin ms personal, el cliente deber disponer de tiempo para visitar al
equipo de desarrollo y discutir el tema personalmente o bien para recibir a algn
miembro clave en sus propias oficinas.
El nfasis est puesto en mantener el proceso lo ms gil posible, y dado que la

recomendacin es construir casos de uso que manifiesten las interacciones a un nivel no
muy detallado siempre existirn dudas que podrn ser mitigadas por los Expertos en el
Dominio.
Respecto a los stakeholders normales, la recomendacin es que los mismos sean

identificados en forma temprana y sus necesidades sean relevadas para verificar que el
sistema conforme a estos adecuadamente. Si bien no ser necesario tener un canal

abierto tan flexible la comunicacin con estos debe ser fluida y honesta ya que en algn
punto el sistema tendr influencia sobre ellos o viceversa.
Participacin Activa del Cliente

AgEnD plantea la necesidad de contar con una incondicional participacin del
Cliente durante el proyecto de desarrollo. Dadas las caractersticas de las aplicaciones a
las que el proceso apunta, los nicos capaces de definir qu debe contener el producto
son los usuarios dado que sern sus necesidades las que se vern afectadas. En esto
AgEnD es inflexible; no hay documento ni modelo ni herramienta que pueda sustituir el
feedback provisto en forma directa mediante contacto cara a cara entre el analista y el
cliente o usuario del sistema. No hay forma de alcanzar el xito en un proyecto si no se
cuenta con el compromiso y el soporte del sponsor. El apoyo del management garantiza
que los obstculos que se presenten polticos, econmicos, sociales puedan ser
removidos mediante su activa participacin.
Las razones de la inflexibilidad en este punto son aquellas que han revelado
cuales eran los factores que ms contribuan al fracaso de los proyectos de software.
Segn estudios realizados por el Grupo Standish [Standish, 1994] la falta de
involucramiento por parte de los usuarios y el poco apoyo del management estn entre
los factores antes mencionados. Si se analiza este hecho concluimos que es lgico
establecer que si el usuario no participa en la construccin del software nunca este
ltimo va a satisfacer sus necesidades por ser el usuario el nico que las conoce. En
otras palabras,
El no involucrar al usuario durante el desarrollo de software nos

permite construir un producto de software que slo cumple las
necesidades de aquellas personas que no van a utilizarlo.
Para lograr esta activa participacin del usuario deberemos poder contar con
usuarios expertos en el dominio que puedan prestar todo el tiempo necesario para las
necesidades del equipo de proyecto. Entre estas se incluye la posibilidad de que los
analistas puedan delinear requerimientos con el grado de detalle necesario para que los

programadores puedan comenzar con el diseo. Tambin los programadores deben

poder consultar a dichos usuarios si se les plantean dudas respecto al dominio del
problema o existen omisiones o inconsistencias en los requerimientos.
Los usuarios debern tener amplio conocimiento del dominio para poder
resolver cualquier duda del equipo respecto a las funcionalidades a desarrollar. Tambin
deber priorizar continuamente el valor del negocio de lo que se construye en cada
iteracin para guiar funcionalmente al equipo.
Estimaciones giles
Al estar Orientadas a los Productos, las metodologas giles permiten realizar
estimaciones de menor granularidad en el da a da para obtener ms precisin en la
estimacin de la entrega de artefactos en cada iteracin, en detrimento de una
visibilidad a largo plazo. Sin embargo, es importante realizar estimaciones realistas de
la duracin de los proyectos sobre todo al principio de los mismos.
La tcnica que propone AgEnD es la estimacin por puntos de caso de uso (use
case points). La misma mide a los sistemas desde una perspectiva funcional y es
independiente de la tecnologa. Sin tener consideracin del lenguaje, mtodo de
desarrollo, o plataforma de hardware utilizada, el nmero de puntos de casos de uso de
un sistema permanecer constante. La nica variable es la cantidad de esfuerzo
necesario para desarrollar un conjunto dado de puntos de caso de uso; por lo tanto el
Anlisis por Puntos de Caso de uso puede ser utilizado para determinar si una
herramienta, un ambiente, un lenguaje es ms productivo comparado con otros dentro
de una organizacin o entre organizaciones. Este es uno de los puntos crticos y uno de
los valores ms importantes de dicho anlisis. El mtodo de puntos de caso de uso est
cubierto y detallado en [Ribu, 2001].
Dentro de los proyecto de implementacin bajo el alcance de AgEnD, el objetivo

es poder hacer una estimacin de la funcionalidad a ser entregada en cada etapa en
funcin de la productividad del equipo de desarrollo. AgEnD requiere que la persona
responsable de un producto, ya sea una clase, un caso de uso o un documento de
administracin de la configuracin, realice la estimacin. Esto va en contra de las
metodologas tradicionales en las que es el lder de proyecto el encargado de realizar

todas las estimaciones del proyecto. En los procesos giles, al reconocer que las
personas son lo ms importante del desarrollo las mismas adquieren ms
responsabilidad en relacin a los productos que entregan, debiendo estimar la duracin
del desarrollo en cada iteracin. Esto no quiere decir que los Programadores estarn a
cargo de hacer la estimacin del proyecto completo - el Lder ser el que lo realice
consultando a todos los miembros del equipo, ya que este es responsable por la
concrecin del proyecto entero - pero si sern responsables por los productos que
construyen durante las tareas que realizan todos los das.
AgEnD fomenta el concepto de estimacin descentralizada. Cada persona

estimar el fruto de sus tareas por la tcnica que considere necesaria. Una consecuencia
de esto es que las personas no sienten que se les ha impuesto un cronograma al que
deben atenerse pudiendo ser reprendidas en caso de retrasos. El responsable de un
producto es la persona ms adecuada para medir su ritmo y estimar los tiempos
necesarios. Al principio esto podr resultar difcil para aquellas personas acostumbradas
a tener fechas y tareas impuestas desde arriba, pero ah es donde entra en juego el
Coordinador para capacitar a los miembros del equipo y perfeccionarlos en las
estimaciones futuras.
La estimacin para una iteracin dada ser realizada durante la iteracin previa,
de forma de tener la planificacin aprobada por el cliente previo a embarcar en las
actividades correspondientes al equipo en el desarrollo. Esta estimacin ser efectuada
por todo el equipo junto al cliente y en la misma ser validada la funcionalidad a ser
prximamente construida.
Enfoque en la Arquitectura
Una de las ideas propuestas por AgEnD consiste en una temprana definicin de
la arquitectura del sistema. La arquitectura no es un concepto que pueda ser explicado
en un par de palabras. Consiste ms bien en una suma de aspectos que estn
relacionados con el diseo de un sistema.
Ya sea que estemos construyendo un edificio, una prensa hidrulica o un

software empaquetado, debemos tener algn elemento de alto nivel que refleje las
decisiones que se van tomando en relacin al diseo de la construccin. Haciendo un

paralelismo con el paradigma de objetos, considerando al sistema como un paquete a ser

embebido en un ambiente especfico, la arquitectura estara dada por:
la organizacin del mismo, definida por los paquetes o clases que

contiene y las relaciones entre los mismos
las interfaces que provee al mundo exterior
los paquetes que requiere para su funcionamiento
los servicios que provee, realizados a partir de mtodos en clases, que

deben dar valor a algn actor que interacta con el sistema
los patrones, estndares, frameworks utilizados para su construccin
Cabe destacar, que la arquitectura mantiene un cierto nivel de abstraccin dentro

de la disciplina de diseo. No contempla los detalles de ms bajo nivel, como la
implementacin interna de las clases y mtodos, ni analiza en detalle los protocolos a
ser utilizados por los sistemas. Simplemente propone un conjunto de vistas [Kruchten,
2000] que enfatizan distintos aspectos del software. Los mismos tienen que ver con:
organizacin lgica
funcionalidad
concurrencia
distribucin del software en la plataforma
Gracias a la arquitectura logramos la integridad conceptual necesaria para dirigir

nuestro proceso. La importancia de esta abstraccin hace necesaria la definicin de un
rol que participe activamente en su creacin y que ya ha sido detallado con anterioridad,
el Arquitecto.
Arquitectura gil
A continuacin detallaremos cul es el propsito de la arquitectura en el marco

del proceso gil propuesto, cmo se construye y cmo se mantiene.

En este punto, y a diferencia de la mayor parte de las metodologas giles,

AgEnD propone definir una arquitectura candidata en forma temprana. La idea
subyacente de este patrn deriva de analizar la curva del costo de cambio propuesta por
Barry Boehm originalmente. En la misma, Boehm indicaba que el costo de reparar un
defecto descubierto durante la fase de requerimientos resultaba 200 veces ms barato
que reparar el mismo defecto en la fase de mantenimiento. Esto est graficado en la
Figura 021, que muestra cmo se obtienen ahorros en una relacin de hasta 200:1 al
encontrar errores en fases tempranas versus a encontrarlos en fases ms tardas. Este
anlisis llevo a Boehm a proponer el Modelo en Espiral, que mitigaba en forma
temprana los riesgos de introducir defectos en la fase de requerimientos mediante la
realizacin de sucesivas iteraciones de validacin con el cliente.
Sin embargo, detrs de esta premisa estaba la idea de tener un entendimiento

global de todos los aspectos funcionales de la aplicacin, creando documentos de
especificacin completos, detallados, y con todas las normas de calidad requeridas. Esto
terminaba degenerando el concepto formulado por el modelo en cascada que una vez
que los requerimientos estaban bien definidos la construccin prosegua como una
secuencia de fases. Ya han sido descritas todas las falencias de este modelo, por lo cual
ahora se analizar como sera la curva del cambio en el universo de las metodologas
giles.
Esta misma nocin aplicaba a la idea de realizar cambios a los requerimientos.

Dadas las caractersticas humanas que hacen muy difcil las actividades de relevamiento
debido a que el cliente va cambiando aprendiendo lo que desea con el tiempo y
derivando de la Figura 021 ya mencionada, se tomaba como referencia en las
metodologas tradicionales la Figura 022 que mostraba el impacto del cambio en cada
fase. De hecho era el mismo modelo en cascada o secuencial el que contribua a que
todos los cambios siguieran esa curva dado su escasa tolerancia al cambio. Esto
fomentaba nuevamente la idea de que realizando una exhaustiva fase inicial de
requerimientos el sistema tendra un mnimo nivel de cambios. Este supuesto era una
falacia como muestra la evidencia propuesta por Capers Jones presentada en la Figura
023. Segn este anlisis el cambio a los requerimientos en proyectos de software va
desde un 10% sobre el alcance total en los proyectos ms chicos, hasta un 35% o ms en
los proyectos ms grandes. Queda demostrado que la construccin de software se halla
en un dominio de alto cambio y el proceso en cuestin debe tomar esto en cuenta.

Figura 021. El costo relativo de reparar un defecto en diferentes fases del ciclo de vida. Tomada de [Leffingwell, 2001].
Figura 022. Curva del costo de cambio a los requerimientos en diferentes fases del ciclo de vida. Tomada de [Beck,
2000].

Figura 023. Tasas de cambio a los requerimientos en proyectos de software respecto al tamao funcional de los mismos.
Tomada de [Larman, 2003].
La premisa propuesta por AgEnD consiste en tener un proceso gil que tenga
alta tolerancia al cambio y que permita que la curva del costo de cambio propuesta por
Boehm no escale exponencialmente en la mayora de los casos. AgEnD sugiere que en
los proyectos se tenga una grfica como muestra la Figura 024. En la figura hay dos
curvas: la nmero 1 que crece exponencialmente al igual que la original de Boehm y en
la que se manifiestan los cambios relacionados con aspectos que involucran altos
riesgos como la arquitectura candidata del sistema, mientras que en la curva nmero 2
que es bastante achatada pondramos todos los cambios relacionados a la funcionalidad
del sistema los cuales pueden ser absorbidos en las distintas iteraciones mediante el
feedback continuo con el cliente.
La idea de AgEnD es tratar de mover todos los cambios a la curva nmero 2

(idealmente ese el postulado de XP, que plantea que la curva del costo de cualquier
cambio es la curva nmero 2), pero reconoce que existen distintas aspectos que
implican un alto costo al cambio una vez que se avanza en el desarrollo. Para aquellos
factores que revisten las caractersticas de la curva nmero 1 AgEnD sugiere una
definicin previa al inicio del desarrollo en gran escala y establece al Documento de
Arquitectura como el repositorio de estas cuestiones.

Figura 024. El costo del cambio actualizado para una metodologa gil. Tomada de [Poppendieck, 2003].
Sin embargo, dadas las caractersticas del proceso resulta burocrtico desarrollar
un documento de grandes proporciones que gue el proceso con las decisiones ms
importantes del diseo, que incorpore extractos de los diversos aspectos que son
reconocidos como esenciales para el desarrollo y que sea actualizado en cada iteracin
para servir a su propsito.
Pero antes de esto deberamos analizar, siendo que el propsito de la arquitectura

es la comunicacin de aspectos esenciales del software entre las partes involucradas o
stakeholders, no se ve reducido drsticamente su alcance dada la estrecha
comunicacin propuesta por la metodologa? En otras palabras, al combinar el principio
de Mxima Comunicacin con el de Arquitectura gil, debemos cambiar la definicin
de arquitectura tradicional ya que la misma no coincide con las prcticas propuestas.
El principio de Arquitectura gil en AgEnD consiste en mantener una visin

nica, formulada por el equipo de proyecto de las decisiones consideradas crticas para
el desarrollo. Ser el mismo equipo el encargado de construir, mantener y obtener los
beneficios de la misma. En consecuencia, la arquitectura no va a ser un documento
esttico con una estructura determinada a la cual el equipo se deba ajustar aunque no
contribuya al desarrollo. Ir evolucionando con el desarrollo de los componentes y ser
mantenida hasta el punto que contribuya a la comunicacin de los aspectos tecnolgicos
dentro del grupo. Una vez que el conocimiento est en las mentes de todos, la misma
habr cumplido su funcin y el documento podr ser dejado a un lado. Esto es as

debido al principio de Proceso Orientado a las Personas, el cual describe la necesidad

de construir aquellos artefactos indispensables para el proyecto de software, aquellos
que sirvan algn propsito claro.
Al momento de definir la arquitectura, AgEnD propone una serie de modelos

extrados y extendidos a travs de estereotipos del Unified Modeling Language (UML).
Los mismos sirven como gua segn el tipo de aplicacin que se este construyendo. En
general, nos referiremos a aplicaciones que se encuentren dentro del espectro de
aplicabilidad de AgEnD; es decir, aplicaciones del sector IS/IT, de una escala media o
pequea, con alto grado de involucramiento de los usuarios.
Estos modelos estn especificados UML y sirven para describir distintas vistas
de la arquitectura necesarias para la comunicacin dentro del equipo. Entre los modelos
que el arquitecto debera manejar al momento de definir la arquitectura encontramos:
Diagrama de Despliegue (Figura 025 y 026):
Definicin: el diagrama de despliegue muestra como y donde el sistema

ser desplegado. En el mismo se muestran nodos fsicos, procesadores, y
los componentes que corren en cada uno. Como se observa en las figuras
este diagrama puede tener distintas implementaciones de acuerdo al
grado de detalle que se quiera llegar. Sin embargo, es muy recomendable
ya que muestra como la aplicacin ser llevada al ambiente de
produccin mediante la separacin de los componentes en nodos.
Diagrama de Componentes (Figura 027):
Definicin: el diagrama de componentes muestra las piezas de software o

entidades que conforman al sistema; en general, un componentes es de
ms alto nivel que una clase y suele ser implementado en tiempo de
ejecucin por un nmero de clases.
Diagrama de Secuencia (Figura 028):
Definicin: el diagrama de secuencia es una representacin de las

interacciones entre clases y objetos para llevar a cabo una operatoria a lo
largo del tiempo. Se utiliza para mostrar flujos de trabajo, pasaje de
mensajes y la cooperacin necesaria para brindar un determinado
resultado.

Diagrama de Estado (Figura 029):
Definicin: el diagrama de estado sirve para mostrar como un elemento

(clase) cambia de estado a lo largo del tiempo y las transiciones que le
son permitidas en cada caso con las correspondientes condiciones.
Diagrama de Clases (Figura 030):
Definicin: el diagrama de clases captura la estructura lgica del sistema

las clases y/o entidades que componen al modelo. Es considerado un
modelo esttico ya que muestra las clases existentes y los atributos,
mtodos de cada una.
Diagrama de Datos (Figura 031):
Definicin: el diagrama de datos sirve para mostrar como el modelo ser

persistido en un RDBMS. El mismo est dentro del perfil de UML para
modelado de datos y maneja estereotipos como Tabla, Primary Key,
Foreign Key, etc.
Figura 025. Diagrama de Despliegue de alto nivel en UML. Tomada de [Sun, 2003].

Figura 026. Diagrama de Despliegue detallado en UML. Tomada de [Sun, 2003].
Apache HTTP Serv er 2.0 httpd.conf
Restart Apache HTTP Server() : void
mod_j k.so Tomcat 4 JBoss 3.0
Messenger
messenger.ear
Database
SQL Serv er SQL Serv er 2003

Configuration
Configure() : void
Restart() : void
Figura 027. Diagrama de Componentes en UML. Tomada de [EA, 2003].

jsp page servlet :Message :TransmissionManager :Contact :SmtpGateway :FaxGateway :PersistanceManager

:MessagePage :SaveMessageServlet
Staff Member
Send Message()
doPost(response,request)
setSender(sender)
sendMessage(message)
getRecipients() getPrimaryContactMethod(contactMethod)
getEmailAddress()
sendMessage(messsage,emailAddress)
getFaxNumber()
sendMessage(message,faxNumber)
makePersistent(message)
Figura 028. Diagrama de Secuencia en UML. Tomada de [EA, 2003].
Compose The message is In

Transit when it has
left the Messenger
System for an
Composed
external recipient.
Save
Sav ed
Send
Transmit via
Cancel Gateway [External
Sent Contact] In Transit
Send
Reach Recipient
Transmit [Internal Contact]
Discarded
Deliv ered Read
Read
Restore Delete AccountLimitReached [HighPriority] /SendMessage
This occurs when Deleted

the message is
removed from
Deleted Items.
Purge Archiv ed
Purged
Figura 029. Diagrama de Estado en UML. Tomada de [EA, 2003].

Staff Member Account

+Owner IsGranted
- Name: char - Status: char
- Email Address: char 1 1
- Cell Phone: int
- Fax: int +Manages 1
- Address Line 1: char
- Address Line 2: char
- City/Town/Suburb: char
- Post Code: char #ManagedBy 1..*
- State/Province: char
- Country: char Message
- Public Key: char Folder
- Name: char
#Sender #Recipient
+Stores 1..*
Sends Receives +StoredIn 0..*
+IsReceivedBy Message
0..* - Subject: char = Blank

- Body: char
+IsSentBy - Sender: char
- Recipient: char
0..*
Figura 030. Diagrama de Clases en UML. Tomada de [EA, 2003].
Figura 030. Diagrama de Datos en UML. Tomada de [EA, 2003].

Se debe tener en cuenta que debe existir un balance entre el esfuerzo en realizar
estos diagramas y la posibilidad de comunicar dichas ideas en forma directa. De
acuerdo al patrn de Mxima Comunicacin conviene que estos diagramas estn en
algn radiador de informacin ya sea mediante impresiones en hojas grandes colgadas,
en una intranet de administracin de conocimiento, o simplemente dibujados en
pizarrones en los casos que se desee ms informalidad. Una vez que el propsito
comunicacional es servido no tiene sentido seguir detallando y/o manteniendo estos
diagramas.
Integracin Continua
Indudablemente una de las prcticas que hoy se encuentra recomendada por la
mayor parte del espectro de metodologas modernas (no solo giles) es el de Integracin
Continua.
Esta prctica nace a partir de los fracasos acarreados por las fases de integracin
de los modelos tradicionales en que una vez que se tenan todos los mdulos
construidos se iniciaba una intensa y compleja fase en que los mismos se integraban
unos con otros hasta lograr el producto a ser entregado. Era en dicho lapso en que
ocurran los mayores descalabros en materia planificacin, excedindose de manera
desmedida el tiempo, haciendo que fracasen proyectos que haban concluido con xito
sus fases anteriores. Una de las causas principales consista en las complejas
interacciones existentes entre los distintos mdulos, construidos por distintos equipos,
los cuales al ser integrados por vez primera presentaban bugs que eran muy difciles de
encontrar por estar generados por distintas personas.
La industria del software aprendi su leccin, y ya desde hace algn tiempo, la

Integracin Continua es considerada esencial en cualquier proceso moderno de
desarrollo por ms burocrtico o minimalista que resulte. Por dar un ejemplo, la
metodologa eXtreme Programming contiene la Integracin Continua entre sus 12
prcticas claves. Ms an es de pblico conocimiento que desde hace muchos aos
Microsoft viene utilizando esta prctica en su proceso de desarrollo de donde surgi la
nocin del daily build, en que todas las noches se integraba, compilaba y linkeaba el
cdigo generado para ser luego probado por los casos de prueba automatizados. Steve

McConnell [McConnell, 1996] fue uno de los que ms analiz esta tcnica
recomendndola entre sus conocidas best practices. Martin Fowler [Fowler, 2002]
escribi un artculo bastante descriptivo de los beneficios de esta prctica.
La Integracin Continua en AgEnD consiste en poseer un ambiente

automatizado mediante el cual se pueda realizar el check out de la herramienta de
Administracin de la Configuracin que se este utilizando y posteriormente tener un
entorno que tome el cdigo fuente, genere los builds con todos los pasos intermedios
que esto involucre, corra los suites de tests automatizados, y emita un reporte con el
resultado del proceso. El nfasis est puesto en la automatizacin del proceso de manera
que resulte algo lo ms transparente posible para el equipo de desarrollo. Existen en la
actualidad herramientas muy potentes en algunos casos, gratuitas por ser de cdigo
abierto las cuales permiten que esta prctica pueda ser llevada a la realidad con un
mnimo esfuerzo. Un ejemplo de herramienta Open Source de estas caractersticas es el
Cruise Control que funciona en conjunto con Ant, CVS, y JUnit para llevar a cabo los
builds continuos en una mquina.
Para tener un build exitoso es recomendable que el mismo tenga ciertas

caractersticas que nos den seguridad respecto a la consistencia e integridad del mismo.
En un entorno ideal un build solo podr ser llamado exitoso si se dan todos los
siguientes pasos correctamente sin intervencin humana:
los ltimos fuentes han sido bajados del repositorio de versionado
cada archivo fue compilado de cero
los ejecutables han sido linkeados y empaquetados para su despliegue
el sistema es ejecutado y las pruebas automatizadas son disparadas
Para entender la prctica en cuestin se dar un ejemplo concreto de su

aplicacin en un proyecto de software usando una metodologa como AgEnD. Se toma
el supuesto de que se tiene un equipo de desarrollo en que cada programador se
encuentra programando un componente en forma paralela a los dems. A intervalos
regulares cada programador terminar la construccin de su componente, correr las

pruebas unitarias sobre el mismo7 y una vez que pase exitosamente el 100% de las
mismas proceder a integrarlo. Cuando el programador se disponga a integrar lo que ha
construido realiza previamente una actualizacin de la copia local de su repositorio para
chequear que est usando la ltima versin de todos los tems de configuracin y luego
subir sus cambios mediante un check-in al repositorio.
En casos que no se cuente con una herramienta de builds automatizada, el

programador har un check out del mdulo correspondiente en la mquina que ha sido
designada como repositorio de los builds maestros. En la misma ejecutar el script de
deployment8 que se encargar de compilar y empaquetar las clases para su despliegue.
Suponiendo que el resultado del script es exitoso se podr efectuar el test funcional en
caso que se desee liberar la versin. Una vez que el programador deja la mquina de
integracin tendr una sensacin de logro y una inmediata recompensa de un trabajo
bien realizado.
Sin embargo, deberemos recordar que hasta este instante estamos verificando la
sintaxis y semntica del cdigo, pero no sabemos nada respecto a si cumple las
necesidades del usuario. Para esto se tienen las pruebas funcionales automatizadas o
manuales que deber crear o especificar el tester junto con el cliente.
Peopleware
Una de las cuestiones en que se enfoca AgEnD es Peopleware - esto es
consistente con la idea de estar alineada bajo el Agile Manifesto ya mencionado. Este
trmino refiere a las personas involucradas en el desarrollo de software y a todos los
aspectos relacionados con las mismas.
Las primeras nociones de Peopleware surgieron alrededor de 1969, cuando la

industria del software apenas comenzaba a madurar, de manos de Gerald Weinberg en
su libro The Psychology of Computer Programming, posteriormente reeditado en 1998
[Weinberg, 1998]. En el mismo, Weinberg relativizaba los aspectos relacionados con el
proceso y las tcnicas utilizadas para construir software abocando la importancia que
7
Esta idea surge del framework de testing creado por Kent Beck para Smalltalk, posteriormente portado y popularizado por la
versin en Java, denominada JUnit, desarrollada por Beck y Erich Gamma. Ms informacin en http://www.junit.org

tena el factor humano en el mismo. La comunidad informtica no incorpor las

consideraciones de Weinberg, quien sigui escribiendo acerca de estos temas durante el
tiempo subsiguiente. Pasaron algo ms de 15 aos hasta que Tom DeMarco tomara
nuevamente estas ideas para su libro Peopleware: Productive Projects and Teams
[DeMarco, 1987] tambin reeditado en 1999. El libro de DeMarco tuvo mayores
repercusiones en la comunidad que las que haba tenido su predecesor, aunque no logr
imponer el cambio necesario para considerar las cuestiones humanas como dominantes
en el desarrollo del software. Cabe destacar que algunas empresas s tomaron las
prcticas de DeMarco con algunos resultados bastante exitosos el ejemplo ms
destacable es Microsoft.
Llevando las ideas de todas estas fuentes al contexto de esta tesis, AgEnD toma
a las personas como partes esenciales del desarrollo y las encuadra en un marco humano
necesario para el entendimiento del impacto que las mismas tienen en la construccin de
los diversos artefactos. Dicho marco humano se centra en tres reas de estudio:
organizacin, rea de desarrollo e individuo.
Dentro de la organizacin agrupamos aquellas cuestiones externas al rea de

desarrollo que no son controladas por el mismo.
El lugar de trabajo.
Recursos de tecnologa disponibles.
La cultura de la empresa.
Por rea de desarrollo entendemos la forma en que se relacionan y organizan los

individuos para realizar el desarrollo.
Dentro del anlisis del individuo se encuentran los factores que afectan a un
individuo al momento de desarrollar software. Las personas necesitan tener un
propsito para lo que hacen y esto toma mayor importancia en relacin a su trabajo ya
que ste ocupa en promedio el 35% del tiempo durante el que realizan actividades.
Consecuentemente, se debe fomentar que el individuo est cmodo en su trabajo y que
exista una buena relacin con sus pares. Para esto es de suma importancia que el Lder
de Proyecto monitoree las dinmicas que entran en juego en el grupo as como el
comportamiento de los individuos.
8
Una de las herramientas ms populares para despliegue en la plataforma Java es el ANT. Este es un subproyecto dentro de la
comunidad de Jakarta que brinda una herramienta indispensable para despliegue automatizado de aplicaciones complejas. Ms

La cultura de una empresa se define como el conjunto de ideologas, valores,

metas, que perciben los individuos que conforman la misma. Representa el folclore de
las personas que interactan bajo una misma organizacin. Una de las primeras
cuestiones con las que debe inmiscuirse rpidamente un individuo al comenzar a formar
parte de una empresa es su cultura. Gracias a sta el empleado se ir adaptando,
cambiando sus valores, formulando nuevos juicios y terminar ponindose las mismas
metas que el resto de las personas o abandonar el intento por no sentirse cmodo con la
misma. La cultura de la empresa tiene tanta relevancia como el trabajo en s para el que
fue contratado el empleado.
Para analizar cmo impacta este factor en el desarrollo de software, utilizando

AgEnD como nuestra metodologa, deberemos comenzar por analizar la cultura de la
empresa en que vamos a implementar el proceso. La empresa ideal para el xito de un
proceso gil es aquella que comparte un principio de information sharing versus
information keeping. Entendemos por information sharing la aptitud de las personas
unidas bajo un mismo objetivo de colaborar para que el conocimiento sea transferido de
donde est contenido a donde es requerido. Esta nocin se contrasta con la information
keeping en la que un grupo de personas compite por acumular conocimiento y se
esfuerza en no comunicarlo a quienes lo necesiten.
Estos extremos de una recta representan el grado de madurez de la disciplina de

Administracin de Conocimiento (KM) dentro de la organizacin. Entendemos por KM
al proceso organizacional para retener, organizar, compartir, y actualizar conocimiento
crtico para la performance individual y la competitividad organizacional [Davenport,
1998]. A continuacin expondremos esto en ms detalle.
Calidad en el Proceso
El referirnos a AgEnD como una metodologa gil no quiere decir que el nfasis
puesto en los entregables y la rapidez del desarrollo no tengan en cuenta el problema de
la calidad.
Tomando como marco de referencia al CMM es sabido que la mayora de las

empresas del pas se encuentran en el nivel 1, denominado Inicial. Una de las razones
informacin en http://www.ant.org

por las cuales esto ocurre radica en la falta de un proceso de desarrollo maduro y en la
tendencia inherente en la gente de sistemas de seguir el modelo Codificar y Probar.
Esta tendencia se debera modificar de forma de seguir un proceso relativamente
disciplinado, generando documentacin de anlisis/diseo previamente, haciendo el
testing luego de la codificacin, siguiendo entregas definidas. Sin embargo, al momento
en que el tiempo apremia se dejan de lado todas estas prcticas, desapareciendo el
proceso al punto de volver al caos del que se deseaba escapar.
Una de las razones de este fracaso consiste en la falta de convencimiento pleno

por parte del equipo de desarrollo en el proceso que utilizan diariamente. Mientras los
hitos se vayan cumpliendo siendo las entregas aceptadas por los clientes el equipo se
siente confidente de que su proceso los llevar al xito y que adems lo estn siguiendo
correctamente. Todos comentarn la necesidad de mantener un proceso disciplinado
mostrando las experiencias pasadas como demostracin de los resultados y de los
productos entregados.
Podr llegar el momento en que el proyecto comience a retrasarse en las

entregas, a disminuir la calidad o a remover funcionalidad de las mismas. Ser en estos
momentos en que nacer un sentimiento de desesperacin que comenzar en el
management descendiendo en la jerarqua hasta el equipo de desarrollo. Se pedirn
entregas imposibles, las cuales llevarn a los programadores a codificar en forma
masiva, dejando de lado completamente cualquier viso de proceso, erradicando
completamente la calidad del software construido.
Por estas cuestiones es importante que el proceso se tenga en alta estima y que la
gente est convencida de su utilizacin. En caso contrario, el proceso no cumple su
funcin. Para mantener la salubridad del mismo incluimos en la prxima seccin una
serie de disciplinas que permiten tener siempre un proceso de calidad que se adece a
las necesidades de la gente que lo utiliza.

Enfoque Sistmico
Uno de los motivos principales de desarrollo de esta tesis consiste en una
investigacin extensa en los campos de la psicologa sistmica, la administracin de
empresas y las relaciones laborales; para incorporar el conocimiento de estas reas en el
desarrollo de software.
Ambiente de Desarrollo de Software

Analizaremos el Desarrollo de Software enfocndonos en tres cuestiones que
hacen al ambiente en el que se lleva a cabo un proyecto. Las tres perspectivas en
cuestin refieren a las diversas reas de interaccin entre las personas que estn
afectadas en cualquier grado al desarrollo.
La primera perspectiva refiere a la Cultura Organizacional (CO), en la que

analizaremos como los individuos realizan su trabajo dadas las condiciones externas al
equipo del desarrollo: el resto de la Organizacin, el Cliente con que se trabaja, los
stakeholders del proyecto y todas aquellas interacciones que salgan fuera del alcance de
los desarrolladores.
La segunda perspectiva refiere a la Equipo de Desarrollo (ED), en la cual

analizaremos en detalle cmo los distintos roles establecidos por la posicin de cada
individuo en la empresa influyen en el resultado y la performance de todo el equipo.
Describiremos los tipos de equipos que se pueden plantear, los problemas sistmicos
que pueden acaecer en los mismos, y cmo la situacin particular del desarrollo de
software nos obliga a centrar nuestra atencin en muchos aspectos de las relaciones
entre los participantes.
La tercera y ltima perspectiva planteada es la de la Psicologa de Individuo

(PI), en la cual estudiaremos cmo el individuo internaliza los procesos que entran en
juego al realizar las distintas actividades que abarca el desarrollo. Desde el Modelado
del Negocio hasta la Administracin de la Configuracin cada disciplina requiere
caractersticas propias del individuo as como existentes caractersticas que trascienden
las tareas y que son esenciales para que una persona se pueda embeber en el dinmico
mundo de los proyectos de desarrollo de IS/IT. La intencin es mostrar las aptitudes

necesarias para cada rol, y las distintas formas en que estas contribuyen a que la persona
este satisfecha de su trabajo.
Para encarar este estudio haremos una breve introduccin al cuerpo de

conocimiento que nos provee la Psicologa Sistmica. Esta rama de la Psicologa,
surgida a partir de cuatro pilares surgidos el siglo pasado que dieron el comienzo de la
Ciberntica y la Informtica. Las ideas de Wiener en relacin al feedback, y el
pensamiento circular surgidas a principios del siglo pasado fueron uno de las primeras
influencias de la sistmica. Posteriormente, Turing trajo consigo el trabajo necesario
para atacar la complejidad inherente a cualquier sistema mediante modelos que servan
para reducir dicha complejidad y hacerla comprensible para la mente humana. A partir
de esta teora se comenzaron a atacar los problemas mediante el desglose sistmico en
distintos modelos que reflejaran las partes que se iban a estudiar. Fue Shannon el
encargado de construir la teora de la informacin a partir de la cual se vio la posibilidad
de transmitir cualquier tipo de informacin a travs de un canal de datos. Ese sera el
inicio de lo que actualmente denominamos la globalizacin en materia de
comunicaciones. Por ltimo, Von Neumann trabaj en formas de convertir la
informacin en seales elctricas de manera que las mismas pudieran ser procesadas en
forma automtica. De esta forma, se sentaron las bases para la creacin de las
computadoras que procesaran la informacin que se les cargaba sin requerir de
operatoria manual.
Gracias a estos cuatro marcos tericos se configura la Teora General de

Sistemas, la cual ha cambiado la forma de estudio de todas las ciencias desde las
humansticas hasta las cientficas. En particular, surge una nueva disciplina que es la
Informtica que est relacionada con las actividades que conciernen a los sistemas de
informacin. Es decir, es la consecucin natural de la Teora General de Sistemas y su
aplicacin a todas las actividades humanas en las que existe algn manejo de
informacin.
Es notable el aporte de Roman Jakobson, uno de los creadores de la lingstica

moderna que traslada los postulados de la teora de la informacin de los sistemas a lo
que se denomina la teora de la comunicacin. El modelo planteado por Jakobson, en
que en toda comunicacin existe un Emisor, un Receptor y un mensaje transmitido
sienta las bases para la especificacin de las interacciones entre las personas como un
fenmeno sistmico susceptible de ser analizado. Retornando a la Psicologa, estas

nociones son utilizadas por diversos psiclogos que estudian la teora de la

comunicacin y como sta influye en patologas y en la forma en que los seres humanos
perciben la realidad. Dentro de este contexto surge la denominada ciencia cognitiva que
intenta describir cmo se construye el conocimiento en una organizacin.
En particular para esta tesis, nos interesa el anlisis de lo que la psicologa

sistmica denomina el efecto paradigma. El concepto toma sus ideas de los textos de
Kuhn en relacin a los movimientos de la ciencia, en los que en un momento dado se
reconstruye todo el conocimiento a partir de un nuevo paradigma. Ejemplo de esto lo
tenemos a fines del siglo XIX cuando se realiza el experimento conocido con el nombre
de la catstrofe del ultravioleta que muestra como el paradigma propuesto por la
mecnica clsica no alcanza a explicar las interacciones a niveles subatmicos. Esto
deriva en una revolucin que termina de ser afirmada con la teora cuntica descripta
por Planck y Heisenberg, entre otros, y la relatividad propuesta por Einstein. Sin
embargo, la transicin no fue gradual y requiri de varias dcadas hasta que el nuevo
paradigma tuviera status en la comunidad cientfica.
Existe una analoga de este efecto en relacin a las personas que componen una
organizacin y tiene que ver con la resistencia al cambio. Al momento de implementar
una metodologa la gente posee un cierto conocimiento respecto a sus actividades y la
forma en que se realizan. La idea es que de alguna forma la implementacin debe
cambiar el modo de pensar de las personas modificando el paradigma metodolgico
existente en la organizacin. Diversos estudios muestran que cuando un paradigma
cambia, todo el mundo vuelve a cero; es decir, el conocimiento es reestructurado. Por lo
tanto se debe tener especial cuidado al momento de llevar a cabo este cambio
analizando la posicin de cada individuo y la tolerancia al cambio de la organizacin.
Tom DeMarco nos presenta un continuo que coloca a las personas en una escala
que va de los Lealmente Ciegos hasta los Opuestos Militantemente, pasando en el
medio por los Creyentes pero Escpticos ver Figura 031. Es importante identificar
como es la posicin de los individuos en este espectro de manera de llevar a la
organizacin en un camino de pequeos cambios hasta llegar al nuevo status quo
deseado.

Figure 031. El Continuo de la Resistencia al Cambio. Tomado de [DeMarco, 1999].
Martn Wainstein, titular de ctedra de Teora y Tcnica de la Clnica Sistmica

de la Facultad de Psicologa de la Universidad de Buenos Aires, expone un mecanismo
utilizado para llevar a cabo intervenciones sistmicas dentro de las organizaciones
extensible a grupos de trabajo e individuos. El mismo tiene una sorprendente analoga al
ciclo de mejora de proceso de calidad propuesto por Edward Deming a mediados del
siglo pasado. Basado en el Bucle de Calais, la Figura 032 muestra los pasos existentes:
Establecimiento
de Criterios
Creacin de
Escrutinio y Conciencia
Revisin
Anlisis Lgico
Puesta en
Prctica Generacin y
Evaluacin de
Alternativas
Figura 032. Metodologa de intervencin en organizaciones.
Esta figura identifica los pasos necesarios para un gradual ciclo de mejora de
procesos. Se parte por el establecimiento de criterios en que las partes interesadas
expondrn los problemas existentes que sern motivos de la intervencin. Luego, se
comenzar a crear una conciencia que facilite el cambio, para esto tomaremos el
continuo mencionado anteriormente respecto a la posicin de los individuos respecto al
cambio. A continuacin se efectuar un anlisis de la situacin, entendiendo las causas

detrs de los problemas para poder empezar a plantear soluciones. Se seguir

estableciendo alternativas que permitan dar soluciones a los problemas existentes. En
forma conjunta se debern formular criterios para evaluar si se ha llegado al xito. El
paso crtico consiste en poner en prctica las soluciones generadas. Finalmente, se
evaluar el resultado de la puesta en prctica, haciendo una revisin que sirva para
decidir sobre la continuacin de iteraciones en pos de resolver el problema o si ya el
status quo ha sido cambiado.
Tomaremos este procedimiento para establecer los pasos necesarios para

implementar AgEnD en una organizacin.
Implementacin del Proceso
Calidad
(AP)
Proceso Gente
(AM)
Figura 033. Las tres guas fundamentales de la Implementacin de AgEnD.
Como se observa en la Figura 033, AgEnD agrega al Universo de Procesos

giles un framework para uno de los ms grandes problemas que se presentan al elegir
una nueva metodologa: su implementacin en la organizacin. Segn la filosofa
planteada en el Manifiesto gil, el proceso debe ser adaptado para las personas que
sern usuarias del mismo. AgEnD sugiere dirigir el esfuerzo en tres actividades
principales que son la Adaptacin Metodolgica (AM) que consiste en adaptar las
diferentes partes del proceso a la realidad organizacional, la Adaptacin de las
Personas (AP) que consiste en institucionalizar el proceso en las personas que estn
involucradas en la utilizacin del mismo y, por ltimo, la Evaluacin (EV) que permite

ir midiendo el progreso de la implementacin de forma de poder verificar el resultado.

Para ello, se deber tener especial cuidado de tomar mtricas que permitan medir el
avance en ambas actividades.
El Ciclo de Vida propuesto en la implementacin de la metodologa corresponde

a un proceso iterativo en la que se van desarrollando las tres actividades antes
mencionadas. En el ciclo se tienen iteraciones que desembocan en reuniones de revisin
(que forman parte de las Actividades de la Evaluacin) en las cuales se reporta el status
de la implementacin. En la Figura 034 se puede observar cmo a medida el proyecto
avanza en iteraciones se inician las actividades de adaptacin metodolgica de AgEnD
para que la misma sea acorde al contexto de desarrollo de la organizacin, del proyecto,
y de las personas. Una vez que dicha metodologa comienza a ser adaptada al entorno,
se requiere una capacitacin de las personas para que las mismas entiendan todas las
actividades que deben realizar bajo AgEnD. En forma paralela se desarrollan las
actividades de evaluacin que otorgan el feedback necesario para el control y
management de la implementacin. El responsable primario de estas actividades es el
Coordinador quien deber supervisar y asesorar respecto a la implementacin de
AgEnD.
Actividades
Adaptacin
Metodolgica
Adaptacin de las
Personas
Evaluacin
Iteraciones Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones
Figura 034. Actividades desarrolladas durante la implementacin de AgEnD.
Adaptacin Metodolgica (AM)
La disciplina de Adaptacin Metodolgica consiste en adaptar el proceso tal

cual ha sido expuesto en esta tesis a las necesidades de la empresa. Para esto se tomarn

las distintas partes de la metodologa seleccionada evaluando cules se ajustan a la

realidad organizacional y a su cultura.
Uno de los primeros pasos es relevar las caractersticas de los proyectos que se
realizan en la empresa para determinar las necesidades metodolgicas. En general se
deber tener en cuenta que los procesos giles aplican a realidades organizacionales
particulares. AgEnD como fue mencionado se recomienda en aquellos casos en que se
tienen recursos capacitados con buenos niveles de comunicacin y con proyectos que
pueden ser fragmentados en pequeos grupos de desarrollo (idealmente no ms de 15
personas).
El siguiente paso consiste en capacitarse en la metodologa gil seleccionada; en

el caso de AgEnD la informacin brindada por esta tesis y diversos papers presentados
en distintas jornadas servir de gua para el Coordinador. Una vez que se ha ledo el
material y que el Coordinador posee el know how necesario, el primer paso ser el de
adaptar la metodologa a la realidad organizacional existente. El Coordinador decidir
qu roles, artefactos, y prcticas sern utilizados y planificar un proyecto piloto en
donde se los pondr a prueba. Este proyecto ser elegido del conjunto de proyectos
reales planteados en el negocio de forma que se pueda evaluar la aplicacin de AgEnD
sobre casos concretos.
Adaptacin de las Personas (AP)

Para analizar cmo las personas interactan dentro de una organizacin y lograr
la institucionalizacin del proceso, AgEnD particiona el anlisis de esta disciplina en
tres perspectivas. La primera de ellas, es la perspectiva organizacional o ambiental que
describe la cultura organizacional y los objetivos al adoptar una metodologa gil. La
segunda perspectiva, la perspectiva del equipo de desarrollo, describe como los
miembros del equipo interactan entre s y con el ambiente que lo rodea. Por ltimo, la
perspectiva del individuo est relacionada con la psicologa y la personalidad de cada
individuo y como esto toma relevancia al momento de seleccionar el rol adecuado segn
el perfil.
Las disciplinas de AP y AM presentan el workflow mostrado en la Figura 035

para el anlisis de la organizacin al momento de la implementacin. En dicha figura se
detalla como las dos actividades principales de la Implementacin de AgEnD ocurren

en paralelo y en forma iterativa, hasta que todos los cambios planificados han sido
ejecutados y existe concurrencia respecto al xito de la adopcin de la metodologa.
Figura 035. Diagrama de Actividad de la implementacin de AgEnD.
A continuacin dividiremos el anlisis en los tres factores que se muestran el la

Figura 035: Organizacin, rea de Desarrollo, Individuo.

La Organizacin
Una organizacin puede ser observada como un sistema abierto. Existen inputs,
un proceso de transformacin que genera outputs, y un ciclo de feedback que ayuda a
controla que los outputs sean los esperados para poder tomar acciones correctivas. Sin
embargo, pensar que este modelo alcanza para describir las actividades fundamentales
de una organizacin es errneo ya que la organizacin reviste un comportamiento
dinmico resultante de una multiplicidad de factores que confluyen para conformar la
identidad organizacional los cuales no pueden ser tomados linealmente sobre esto se
podr consultar [Etkin, 1989].
En el inicio de la implementacin de AgEnD se efecta un relevamiento del
status organizacional. Para esto se debern identificar aquellos stakeholders claves para
que el proceso de implementacin resulte exitoso. En la Tabla 001 se describen aquellos
stakeholders que resultan importantes incluir al momento de llevar a cabo el
relevamiento.
Stakeholder Influencia
Sponsor Ejecutivo Persona responsable de obtener el soporte ejecutivo necesario

para el xito de la implementacin de una metodologa gil
Gerente de Sistemas Persona a cargo del rea de sistemas que administra el sector
Project Manager Persona/s a cargo que coordinan los proyectos de desarrollo
Lder de QA Persona a cargo del rea de QA (Quality Assurance) en la

organizacin
Coordinador Persona a cargo de la implementacin de la metodologa en la

organizacin
Tabla 001. Stakeholders involucrados en el proceso de implementacin de AgEnD.
El mismo ser realizado mediante la realizacin de un Workshop de Status

Organizacional (WSO) en el cual se contar con la participacin de los stakeholders que
tendrn la mayor influencia en la implementacin de AgEnD. El objetivo de este
workshop es el de poder formalizar ciertos aspectos que darn comienzo al proceso de

implementacin y de lograr concurrencia en relacin a los objetivos organizacionales de

mejora del proceso. Como resultado el mismo debera dar:
Especificacin de los objetivos organizacionales de la implementacin
Especificacin de cmo el proceso influenciar a sus usuarios y dems

stakeholders
Status del proceso actual y las principales razones que influyeron en el

cambio
Asesoramiento de la cultura organizacional para poder planificar

cualquier intervencin para que las personas adapten su forma de trabajo
El workshop permite entender cmo la organizacin manejar la adopcin de un

nuevo proceso de desarrollo de software de forma exitosa. En el caso de AgEnD, o de
cualquier otra metodologa gil a ser implementada en una organizacin, es importante
considerar que se requiere una cultura abierta en la que se fomente la comunicacin e
interaccin de los individuos (tema a ser tratado en las etapas de AP). El resultado de
este workshop ser plasmado en algn medio de informacin de la empresa para que las
personas involucradas puedan conocer el avance en la implementacin.
Segn los estudios de otros investigadores citados por Jim Highmith [Highsmith,
2002] en relacin a la implementacin de metodologas giles, existen cuatro tipos
bsicos de culturas organizacionales; cada una est caracterizada por una motivacin
que permite que la misma se mantenga en forma invariable. Las cuatro culturas son: la
cultura de competencia, la cultura de colaboracin, la cultura de control y la cultura de
cultivo.
La cultura de competencia enfatiza la capacidad de los individuos, su

responsabilidad y su conocimiento. De alguna forma los niveles jerrquicos son dados
por aquellas personas que ms conocimiento tienen. En stas los ttulos son algo
secundario y las cuestiones polticas quedan de lado.
La cultura de colaboracin se da cuando se tienen equipos multidisciplinarios. El

liderazgo se establece en relacin al rol en vez del ttulo en s. Generan una importante
cantidad de innovacin dando una gran relevancia a la formacin de equipos internos
para las distintas reas.

La cultura de control est basada en el poder y las grandes jerarquas. En las

mismas se tienen mecanismos polticos muy fuertes lo que las hace a veces bastante
burocrticas. Sin embargo, dado su tamao, se mantienen en el mercado por largo
tiempo. La prioridad en ellas es la planificacin de las tareas, y el seguimiento y control
de las actividades realizadas por todos los recursos.
La cultura de cultivo es similar a la cultura de colaboracin con la diferencia que

se prioriza a los individuos por sobre los equipos. Idealmente tienen su nicho en
aquellas empresas que realizan productos nuevos o grandes innovaciones. En general
son auto-organizativas y carecen de formalismos en cuanto estructura, procesos o
documentacin.
Analizando estas nociones se identifica a AgEnD como una metodologa que

tendr mayores xitos si es implementada en culturas de competencia y de colaboracin.
Las razones de esto tienen que ver con que ambas priorizan a la gente por sobre los
procesos y los rigurosos controles sin por eso caer en el caos o la auto-organizacin de
las personas (algo que s ocurre en la cultura de cultivo). Si en el workshop antes
mencionado se resuelve que la cultura de la empresa tiene similitud con alguna de estas
dos, las probabilidades de una implementacin de exitosa AgEnD dentro de la
organizacin sern altas.
La cultura de control requiere niveles metodolgicos de mayor peso (lo que a

veces puede caer en una extremada burocracia) que le permitan mantener las jerarquas
de poder y la planificacin continua de los proyectos. Por estas razones y por poner el
nfasis en la estructura y la organizacin por sobre las personas, las metodologas giles
no sern una buena opcin. En estos casos se podrn realizar proyectos pilotos de
implementacin de AgEnD pero la metodologa en cuestin rara vez ser
institucionalizada.
Finalmente, como ya fue mencionado la cultura de cultivo rechaza en cierta

forma cualquier tipo de organizacin ms la propia generada por las personas. Adems
mantiene a los individuos y su continuo deseo de hacer lo que ms les interese, por
encima de la colaboracin de grupos de trabajo. Esto hace que el peso inherente a
cualquier metodologa (inclusive AgEnD) sea intolerable y probablemente al poco
tiempo la iniciativa sea dejada de lado.

Si se intenta algn tipo de cambio organizacional ya que la cultura resulta

inadecuada para los objetivos de la empresa, el mismo deber ser realizado
cuidadosamente, teniendo en cuenta la resistencia al cambio mencionada anteriormente.
Como ya fue explicado existen mtodos de intervencin organizacional que pueden
ayudar durante la mejora de proceso [Wainstein, 2000].
El rea de Desarrollo
Sin duda alguna el rea que estar sometida a la mayor influencia ser el rea de
Desarrollo. Aqu se encontrarn los usuarios finales del proceso que sern los que
participarn en la customizacin del mismo. Para ejecutar la implementacin se
evaluar primero el enfoque de la Adaptacin Metodolgica en que cada disciplina,
artefacto y actividad de AgEnD ser contrastada con la forma de trabajo de las personas
para poder elegir la mejor manera en que ests ltimas podrn absorber el proceso.
Teniendo en cuenta las diferentes reas de conocimiento de la Ingeniera de

Software, propuestas en el SWEBOK [SWEBOK, 2002], identificaremos los roles de
cada individuo en relacin a las mismas. Las reas en cuestin son: Requerimientos de
Software (SR), Diseo de Software (SD), Construccin de Software (SC), Testing de
Software (ST), Mantenimiento de Software (SM), Administracin de la Configuracin
del Software (SCM), Administracin de Ingeniera de Software (SEM), Proceso de
Ingeniera de Software (SEP), Mtodos y Herramientas de Ingeniera de Software
(SETM), Calidad de Software (SQ).
Cada una de estas reas puede estar o no contemplada dentro de la organizacin

y ser realizada por uno o ms roles. La realidad del mercado informtico en consultoras
de tamao modesto en la Argentina indica que es comn que la estructura est formada
por un grupo importante de personas en el rea de SD/SC, un pequeo grupo de
personas en SR/ST, grupos de personas dispersas en SM, y un mnimo nmero, o
ninguno en algunos casos, de personas abocadas a SEP/SETM/SQ. Es decir, aquellas
actividades cuyo ROI es ms inmediato concentran la mayor cantidad de recursos en
detrimento de aquellas actividades cuyos beneficios solo son visibles a largo plazo, que
tienden a contar con poco personal.

A consecuencia de esta realidad planteada se deber incluir al menos un recurso

responsable de la implementacin del proceso. Como sugiere AgEnD esta persona
tendr el rol de Coordinador y supervisar el proceso velando por que el mismo sea
implementado correctamente pudiendo customizarlo de acuerdo a las necesidades de
sus usuarios.
Regresando a las reas de conocimiento de la Ingeniera de Software antes

mencionadas no todas demandan el mismo grado de Adaptacin Metodolgica. Dicho
grado estar dado principalmente por los requerimientos comunicacionales y el nivel de
predictibilidad de los roles asociados a dicha rea de conocimiento. Como se observa en
la Figura 036, a medida que abarcamos reas ms predecibles las tareas de
customizacin dadas por la AM disminuyen. Por ejemplo, las actividades relacionadas
con SCM suelen estar ms estandarizadas y presentan una menor variabilidad; esto se
traduce en un esfuerzo menor al momento de adoptar las prcticas. Especialmente esto
es cierto en aquellas rea de conocimiento que han logrado una importante
automatizacin por sobre aquellas que todava son realizadas de manera ms
artesanal.
Customizacion
del Proceso
Predictibilidad
Figure 036. Customization vs. Predictibilidad del Rol.
La Figura 036 manifiesta la necesidad de customizar aquellas reas que poseen

una mayor preponderancia del factor humano y las cuales se encuentran en un escaln
de madurez ms bajo dentro de nuestra ingeniera. El Coordinador comenzar mediante
el anlisis de cmo cada rea de conocimiento ser implementada dentro del rea de
desarrollo de la organizacin. Ser relevante presentar las tcnicas que puede utilizar el

Coordinador para las actividades de Adaptacin de las Personas. Alistair Cockburn

[Cockburn, 2001a], quien estudi el desempeo de los grupos de desarrollo de software,
sugiere cuatro herramientas sencillas que pueden lograr que las personas que participan
del desarrollo se alien para entender los beneficios de la mejora de proceso. stas
consisten en darle a la gente:
Informacin adicional respecto de los objetivos de los proyectos
Informacin adicional acerca del efecto de sus acciones, para que

identifiquen aquellas acciones que van en contra de los objetivos
Una mejor razn para que empujen en la direccin deseada
Como se observa, muchas de estas cuestiones parten del sentido comn pero
pueden servir para que un equipo de desarrollo que presenta cierta resistencia a AgEnD
comience a alinear sus esfuerzos hacia la implementacin de las prcticas y la
articulacin de los principios. Podemos mencionar que la disciplina de Administracin
de Proyecto dentro de AgEnD debe aportar toda la informacin necesaria para que el
equipo sepa hacia dnde dirigir sus esfuerzos.
El Individuo
El desarrollo de software es una actividad humano-intensiva. Dada la

complejidad inherente al software las personas se ven obligadas a trabajar en forma
grupal interactuando con sus pares. En estas interacciones que ocurren a diario en las
organizaciones se juegan juegos de poder. Estos determinan el comportamiento de las
personas las cuales ejercen su autoridad y son sujetas a las autoridades de otros.
Si recurrimos al Modelo Motivacional de la Figura 037 propuesto por Harold

Leavitt, observamos que las personas estn continuamente buscando el equilibrio
interno; cuando algo desafa este estado de equilibrio, existe un sentimiento de
frustracin que genera alguna accin en la persona y que hace que esta cambie buscando
un nuevo estado de satisfaccin. De hecho, este ciclo contina en todos los mbitos de
la vida humana durante la existencia del individuo y es de utilidad entenderlo ya que la
satisfaccin/motivacin de las personas en su trabajo determinar ulteriormente el
resultado de la implementacin de un proceso gil de software.

Equilibrio
Interno
Estmulo
Necesidad
Tensin
Accin
Satisfaccin
Figure 037. Modelo Motivacional para una persona.
Desde un punto de management, acorde a las palabras de Tom Peters, una de las
consideraciones principales que tendrn las empresas del maana ser que su valor de
mercado estar dado por los bienes intangibles que esta posee (a diferencia de la visin
tradicional en que se valoran principalmente los tangibles). Los bienes intangibles estn
dados por el intelecto e imaginacin de las personas denominadas knowledge workers
bajo este esquema.
Como ya fue descrito el proceso plantea ciertos principios, prcticas y patrones

que conviene sean utilizados para lograr la satisfaccin continua de la gente que lleva a
cabo la construccin del software. La satisfaccin de cada uno de los individuos
contribuir a la motivacin del equipo y ayudar en la implementacin del proceso.
Dentro del espectro de comportamientos humanos, una metodologa tiene dos

opciones para lidiar con la diversidad de personalidades: ser tolerante a la
individualidad o ser estricta y disciplinada para lograr comportamientos determinados.
Dado que cada individuo es nico y posee una personalidad que lo caracteriza, AgEnD
plantea un marco de implementacin tolerante a la diversidad de personalidades y
formas de trabajo de los individuos. Para que la tolerancia de la metodologa tenga xito
y la construccin del software no sea algo catico se requieren ambientes de
colaboracin, con buenas relaciones interpersonales, y un cierto grado de empata por
hacer el trabajo y ayudar a otros a que lo hagan. En general podemos decir que a veces
la disciplina resulta conveniente y aunque sea difcil de lograr puede resultar ms

eficiente. La tolerancia puede resultar ms fcil de adoptar pero quizs sea menos
productiva.

Aportes de AgEnD al Espectro

Metodolgico
A continuacin se expondrn cuales son los aportes que realiza AgEnD al
universo de las metodologas giles, en base a un anlisis exhaustivo de los procesos
existentes y de la identificacin de aquellos aportes que hacen de AgEnD un proceso
gil nico.
Nomenclatura Estandarizada
Una de las primeras facilidades que una persona se encuentra al aprender
AgEnD es el uso de nombres estandarizados para todos sus elementos. Muchos de los
nombres utilizados han sido tomados del RUP [RUP, 2002] que sirve como base de
conocimiento para procesos de desarrollo. Tambin existieron fuertes influencias del
SWEBOK [SWEBOK, 2001] que comprende el cuerpo de conocimiento de la
ingeniera de software y que es fiel esperanza del autor que dicho proyecto siente las
bases hacia una profesionalizacin de nuestra disciplina.
Gracias a esta estandarizacin, AgEnD contribuye a un global entendimiento de

los conceptos involucrados lo cual habilita una comunicacin ms fluida entre las
personas involucradas.
Administracin de Proceso
AgEnD propone distintos patrones enmarcados en una disciplina que pueden ser
utilizados para customizar el proceso en distintas etapas. Los patrones sirven para que
AgEnD pueda ser implementado exitosamente y para adaptar el mismo a las
necesidades particulares del proyecto. Esto logra captar el feedback de la gente que es
usuaria del proceso y dinmicamente modificarlo para que cumpla mejor sus objetivos.
AgEnD propone distintos patrones enmarcados en una disciplina que pueden ser
utilizados para manejar mejor el factor humano dentro del desarrollo. Los patrones
ayudan a mejorar el ambiente de trabajo de los individuos, mejorar la motivacin de los

grupos de trabajo y mitigar las fricciones que puedan existir. El resultado ser una
adopcin rpida y eficaz de AgEnD, tolerante a la diversidad de personalidades
existentes.

AgEnD explcitamente establece una disciplina de Administracin del
Conocimiento que contribuye al aprendizaje organizacional. La misma establece una
serie de prcticas giles que ayudan a que el conocimiento novedoso generado durante
un proyecto sea capturado para una posterior recuperacin. El objetivo es que el
conocimiento se disemine por los grupos de trabajo y que se vaya aprendiendo de la
experiencia para el mejoramiento de las personas y la agilizacin del proceso.
Procedimiento para la Implementacin

Existe una frase en el terreno de la Ingeniera de Software que dice: Lo difcil
no es definir una metodologa, sino implementarla en la organizacin. Dada esta
realidad, AgEnD plantea una serie de consideraciones, surgidas a partir de las
experiencias de otras reas de conocimiento, que contribuyen a su implementacin en
un grupo humano.
Prcticas Probadas por la Experiencia

Las prcticas propuestos por AgEnD no son invenciones del autor ni conceptos
tericos ultra novedosos. Son prcticas que han sido probadas durante suficiente tiempo
como para concederles un status de best practices. Las mismas han sido estudiadas en
libros mencionados en la bibliografa y se reconoce su valor agregado para mejorar el
proceso de construccin de software.
En especial, AgEnD rene un conjunto de prcticas que considera adecuadas a la

aplicabilidad de la metodologa y que ha sido demostrada por la experiencia propia del
autor en diversos proyectos (ver ms informacin en el captulo de Resultados
Experimentales).

Templates de Artefactos
AgEnD ofrece una serie de templates (ver Apndice A) que ayudarn al
Coordinador que lleve a cabo la implementacin a elaborar los artefactos sugeridos.
Estos han sido utilizados en distintos proyectos y plasman de una manera concisa la
informacin que se desea transmitir. La idea de los mismos es adaptarlos de acuerdo a
la realidad de los proyectos manejados por la organizacin.
Baja Curva de Aprendizaje

AgEnD est pensado para ser utilizada tal cual establece esta tesis. No es
necesario poseer conocimiento avanzados en conceptos tericos ni disponer de una
estructura organizacional dedicada exclusivamente a la implementacin del proceso.
Las prcticas han sido elegidas entre otras cosas por adaptarse a la forma de trabajo de
la gente ayudando a resaltar aquellos elementos que hacen a una metodologa gil.
Asimismo las prcticas resultan sencillas de transmitir y de implementar para

toda persona que conozca las ideas detrs de los procesos de desarrollos iterativos e
incrementales.

Capitulo IV - Resultados Experimentales de

las Prcticas de AgEnD
A continuacin se describirn dos experiencias de desarrollo en las que se utiliz

AgEnD como metodologa. En ambas el autor form parte del equipo de desarrollo
teniendo a su cargo el anlisis de la realidad organizacional previa, la adaptacin inicial
de la metodologa, la capacitacin a las personas, y la customizacin dinmica en
intervalos regulares que permitiera adecuar AgEnD al proyecto en cuestin.
Las experiencias muestran como AgEnD contribuy a que los proyectos lleguen
a su concrecin exitosamente sin por eso restar importancia a los equipos de trabajo
que son el factor ms importante del desarrollo. Describiremos cada proyecto con un
nombre clave por cuestiones de confidencialidad. Se ese dar un nombre de fantasa a
cada proyecto, el primero ser FIDoNET y el segundo ser CONEST.

Experimentacin de Prcticas utilizando AgEnD

Primer Ejemplo: Aplicacin en FIDoNET
A continuacin, veremos como las diversas prcticas recomendadas por AgEnD

han sido probadas experimentalmente tanto por el autor de esta tesis como por diversas
personas que han diseado reconocidas Metodologas giles.
Plantearemos la experiencia de un proyecto que es encarado por una empresa

que presta servicios a ONGs, la cual es llamada FIDoNET9 que realiza desarrollos a
medida para clientes de gran envergadura. FIDoNET ha decidido crear un sistema para
la administracin de las actividades que posee un ONG y la interaccin con sus
usuarios. Dicho sistema ser utilizado en distintos pases de Latinoamrica en que
FIDoNET tiene contactos y clientes, por lo que deber ser multilenguaje.
Background del Proyecto
El proyecto en cuestin tiene como objetivo construir una herramienta que

brinde servicios a las ONG y a las personas que pertenecen a estas. El proyecto es
conocido internamente como FIDoNET y el lema que impulsa al sistema es el siguiente:
Construyamos relaciones solidarias donde los deseos y las actividades en

comn se constituyan en la sociedad mediante una herramienta humanista, que
se adecue a las singularidades.
FIDoNET ha decidido utilizar un equipo de desarrollo que inicialmente ser de 4

personas, y posteriormente en la construccin crecer a unas 5 personas. El proyecto
ser conducido utilizando AgEnD como proceso, siendo este proyecto la prueba piloto
de la implementacin y utilizacin de la misma. Este es el primer proyecto de gran
envergadura en que la empresa utilizar esta metodologa. Inicialmente, AgEnD ser
utilizado en forma completa sin realizarse ninguna modificacin; a medida se avance en
las iteraciones se irn realizando reuniones de post mortem para configurarlo acorde a
las necesidades del equipo de desarrollo. Todo el equipo detrs del emprendimiento de
9
Por cuestiones de confidencialidad se dar un nombre de fantasa de la empresa.

FIDoNET est comprometido a utilizar AgEnD en todas sus fases pudiendo adaptarlo a
medida se avanza en el desarrollo mediante la intervencin del Coordinador.
Inicialmente los stakeholders del proyecto forman un grupo de considerable

diversidad. En el mismo incluimos a ONGs, Empresas asociadas con FIDoNET,
Instituciones, Usuarios individuales y recursos de FIDoNET. El gran porcentaje de
comunicacin en el desarrollo ser realizado con dos usuarios expertos de la propia
empresa los cuales conocen el sistema a construir en detalle. Ellos recibirn pedidos de
los dems stakeholders y los canalizarn en el proyecto al fin de cada iteracin.
Roles y Recursos
Los roles de AgEnD estn llevados a cabo por distintas personas del proyecto. A
continuacin mencionamos a los trabajadores que participaron en la primera versin del
proyecto:
Existan dos Usuarios Expertos, quienes estuvieron en contacto con las

ONGs siendo el input funcional para el Equipo de Desarrollo. A lo largo
de este captulo nos referimos a estos como el Cliente.
Resea: Los Usuarios Expertos conformaban un do cohesivo que posee

caractersticas que los hicieron ideales para dichos roles. Eran personas
accesibles, informales, flexibles y tolerantes. No trataban de imponer sus
decisiones sino que permitan espacios de discusin en cualquier mbito.
Tenan muchos contactos en la comunidad de ONGs de la Argentina.
Exista un Patrocinante o Sponsor que vel por mantener el proyecto en

su rumbo, eliminando obstculos que estuviesen fuera del alcance del
Equipo de Desarrollo.
Resea: El Sponsor fue la persona que guo el emprendimiento

FIDoNET. Sus aptitudes eran las de ser un muy buen negociador, poseer
contactos con diversas reas del medio, entender el proyecto en forma
ntegra. Era el encargado de verificar el progreso de las distintas reas y
de financiar el proyecto.

Exista un Lder de Proyecto que cumpli tambin funciones de

Coordinador de Proceso y de Administrador de Conocimiento.
Resea: El Lder de Proyecto fue la persona encargada de gestionar el

proyecto. Asimismo era entusiasta de las metodologas giles,
proponiendo la utilizacin de AgEnD como proceso de desarrollo del
proyecto.
Exista un Analista que tambin cumpli funciones de Tester.
Resea: El Analista era una persona con mucha habilidad y experiencia

en las cuestiones humanas, el trato con el cliente, tcnicas de
relevamiento y especificacin de requerimientos. La tcnica de Casos de
Uso fue relativamente nueva para esta persona por lo se requiri alguna
capacitacin.
Exista un Arquitecto que tambin cumpli funciones de Desarrollador.
Resea: El Arquitecto era una persona con mucha habilidad y

experiencia en las cuestiones tcnicas del desarrollo. Llevaba aos
trabajando en tecnologas Java y trabaj como arquitecto en proyectos de
gran escala.
Existan dos Desarrolladores que posean distintos grados de experiencia

en las tecnologas del proyecto.
Resea: Los dos tenan cargo de Programador Senior y conocan a fondo

la tecnologa seleccionada. Conocann la Plataforma Java 2 en forma
terica y prctica ya que poseen abundante experiencia laboral.
Tecnologas
Dadas los objetivos globales de FIDoNET como organizacin de crear unin

entre personas fomentando la solidaridad, se prioriz al momento de seleccin de
tecnologas aquellas que respondan al modelo de desarrollo Open Source y que puedan
usar libremente sin costos de licencias asociados. Conjuntamente, otro de los factores a

tener en cuenta en la seleccin es la madurez de la herramienta/tecnologa/framework en

la industria, descartndose aquellas que estuvieran en sus fases iniciales de desarrollo.
Arquitectura de la Aplicacin
Arquitectura Web: presenta la interfase al usuario mediante un navegador de

internet pudiendo desacoplar las capas de interfase/lgica de negocio/datos en el
servidor mediante frameworks disponibles.
La arquitectura de la aplicacin para prestar servicios web estuvo compuesta por

las siguientes capas (tiers):
Capa de Presentacin: pginas web servidas mediante un framework de

MVC que desacopla esta capa de las capas de lgica del negocio y manejo de
datos. Asimismo, se tuvo especial nfasis en utilizar un medio que permita que
se muestre esta capa en distintos dispositivos (Ej.: PDA, celulares, tablet-pc,
sistemas embebidos, etc.) sin tener que hacer cambios importantes a la
aplicacin.
Capa de Lgica del Negocio: inicialmente, se pens en un esquema

sencillo de lgica del negocio que simplemente recibe/enva la informacin a la
capa de presentacin, mediante la interaccin directa con la capa de manejo de
datos. Se plante un esquema de componentes que resuelvan los pedidos
realizados sin necesidad de utilizar un application server. Sin embargo, si en
algn momento se vea la necesidad de que la aplicacin escale y que se pueda
adaptar a requerimientos no funcionales ms fcilmente, se vera la utilizacin
de un application server el cual resuelva cuestiones como persistencia,
seguridad, manejo de transacciones, logging, etc.
Capa de Manejo de Datos: para esto se utiliz un motor de base de datos

relacional. El mismo es accedido mediante un esquema de persistencia que hace
transparente para la aplicacin el mapeo objetos-relacional (ORM). Para ello, se
analizaron diversos frameworks que resuelven estas cuestiones.

Presentacin Lgica Datos
<HTML>
<BODY>
...
</BODY>
</HTML>
Web Server Application RDBMS

Server
Figura 037. Diagrama de nodos fsicos de la aplicacin web de FIDoNET
Plataforma Base y Herramientas
Linux: inicialmente se plantea la utilizacin de este SO como servidor que

contenga la lgica del negocio y el motor de BD
Microsoft Windows: SO utilizado en las mquinas de desarrollo
Apache Tomcat: Web Container
CVS: Sistema de Administracin de la Configuracin
Eclipse: IDE de Desarrollo
Macromedia Dreamweaver: Herramienta de diseo de pginas web
Motores de BD
MySQL: uno de los motores Open Source ms populares, MySQL es utilizado en

la mayora de los sitios web del mundo en forma conjunta con el lenguaje de
scripting PHP. El motor es muy robusto y si bien no posee toda la funcionalidad
de un motor como Oracle, es una opcin ms que interesante por la rapidez y
sencillez del mismo.

Framework de MVC
Jakarta Struts: framework utilizado para la capa de presentacin de la

aplicacin. El mismo se utiliza para armar el patrn MVC pudiendo desacoplar
la presentacin de la lgica del negocio.
En particular, Struts utiliza JSP para enviar la pgina al cliente que efecta el
request (View Component). En el mismo se podrn usar tags propios de la
librera de Struts que permiten minimizar el cdigo que se escribe en el JSP.
Struts ha madurado y es utilizado en todo el mundo. La comunidad de usuario de

Struts crece a un ritmo considerable. Existen muchas aplicaciones
complementarias disponibles para usar con el framework y muchos
desarrolladores haciendo contribuciones al mismo.
Object Relational Mapping (ORM)
Torque Apache DB Project: framework que se utiliza para realizar la capa de

persistencia de la aplicacin. El mismo provee una forma de acceder al motor de
RDBMS sin necesidad de escribir cdigo SQL dentro de la aplicacin.
De esta forma permite abstraer la persistencia facilitando el mantenimiento del

cdigo ante cambios en la representacin de los datos o en la tecnologa de BD
utilizada.
El mismo es utilizado ampliamente por la comunidad Open Source, y ha

madurado hasta consolidarse como un importante y estable framework que
actualmente se encuentra en su versin 3.0.2.
Lanzamiento del Proyecto
FIDoNET comienza el proyecto en la fase denominada Factibilidad, durante la

cual se genera un modelado del negocio sobre el cual ser construido el sistema. El
propsito es entender toda la problemtica que tienen las ONGs en la Argentina para

poder acotar el campo de funcionalidad que ser incluido en la aplicacin. Esta funcin
es llevada a cabo por las personas Responsables del Negocio que conocen en
profundidad a los stakeholders del futuro sistema y los servicios que sern provistos a
estos. Durante un perodo de 4 meses estas personas mantienen reuniones peridicas en
las que se identifican aquellas ONGs que servirn como referentes al momento de
relevar necesidades.
Se planifican las fases en que el proyecto de FIDoNET ser dividido tomando

como referencia las fases de AgEnD. Se realiza una estimacin inicial de muy alta
granularidad para que los stakeholders vayan teniendo visibilidad y tambin para
asegurar la viabilidad econmica del proyecto.
Resultados del Proyecto
Despus de seis meses de desarrollo el proyecto llega a un hito importante, la

entrega del release 1.0 que concluye la puesta en prctica de AgEnD. El mismo ha
terminado en forma satisfactoria para las partes involucradas. Se han implementado
todas las prcticas recomendadas por AgEnD y se realiz una reunin de Cierre de esta
primer etapa para relevar y analizar el proyecto y la metodologa. A continuacin se
comentan aspectos de la metodologa que contribuyeron al xito del proyecto.
Configuracin del Proceso
AgEnD recomienda ir customizando la metodologa de acuerdo a las

necesidades del proyecto y de las personas. Se llevaron a cabo varias reuniones de
revisin de la metodologa en la que se fueron ajustando diversos aspectos de la misma
segn se vea la forma de trabajo de la gente y la naturaleza del proyecto.
En el proyecto de FIDoNET una de las primeras cuestiones que se observ era

que los Casos de Prueba insuman mucho trabajo para el Tester el cual en general tena
que estar bastante tiempo realizndolos. Este opt por anotar en una planilla de clculo
un breve mensaje dejando registrado el nombre del caso de prueba y por cada fila el
resultado de la ejecucin en una versin dada de la aplicacin. Esto aceler sus tareas
sin degradar el testing efectuado.

Algo similar ocurri con los Casos de Uso que inicialmente fueron basados en el
template de [RUP, 2002]. Los mismos eran especificados por el Analista en conjunto
con los Usuarios Expertos. Durante las primeras iteraciones se observ que los
Desarrolladores los lean por arriba y hacan las preguntas directamente a los Usuarios
Expertos quienes hacan un breve repaso por el flujo de interacciones. A partir de ese
momento se decidi especificar el comportamiento en casos de uso mucho ms
informales que permitieran que los Desarrolladores tuvieran un idea de lo que tenan
que implementar pudiendo profundizar con la comunicacin cara a cara con los
Usuarios Expertos. Finalmente, los casos de uso terminaron siendo bastante parecidos a
las User Stories planteadas por XP [Jeffries, 2001].
Tomando el concepto del Scrum Daily Meeting sugerido por Scrum [Schwaber,
2001], se decidi agregar dentro de la disciplina de Administracin de Proyecto de
AgEnD esta reunin diaria de quince minutos a primera hora de la maana con el
equipo de desarrollo. La misma era coordinada por el Lder de Proyecto quien
preguntaba a cada persona del equipo qu haba hecho de la durante el da anterior, que
iba a hacer durante ese da y que obstculos tena para llevar a cabo sus actividades. En
la reunin poda participar el Cliente pero solo como observador. Esto permiti ir
teniendo un control y monitoreo constante sobre el progreso y los riesgos que se iban
dando.
En relacin a los artefactos sugeridos por AgEnD se dejaron de lado la Lista de

Riesgos ya que con la reunin diaria del Lder con el equipo el control y monitoreo de
los mismos era on-line. Tambin no se vio la necesidad de generar Notas de Entrega ya
que el equipo de desarrollo era parte del Cliente y exista plena confianza e
involucramiento de este ltimo en el proyecto.
Dentro del contexto de un proceso moderno de desarrollo es indispensable

contar con una herramienta que automatice todas las tareas relacionadas con los tems
de configuracin generados durante un proyecto. Para esto se seleccion la herramienta
CVS (Concurrent Versions System) que permite llevar esta tarea a cabo.
De acuerdo a lo recomendado por AgEnD todos los artefactos generados durante

un proyecto sern puestos bajo control de versiones. Para comodidad del equipo de

desarrollo se decidi tener dos mdulos independientes dentro de un mismo repositorio.

El repositorio tena el nombre del proyecto y existan dos mdulos: uno denominado
Project y otro Sources. El primer mdulo inclua toda la documentacin asociada a las
distintas disciplinas de AgEnD categorizadas en directorios con el nombre de la
disciplina. El segundo mdulo tena todo el cdigo de la aplicacin a ser cargado en la
IDE utilizada el Eclipse.
Esta disciplina permiti que en un momento determinado se pudieran probar

ciertas implementaciones de casos de uso utilizando un branch separado manteniendo
consistente la rama de desarrollo principal en la que se iban liberando releases al
Cliente.
Mxima Comunicacin
Una de las prcticas que fue aplicada con mayor xito en el proyecto fue la de
Mxima Comunicacin. Todas las personas involucradas en el proyecto (tanto de parte
de los usuarios expertos como el equipo de desarrollo) estaban en un mismo piso de un
edificio en oficinas adyacentes. Esto permita que cualquier duda planteada por
cualquier parte se resolviera mediante la rpida consulta con el miembro que tena el
conocimiento. Esta es una prctica esencial en AgEnD que es prerrequisito de su
implementacin. Alistair Cockburn [Cockburn, 2001a] identifica como las corrientes
comunicacionales mejoran la transferencia de conocimiento y son una de las causas por
las cuales se pueden minimizar el overhead metodolgico. Esto fue tratado ampliamente
en el captulo anterior.
En caso que esta prctica no se hubiera implementado no se podra haber

implementado una metodologa como AgEnD ya que el grado de ceremonia de esta no
es conforme a ambientes en donde se debe suplir la carencia de comunicacin mediante
comunicacin. Para esto se recomienda usar alguna metodologa como el Unified
Process.
Participacin Activa del Cliente
De acuerdo a la prctica de Mxima Comunicacin el Cliente estuvo

involucrado durante todo el proyecto. El mismo participaba en las reuniones diarias de

avance solo como observador y en las reuniones semanales de revisin para validar el
contenido de lo que se construy.
El Cliente junto con el Analista tena a su cargo la especificacin de los casos de

uso. Al final la aplicacin contaba con 42 casos organizados en distintos mdulos que
mapeaban con el formato de la interfase grfica. Otra de las prcticas importantes que se
utiliz en relacin al Cliente fue un Control de Cambios formal. Para esto el Cliente
dejaba en el Gantt del Proyecto distintos pedidos de cambio. Cada uno de estos era
evaluado por el Lder de Proyecto y por el Arquitecto quienes discutan el impacto del
cambio y el costo en recursos/tiempo del mismo. Las posibilidades eran hacer el cambio
en la prxima iteracin, dejarlo para la prxima versin del sistema o desecharlo
completamente. Esto funcionaba como escudo para los Desarrolladores quienes de otra
forma hubieran tenido que estar continuamente cambiando el cdigo que desarrollaban
dado el ambiente de alta volatilidad existente.
Estimaciones giles
Esta prctica fue utilizada frecuentemente al principio del proyecto y luego

continuadamente en cada iteracin. Durante la primera fase se tomaron los features del
documento de Visin del producto los cuales comenzaron a ser pasados a casos de uso.
El Lder de Proyecto en forma conjunta con el Arquitecto y el Cliente, dieron prioridad
a estos casos de uso seleccionando la versin del producto en que cada uno aparecera.
De acuerdo a la propuesta de AgEnD se tomaron los casos de uso seleccionados para la
primera versin de manera de efectuar una estimacin global de la duracin del
proyecto. Se dej en claro que dicha estimacin arrojara un resultado aproximado y
dada la naturaleza de los procesos giles el mismo simplemente servira para planificar
hitos importantes del proyecto.
Usando la metodologa de UCP (Use Case Points) junto con los factores de
ajuste correspondientes, la estimacin arroj un total de 215 UCP no ajustados.
Mediante la utilizacin del factor de ajuste estandar de la industria de 20 horas/persona
por UCP se obtuvo un esfuerzo para el proyecto de 18,78 meses/persona. De acuerdo al
equipo de desarrollo descrito anteriormente se estim la duracin en 5 meses.
Este resultado fue bastante acertado si se tiene en cuenta que la primer versin
fue liberada 6 meses despus. Cabe remarcar que durante el desarrollo hubo grandes

cambios en los requerimientos y la estructura y priorizacin de los casos de uso se

modific considerablemente.
Esta prctica fue de gran ayuda en el desarrollo ya que permiti definir

cuestiones tcnicas que impactara positivamente en la solucin al problema. Una vez
que se comenz con la especificacin de los casos de uso, en paralelo el Arquitecto
junto con los Desarrolladores comenzaron a definir la arquitectura del sistema. Uno de
los requerimientos no funcionales ms importante era el construir un sistema mantenible
y flexible, el cual pudiera incorporar cambios con facilidad. Exista tambin una fuerte
restriccin de diseo de mantener los costos lo ms bajo posibles y de que el sistema no
tuviera licenciamento alguno por lo cual se deban utilizar componentes Open Source.
Tomando como input los casos de uso que se iban teniendo y las cualidades
sistmicas requeridas se fue armando el documento de Descripcin de la Arquitectura.
Un breve resumen del mismo se puede observar en el punto anterior donde se visualizan
los componentes ms importantes de la solucin.
Podemos mencionar que a diferencia de otras metodologas giles (XP entre las
ms conocidas) que plantean el no realizar ningn esfuerzo de arquitectura al principio,
AgEnD sugiere especificar las cuestiones tcnicas ms importantes en forma temprana
de manera de minimizar el impacto del cambio en este sentido. Esto permiti que una
vez elegida la arquitectura, el Arquitecto y los desarrolladores construyeron un
prototipo proof of concept que validara las decisiones tomadas. Se seleccionaron los
casos de uso ms crticos de los que estaban especificados y se implement el prototipo.
El mismo fue exitoso y sent la base para la posterior implementacin de los casos de
uso.
Integracin Continua
De acuerdo a la prctica de AgEnD se configur un entorno de desarrollo que

fomentara la integracin continua. Los Desarrolladores trabajaban en la implementacin
de los casos de uso y peridicamente suban su trabajo al repositorio, en este caso el
CVS. El cdigo slo era subido si las pruebas unitarias pasaban en su totalidad.

Una vez que estaba subida la aplicacin la misma era testeada unitariamente y
funcionalmente por el desarrollador para verificar que el sistema continuaba en
funcionamiento. Al fin de cada semana el Tester tomaba todo lo construido y guindose
con los casos de uso llevaba a cabo el testing funcional en forma conjunta con el Cliente
en algunos casos.
Gracias a la prctica de Integracin Continua se evitaron los problemas de

modelos anteriores ms rigurosos que posponan la integracin para el final del
proyecto, una vez que todos los mdulos estuvieran codificados, lo cual creaba un alto
riesgo debido a la incompatibilidad de interfases y comportamientos. En el proyecto de
FIDoNET no existieron problemas de este tipo.
Peopleware
El nfasis de AgEnD en la gente fue llevado a la prctica en el proyecto. En todo

momento el Lder de Proyecto fomentaba la motivacin de su equipo. Hubo solamente
un par de semanas con algunos das con horas extras, especialmente en fechas crticas
de entregas pero los mismo fueron seguidos de semanas ms tranquilas con menos carga
laboral.
Las personas del equipo disponan de amplios lugares de trabajo, mquinas

potentes, cmodos escritorios que les permitan llevar a cabo programacin de a pares si
se deseaba. Tambin permita que el Cliente pudiera sentarse con el Analista a evaluar
la aplicacin.
En todo momento se foment la cohesin del grupo llevando a cabo actividades

extra-curriculares que permitieran generar un espritu de grupo. Estas actividades
incluyeron salidas despus del trabajo, asados con el equipo de desarrollo, almuerzos a
cargo de la empresa, etc. Las mismas ayudaron a que la gente entrara en contacto entre
s y se hablarn de cuestiones no concernientes al mbito laboral.
Como se mencion anteriormente el propsito de una metodologa es garantizar

el tener una forma de trabajo predecible que permita terminar en costo, tiempo y forma
los proyectos. Dado que para la siguiente versin de la aplicacin era probable la

incorporacin de ms gente de la empresa resultaba de gran importancia llevar a cabo la

prctica de Administracin del Conocimiento.
El Lder de Proyecto era el encargado de administrar el conocimiento

almacenado y guardarlo en un lugar para su posterior recuperacin y utilizacin. El
propsito era administrar el conocimiento organizacional para que FIDoNET pudiese
desarrollar aplicaciones ms ambiciosas ya que la mayor parte del conocimiento estaba
almacenado. La herramienta utilizada para el proyecto fue una Swiki herramienta web
que permite automatizar la generacin, publicacin y administracin de contenido.
En cada una de las reuniones semanales de revisin de la iteracin el Lder de

Proyecto se encargaba de averiguar que conocimiento se haba generado de cada
participante y posteriormente se juntaba con dicha persona/s para capturarlo de una
manera estandarizada.
Artefactos
De acuerdo a la definicin de AgEnD se recomienda especificar al principio del

proyecto aquellos artefactos que sern generados y mantenidos durante el ciclo de vida.
Esta es una de las tareas que el Coordinador de Proceso (tomado en este caso por el
Lder de Proyecto) realiza durante las primeras iteraciones. El resultado de la misma es
el siguiente:
Minutas de Reunin, documentos que ponen de manifiesto los tpicos que

fueron tratados en una reunin de FIDoNET
Plan de Proyecto, representado mediante un diagrama de Gantt en el que se

ir plasmando la planificacin del proyecto durante el tiempo
Visin, contiene los features principales del sistema as como la

identificacin de los involucrados en el proyecto
Gua de Estilo, contiene las decisiones que fueron tomadas en el diseo de la

UI y los estndares que se debern tener en cuenta para la extensin de este
diseo
Casos de Uso, contiene los requerimientos funcionales del sistema con

apndices de diseo

Documento de Arquitectura, contiene las decisiones de diseo ms

relevantes que se tomaron en el proyecto y las vistas arquitectnicas
relevantes
Cdigo Fuente y Scripts de Despliegue, incluye el cdigo de las clases, las

pginas HTML, las imgenes, los archivos de configuracin, los scripts de
despliegue y dems recursos que componen el proyecto de desarrollo
Repositorio Unificado, repositorio unificado implementado en CVS que

contendr la totalidad de los tems de configuracin del proyecto
(documentos, cdigo, imgenes, videos, etc.)
Planilla de Incidentes, usada por el Tester al momento de reportar bugs y

mejoras a los Desarrolladores
Conclusiones acerca del Proyecto
Despus de seis meses de desarrollo el proyecto llega a un hito importante, la

entrega del release 1.0 que concluye la puesta en prctica de AgEnD. El mismo ha
terminado en forma satisfactoria para las partes involucradas. Se han implementado
todas las prcticas recomendadas por AgEnD y se realiz una reunin de Cierre de esta
primer etapa para relevar y analizar el proyecto y la metodologa.

Experimentacin de Prcticas utilizando AgEnD

Segundo Ejemplo: Aplicacin en CONEST
Tomando otro proyecto de anlisis mostraremos cmo las prcticas

recomendadas por AgEnD permitieron llegar al xito. Una diferencia importante es que
no se implementaron tantas prcticas como en el proyecto descrito anteriormente.
Este proyecto fue encarado por una empresa que presta servicios de desarrollo
de software. El cliente para el cual realiza el proyecto en particular es CONEST10 quien
maneja importantes centros de compras dentro del pas. CONEST ha decidido
encargarle a la consultora un sistema para la administracin de recursos de hardware y
software disponibles en la empresa. Dicho sistema ser internamente por el
departamento de tecnologa de CONEST quin deber administrar el inventario de estos
bienes. El proyecto es relativamente pequeo (3 meses aprox.) como se mostrar en la
seccin de estimaciones.
Background del Proyecto
CONEST ha decidido utilizar un equipo de desarrollo que inicialmente ser de 3

personas, y posteriormente en la construccin crecer a unas 5 personas. El proyecto
ser conducido utilizando algunas prcticas de AgEnD como proceso, siendo las
prcticas seleccionadas por un Coordinador con conocimiento de la metodologa (el
Autor en este caso). Al igual que antes recalcamos la realizacin de reuniones
frecuentes para configurar AgEnD acorde a las necesidades del equipo de desarrollo.
Todo el equipo detrs del emprendimiento de CONEST est comprometido a utilizar
AgEnD en todas sus fases pudiendo adaptarlo a medida se avanza en el desarrollo
mediante la intervencin del Coordinador.
Roles y Recursos
Los roles de AgEnD estn llevados a cabo por distintas personas del proyecto. A
continuacin mencionamos a los trabajadores:
10
Nuevamente, por cuestiones de confidencialidad se dar un nombre de fantasa de la empresa.

Existen un Usuario Experto, el cual trabaja en las oficinas del Cliente y

forma parte del departamento de tecnologa este interacta nicamente
con el Analista Funcional. A lo largo de este captulo nos referimos a
este rol como el Cliente.
Resea: No existe mucha referencia del Usuario Experto ya que es el

primer proyecto en que este contrata a la consultora. Sin embargo de los
primeros relevamientos surge que son personas flexibles que ayudarn al
equipo en todas las cuestiones funcionales.
Existe un Ejecutivo de Cuenta que velar por mantener el proyecto en su

rumbo, eliminando obstculos polticos que estn fuera del alcance del
Equipo de Desarrollo.
Resea: El Ejecutivo de Cuenta es la persona que efecta el primer

contacto con el Cliente. Sus aptitudes son las de ser un muy buen
negociador y conocer el rea desde un punto de vista comercial.
Existe un Lder de Proyecto.
Resea: El Lder de Proyecto es la persona encargada de gestionar el

proyecto. El mismo tiene otros proyectos a su cargo con lo cual su
dedicacin ser part-time.
Existe una Analista Funcional encargada de llevar a cabo el

relevamiento.
Resea: La Analista es una persona con mucha habilidad y experiencia

en relevamientos en grandes proyectos. Esta especializada en la
confeccin de Casos de Uso y en el uso de herramientas CASE como el
Enterprise Architect para el modelado. La misma cumple sus funciones
en otros proyectos con lo cual su dedicacin ser part-time.
Existe un Coordinador que ayudar al equipo en la implementacin de la

metodologa.
Resea: El Coordinador ayudar al Equipo de Desarrollo en la

implementacin de las prcticas de AgEnD y en la creacin de los
artefactos propuestos. Tambin actuar de Mentor en relacin a las

tecnologas seleccionadas en el proyecto. Esta persona cumple sus

funciones en otros proyectos con lo cual su dedicacin ser part-time.
Existen dos Desarrolladores que poseen distintos grados de experiencia

en las tecnologas del proyecto. Uno estar involucrado en el proyecto
desde el principio y el otro lo iniciar posteriormente.
Resea: Los dos tienen cargos de Programadores Junior y conocen a en

forma terica la tecnologa seleccionada contando con poca experiencia
prctica. No poseen abundante experiencia laboral.
Existe un Tester que se encargar de disear y ejecutar los casos de

prueba de la aplicacin
Resea: El Tester ser el responsable de llevar a cabo el control de

calidad de la aplicacin. A medida se vayan liberando versiones realizar
el testing funcional de las mismas en base a los casos de prueba que este
construyo.
Tecnologas
Al momento de armar la Propuesta Econmica del proyecto se prioriz la

seleccin de tecnologas basadas sobre la plataforma Java 2, prefirindose aquellas que
respondiesen al modelo de desarrollo Open Source y que pudiesen usarse libremente sin
costos de licencias asociados.
Arquitectura de la Aplicacin
Arquitectura Web: arquitectura que presenta la interfase al usuario mediante un

navegador de internet pudiendo desacoplar las capas de interfase/lgica de
negocio/datos en el servidor mediante frameworks disponibles.
La arquitectura de la aplicacin para prestar servicios web estar compuesta por

las siguientes capas (tiers):

Capa de Presentacin: pginas web servidas mediante un framework de

MVC que desacopla esta capa de las capas de lgica del negocio y manejo de
datos.
Capa de Lgica del Negocio: inicialmente, se puede pensar en un

esquema sencillo de lgica del negocio que simplemente reciba/enve la
informacin a la capa de presentacin, mediante la interaccin directa con la
capa de manejo de datos. Se plantear un esquema de componentes que
resuelvan los pedidos realizados sin necesidad de utilizar un application server.
Capa de Manejo de Datos: para esto se utilizar un motor de base de

datos relacional. El mismo ser accedido mediante el patrn DAO (Data Access
Object) que desacopla la persistencia del RDBMS seleccionado.
Plataforma Base y Herramientas
Microsoft Windows: SO de desarrollo
Apache Tomcat: Web Container
CVS: Sistema de Administracin de la Configuracin
Eclipse: IDE de Desarrollo
Macromedia Dreamweaver: Herramienta de diseo de pginas web
Enterprise Architect: Herramienta de modelado para realizar el Modelo de casos

de uso y los diagramas de arquitectura
Motores de BD
Microsoft SQL Server: uno de los motores comerciales ms utilizados en el

mercado. El mismo es estndar del cliente por lo que resulta en una restriccin
de la aplicacin. Tambin se debe acceder al mismo nicamente mediante Stored
Procedures que sern escritos por los desarrolladores.
Framework de MVC

Jakarta Struts: framework utilizado para la capa de presentacin de la

aplicacin. El mismo se utiliza para armar el patrn MVC pudiendo desacoplar
la presentacin de la lgica del negocio.
Framework de Reporting (Descartado)
Jasper: inicialmente se decidi utilizar este framework de reporting que permite

generar reportes customizados en la aplicacin. El mismo est desarrollado en
Java y es Open Source. Finalmente y por cuestiones de falta de features y
problemas tcnicos, la utilizacin del mismo fue descartada.
Data Access Object (DAO)
DAO: patrn de diseo a ser implementado en la solucin. El mismo especifica

una framework que se utiliza para realizar la capa de persistencia de la
aplicacin. El mismo provee una forma de acceder al motor de RDBMS sin
necesidad de escribir cdigo SQL dentro de la aplicacin.
Como se observa en la Figura 038, tomada del libro sobre patrones en J2EE
[Alur, 2001], el patrn encapsula la creacin de entidades que mantienen los
datos de la aplicacin. Estos Value Objects son los que contienen las sentencias
de accesos al RDBMS.

Figura 038. Diagrama de secuencia de interacciones en el patrn DAO. Tomada de [Alur, 2001].
Middlegen DAO Generator: se utiliz una aplicacin escrita en Java

denominada Middlegen que automatiza la creacin de todas las clases del patrn
DAO tomando como input las tablas de la base de datos. De esta forma se
redujeron considerablemente los tiempos de desarrollo de la capa de
persistencia.
Lanzamiento del Proyecto
CONEST inicia el proyecto convocando a la consultora de sistemas para el

desarrollo de su sistema. La consultora efecta un primer relevamiento en el que obtiene
los casos de uso de la aplicacin. A partir de ah elabora una propuesta econmica con

una estimacin tentativa, costos, equipo de desarrollo y dems informacin para el

Cliente. El relevamiento es conducido por la Analista Funcional la cual identifica de
forma temprana a los stakeholders del futuro sistema y los servicios que estos requerirn
del sistema.
En la Propuesta entregada al Cliente se establece una planificacin con las fases

en que el proyecto de CONEST ser dividido tomando como referencia las fases de
AgEnD. La estimacin se lleva a cabo mediante el conteo por UCP (Use Case Points)
analizando la complejidad de los casos de uso en funcin de los escenarios planteados.
Resultados del Proyecto
Despus de 3 meses y 3 semanas de desarrollo el proyecto llega al hito de

entrega del release 1.0 que concluye la puesta en prctica de las prcticas de AgEnD. Si
bien se ha sufrido un leve retraso debido a causas que mencionaremos a continuacin, el
proyecto entreg la funcionalidad requerida por el Cliente con la calidad acordada. Se
han implementado gran parte de las prcticas recomendadas por AgEnD y se realiz una
reunin de Cierre de esta primer etapa para relevar y analizar el proyecto y la
metodologa. A continuacin se comentan aspectos de la metodologa que
contribuyeron al xito del proyecto.
Configuracin del Proceso
En el proyecto de CONEST una de las primeras cuestiones que se observ fue la

carencia de una persona que actuara como Arquitecto en el proyecto tomando los
requerimientos no funcionales y seleccionando una solucin adecuada al problema
planteado. Debido a esto, el Coordinador en sus tiempos libres ayud a uno de los
desarrolladores a armar dicho documento. Dado que ste no dispona de mucho tiempo
se tom algunos das para elaborar un Documento de arquitectura que comunicara la
solucin a los desarrolladores de manera fcil y sin necesidad de tener la presencia
fsica del Arquitecto constantemente.
Al principio, esto sirvi al propsito, pero con el correr de las semanas se

observ en las reuniones de avance diarias que los desarrolladores trabajaban demasiado
lento debido a que la arquitecta les era nueva. Finalmente, siguiendo la prctica de

Mxima Comunicacin el Coordinador dedic unos 4 das full time al proyecto para
llevar a cabo un refactoring de la Arquitectura suplantando el documento en s por
cdigo ejecutable que sirviera para gua a los desarrolladores. Los resultados fueron
excelentes.
Al igual que en el proyecto anterior se decidi agregar dentro de la disciplina de

Administracin de Proyecto del proceso al Scrum Daily Meeting. La misma era
coordinada por el Lder de Proyecto quien preguntaba a cada persona del equipo qu
haba hecho la durante el da anterior, que iba a hacer durante ese da y que obstculos
tena para llevar a cabo sus actividades. Esto permiti ir teniendo un control y
monitoreo constante sobre el progreso y los riesgos que se iban dando.
En relacin a los artefactos sugeridos por AgEnD la Visin fue suplantada por la
Propuesta Econmica a partir de la cual el Cliente decida respecto a la ejecucin del
proyecto. Todos los dems artefactos sugeridos fueron realizados incluyndose como
parte de los casos de uso los prototipos de pantalla en HTML correspondientes. Esto
sirvi para obtener un rpido feedback del usuario respecto a aquellas funcionalidades
que resultaban ambiguas.
Se arm el repositorio en CVS que es la herramienta de SCM usada por la

consultora. Todos los artefactos generados durante el proyecto fueron puestos bajo
control de versiones. Para comodidad del equipo de desarrollo se decidi tener dos
mdulos independientes dentro de un mismo repositorio. El repositorio tena el nombre
del proyecto y existan dos mdulos: uno denominado Project y otro Sources. El primer
mdulo inclua toda la documentacin asociada a las distintas disciplinas de AgEnD
categorizadas en directorios con el nombre de la disciplina. El segundo mdulo tena
todo el cdigo de la aplicacin a ser cargado en la IDE utilizada el Eclipse.
El mantener todo el cdigo fuente bajo control de versiones permiti que en un

punto los desarrolladores entregaran una primera versin de demo al cliente para validar
los flujos de los casos de uso, usando el HEAD del repositorio para mantener los tems
de configuracin. En paralelo, el Coordinador que emprendi tareas de Arquitectura
empez a trabajar en un refactoring de la Arquitectura destinado a mejorar la
flexibilidad y mantenibilidad del cdigo generado. Para esto se decidi abrir un branch

de desarrollo paralelo que permitiera desarrollar manteniendo limpio el HEAD para

correcciones sobre las versiones de entrega al Cliente. Finalmente, dado que el
refactoring de arquitectura result exitoso el desarrollo prosigui por el branch
quedando el HEAD obsoleto.
Mxima Comunicacin
La prctica de Mxima Comunicacin no pudo ser implementada

completamente debido a que el Cliente estaba separado en su propia empresa y slo
poda ser accedido va email o telefnicamente. Esto traa aparejado una lentitud de
respuesta y una falla comunicacional importante que trat de ser subsanada mediante
casos de uso validados y detallados por el Analista junto al Cliente. Ocurrieron
situaciones en las que se tuvo que esperar casi 72 horas hasta obtener clarificaciones
respecto a cuestiones de la aplicacin por parte del Cliente.
Todas las personas del equipo de desarrollo estaban en un mismo piso de un

edificio en oficinas adyacentes. Esto permita que cualquier duda planteada por
cualquier parte se resolviera mediante la rpida consulta con el miembro que tena el
conocimiento.
Esta prctica fue de gran ayuda en el desarrollo ya que permiti definir

cuestiones tcnicas que impactaran positivamente en la solucin al problema. Sin
embargo como ya fue mencionado fue donde se materializaron importantes riesgos que
llevaron al desvo en el cronograma del proyecto.
Una vez que se comenz con la especificacin de los primeros casos de uso, en
paralelo el Coordinador en rol de Arquitecto junto con los Desarrolladores comenzaron
a definir la arquitectura del sistema. Uno de los requerimientos no funcionales ms
importante era el construir un sistema mantenible y flexible, el cual pudiera incorporar
cambios con facilidad y que debera ser interoperable con otras aplicaciones dentro de
los sistemas del Cliente.
Tomando como input los casos de uso que se iban teniendo y las cualidades
sistmicas requeridas se fue armando el documento de Descripcin de la Arquitectura.

Un breve resumen del mismo se puede observar en el punto anterior donde se visualizan
los componentes ms importantes de la solucin.
El nico comentario que podemos incluir es que la falta de una persona

experimentada desde el punto de vista tcnico guiando al equipo de desarrollo full time,
como establece el rol de Arquitecto en AgEnD, caus problemas debido a la
inexperiencia del equipo de desarrollo. Volvemos a destacar la necesidad de invertir
constantemente en la gente y el riesgo que trae aparejado el no tener recursos a la altura
de las circunstancias.
Estimaciones giles
Esta prctica fue utilizada al principio del proyecto en el armado de la Propuesta.

Durante la primera fase se tomaron los casos de uso del producto y el Lder de Proyecto
en forma conjunta con el Coordinador y el Cliente, dieron prioridad a seleccionando la
versin del producto en que cada uno aparecera. Siguiendo a AgEnD se tomaron los
casos de uso seleccionados para la primera versin de manera de efectuar una
estimacin global de la duracin del proyecto. Se dej en claro que dicha estimacin
arrojara un resultado aproximado y dada la naturaleza de los procesos giles el mismo
simplemente servira para planificar hitos importantes del proyecto.
Usando la metodologa de UCP (Use Case Points) junto con los factores de
ajuste correspondientes y efectuando una estimacin en paralelo basada en la
experiencia de especialistas tcnicos dentro de la consultora la estimacin arroj un
esfuerzo para el proyecto de 12 meses/persona. De acuerdo al equipo de desarrollo
descrito anteriormente se estim la duracin en 3 meses.
Este resultado fue bastante acertado si se tiene en cuenta que la primer versin
fue liberada 3 meses y 3 semanas despus. Cabe remarcar el desvo surgido debido a los
temas antes mencionados respecto a la comunicacin de la arquitectura y a las
dificultades con el paquete de reporting seleccionado.
Integracin Continua
De acuerdo a la prctica de AgEnD se configur un entorno de desarrollo que

fomentara la integracin continua. Los Desarrolladores trabajaban en la implementacin

de los casos de uso y peridicamente suban su trabajo al repositorio, en este caso el

CVS.
Una vez que estaba subida la aplicacin la misma era testeada unitariamente y
funcionalmente por el desarrollador para verificar que el sistema continuaba en
funcionamiento. Al fin de cada iteracin el Tester tomaba todo lo construido y
guindose con los casos de prueba llevaba a cabo el testing funcional en forma conjunta
con el Cliente en algunos casos. En el proyecto de CONEST no existieron problemas
relacionados con la integracin.
Peopleware
El nfasis de AgEnD en la gente fue llevado a la prctica parcialmente en el

proyecto. En todo momento el Lder de Proyecto fomentaba la motivacin de su equipo.
Hubo solamente un par de semanas con algunos das con horas extras, especialmente en
fechas crticas de entregas pero los mismo fueron seguidos de semanas ms tranquilas
con menos carga laboral.
Las personas del equipo disponan de amplios lugares de trabajo, mquinas

potentes, cmodos escritorios que les permitan llevar a cabo programacin de a pares si
se deseaba.
Los mayores inconvenientes en relacin a esta prctica fueron la carencia de una

persona cubriendo el rol de Arquitecto en forma continua y la falta de un alto nivel de
comunicacin con el Cliente. Respecto a esto ltimo toda la comunicacin con el
Cliente era realizada mediante la intermediacin del Analista Funcional con lo cual el
delay resultaba muy ineficiente para el desarrollo. Esto fue notificado por el
Coordinador en forma temprana ya que implicaba un alto riesgo en la implementacin
de una metodologa gil pero sin embargo el Lder de Proyecto no pudo efectuar
ninguna accin correctiva ms que tratar de mantener un canal abierto con un usuario
experto para posibles consultas.
El Coordinador era el encargado de administrar el conocimiento almacenado y

guardarlo en un lugar para su posterior recuperacin y utilizacin. El propsito era

administrar el conocimiento organizacional para que CONEST pudiese desarrollar

aplicaciones ms ambiciosas ya que la mayor parte del conocimiento estaba
almacenado. Dado que la arquitectura era bastante conocida y se contaba con suficiente
informacin se decidi simplemente documentar el funcionamiento de aquellos
paquetes sobre los cuales no se dispona de informacin.
El Coordinador pidi a los Desarrolladores que armarn un documento como

introduccin al Jasper el framework de reporting que fue analizado pero descartado
finalmente, y otro documento que sirviera de introduccin para el uso del Middlegen
el paquete que permita automatizar la creacin de DAOs a partir de una base de datos
determinada.
Una vez que dichos documentos fueron generados el Coordinador los formate
adecuadamente y los puso a disposicin de todos en la intranet de conocimiento de la
consultora. Esta medida llevada a la escala de todos los proyectos en que se implemente
AgEnD permitir que cualquier tipo de conocimiento generado sea permeado en la
gente aumentando el conocimiento organizacional.
Artefactos
De acuerdo a la definicin de AgEnD se recomienda especificar al principio del

proyecto aquellos artefactos que sern generados y mantenidos durante el ciclo de vida.
Esta es una de las tareas que el Coordinador de Proceso realiza durante las primeras
iteraciones. El resultado de la misma es el siguiente:
Minutas de Reunin, documentos que ponen de manifiesto los tpicos que

fueron tratados en una reunin de CONEST
Plan de Proyecto, representado mediante un diagrama de Gantt en el que se

ir plasmando la planificacin del proyecto durante el tiempo
Propuesta Econmica, contiene los features principales del sistema as como

la identificacin de los involucrados en el proyecto, el costo total, el equipo
de desarrollo y una estimacin inicial del mismo
Prototipos de GUI, realizados por un diseador grfico para todas las

pantallas de cada transaccin dentro de un caso de uso

Casos de Uso, contiene la especificacin de los requerimientos funcionales

del sistema
Documento de SRS, contiene los requerimientos funcionales de carcter ms

tcnico y no funcionales del sistema con apndices de diseo
Documento de Arquitectura, contiene las decisiones de diseo ms

relevantes que se tomaron en el proyecto y las vistas arquitectnicas
relevantes
Cdigo Fuente y Scripts de Despliegue, incluye el cdigo de las clases, las

pginas HTML, las imgenes, los archivos de configuracin, los scripts de
despliegue y dems recursos que componen el proyecto de desarrollo
Repositorio Unificado, repositorio unificado implementado en CVS que

contendr la totalidad de los tems de configuracin del proyecto
(documentos, cdigo, imgenes, videos, etc.)
Casos de Prueba, contienen los flujos de ejecucin que sern utilizados por
los Testers para probar la aplicacin desde un punto de vista funcional; son
creados a partir de los casos de uso
Planilla de Incidentes, usada por el Tester al momento de reportar bugs y

mejoras a los Desarrolladores
Conclusiones acerca del Proyecto
Despus del tiempo mencionado de desarrollo el proyecto llega a un hito

importante, la entrega del release 1.0 que concluye la puesta en prctica de AgEnD. El
mismo ha terminado en forma satisfactoria para las partes involucradas, a excepcin del
desvo mencionado. Se han implementado muchas de las prcticas recomendadas por
AgEnD y se realiz una reunin de Cierre de esta primer etapa para relevar y analizar el
proyecto y la metodologa.
Cabe mencionar que en aquellos casos en los que las prcticas no pudieron ser
implementadas siguiendo los lineamientos propuestos en esta tesis, hubo importantes
perjuicios que se manifestaron como desvos en el cronograma del proyecto. Es de

opinin del autor que estas cuestiones no hubieran sucedido si las circunstancias
hubieran permitido la implementacin completa de las prcticas.

Capitulo V - Conclusiones
Las metodologas de desarrollo de software giles permiten a los pequeos

grupos de desarrollo concentrarse en la tarea de construir software fomentando prcticas
de fcil adopcin y un entorno ordenado que ayude a que las personas trabajen mejor y
permita que los proyectos finalicen exitosamente. Las mismas estn basadas en los
cuatro principios del Manifiesto gil que fueron mencionados al principio de este
trabajo. AgEnD, la metodologa propuesta en esta tesis, avanza en el conocimiento
terico de estos procesos analizando estos principios mencionados y reuniendo prcticas
y patrones que contribuyen a la implementacin y posterior adaptacin del proceso a la
realidad de cada organizacin.
Para llevar a cabo este trabajo se recab informacin exhaustiva de procesos de

desarrollo, reas de conocimiento de ingeniera de software, metodologas giles,
prcticas de desarrollo gil y otras disciplinas dentro de la informtica. Adems, se ley
bibliografa de temas como Administracin de Empresas, Psicologa Sistmica y
Recursos Humanos. Como se observar en la parte final de bibliografa, la lista que fue
reunida no es menor y representa en gran parte el state-of-the-art de los
conocimientos aplicados en esta tesis. Mencionaremos a continuacin las tareas llevadas
a cabo en el transcurso de este trabajo.
Primeramente, se describi la historia de los procesos de desarrollo de software,

explicando brevemente los distintos modelos que fueron surgiendo y las virtudes /
falencias de cada uno. A esto prosigui una breve historia del surgimiento de las
metodologas giles y una caracterizacin de las ms importantes durante el perodo de
escritura de esta tesis: XP, Scrum, Cristal Clear, DSDM, FDD, ASD, XBreed. Gracias a
este captulo logramos ubicar al lector dentro del universo del cual habramos de
explayarnos ms adelante.
Posteriormente, en el capitulo 2, se describieron las problemticas planteadas

por los modelos de procesos de desarrollo existentes y cmo las metodologas giles, en
particular AgEnD, proponan principios para mitigar los riesgos asociados a la
complejidad inherente del desarrollo de software (descrita por Fred Brooks). Esta
descripcin pretende auxiliar al lector a entender el porqu de los principios sobre los

cuales se basan las metodologas giles y que dirigirn todos los objetivos de la solucin
propuesta ms adelante.
En el captulo 3 se comenz a desglosar la metodologa propuesta para su

entendimiento en detalle. Partiendo de una definicin de aspectos abarcativos de un
proceso mencionada por Alistair Cockburn, el texto analiza los diversos elementos que
componen AgEnD: roles, artefactos, fases, disciplinas, hitos, patrones de desarrollo.
Manteniendo la ideologa de priorizar a las personas sobre el proceso, se trato de poner
continuamente el nfasis en el factor humano tratando de mantener el overhead
metodolgico al mnimo posible. Asimismo, todos los problemas planteados en el
capitulo anterior tienen una respuesta tangible en la metodologa. Se trat de aprender
de los viejos errores y de generar un repositorio de buenas prcticas.
Avanzando en el captulo se propusieron una serie de tcnicas y estudios que

permiten implementar una metodologa gil dentro de una organizacin. Esta parte
constituye en s uno de los principales aportes al espectro de metodologas giles por no
encontrarse muchas lneas de investigacin hasta el momento y menos que tomen en
cuenta otras ramas del conocimiento distintas a la informtica. Es creencia del autor que
es de suma importancia: empezar a formalizar la mejora del proceso dentro de una
organizacin a consecuencia del incremento continuo en la complejidad de los sistemas
construidos y disponer de personas que se encarguen de velar por mantener y actualizar
un proceso lo ms gil e institucionalizado posible valor estratgico a futuro de los
SEPG (Software Engineering Process Group) que ya se encuentran en las grandes
organizaciones.
En el captulo 4 se presentaron dos casos de xito de implementacin de AgEnD

en distintas organizaciones. Estos proyectos contaron con la presencia constante del
autor de la tesis, quien realiz la capacitacin inicial de las personas respecto a AgEnD
y quien continuamente recab informacin de cmo el proceso era llevado a la prctica,
adaptndolo de ser necesario. Estas puestas en prctica resultaron positivas ya que
dieron una cierta tangibilidad a una tesis de ingeniera de software fuertemente
orientada hacia aspectos conceptuales.
En relacin con puntos de investigacin a futuro el autor evaluar la posibilidad

de crear una herramienta CASE que ayude a customizar un proceso gil para un
proyecto en particular. Asimismo, se iniciaron lneas de investigacin en otras

disciplinas para analizar factores humanos dentro de la Ingeniera de Software. El

profundizar ms por la bibliografa y las reas de conocimiento de la Sociologa,
Psicologa, Relaciones Laborales ayudar a hacer crecer nuestra ingeniera.

Anexo A - Templates de Artefactos

A continuacin se proponen distintos templates para los artefactos
recomendados por AgEnD. Los mismos podrn ser tomados por el Coordinador como
punto de partida al momento de implementar la metodologa en la organizacin.
Los templates que se ofrecen son para los siguientes artefactos:
Visin
Lista de Riesgos
Especificacin de Casos de Uso
Documento de Especificacin de Requerimientos de Software (SRS)
Descripcin de la Arquitectura
Casos de Prueba
Nota de Entrega
Dado que los mismos son documentos totalmente independientes de esta tesis, se
incluyen en los distintos formatos generados por cada herramienta al fin de la misma.

Anexo B - Tabla de Lenguajes de

Programacin
Release 8.2, Marzo 1996
Por Capers Jones, Chairman, Software Productivity Research, Inc.
Copyright 1997 por Software Productivity Research, Inc. Todos los derechos reservados.
Table 1. Language Level Relationship to Productivity
LANGUAGE LEVEL PRODUCTIVITY AVERAGE

PER STAFF MONTH
-------------- -------------------------
1-3 5 to 10 Function Points
4-8 10 to 20 Function Points
9 - 15 16 to 23 Function Points
Above 55 40 to 100 Function Points
What Is The Basis For Language Levels?
The languages and levels in Table 2 were gathered in four ways.
Counting Function Points and Source Code
Counting Source Code
Inspecting Source Code
Researching Languages
Counting Function Points And Source Code
Actual counts of Function Points and source code statements were performed. Samples of
counting Function Points and source code statements were done on Ada, several BASIC

dialects, COBOL, PASCAL, and PL/I.
Counting Source Code
Source code statements were counted, then compared to the size of the same program in
languages of known levels. Assembly, APL, C, OBJECTIVE C, FORTH, FORTRAN, LISP,
PILOT, and PROLOG are languages that produce the same source code count as COBOL.
So code sizes were compared to the known quantity of COBOL source code.
Inspecting Source Code
Source code inspection for common applications was done. Then the volume of code for the
application in a measured language was hypothesized. ACTOR, CLARION, and TRUE
BASIC are examples of languages that were inspected and their levels hypothesized by
subjective means.
List Of Programming Languages
As of 1996, there were more than 500 languages and major dialects of languages available
to software practitioners. Table 2 lists the most common of them in what is considered
version 7 of the SPR Programming Languages Table.
Table 2. Programming Languages and Levels
AVERAGE SOURCE
LANGUAGE LEVEL STATEMENTS PER
FUNCTION POINT
1032/AF 20.00 16
1st Generation default 1.00 320
2nd Generation default 3.00 107
3rd Generation default 4.00 80
4th Generation default 16.00 20
5th Generation default 70.00 5
Access 8.50 38
Ada 83 4.50 71
Ada 95 6.50 49
AI shell default 6.50 49
ANSI BASIC 5.00 64
ANSI COBOL 74 3.00 107
ANSI COBOL 85 3.50 91
ANSI SQL 25.00 13

Application Builder 16.00 20

Application Manager 9.00 36
Assembly (Basic) 1.00 320
Assembly (Macro) 1.50 213
Associative default 5.00 64
awk 15.00 21
BASIC 3.00 107
BASIC A 2.50 128
Basic assembly 1.00 320
Berkeley PASCAL 3.50 91
BETTER BASIC 3.50 91
C 2.50 128
C Set 2 3.50 91
C++ 6.00 53
DELPHI 11.00 29
Eclipse 6.50 49
EIFFEL 15.00 21
EXCEL 1-2 51.00 6
EXCEL 3-4 55.00 6
EXCEL 5 57.00 6
FOXPRO 2.5 9.50 34
GENEXUS 21.00 15
Haskell 8.50 38
HTML 2.0 20.00 16
HTML 3.0 22.00 15
IBM CICS/VS 8.00 40
IBM Compiled BASIC 3.50 91
IBM VS COBOL 3.00 107
IBM VS COBOL II 3.50 91
INFORMIX 8.00 40
JAVA 6.00 53
JCL 1.45 221
LISP 5.00 64
LOTUS 123 DOS 50.00 6
LOTUS Macros 3.00 107
Machine language 0.50 640
Macro assembly 1.50 213
MATHCAD 60.00 5
Microsoft C 2.50 128
MODULA 2 4.00 80
MOSAIC 50.00 6
MS C ++ V. 7 6.00 53
MS Compiled BASIC 3.50 91

Natural language 0.10 3200

Non-procedural default 9.00 36
Notes VIP 9.00 36
Object-Oriented default 11.00 29
OBJECT Assembler 5.00 64
Object LISP 11.00 29
Object LOGO 11.00 29
Object PASCAL 11.00 29
ORACLE 8.00 40
Oracle Developer/2000 14.00 23
PARADOX/PAL 9.00 36
PASCAL 3.50 91
PERL 15.00 21
Persistance Object Builder 15.00 21
PILOT 6.00 53
PL/I 4.00 80
PL/M 4.50 71
PL/S 3.50 91
PowerBuilder 20.00 16
POWERHOUSE 23.00 14
PPL (Plus) 8.00 40
Pro-C 12.00 27
PRO-IV 5.50 58
Problem-oriented default 4.50 71
Procedural default 3.00 107
Professional PASCAL 3.50 91
Program Generator default 20.00 16
PROGRESS V4 9.00 36
PROLOG 5.00 64
QBasic 5.50 58
QUATTRO 51.00 6
QUATTRO PRO 51.00 6
Query default 25.00 13
QUICK BASIC 1 5.00 64
Quick C 2.50 128
Quickbuild 11.50 28
QUIZ 22.00 15
Reuse default 60.00 5
REXX (MVS) 4.00 80
REXX (OS/2) 7.00 46
RPG I 4.00 80

RPG II 5.50 58
RPG III 5.75 56
Screen painter default 57.00 6
SIMULA 67 7.00 46
Simulation default 7.00 46
SMALLTALK 286 15.00 21
SMALLTALK 80 15.00 21
SMALLTALK/V 15.00 21
SQL 25.00 13
SQL-Windows 27.00 12
Statistical default 10.00 32
Strongly typed default 3.50 91
Symantec C++ 11.00 29
Tandem Access Language 3.50 91
Topspeed C ++ 11.00 29
Turbo C 2.50 128
TURBO C++ 6.00 53
TURBO EXPERT 6.50 49
Visual Basic 1 7.00 46
Visual Basic DOS 8.00 40
Visual C++ 9.50 34
Visual COBOL 16.00 20
Visual Objects 20.00 16
VisualAge 15.00 21
VisualGen 18.00 18
Copyright 1997 by Software Productivity Research, Inc. All Rights Reserved.

Anexo C - Glosario
Casos de Uso. Notacin utilizada para representar los requerimientos funcionales de un
sistema basada en el esquema propuesto por Ivar Jacobson a principios de la dcada del
90.
CVS (Concurrent Versions System). Herramienta que permite seguir los cambios a un
conjunto de archivos a lo largo del tiempo. CVS es comnmente usado en el desarrollo
de software para:
permitir que mltiples desarrolladores coordinen sus cambios
poder realizar el seguimiento de todas las versiones de los tems de

configuracin
fomentar el desarrollo en simultneo de diferentes versiones del mismo cdigo
IS/IT (Information Systems/Information Technology). Refirase a los sectores de las

organizaciones relacionados con el manejo de la informacin y con las tecnologas
involucradas en este manejo.
Metfora. Equivalente de la arquitectura en el universo de XP. La metfora gua al

desarrollo proveyendo de integridad conceptual al diseo y comunicando a todos los
involucrados los elementos bsicos de la solucin y sus relaciones.
Product Backlog. En el universo de Scrum este es el conjunto de requerimientos a ser

implementados para el sistema en construccin siendo el mismo priorizado
continuamente por el Cliente para armar el Backlog de cada iteracin (denominado
Sprint Backlog).
Programacin de a Pares (Pair Programming). Una de las doce practicas de XP, en

la que dos personas programan frente a una computadora. Una de ellas escribe el cdigo
mientras la otra inspecciona continuamente lo que se desarrolla realizando un Control
de Calidad en el momento.
Refactoring. Tcnica que mantiene intacto el funcionamiento del software mejorando

la estructura interna del mismo.
ROI (Return On Investment). Mtrica financiera que representa el retorno en

ganancias que se obtendr posteriormente a realizar una inversin dada.

Sprint. En el universo de Scrum este es el nombre que se le da a una iteracin.
Stakeholder. Toda aquella persona u organizacin siendo influenciada o ejerciendo

influencia sobre el software que est siendo construido.
Unit Testing. Tcnica utilizada por muchas de las metodologas giles descritas que
consiste en realizar pruebas automatizadas que verifiquen el correcto funcionamiento de
las clases que son desarrolladas. Para esto se utilizan frameworks como el JUnit,
Cactus, HttpUnit, etc.
WBS. Sigla en ingls de un Work Breakdown Structure. Especifica una tcnica que
consiste en desglosar un proyecto en actividades atmicas y estimar el esfuerzo de cada
una de estas actividades. Finalmente, mediante la sumatoria de todos los esfuerzos se
tendr el esfuerzo del proyecto.

Referencias Bibliogrficas
[Alexander, 1977] Alexander, Christopher, A Pattern Language, New York, Oxford

University Press, 1977.
[Alexander, 1979] Alexander, Christopher, The Timeless Way of Building, New York,
Oxford University Press, 1979.
[Alur, 2001] Alur, Deepak, John Crupi, Dan Malks, Core J2EE Patterns, New York:
Prentice Hall, 2001.
[Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP

Series, 2000.
[Beck, 2002] Beck, Kent, Test-Driven Development By Example, Addison-Wesley,

November 2002.
[Boehm, 1981] Boehm, Barry W., Software Engineering Economics, Prentice Hall,
1981.
[Boehm, 1988] Boehm, Barry W., A Spiral Model of Software Development and
Enhancement, IEEE Computer, Vol. 21, No. 15 (May 1988) pp. 61-72.
[Boehm, 1995] Boehm, Barry W., Anchoring the Software Process, USC, November
1995.
[Boehm, 2000] Boehm, Barry W., Ellis Horowitz, Ray Madachy, Donald Reifer,
Bradford K. Clark, Bert Steece, A. Winsor Brown, Sunita Chulani, Chris Abts, Software
Cost Estimation with Cocomo II, Prentice Hall, 2000.
[Booch, 1999] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling
Language User Guide, Addison-Wesley Object Technology Series, 1999.
[Brooks, 1975] Brooks, Frederick P., The Mythical Man Month, Reading, Mass.:
Addison-Wesley, 1975.

[Brooks, 1987] Brooks, Frederick P., No Silver Bullet: Essence and Accidents of
Software Engineering, IEEE Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
[C3, 1998] C3 Team, Chrysler Goes to Extremes, Distributed Computing, (October

1998) pp. 24-28.
[Calligo, 2003] Calligo, Anbal, Marcelo Schenone, Tcnicas de Produccin de

Software I Modelos de Proceso de Desarrollo, Facultad de Ingeniera, UBA, 2003.
[Charvat, 2003] Charvat, Jason, Project Management Methodologies: Selecting,

Implementing, and Supporting Methodologies and Processes for Projects, John Wiley
& Sons, 2003.
[Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,
http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users-
Guide/Feature_Driven_Development.htm, 1998.
[Coad, 1999] Coad, Peter, Eric Lefebrve, Jeff De Luca, Java Modeling in Color with
UML, Prentice Hall, 1999.
[Coad, 2000] Coad, Peter, Feature-Driven Development and Extreme Programming,

http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html, Coad Letter,
Issue 70, July 2000.
[Cockburn, 1998] Cockburn, Alistair, Surviving Object Oriented Projects, Addison-

Wesley Object Technology Series, 1998.
[Cockburn, 1999] Cockburn, Alistair, Characterizing People as Non-Linear, First-

Order Components in Software Development,
http://members.aol.com/humansandt/papers/nonlinear/nonlinear.htm, October 1999.
[Cockburn, 2000a] Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley,

2000.
[Cockburn, 2000b] Cockburn, Alistair, Just-In-Time Methodology Construction,

http://crystalmethodologies.org/articles/jmc/justintimemethodologyconstruction.html,
January 2000.

[Cockburn, 2001a] Cockburn, Alistair, Agile Software Development, Addison-Wesley,

The Agile Software Development Series, 2001.
[Cockburn, 2001b] Cockburn, Alistair, Crystal Clear: A human-powered software

development methodology for small teams,
http://members.aol.com/humansandt/crystal/clear/, Humans and Technology, 1998-
2001.
[Constantine, 1995] Constantine, Larry, Constantine on Peopleware, Yourdon Press

Computing Series, Prentice Hall, 1995.
[Constantine, 2001] Constantine, Larry, Process Agility and Software Usability:

Toward Lightweight Usage-Centered Design, Constantine & Lockwood, Ltd.,
University of Technology, Sydney, 2001.
[Crispin, 2002] Crispin, Lisa, Tip House, Testing Extreme Programming, Addison-
Wesley The XP Series, 2002.
[Davenport, 1998] Davenport, T.H., D.W. DeLong, M.C. Beers, Successful

Knowledge Management Projects, Sloan Management Rev., vol. 39, no. 2, (Winter
1998) pp. 4357.
[DeMarco, 1987] DeMarco, Tom, Timothy Lister, Peopleware: Productive Projects

and Teams, Dorset House Publishing Co., 1987.
[DeMarco, 1999] DeMarco, Tom, Timothy Lister, Peopleware: Productive Projects

and Teams, Second Edition, Dorset House Publishing Co., 1999.
[EA, 2003] Enterprise Architect v3.61, Online Help, Sparx Systems, 2003.
[Etkin, 1989] Etkin, Jorge, Leonardo Schvarstein, Identidad de las Organizaciones:

Invariancia y Cambio, Editorial Paids, 1989.
[Etkin, 2000] Etkin, Jorge, Poltica, Gobierno y Gerencia de las Organizaciones,

Prentice Hall, 2000.

[Fowler, 2000] Fowler, Martin, The New Methodology,

http://www.martinfowler.com/articles/newMethodology.html, ThoughtWorks Inc., July
2000.
[Fowler, 2001] Fowler, Martin, Cara Taber, Planning and Running an XP Iteration,
http://www.martinfowler.com/articles/planningXpIteration.html, ThoughtWorks Inc.,
January 2001.
[Fowler, 2002] Fowler, Martin, Matthew Foemmel, Continuous Integration,

http://www.martinfowler.com/articles/continuousIntegration.html, ThoughtWorks Inc.,
2002.
[Gamma, 1995] Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides,
Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley,
1995.
[Glass, 2002] Glass, Robert L., Facts and Fallacies of Software Engineering, Addison-
Wesley, 2002.
[Highsmith, 1999] Highsmith, Jim, Adaptive Software Development: A Collaborative

Approach to Managing Complex Systems, Dorset House, 1999.
[Highsmith, 2000] Highsmith, Jim, Retiring Lifecycle Dinosaurs, Software Testing &
Quality Engineering (STQE), (July/August 2000) pp. 22-28.
[Highsmith, 2002] Highsmith, Jim, Agile Software Development Ecosystems, Addison-

Wesley, The Agile Software Development Series, 2002.
[Jacobson, 1999] Jacobson, Ivar, Grady Booch, James Rumbaugh, The Unified Software
Development Process, Addison-Wesley Object Technology Series, 1999.
[Jeffries, 2001] Jeffries, Ron, Ann Anderson, Chet Hendrickson, Extreme Programming
Installed, Addison-Wesley The XP Series, 2001.
[Jones, 1997] Jones, Capers, Programming Languages Table, Release 8.2, Software
Productivity Research, March 1996.
[JUnit, 2001] Beck, Kent, Erich Gamma, JUnit, http://www.junit.org/, 2001.

[Kruchten, 2000] Kruchten, Philippe, The Rational Unified Process: An Introduction,

Second Edition, Addison-Wesley Object Technology Series, 2000.
[Kruchten, 2003] Kruchten, Philippe, Per Kroll, The Rational Unified Process Made
Easy: A Practitioners Guide to the RUP, Addison-Wesley Object Technology Series,
2003.
[Kulak, 2003] Kulak, Daryl, Eamonn Guiney, Use Cases: Requirements in Context,
Second Edition, Addison-Wesley, 2003.
[Larman, 2002] Larman, Craig, Applying UML and Patterns: An Introduction to

Object-Oriented Analysis and Design, Second Edition, Prentice Hall, 2002.
[Larman, 2003] Larman, Craig, Agile and Iterative Development: A Managers Guide,
Addison-Wesley Agile Software Development Series, 2003.
[Leffingwell, 2001] Leffingwell, Dean, Don Widrig, Managing Software Requirements,

Addison-Wesley Object Technology Series, 2001.
[Manifesto, 2001] Manifesto for Agile Software Development,

http://www.agilealliance.org/, 2001.
[Martin, 1991] Martin, J., Rapid Application Development, Macmillan Inc., New York,
1991.
[McBreen, 2002] McBreen, Pete, Questioning Extreme Programming, Addison-Wesley

The XP Series, 2002.
[McConnell, 1996] McConnell, Steve, Rapid Development: Taming Wild Software

Schedules, Microsoft Press, 1996.
[McConnell, 2003] McConnell, Steve, Professional Software Development: Shorter

Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers,
Addison Wesley, 2003.
[Nunes, 1999] Nunes, Nuno Jardim, Joo Falco e Cunha, A Bridge too Far: The
WISDOM Approach, ECOOP99 Workshop on Interactive System Design and Object

Models, Universidade da Madeira, Faculdade de Engenharia da Universidade do Porto,

1999.
[PMBOK, 2000] Project Management Body of Knowledge, http://www.pmi.org/,

Project Management Institute Inc., 2000.
[Poppendieck, 2003] Poppendieck, Mary, Tom Poppendieck, Lean Software

Development: An Agile Toolkit, Addison-Wesley, The Agile Software Development
Series, 2003.
[Ribu, 2001] Ribu, Kirsten, Estimating Object-Oriented Software Projects with Use
Cases, Master of Science Thesis, University of Oslo, Department of Informatics,
November 2001.
[Royce, 1970] Royce, Winston, Managing the Development of Large Software Systems,
Proceedings of IEEE Westcon, 1970.
[Royce, 1998] Royce, Walker, Software Project Management: A Unified Framework,

Addison-Wesley Object Technology Series, 1998.
[RUP, 2002] Rational Unified Process Version 2002.05.00, Copyright Rational

Software Corporation, All Rights Reserved.
[Schenone, 2002] Schenone, Marcelo, AgEnD: Agility Enhanced Development,

Proceedings, JAIIO 31, ASSE, Agosto 2002.
[Schwaber, 2001] Schwaber, Ken, Mike Beedle, Agile Software Development with
Scrum, Prentice Hall, 2001.
[Sinan, 1998] Sinan Si Alhir, UML in a Nutshell, OReilly & Associates, 1998.
[Smith, 2001] Smith, John, A Comparison of RUP and XP, Rational Software White
Paper, 2001.
[Standish, 1994] The Standish Group, The CHAOS Report, The Standish Group
International, 1994.
[Standish, 1996] The Standish Group, Unfinished Voyages: A Follow-Up to The

CHAOS Report, The Standish Group International, 1996.

[Standish, 1999] The Standish Group, CHAOS: A Recipe for Success, The Standish
Group International, 1999.
[Stapleton, 1997] Stapleton, Jennifer, DSDM Dynamic Systems Development Method,

[Sun, 2003] Architecting and Designing J2EE Applications, Copyright 2003 Sun
Microsystems Inc., 2003.
[SWEBOK, 2001] Software Engineering Body of Knowledge, http://www.swebok.org/,

2001.
[Wainstein, 2000] Wainstein, Martn, Intervenciones con Individuos, Parejas, Familias

y Organizaciones, EUDEBA, Universidad de Buenos Aires, 2000.
[Weinberg, 1998] Weinberg, Gerald M., The Psychology of Computer Programming,

Silver Edition, Dorset House, 1998.
[Williams, 2000] Williams, Laurie, Robert R. Kessler, Ward Cunningham, Ron Jeffries,
Strengthening the Case for Pair Programming, IEEE Software, Vol. 17, No. 4
(July/August 2000) pp. 19-25.
[Williams, 2002] Williams, Laurie, Robert R. Kessler, Pair Programming Illuminated,


Links en Internet sobre Metodologas giles
AgEnD Marcelo Schenone: http://www.agend.com.ar/
Agile Alliance Agile Alliance: http://www.agilealliance.com/
Adaptive Software Jim Highsmith: http://www.asd.com/

Development
Crystal Alistair Cockburn: http://crystalmethodologies.org/
DSDM DSDM Consortium: http://www.dsdm.org/
dX Robert Martin:
http://www.objectmentor.com/publications/RUPvsXP.pdf
Extreme Modeling Scott Ambler: http://www.extreme-modeling.com/
FDD Peter Coad, Eric Lefebvre, Jeff De Luca:

http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users-
Guide/Feature_Driven_Development.htm
Peter Coad: http://www.togethercommunity.com/coad-letter/Coad-

Letter-0070.html
SCRUM Ken Schwaber: http://www.controlchaos.com/
Jeff Sutherland: http://jeffsutherland.com/scrum/
Usage-Centered Design Larry Constantine: http://www.foruse.com/
XBreed Mike Beedle: http://www.xbreed.net/
XP Ron Jeffries: http://www.xprogramming.com/
Robert Martin: http://www.objectmentor.com/
Don Wells: http://www.extremeprogramming.org/
Jim Highsmith on Extreme Programming:

http://www.cutter.com/ead/ead0002.html

<<Logo Empresa>>
Descripcin del Proyecto

Documento de Visin
<Versin>
<Autor>
Historia de Revisin
Fecha Versin Descripcin Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1

1. Introduccin .......................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Posicionamiento ................................................................................................................... 2
Situacin Actual ........................................................................................................................................... 2
3. Stakeholders y Usuarios ...................................................................................................... 2
Stakeholders identificados ........................................................................................................................... 2
Usuarios identificados.................................................................................................................................. 2
4. Caractersticas del Producto ............................................................................................... 2
Features de Alto Nivel.................................................................................................................................. 2
5. Otros Requerimientos .......................................................................................................... 2
Requerimientos No Funcionales.................................................................................................................. 3
Restricciones................................................................................................................................................ 3
Reglas del Negocio Clave............................................................................................................................ 3
<<Datos de la empresa>> 1
<<Logo Empresa>>
1. Introduccin
[Descripcin del documento y del contexto del proyecto de desarrollo. Se identifica al Cliente y el
propsito detrs de la construccin del sistema.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
2. Posicionamiento
Situacin Actual
[Descripcin del problema actual que se presenta y la forma en que el sistema beneficiar a los
usuarios mediante una solucin dada.]
3. Stakeholders y Usuarios
Stakeholders identificados
[Tabla que muestra a los stakeholders involucrados en el proyecto. Se da una breve descripcin
de cada uno y se analiza el impacto de este en la solucin.]
Usuarios identificados
[Tabla que muestra a los usuarios que tendr el sistema. Se da una breve descripcin de cada uno
y se analiza las responsabilidades en relacin al sistema en construccin.]
4. Caractersticas del Producto

[A continuacin se detallan las caractersticas del producto en forma de features de alto nivel. Estos
identifican las capacidades que tendr el sistema para cubrir las necesidades de los usuarios.]
Features de Alto Nivel
[Feature 1.]
[Feature 2.]
...
[Feature X.]
5. Otros Requerimientos
[A continuacin se detallan las caractersticas del producto en forma de requerimientos no funcionales
de alto nivel, restricciones a ser impuestas a la solucin y reglas del negocio que determinarn la
descripcin de la arquitectura candidata resultante.]
<<Logo Empresa>>
[Requerimiento No Funcional 1.]

[Requerimiento No Funcional 2.]
...
[Requerimiento No Funcional X.]
Restricciones
[Restriccin 1.]
[Restriccin 2.]
...
[Restriccin X.]
Reglas del Negocio Clave
[Regla del Negocio 1.]

[Regla del Negocio 2.]
...
[Regla del Negocio X.]
<<Logo Empresa>>

Lista de Riesgos
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
2. Riesgos.................................................................................................................................. 2
<<Identificacin del Primer Riesgo>>.......................................................................................................... 2
Descripcin........................................................................................................................................................2
Criticidad............................................................................................................................................................2
Probabilidad de Ocurrencia...............................................................................................................................2
Impacto..............................................................................................................................................................2
Estrategia de Mitigacin ....................................................................................................................................2
Plan de Contingencia ........................................................................................................................................2
<<Identificacin del Segundo Riesgo>>...................................................................................................... 2
...................................................................................................................................................................... 2
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
2. Riesgos
[A continuacin se enumerarn todos los riesgos que presenta el proyecto. En dicha lista deben figurar
tanto los riesgos de management identificados por el Lder de Proyecto, como los riesgos ms tcnicos
identificados por el Arquitecto.]
<<Identificacin del Primer Riesgo>>

Descripcin
[Breve descripcin del riesgo.]
Criticidad
[Indicar el nivel de criticidad en caso de que el riesgo se materialice. El rango puede
estar en una escala de alta, media o baja.]
Probabilidad de Ocurrencia
[Indicar la probabilidad de que ocurra el riesgo en el proyecto. El rango puede estar en
una escala de alta, media o baja.]
Impacto
[El impacto est dado por el producto de la criticidad y la probabilidad de ocurrencia.
En base a esto los riesgos sern priorizados y monitoreados por el Lder de Proyecto y el
Arquitecto. Por ejemplo, un riesgo con criticidad alta y probabilidad de ocurrencia alta
deber ser monitoreado frecuentemente.]
Estrategia de Mitigacin
[Indicar la estrategia a ser utilizada para minimizar el impacto del riesgo en caso que
este se materialice.]
Plan de Contingencia
[Indicar el plan de contingencia que ser tenido en cuenta en caso que la estrategia de
mitigacin no tenga xito.]
<<Identificacin del Segundo Riesgo>>
...
<<Logo Empresa>>

Cdigo y Nombre del Caso de Uso
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Breve Descripcin ................................................................................................................ 2
2. Actores .................................................................................................................................. 2
3. Flujo de Eventos ................................................................................................................... 2
3.1. Flujo Bsico........................................................................................................................................... 2
3.2. Flujos Alternativos................................................................................................................................. 2
3.3. Flujos de Excepcin.............................................................................................................................. 2
4. Requerimientos Suplementarios ......................................................................................... 2
5. Precondiciones ..................................................................................................................... 2
6. Poscondiciones .................................................................................................................... 2
7. Puntos de Extensin ............................................................................................................ 2
8. Diagramas Asociados .......................................................................................................... 2
9. Supuestos y Dudas............................................................................................................... 2
<<Logo Empresa>>
1. Breve Descripcin
[Breve descripcin del propsito del caso de uso. Recordar que el mismo debe dar algn valor a algn
actor del sistema.]
2. Actores
[Enumerar los actores que participan en este caso de uso.]
3. Flujo de Eventos
[A continuacin se describe la secuencia de pasos desde que el actor dispara el caso de uso hasta que la
interaccin llega a su fin.]
3.1. Flujo Bsico

[El flujo bsico representa la interaccin normal del caso de uso. Es la situacin en que todos los
pasos se ejecutan normalmente, sin existir excepciones ni errores.]
3.2. Flujos Alternativos

[Los flujos alternativos se dan ante alternativas complejas dentro de la ejecucin del flujo las
cuales ocurren ante ciertos eventos alternos de la interaccin.]
3.3. Flujos de Excepcin

[Los flujos de excepcin ocurren cuando existen excepciones en la ejecucin del flujo bsico
debida a errores internos de la aplicacin o de la interaccin del usuario con esta.]
4. Requerimientos Suplementarios
[Indicar aquellos requerimientos suplementarios relacionados nicamente con este caso de uso.
Recordar que los requerimientos suplementarios globales van en el SRS]
5. Precondiciones
[Indicar las condiciones que deben darse para que se pueda disparar la ejecucin de este caso de uso.]
6. Poscondiciones
[Indicar como quedar el sistema despus que se termine la ejecucin de este caso de uso.]
7. Puntos de Extensin
[Puntos a partir de los cuales se extiende el flujo bsico de este caso de uso. Relacionado con la relacin
<<extends>> de UML.]
8. Diagramas Asociados
[Colocar aquellos diagramas asociados con este caso de uso. En este punto se puede colocar el modelo
de casos de uso afectado a este caso de uso, diagrama de estado, diagrama de actividad, prototipo de
GUI, etc.]
9. Supuestos y Dudas
[Dejar constancia de los supuestos que se han tomado en la especificacin del casos de uso as como las
dudas que el Analista tiene pendiente y debern ser resueltas con el Cliente.]
<<Logo Empresa>>

Documento de Especificacin de
Requerimientos de Software (SRS)
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Requerimientos Funcionales ............................................................................................... 2
Detalle de Requerimientos Funcionales...................................................................................................... 2
3. Requerimientos Suplementarios ......................................................................................... 2
Requerimientos No Funcionales.................................................................................................................. 2
Restricciones................................................................................................................................................ 2
Reglas del Negocio ...................................................................................................................................... 2
<<Logo Empresa>>
1. Introduccin
Propsito
Referencias
2. Requerimientos Funcionales
Detalle de Requerimientos Funcionales
[A continuacin se enumerarn todos aquellos requerimientos de carcter funcional que tengan

que ver con aspectos ms tcnicos relacionados con la solucin. Los mismos quedan fuera de las
especificaciones de los casos de uso.]
3. Requerimientos Suplementarios
[A continuacin se enumerarn todos aquellos requerimientos no funcionales que son globales a

la aplicacin. Los mismos refieren a las cualidades sistmicas asociadas con: usabilidad,
performance, mantenibilidad, seguridad, tolerancia, etc.]
Restricciones
[A continuacin se enumerarn todas las restricciones que se aplican a la solucin planteada. Las
mismas restringen los grados de libertad al momento de disear una solucin determinada a un
problema.]
Reglas del Negocio
[A continuacin se enumerarn todas aquellas reglas del negocio globales a la aplicacin. Las
mismas tienen que ver con las polticas y/o condiciones que se dan en los procesos del negocio y
que deben ser implementadas en la solucin.]
<<Logo Empresa>>

Descripcin de Arquitectura
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Objetivos Arquitectnicos ................................................................................................... 2
3. Vista de Casos de Uso ......................................................................................................... 2
4. Vista Lgica........................................................................................................................... 2
5. Vista de Despliegue .............................................................................................................. 2
6. Bibliografa ............................................................................................................................ 2
<<Logo Empresa>>
1. Introduccin
Propsito
Referencias
2. Objetivos Arquitectnicos
[Se mencionarn los requerimientos no funcionales y restricciones que guiaron el trabajo del arquitecto.
Los mismos estarn basados en lo que fue documentado en el SRS, pero haciendo nfasis sobre como la
arquitectura candidata resuelve cada uno de estos.]
3. Vista de Casos de Uso
[Es una descripcin de una vista de la arquitectura del software a travs de los casos de usos.
Representa el conjunto de escenarios de la iteracin que describen o representan la funcionalidad
requerida para el proyecto.]
4. Vista Lgica
[Es una descripcin de una vista de la arquitectura del software a travs de la evaluacin realizada de
los requerimientos funcionales y no funcionales. Representa la organizacin en paquetes de servicios y
subsistemas y la organizacin de estos subsistemas en layers. Tambin se describen aqu las
realizaciones de caso de uso ms importantes.]
5. Vista de Despliegue
[La vista de despliegue permitir describir la distribucin fsica posible de los diferentes nodos de
procesamiento describiendo adems el modelo de crecimiento de la solucin.]
6. Bibliografa
[En este apartado se podr mencionar la bibliografa de donde se puede obtener ms informacin de los
elementos mencionados en este documento.]
<<Logo Empresa>>

Caso de Prueba
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Definicin de Casos de Prueba ........................................................................................... 2
Nmero Caso de Prueba ............................................................................................................................. 2
Ttulo Caso de Prueba ................................................................................................................................. 2
ID de Caso de Uso....................................................................................................................................... 2
Mdulo/Componente.................................................................................................................................... 2
Funcionalidad............................................................................................................................................... 2
Modo de Prueba........................................................................................................................................... 2
Preparacin de Configuracin ..................................................................................................................... 2
Procedimiento de la Prueba ........................................................................................................................ 2
Resultados Esperados................................................................................................................................. 2
<<Logo Empresa>>
1. Introduccin
Propsito
Referencias
2. Definicin de Casos de Prueba
Nmero Caso de Prueba

[Nmero del caso de prueba usado para identificacin y posteriormente para tener estadsticas.]
Ttulo Caso de Prueba

[Ttulo descriptivo del caso de prueba.]
ID de Caso de Uso
[Identificacin del caso de uso. Por ejemplo, podra ser algo como CUXXX Alta de Usuarios.]
Mdulo/Componente
[Mdulo de la aplicacin que esta siendo probado.]
Funcionalidad
[Funcionalidad de la aplicacin que se prueba.]
Modo de Prueba
[Manual o automtico (mediante algn script o robot).]
Preparacin de Configuracin
[Preparacin de configuracin para llevar a cabo la prueba. En este punto colocaremos
cualquier infraestructura o configuracin o carga de datos que requiera la prueba.]
Procedimiento de la Prueba
[Secuencia de pasos para llevar a cabo la prueba.]
Resultados Esperados
[Resultados esperados por la prueba.]
<<Logo Empresa>>

Nota de Entrega
<Versin>
<Autor>
Historia de Revisin
Tabla de Contenidos

1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Informacin de la Entrega .................................................................................................... 2
Overview ...................................................................................................................................................... 2
3. Nuevos Features................................................................................................................... 2
Lista de Nuevos Features ............................................................................................................................ 2
Features ....................................................................................................................................................... 2
4. Bugs Conocidos o Limitaciones ......................................................................................... 2
Lista de Bugs Conocidos ............................................................................................................................. 2
Bugs ............................................................................................................................................................. 2
Lista de Limitaciones ................................................................................................................................... 2
Limitaciones ................................................................................................................................................. 3
<<Logo Empresa>>
1. Introduccin
Propsito
Referencias
2. Informacin de la Entrega
Overview
[Breve descripcin del contenido de la entrega que se lleva a cabo. Se enumeran todos los
artefactos que la misma incluye, identificando el nmero de versin donde corresponda.]
3. Nuevos Features
Lista de Nuevos Features

[Listado de los features que estn contenidos en la versin que se entrega al Cliente. Orientado a
entregables de implementacin.]
Features
[Feature 1.]
[Feature 2.]
...
[Feature X.]
4. Bugs Conocidos o Limitaciones
Lista de Bugs Conocidos

[Listado de los bugs conocidos que no han podido ser corregidos para la corriente entrega. Los
mismos sern identificados de forma que el Cliente los conozca y no necesite reportarlos
nuevamente al equipo.]
Bugs
[Bug 1.]
[Bug 2.]
...
[Bug X.]
Lista de Limitaciones
[Listado de las limitaciones de la versin entregada. Se detallarn aquellas cuestiones que
quedaron fuera de la implementacin corriente.]
<<Logo Empresa>>
Limitaciones
[Limitacin 1.]
[Limitacin 2.]
...
[Limitacin X.]
Introduccin a
las metodologas
giles
Otras formas de analizar y desarrollar
Jorge Fernndez Gonzlez

PID_00184468
CC-BY-NC-ND PID_00184468 Introduccin a las metodologas giles
Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia de
Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa de Creative Commons. Podis copiarlos, distribuirlos
y transmitirlos pblicamente siempre que citis el autor y la fuente (FUOC. Fundacin para la Universitat Oberta de Catalunya),
no hagis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/
licenses/by-nc-nd/3.0/es/legalcode.es
ndice
Introduccin............................................................................................... 5
Objetivos....................................................................................................... 7
1. La necesidad de ser giles................................................................ 9

1.1. El ''Manifiesto gil'' ..................................................................... 10
1.2. Metodologas giles ms importantes ......................................... 13
1.2.1. SCRUM ........................................................................... 13
1.2.2. Dynamic Systems Development Method ...................... 14
1.2.3. Crystal Methodologies ................................................... 15
1.2.4. Feature-Driven Development ........................................ 15
1.2.5. Adaptive Software Development ................................... 16
1.3. Cundo puedo aplicar una metodologa gil? .......................... 16
1.4. Han muerto las metodologas tradicionales? RUP is RIP? ........ 18
2. EXtreme Programming (XP)........................................................... 19

2.1. Las variables XP: coste, tiempo, calidad y alcance ..................... 21
2.2. Los cuatro valores: comunicacin, simplicidad,
realimentacin y coraje .............................................................. 23
2.3. Las doce prcticas bsicas de XP ................................................ 24
2.3.1. Diseo simple ................................................................ 25
2.3.2. Refactorizacin ............................................................... 25
2.3.3. Test ................................................................................. 26
2.3.4. Estndares de codificacin ............................................ 27
2.3.5. Propiedad colectiva del cdigo ...................................... 28
2.3.6. Programacin por parejas .............................................. 28
2.3.7. Integracin continua ..................................................... 29
2.3.8. 40 horas semanales ........................................................ 30
2.3.9. Metfora del negocio ..................................................... 30
2.3.10. Cliente in situ.................................................................. 30
2.3.11. Entregas frecuentes ........................................................ 31
2.3.12. Planificacin incremental .............................................. 31
2.4. El ciclo de vida de la metodologa XP ........................................ 31
2.4.1. La fase de exploracin ................................................... 33
2.4.2. La fase de planificacin ................................................. 34
2.4.3. La fase de iteraciones ..................................................... 35
2.4.4. La fase de produccin ................................................... 36
2.4.5. La fase de mantenimiento ............................................. 37
2.4.6. La fase de muerte del proyecto ..................................... 37
2.5. Los diferentes roles dentro de XP ............................................... 37
2.6. El entorno de trabajo .................................................................. 38
2.7. Qu dicen los detractores de XP ................................................. 39

2.8. Un ejemplo de XP ...................................................................... 40
2.8.1. Fase de exploracin ....................................................... 41
2.8.2. Fase de planificacin ..................................................... 43
2.8.3. Fase de iteraciones ......................................................... 45
2.8.4. Fase de produccin ........................................................ 47
2.8.5. Fase de mantenimiento ................................................. 48
2.8.6. Fase de muerte ............................................................... 49
3. Ser giles no es solo programar giles......................................... 50
Resumen....................................................................................................... 51
Actividades.................................................................................................. 53
Ejercicios de autoevaluacin.................................................................. 53
Solucionario................................................................................................ 54
Glosario........................................................................................................ 55
Bibliografa................................................................................................. 56
CC-BY-NC-ND PID_00184468 5 Introduccin a las metodologas giles
Introduccin
Algunos de vosotros os estaris preguntado qu significa eso de "gil" y si con-

lleva de forma intrnseca un poco de "hacer mal las cosas" o de "dejarlo a me-
dias". Cierto es que durante la asignatura casi todo lo que hemos intentado
ensear es precisamente a ser metdicos, rigurosos y estrictos cientficamente
hablando, aunque no menos cierto es que hemos intentado inculcaros tam-
bin algo de espritu crtico. Pues bien, es precisamente a este espritu crtico
al que tenemos que apelar en este mdulo. Para intentar comprender que ser
"giles" no significa renunciar a formalismos ni dejar de ser estrictos y riguro-
sos.
Muchos profesionales que nos dedicamos a los sistemas de informacin hemos

dicho en alguna ocasin algo semejante a esto "eso es en teora y queda muy
bonito pero en la prctica no puedes perder tanto tiempo haciendo el anlisis
porque cuando acabas el sistema ya ha cambiado y el cliente se ha aburrido".
Yo mismo soy consciente de lo fcil que se puede caer en esta dinmica cuando
la presin se nos echa encima y los plazos de entrega se acercan.
La alta competitividad actual hace que los sistemas de informacin se tengan

que desarrollar de forma rpida para adaptarse a la organizacin. Las prisas
hacen que lo primero que se deseche en esta carrera "loca" hacia un rpido
desarrollo sea un anlisis exhaustivo y se sustituye por uno superficial o sim-
plemente se elimina. ste es sin duda elgranerror, deseamos tener un sistema
desarrollado rpidamente pero con lo que realmente nos encontramos entre
las manos es con un sistema lleno de errores, inmanejable y que no se puede
mantener.
Es difcil cambiar las reglas del mercado mundial, as que lo que se ha pensado
es adaptar las metodologas de especificacin y desarrollo a este entorno cam-
biante y lleno de presiones, en el que obtener un resultado rpido, algo que se
pueda ver, mostrar y sobre todo utilizar, se ha vuelto crucial para el xito de
las organizaciones. La metodologa necesariamente ha de ser gil, debe tener
un ciclo corto de desarrollo y debe incrementar las funcionalidades en cada
iteracin del mismo preservando las existentes, ayudando al negocio en lugar
de darle la espalda.
Es para este entorno para el que han nacido las metodologas giles.
Las metodologas giles no son la gran solucin a todos los problemas

del desarrollo de aplicaciones, ni tan siquiera se pueden aplicar en todos
los casos, pero s que nos aportan otro punto de vista de cmo se pueden
llegar a hacer las cosas, de forma ms rpida, ms adaptable y sin tener
que perder la rigurosidad de las metodologas clsicas.
El objetivo de este mdulo no es otro que mostrar que no siempre hay un

camino nico para hacer bien las cosas, no todo es blanco o negro, sino que
hay una gran gama de grises. Esos tonos grises tambin los tenemos en las
metodologas de especificacin y desarrollo.
En esta Introduccin a las metodologas giles pretendemos mostrar el actual aba-

nico existente de este tipo de metodologas, para pasar luego a centrarnos en
una que est teniendo especial xito entre los profesionales del sector, la Ex-
treme Programming, ms conocida por metodologa XP.
A medida que vayamos viendo esta metodologa, iremos haciendo hincapi en

las ventajas y en los inconvenientes, concluiremos con un ejemplo de aplica-
cin de XP en un entorno basado en Java. La eleccin de Java no es arbitraria,
responde al hecho de que la idea de "agilidad" en el desarrollo de aplicaciones
esta muy ligada a la de "software libre", sin duda debido a que los ncleos im-
pulsores de ambas ideas son muy cercanos.
Finalizaremos mostrando cmo la idea de "gil" se est introduciendo con fuer-

za en diferentes mbitos, como es el caso del diseo de bases de datos y obje-
tos, en la documentacin, etc.
Objetivos
El objetivo general de este mdulo es que adquiris una primera visin de las
metodologas giles para que as tengis la posibilidad de reconocer cundo
un proyecto es propicio para usarlas. El objetivo general se descompone en los
siguientes objetivos parciales, que el estudiante debe conseguir:
1. Adquirir los conceptos del manifiesto gil.
2. Conocer las principales metodologas giles actuales.
3. Desarrollar un espritu crtico que le permita aplicar la metodologa ms

adecuada a cada proyecto en concreto.
4. Conocer en detalle la metodologa gil que est teniendo mayor xito:

Extreme Programming.
5. Vislumbrar hacia dnde puede ir la metodologa de la ingeniera del soft-

ware en los prximos aos.
1. La necesidad de ser giles
gil (del lat. Agilis).
1) adj. Ligero, pronto, expedito.
2) adj. Dicho de una persona o de un animal: que se mueve o utiliza sus

miembros con facilidad y soltura.
3) adj. Se dice tambin de estos miembros y de sus movimientos, y de

otras cosas. Luces giles. Prosa gil.
Diccionario de la Real Academia Espaola
"Que se mueve o utiliza sus miembros con facilidad y soltura". A priori no

parece un adjetivo muy adecuado para una metodologa. Para buscar el origen
de ese adjetivo, debemos remontarnos al sujeto inicial que lo posea que no
es otro que la organizacin o empresa. Es sta la que debe ser gil, la que
debe mover todos sus "miembros" con facilidad y soltura, en una orquestacin
que le permita sobrevivir en el mundo altamente competitivo en el que nos
encontramos. Para ello necesita de un "cerebro", de un sistema de informacin
que debe crecer segn la demanda de necesidades que se le exijan, y que debe
crecer de una forma rpida y coherente, de manera que la organizacin pueda
adaptarse rpidamente a los cambios producidos en su entorno.
La competencia cada da es ms feroz y los ritmos de cambios son ms rpidos.

Las organizaciones tendrn que responder de forma inmediata a estos cambios
si quieren sobrevivir, tendrn que evolucionar en un plazo corto de tiempo.
Los sistemas de informacin (SI) no se pueden quedar atrs, las organizaciones
dependen de ellos para funcionar y no deben ser un lastre, sino una ventaja
competitiva. El papel de los SI y su velocidad de adaptacin a los cambios
marcar la diferencia entre una empresa prspera y una en declive. Los SI ten-
drn que ayudar a que esta evolucin continua no slo sea una realidad, sino
que lo sea con el mnimo coste de recursos posible. Han de permitir que las
organizaciones evolucionen de forma eficaz, eficiente y, cmo no, gil.
As pues, de forma transitiva, si la organizacin ha de ser gil, y el SI que la

controla ha de ser gil, que menos que la metodologa para desarrollar partes
del SI tambin sea gil.
Pero cuando realmente naci el adjetivo gil aplicado al desarrollo de soft-

ware fue en febrero de 2001, en Snowbird Ski Resort de UTAH (EE.UU.). Se
reunieron para descansar, esquiar y, ya que estaban, conversar, un grupo de
17 expertos de la industria del software para, precisamente, ver qu se poda
hacer para adecuar las metodologas a las necesidades de la industria. Asistie-

ron representantes de diferentes metodologas como Extreme Programming,
SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven De-
velopment, que ya estaban ofreciendo una alternativa a los desarrollos "tradi-
cionales" caracterizados por la rigidez y la documentacin exhaustiva en cada
una de las etapas y que se haban mostrado inadecuados para los proyectos de
pequea envergadura (y en ocasiones incluso para los medianos).
Tras esta reunin, se crearon dos cosas que han dado mucho que hablar en Webs complementarias
los ltimos aos, la primera de ellas es el "Manifiesto gil para el desarrollo de
Podis ver el contenido
software" que recoge la filosofa de las metodologas giles. de "Manifiesto gil para
el desarrollo de software"
y "The Agile Alliance"en
La segunda de ellas es una organizacin sin nimo de lucro "The Agile Allian- las webs siguientes: http://
www.agilemanifesto.org/
ce", dedicada a promover los conceptos relacionados con el desarrollo gil de
(http://
software y ayudar a las organizaciones y empresas a adoptar la agilidad. www.agilealliance.org/)
1.1. El ''Manifiesto gil''
En el "Manifiesto gil" se definen los cuatrovalores por las que se deberan

guiar las metodologas giles.
"Estamos buscando mejores maneras para desarrollar software y ayudar a otros a desarro-
llarlo. En este trabajo valoramos:
Al individuo y sus interacciones ms que al proceso y las herramientas.
Desarrollar software que funciona, ms que obtener una buena documentacin.
La colaboracin con el cliente ms que la negociacin de un contrato.
Responder a los cambios ms que seguir una planificacin.
De esta manera, mientras mayor valor tengamos en la parte derecha ms apreciaremos

los de la parte izquierda."
"Manifiesto gil"
Firmado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cun-
ningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,
Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland
y Dave Thomas.
Veamos qu significa cada uno de estos valores:
1)Alindividuoysusinteraccionesmsquealprocesoylasherramientas.
Sin duda, la herramienta fundamental de la ingeniera del software y del desa-

rrollo de aplicaciones es el cerebro humano. Unas jornadas maratonianas de
catorce horas de trabajo van en detrimento de la calidad del producto final.
Pero una persona sola no realiza un proyecto, necesita de un entorno en el que
desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones
deben tambin cuidarse. Un factor clave para el xito es construir un buen
equipo, que se lleven bien entre ellos, y que adems sepan cmo construir su
propio entorno de desarrollo. Muchas veces se comete el error de construir
primero el entorno y esperar que el equipo se adapte a l. Esto nos resta efi-
ciencia, es mejor que el equipo lo configure sobre la base de sus necesidades
y sus caractersticas personales.
Adems, las interacciones que haga el equipo con el usuario final deberan
ser igual de fluidas siendo este usuario un miembro ms del equipo, con un
objetivo comn, que es conseguir que el proyecto funcione y sea til para l.
Si todo esto funciona bien, es obvio que la eleccin de las herramientas y el

proceso mismo de desarrollo pasan a estar en un plano totalmente secundario
en la ecuacin del xito del proyecto.
2)Desarrollarsoftwarequefuncionamsqueobtenerunabuenadocu-
mentacin.
Uno de los objetivos de una buena documentacin es poder ir a consultarla

cuando haya que modificar algo del sistema. Sin duda es un arma de doble filo,
una buena documentacin actualizada en cada modificacin y bien manteni-
da al da permite saber el estado de la aplicacin y cmo realizar las modifica-
ciones pertinentes, pero son pocos los que con las presiones externas de tiem-
po y dinero acaban actualizando la documentacin. Generalmente, cuando se
tiene que arreglar un programa porque algo falla, nos concentramos en que
funcione ya que es muy posible que haya usuarios parados (incluso enfadados)
y que la empresa o la organizacin est perdiendo dinero; en estos casos, ni
nos paramos a mirar detenidamente la documentacin ni, cuando se acaba de
arreglar, nos ponemos a actualizarla.
En la filosofa gil, lo primordial es evitar estos fallos, centrar nuestro tiempo

en asegurar que el software funciona y que se ha testeado exhaustivamente, e
intentar reducir la creacin de documentos "intiles", de stos que acaban no
mantenindose, ni tan siquiera consultndose. La regla no escrita es nopro-
ducirdocumentossuperfluos, y slo producir aquellos que sean necesarios
de forma inmediata para tomar una decisin importante durante el proceso
de desarrollo. Estos documentos deben "ir al grano", ser cortos y centrarse en
lo fundamental, olvidndonos de los circunloquios que no aportan nada a la
comprensin del problema.
3)Lacolaboracinconelclientemsquelanegociacindeuncontrato.
La consultora informtica de los ltimos aos se ha convertido en una lucha

a muerte entre el proveedor del servicio y el cliente que lo contrata. Por una
parte, el cliente intenta que se hagan el mayor nmero de funcionalidades
con el mismo dinero, por otra parte, el consultor intenta que por ese dinero
slo se realicen las funcionalidades contratadas inicialmente. En las reuniones
de seguimiento de los proyectos es fcil or frases del tipo "esta modificacin
no entra en el contrato" respondida generalmente por la tan tpica "pues yo
ya no tengo ms presupuesto y as no podemos trabajar". Al final, este tipo
de proyectos hacen que el consultor informtico sea un hbrido entre analista

y abogado, que desarrolla habilidades legales para salvaguardarse en caso de
conflicto jurdico.
Sin embargo, para que un proyecto tenga xito es fundamental la complicidad

y el contacto continuo entre el cliente y el equipo de desarrollo. El cliente
debe ser y sentirse parte del equipo. De esta manera, ambos entendern las
dificultades del otro y trabajarn de forma conjunta para solucionarlo.
4)Responderaloscambiosmsqueseguirunaplanificacin.
Una organizacin cambia constantemente, se adapta a las necesidades del mer-

cado y reorganiza sus flujos de trabajo para ser ms eficiente. Es difcil, pues,
que en el desarrollo de un proyecto, ste no sufra ningn cambio, ya que es
seguro que las necesidades de informacin de la empresa habrn cambiado. Y
no slo esto, sino que las posibilidades econmicas de la misma pueden influir
sobre nuestro proyecto, bien sea agrandndolo o bien sea reducindolo. Son
muchos los factores que alterarn nuestra planificacin inicial del proyecto.
Si no la adaptamos a estos cambios, corremos el riesgo de que, cuando aca-
bemos, nuestra aplicacin no sirva para nada y el cliente se haya gastado el
dinero en vano. La habilidad de responder a los cambios de requisitos, de tec-
nologa, presupuestarios o de estrategia, marca sin duda el camino del xito
del proyecto.
Como consecuencia de estos cuatrovalores, el Manifiesto gil tambin enun-

cia los doceprincipios que caracterizan un proceso gil diferencindolo de
otro tradicional donde este enfoque no se haba aplicado lo suficiente; siempre
se haba dejado implcito pero sin hacer hincapi en ellos.
1) La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
2) Dar la bienvenida a los cambios incluso al final del desarrollo. Los

cambios le darn una ventaja competitiva a nuestro cliente.
3) Hacer entregas frecuentes de software que funcione, desde un par de

semanas a un par de meses, con el menor intervalo de tiempo posible
entre entregas.
4) Las personas del negocio y los desarrolladores deben trabajar juntos

diariamente a lo largo de todo el proyecto.
5) Construir el proyecto en torno a individuos motivados. Darles el en-

torno y el apoyo que necesitan y confiar en ellos.
6) El dilogo cara a cara es el mtodo ms eficiente y efectivo para co-

municar informacin dentro de un equipo de desarrollo.
7) El software que funciona es la principal medida del progreso.
8) Los procesos giles promueven un desarrollo sostenido. Los promo-

tores, usuarios y desarrolladores deben poder mantener un ritmo de tra-
bajo constante de forma indefinida.
9) La atencin continua a la calidad tcnica y al buen diseo mejoran

la agilidad.
10) La simplicidad es esencial. Se ha de saber maximizar el trabajo que

no se debe realizar.
11) Las mejores arquitecturas, requisitos y diseos surgen de los equipos

que se han organizado ellos mismos.
12) En intervalos regulares, el equipo debe reflexionar con respecto a

cmo llegar a ser ms efectivo, y ajustar su comportamiento para con-
seguirlo.
Llegados a este punto, podemos intuir que las formas de hacer las cosas en la
ingeniera del software estn cambiando, adaptndose ms a las personas y a
las organizaciones en las que han de funcionar las aplicaciones.
Estamos en la antesala de una revolucin? Posiblemente.
1.2. Metodologas giles ms importantes
Son muchas las metodologas que poseen el calificativo de giles; algunas de

ellas exploran diferentes principios para conseguir el objetivo de satisfacer ple-
namente las necesidades del sistema de informacin que se intenta implemen-
tar. Veamos algunas de las ms importantes.
1.2.1. SCRUM
SCRUM es una metodologa que naceajenaaldesarrollodelsoftware, de Principio de requisitos

hecho sus principios fundamentales fueron desarrollados en procesos de rein- indefinidos de Humphrey
geniera por Goldratt, Takeuchi y Nonaka en la dcada de 1980. Para un nuevo aplicativo, los
requerimientos no sern total-
mente conocidos hasta que el
Podramos decir que SCRUM se basa en cierto "caoscontrolado" pero esta- usuario no lo haya usado.
blece ciertos mecanismos para controlar esta indeterminacin, manipular lo
impredecible y controlar la flexibilidad.
Lema de Wegner
Se establecen tres fases: Es imposible definir completa-

mente un sistema iterativo.
1) pre-juego,
2) juego y
3) post-juego.
En el pre-juego se definen y/o revisan las funcionalidades que ha de tener el El principio de

sistema, en el juego se distribuyen las tareas para cada miembro del equipo, se incertidumbre de Ziv
trabaja duro y se intenta conseguir el objetivo. Todos los miembros del equipo En la ingeniera del software:
han de participar en una reunin diaria que en ningn caso deber exceder los la incertidumbre es inherente
e inevitable en el proceso de
30 minutos. En la fase de post-juego se evala la entrega de funcionalidades, desarrollo de aplicaciones.
se ven las tareas pendientes, se evala el progreso del proyecto y se redefine el
tiempo de entrega del mismo si fuera necesario.
1.2.2. Dynamic Systems Development Method
Nace en 1994 con el objetivo de crear una herramienta RAD (rapid applications DSDM
development) unificada, mediante la definicin de un framework de desarrollo
Se origin en Inglaterra y se
(sin propietario ni nimo de lucro) para los procesos de produccin de soft- ha ido extendiendo por Euro-
ware. pa (no tanto por EE.UU.). Exis-
te una organizacin que se en-
carga de su mantenimiento y
desarrollo llamada DSDM Con-
sortium.
DSDM se ha desarrollado teniendo como ideas fundamentales:
Nada es construido a la perfeccin a la primera.
La vieja regladel80-20 es cierta (el 80% de las funcionalidades del

proyecto se realizan con el 20% del tiempo, y el 20% restante, los
detalles, consumen el 80% del tiempo restante).
Es improbable que alguien conozca todos los requisitos del sistema

desde el primer da.
DSMD propone cinco fases, de las que slo las tres ltimas son iterativas a
pesar de que hay retroalimentacin en todas las fases.
a)Estudiodelaviabilidad. Lo primero que se evala es si DSDM se puede

o no aplicar al proyecto.
b)Estudiodelnegocio. Se estudia el negocio, sus caractersticas y la tecno-

loga.
c)Modeladofuncional. En cada iteracin se planean los procesos funcionales

del negocio sobre el prototipo.
d) Diseo y construccin. Aqu es donde se construye la mayor parte del

sistema. El prototipo se vuelve apto para que los usuarios puedan utilizarlo.
e)Implementacin. Pasamos de un prototipo a un sistema de produccin. Se

entrena a los usuarios para que lo usen.
La idea dominante en DSDM es contraria a la intuicin inicial. En es-

ta metodologa, tiempo y recursos se mantienen como constantes y
se ajusta la funcionalidad de acuerdo con ello. Es decir, la idea no es:
"cunto me va a costar desarrollar este sistema?", sino que ms bien
es: "con este tiempo y estos recursos cuntas de las funcionalidades del
sistema puedo hacer?".
1.2.3. Crystal Methodologies
Nosetratadeunanicametodologa sino de un conjunto de ellas centradas Web complementaria

en las personas que tienen que desarrollar el software, elequipoeslabase de
http://alistair.cockburn.us/
estas metodologas creadas por Alistair Cockburn. crystal/crystal.html
Desarrollar aplicaciones ha de ser como un juego en el que todos cooperan,

aportan su parte de invencin y se comunican. Por qu olvidamos esta parte?
Crystal establece una serie de polticasdetrabajoenequipo(Methods) orien-

tadas a fomentar la mejora de estas habilidades. Dependiendo del tamao del
equipo, se establece una metodologa u otra designadas por color: Crystal Clear
(para 3-8 personas), Crystal Yellow (para 10-20 personas), Crystal Orange (para
25-50), etc.
Ejemplo
No es lo mismo cocinar para cuatro personas que para veinte; no es lo mismo planificar
un fin de semana para dos personas que para cuarenta, entonces por qu utilizamos la
misma metodologa para un grupo de tres desarrolladores que para un grupo de quince?
1.2.4. Feature-Driven Development
Impulsado por Jeff de Luca y Meter Coad, Feature-Driven Development (FDD)

se basa en un ciclomuycortodeiteracin, nunca superior a dos semanas, y
en el que el anlisis y los desarrollos estn orientados a cumplir unalistade
"caractersticas" (features) que tiene que tener el software a desarrollar.
Ejemplos de
Una "caracterstica": ''caractersticas''
Ha de ser muy simple, y poco costosa de desarrollar, entre uno y Calcular el balance de situa-
cin.
diez das. Conceder un crdito a un
cliente de un banco.
Ha de aportarle valor al cliente y ser relevante para su negocio. Comprobar la validez del
Debe poderse expresar en trminos de <accin> <resultado> <obje- PIN de una tarjeta.
to>.
La metodologa sigue cinco fases iterativas: Desarrollo/Modificacin de un Mo-

delo Global; Creacin/Modificacin de la lista de "caractersticas"; Planifica-
cin; Diseo de la caracterstica, e Implementacin de la caracterstica.
1.2.5. Adaptive Software Development
Esta metodologa parte de la idea de que las necesidades del cliente son siem- Ejemplo
pre cambiantes durante el desarrollo del proyecto (y posteriormente a su en-
La incertidumbre y el cambio
trega). Su impulsor es Jim Highsmith, la novedad de esta metodologa es que continuo son el estado natu-
en realidad noesunametodologadedesarrollodesoftware, sino un m- ral de los sistemas de informa-
cin, pero parece ser que mu-
todo (como un caballo de troya) a travs del cual inculcar una cultura adapta- chas organizaciones an no
son conscientes de ellos. La
tiva a la empresa, ya que su velocidad de adaptacin a los cambios marcar la idea de "finalizar" un proyecto
carece de sentido porque debe
diferencia entre una empresa prspera y una en declive. seguir adaptndose.
Los objetivos de esta metodologa son cuatro:
1) Concienciar a la organizacin de que debe esperar cambio e incertidumbre

y no orden y estabilidad.
2) Desarrollar procesos iterativos de gestin del cambio.
3) Facilitar la colaboracin y la interaccin de las personas a nivel interperso-
nal, cultural y estructural.
4) Marcar una estrategia de desarrollo rpido de aplicaciones pero con rigor
y disciplina.
1.3. Cundo puedo aplicar una metodologa gil?
Ya hemos visto una serie de metodologas giles, nos hemos dejado en el tin-
tero muchas otras (lean development, pragmatic programming, etc.), pero an no
hemos visto cundo debemos utilizar una metodologa gil.
Cmo? No es siempre? Pues no. Como casi todo en esta vida, depende. De-
pende de cada proyecto en concreto, cada uno necesita de una metodologa
adecuada a l que le garantice el xito. Necesita que se adecue no slo a sus
funcionalidades a desarrollar, sino adems al equipo de desarrollo, a los recur-
sos disponibles, al plazo de entrega, al entorno socio-cultural, etc.
Un buen profesional no debera cerrarse en una sola metodologa de

desarrollo, debera analizar el proyecto en concreto y ver cul de todas
las existentes sera la ms adecuada a su proyecto. Y si ninguna le satis-
face plenamente, debera de ser capaz de adaptarlas. Las metodologas
son para ayudarnos, pero nosotros debemos decidir cundo y cmo es
mejor aplicarlas.
Aun as, existen algunas reglas bsicas, de "sentido comn", para discernir si
debemos aplicar una metodologa tradicional o una metodologa gil. Pero
recordad que son simplemente una gua, no un mandamiento.
Primero debis responder a las siete preguntas siguientes:
1)Cmoesdegrandevuestroproyecto? Si es muy grande y/o involucra a

muchas personas en el equipo, lo mejor es que se utilicen metodologas ms
estrictas y que se basen en la planificacin y control del proyecto. Si se trata de
un proyecto pequeo y/o con un equipo reducido de desarrollo, de tres a ocho
personas, tenis una oportunidad de experimentar con los mtodos giles.
2)Vuestrosrequisitossondinmicos? Si os encontris ante un mbito de Reworking

actuacin donde los flujos de negocio estn cambiando constantemente y te-
Son aquellas modificaciones
nis que adaptarlos, como podra ser una gestin de fuerza de ventas, entonces que se realizan en la aplicacin
la metodologa gil os ayudar a adaptaros. Si estis en un mbito en el que el debido a los errores cometidos
durante la codificacin. No se
dinamismo es escaso, por ejemplo, en la creacin de un sistema de contabili- trata de ampliaciones, sino de
volver a realizar el trabajo por
dad, quizs deberais utilizar una metodologa orientada al plan que contem- no cumplir la calidad necesa-
ria.
ple los cambios previsibles y que os asegure minimizar el reworking.
3)Qupasasivuestrosistemafalla? Si os encontris en un sistema crtico

en el que cualquier fallo involucra prdidas humanas o grandes cantidades de
dinero, por favor, no utilicis las metodologas giles. Si estis diseando un
sistema para controlar un bistur lser, no hay lugar para muchas pruebas, lo
mejor es que funcione a la primera y las metodologas clsicas garantizan la
calidad.
4)Vuestroclientetienetiempoparadedicarloalproyecto? Si no vamos
a conseguir que nuestro cliente se involucre en la creacin de un sistema que
en el fondo es para l, nos ser imposible aplicar una metodologa gil. En
este caso lo mejor es utilizar una metodologa en cascada con un gran anlisis
inicial.
5)Cuntosjniorstenisenvuestroequipodedesarrollo? Las metodolo-

gas giles requieren de una gran madurez, experiencia y una dosis de talen-
to. Deben ser equipos con gente seniors o semi-seniors. Si vuestro equipo lo
constituyen principalmente jniors, lo mejor es que no lo intentis con las
metodologas giles.
6)Culeslaculturaempresarialdelaempresaenlaquesevaadesarrollar
elproyecto? Las metodologas giles requieren de cierto ambiente "informal",
que fomente la comunicacin de igual a igual. Si la organizacin en la que se
quiere desarrollar el proyecto tiene un alto grado de ceremonia y jerarquas
estrictas, no deberais utilizar las metodologas giles.
7)Osapetece? Hay que saber si realmente se tienen ganas de probar una me-
todologa gil. Aprender cosas nuevas supone casi siempre un nuevo sacrificio.
Si vuestro equipo es pequeo y est formado mayoritariamente por gen-

te con talento y experiencia, si el cliente final est involucrado y no
impone barreras de comunicacin, si los requisitos son altamente cam-
biantes, si no es proyecto crtico y no es demasiado grande, y os apetece
probar una metodologa gil, no lo dudis, es el momento de experi-
mentar esta forma de disear y crear aplicaciones.
1.4. Han muerto las metodologas tradicionales? RUP is RIP?
Sin duda, la respuesta es no; siguen muy vivas y muy necesarias para grandes
proyectos con grandes equipos de desarrollo o para entornos crticos como
hemos visto antes, pero, sin embargo, ahora tienen una serie de competido-
res en el mbito de los proyectos ms manejables y que requieren de rpida
adaptacin y de resultados frecuentes.
De las metodologas clsicas la ms famosa es RUP (rational unified process), al-

gunos podran aseverar que se opone radicalmente a lo que hemos visto has-
ta ahora, pero la realidad es que, como ya hemos dicho, cada proyecto tiene
su metodologa propia y en muchos casos mltiples metodologas pueden co-
existir en el mismo proyecto. Rational ha trabajado estrechamente con DSDM
Consortium y han creado documentos conjuntos que demuestran la compa-
tibilidad del modelo DSDMconRUP.
Existen mltiples estudios de cmo utilizar UML dentro de la filosofa de

eXtremeProgramming; a pesar de que XP desenfatiza el uso de diagramas
innecesarios, no hace falta disear cada clase, sino las ms representativas y/
o complejas. El usodepatrones no est prohibido en las metodologas giles,
pero s que est quizs menos extendido, ya que se prioriza una entrega rpida
del producto y el anlisis de patrones puede ralentizar el ciclo. Pero sin duda
los patrones ms repetitivos y extendidos deben utilizarse. Podemos disponer
de una implementacin de los mismos como parte de las herramientas con
las que vamos a construir nuestro sistema a pesar de que no nos pongamos a
analizar los patrones especficos del mismo.
Como podis ver, cada proyecto, e incluso cada parte de un proyecto,

debe tener su propia metodologa independientemente de que sea gil,
o que sea orientada al plan; lo importante es que nos sirva y que sepa-
mos aprovechar las diferentes cualidades que nos ofrecen.
2. EXtreme Programming (XP)
La programacin extrema (en adelante XP) puede que marque un antes y un

despus en la ingeniera del software. En este segundo punto del mdulo, in-
tentaremos mostrar todas sus ventajas y desventajas, as como su ambicioso
punto de partida: elsoftwarecomosolucingilynocomoproyectosar-
quitectnicos.
Creada por Kent Beck, Ward Cunninghamn y Ron Jeffries a finales de los no-
venta, la programacin extrema ha pasado de ser una simple idea para un
nico proyecto a inundar todas las "factoras de software". Algunos la definen
como un movimiento "social" de los analistas del software hacia los hombres
y mujeres de negocios, de lo que debera ser el desarrollo de soluciones en
contraposicin a los legalismos de los contratos de desarrollo.
Estamos viviendo una utopa? Quizs, pero actualmente esta metodologa

pasa de boca en boca como si de "algo secreto y pecaminoso" se tratase, y
muchos jefes de proyectos estn buscando la oportunidad para convencer a
sus directivos y clientes de ponerla en prctica con algn proyecto piloto. Los
resultados dictarn si XP pasa a impregnar el desarrollo del software de las
prximas dcadas o si simplemente nos quedaremos con la idea de aquella
versin utpica de desarrollo de software.
Para alcanzar el objetivo de softwarecomosolucingil, la metodologa XP

se estructura en tres capas que agrupan las doce prcticas bsicas de XP:
1)Metodologadeprogramacin: diseo sencillo, test, refactorizacin y co-

dificacin con estndares.
2)Metodologadeequipo: propiedad colectiva del cdigo, programacin en

parejas, integracin continua, cuarenta horas semanales y metfora del nego-
cio.
3)Metodologadeprocesos: cliente in situ, entregas frecuentes y planifica-

cin del juego.
Introducir la vertiente de las relaciones sociales dentro de una metodologa

es lo que hace de XP algo ms que una gua de buenas maneras. Convierte
laprogramacinenalgomuchoms"humanizado", en algo que permite
a las personas relacionarse y comunicarse para encontrar soluciones, sin jerar-
quas ni enfrentamientos. Los analistas y programadores trabajan en equipo
con el cliente final, todos estn comprometidos con el mismo objetivo, que la
aplicacin solvente o mitigue los problemas que tiene el cliente. La vertiente
social es fundamental en otras reas del conocimiento: por ejemplo, en las
relaciones del equipo mdico con el paciente, o en las de bufete de abogados
con un cliente, o en las de profesorado y alumnos, cada uno tiene su funcin
pero el objetivo es comn.
XP tambin humaniza a los desarrolladores. Un entorno agradable para el tra-

bajo, que facilite la comunicacin y los descansos adecuados, forma parte de
esta metodologa.
Pero donde XP centra la mayor innovacin es en desmontar la preconcebida

idea del coste del cambio de las metodologas en cascada, es decir, lo que cues-
ta cambiar alguna funcionalidad de nuestro aplicativo a medida que vamos
avanzando en l. La idea generalizada es que cualquier modificacin a final
del proyecto es exponencialmente ms costosa que al principio del mismo; si
algo no estaba especificado inicialmente, cuesta mucho introducirlo al final
del proyecto.
Lo que XP propugna es que esta curva ha perdido vigencia y que con una com-
binacin de buenas prcticas de programacin y tecnologa es posible lograr
que la curva no crezca siempre de forma exponencial.
XP pretende conseguir una curva de coste del cambio con crecimiento leve,
que en un inicio es ms costosa, pero que a lo largo del proyecto permiteto-
mardecisionesdedesarrollolomstardeposible sin que esa nueva decisin
de cambio implique un alto coste en el proyecto.
Slo al ver esta grfica es cuando podemos entender el significado de

uno de los lemas ms repetidos en la metodologa XP "Bienvenidos los
cambios".
XPnoseolvidadelanecesariarentabilidaddelosproyectos, imprescin-
dible en una economa tan competitiva como la occidental. Por eso propone
una ecuacin de equilibrio entre el coste, el tiempo de desarrollo, la calidad
del software y el alcance de funcionalidades del mismo.
2.1. Las variables XP: coste, tiempo, calidad y alcance
El punto de partida de la metodologa XP son las variables que utiliza para

cada proyecto: coste (la inversin econmica y en recursos), tiempo (el tiempo
empleado, determinado por la fecha de entrega final), calidad (del cdigo y
del aplicativo desarrollado) y alcance (Conjunto de funcionalidades).
De estas cuatro variables, slo tres podrn ser fijadas por el cliente y/
o por el jefe de proyectos, la cuarta es responsabilidad del equipo de
desarrollo y se establecer en funcin de las otras tres.
Qu significa esto? Pues que se eliminan las imposiciones imposibles. Se eli-

minan frases del tipo:
"El cliente quiere estos requisitos satisfechos e implementados en dos meses; el equipo
es ste y no habr ms, y el software debe superar todos los test de calidad, ya que es
para una farmacutica".
En este caso el cliente ha establecido dos variables, la de tiempo y los requisitos,

y el jefe de proyecto ha fijado el equipo y la calidad. En qu puede derivar
esto? Pues simplemente en que seguramente la calidad no ser la adecuada o
que no se cumplirn todos los requisitos o que el equipo de desarrollo tendr
que hacer jornadas de catorce horas diarias.
El equipo de desarrollo tiene que tener voz y voto y la posibilidad de

fijar al menos una de las cuatro variables. De esta manera podremos
establecer un proyecto viable.
Obviamente con XP no se establece el valor de todas las variables a la primera

de cambio, es un proceso paulatino en el que cada uno de los responsables
(cliente, jefe de proyecto y equipo de desarrollo) negocian el valor de las va-
riables que tienen asignadas hasta conseguir una ecuacin equilibrada y que
satisfaga a todos.
Advertencia: las interrelaciones entre estas cuatro variables no son siem-

pre tan sencillas como parecen.
Ejemplo
Aumentar los recursos de equipos de hardware ms eficientes puede que inicialmente

disminuya el tiempo de desarrollo, pero seguir aumentando sus capacidades puede que
ya no aporte ningn beneficio; o duplicar las personas del equipo de desarrollo no tiene
por qu disminuir por dos el tiempo de implementacin; es ms, en algunos casos incluso
puede agravar los problemas de coordinacin y comunicacin, incrementndolo en lugar
de reducirlo.
Tambin hay tareas que ya tienen todas sus variables fijadas de antemano por
su propia naturaleza y sobre las que no podemos hacer nada para modificar la
ecuacin. En este sentido hay una frase muy conocida que refleja esta situa-
cin: "nueve mujeres no pueden tener un hijo en un mes". Por mucho que se
intente, hay tareas que necesitan su tiempo y sus recursos para hacerlas.
Ejemplo
Otro ejemplo paradjico es el hecho de que en muchos casos aumentar la calidad acaba
derivando en una disminucin del tiempo de implementacin, sobre todo en aquellos
proyectos en los que se prev una gran cantidad de cambios durante el desarrollo. No
siempre bajar la calidad del software nos ahorrar costes.
Como podis ver, las relaciones entre estas cuatro variables no son siempre
evidentes, pero s hay una pregunta que nos haremos siempre con la metodo-
loga XP: Quvariableeslaquedebemossacrificar?
Pues depende, pero lamayoradelasveceseselalcance. La razn es simple.

No siempre tenemos todo el tiempo del mundo, el coste es algo que general-
mente se tiende a minimizar, y sin calidad todo el proceso de XP deja de tener
significado, no podramos mantener las aplicaciones si son un caos. Eso nos
deja slo una variable como la candidata ms adecuada a sacrificar.
Distinguir entre los requisitos ms importantes y los que aportan menor valor
al negocio, dando prioridad a los primeros, nos ayudar a conseguir que el
proyecto tenga en cada instante tanta funcionalidad como sea posible. De esta
manera, cuando nos acerquemos al plazo de entrega nos aseguraremos de que
lo principal est implementado y que slo quedarn los detalles de los que
podemos prescindir en el caso de necesidad. El objetivo es siempre maximizar
el valor de negocio.
2.2. Los cuatro valores: comunicacin, simplicidad,

realimentacin y coraje
Los creadores de esta metodologa quisieron medir su utilidad a travs de cua-

tro valores, que representan aquellos aspectos cuyo cumplimiento nos va a
garantizar el xito en el proyecto: comunicacin, simplicidad, realimentacin
y coraje. Veamos qu significa cada uno de ellos:
a)Comunicacin. Debe ser fluida entre todos los participantes en el proyecto;

adems el entorno tiene que favorecer la comunicacin espontnea, ubicando
a todos los miembros en un mismo lugar. La comunicacin directa nos da
mucho ms valor que la escrita, podemos observar los gestos del cliente, o la
expresin de cansancio de nuestro compaero.
b)Simplicidad. Cuanto ms sencilla sea la solucin, ms fcilmente podre-

mos adaptarla a los cambios. Las complejidades aumentan el coste del cambio
y disminuyen la calidad del software. En XP nos vamos a olvidar de frases co-
mo "haremos un sistema genrico que...", o "esto lo pongo por si acaso algn
da lo necesitamos".
Slo se utiliza lo que en ese momento nos da valor, y lo haremos de la

forma ms sencilla posible.
Alguno de vosotros puede pensar que eso va en contra de toda la filosofa de

diseo y utilizacin de patrones. Nada ms alejado de la realidad. En un pro-
yecto XP, el uso de patrones nos va a ayudar a reducir el tiempo de implanta-
cin, pero lo que no vamos a hacer es dedicar tiempo a la implementacin
de patrones que no vayamos a utilizar en este proyecto; slo haremos los que
sean necesarios para ste, no utilizaremos tiempo del proyecto para beneficiar
a otro proyecto futuro que quizs no llegue nunca. Por otro lado, nada nos
impide desarrollar un proyecto que nicamente se dedique a desarrollar pa-
trones que ms tarde se utilicen en proyecto XP.
c)Realimentacin. El usuario debe utilizar desde la primera entrega el softwa-

re desarrollado, dndonos sus impresiones y sus necesidades no satisfechas, de
manera que esas historias vuelvan a formar parte de los requisitos del sistema.
d)Coraje. Coraje para vencer la frase ms tpica de los desarrolladores: "si fun-
ciona no lo toques". Con XP debemos tocar continuamente cosas que ya fun-
cionan, para mejorarlas. Hemos de cambiar esta frase por la de: "si funciona,
puedes mejorarlo". Y eso, os lo aseguramos, requiere de mucho valor y coraje.
2.3. Las doce prcticas bsicas de XP
Kent Beck, Ward Cunninghamn y Ron Jeffries tenan muy claro las prcticas
que les haban dado mejores resultados en sus proyectos. As que intentaron
aplicarlas todas juntas dando una vuelta de tuerca. se fue el embrin de la
metodologa XP. Crearon las doce prcticas que se refuerzan entre s para ob-
tener los mejores resultados. Las relaciones entre ellas las podemos ver en el
siguiente grfico que hemos adaptado del que propuso Kent Beck.
En el centro hemos situado las prcticas que ms resultados nos pueden dar
al adaptarlas; no son otras que el diseo simple, el test y la refactorizacin.
Incluso si no queremos tomar la totalidad de las prcticas de XP adoptando
estas tres a nuestra metodologa habitual, podemos tener una sustancial me-
jora en los resultados obtenidos.
2.3.1. Diseo simple
"Debe ser simple para ser cierto. Si no es simple, probablemente no podremos descifrarlo."
Albert Einstein
Nada tan acertado como esta frase para ilustrar la idea de diseo simple de XP.
Si nuestro diseo es simple, cuando alguien lo vea lo entender, si es complejo,
probablemente no pueda descifrarlo.
El principio es "utilizar el diseo ms sencillo que consiga que todo funcione",

de esta manera facilitaremos el mantenimiento y minimizaremos los riesgos
de modificaciones que se hagan sin "entender" el cdigo.
XP define un "diseotansimplecomoseaposible" como aquel que:
No tiene cdigo redundante, ni duplicado.
Supera todos los tests de funcionalidad, integridad y aceptacin.
No utiliza sintaxis complejas, es decir, que queda clara la intencin

de los programadores en cada lnea de cdigo.
Contiene el menor nmero posible de clases y mtodos.
2.3.2. Refactorizacin
As como en el Gnesis nos explican que en un principio todo era caos y luego
todo fue orden, cuando programamos generalmente pasa lo contrario. Inicial-
mente todo son lneas de cdigo bien ordenadas y comentadas, pero a medida
que vamos introduciendo cambios, el orden se va perdiendo hasta que aquello
deriva en una serie de lneas de cdigo caticas, llenas de cdigo comentado
de las diferentes pruebas y con comentarios obsoletos que no se corresponden
con la realidad de la funcionalidad.
El excesivo coste de las modificaciones de las metodologas tradicionales

se debe en gran medida a este deterioroprogresivodelcdigo, tras la
acumulacin de modificaciones.
Para mantener la curva del coste de cambio tan plana como sea posible, en la
metodologa XP se aplica larefactorizacin, que no es otra cosa que modificar
el cdigo para dejarlo en buen estado, volviendo a escribir las partes que sean
necesarias pero siempre desde un punto de vista global a la funcionalidad,
independientemente del cambio que hagamos.
El cdigo final debe conservar la claridad y sencillez del original.
Los comentarios son muy importantes para mantener esta claridad y sencillez.
2.3.3. Test
Es el pilar fundamental de las prcticas de esta metodologa, sin los test, XP

sera un fracaso total, es el punto de anclaje que le da la base metodolgica
a la flexibilidad de XP.
Si una funcionalidad no se ha testeado, slo funciona en apariencia, los tests

han de ser aplicados tras cada cambio, y handeserautomatizados. Si no lo
hacemos, podemos incurrir en fallos humanos a la hora de testearlos y eso
puede resultar fatal.
El objetivo de los tests no es detectar errores, sino evitarlos, no se trata

de corregir errores, sino de prevenirlos.
Para ello, los tests siempre se escriben antes que el cdigo a testear, nunca des-
pus. De esta manera estamos obligados a pensarporadelantado cules son
los problemas que podemos encontrar cuando usen nuestro cdigo, a poner-
nos en el lugar del usuario final, y este hecho de pensar por adelantado evita
muchos problemas, previnindonos sobre ellos en lugar de dejar que aparez-
can y luego responder sobre la marcha.
Cuando escribimos el cdigo, ya sabemos a qu se ha de enfrentar y de

esta manera los errores se minimizan. El objetivo de nuestro software
ya no es cumplir unas funcionalidades sino pasar unos tests.
Es por esto por lo que el usuario final debe ayudar al programador a desarrollar
los tests de forma conjunta, ya que en estos tests estar implcita la funcio-
nalidad que queremos que tenga. Otro factor clave es que debe ser el mismo
programador el que desarrolle los tests, si no es as, perdemos la ventaja de
minimizacin de errores.
Los tests han de ser de tres tipos: tests de aceptacin, tests unitarios y tests de
integridad; y siempre han de estar automatizados.
Testdeaceptacin. Es creado conjuntamente con el cliente final y debe

reflejar las necesidades funcionales del primero.
Testunitario. Es creado por el programador para ver que todos los mto-
dos de la clase funcionan correctamente.
Testdeintegridad. Es creado por el equipo de desarrollo para probar que

todo el conjunto funciona correctamente con la nueva modificacin.
El uso de los tests nos facilita la refactorizacin, permitindonos comprobar

de forma sencilla que los cambios originados por la refactorizacin no han
cambiado el comportamiento del cdigo.
2.3.4. Estndares de codificacin
El equipo de desarrollo debe tener unas normas de codificacin comn, unas Web complementaria
nomenclaturas propias que todos los miembros del equipo puedan entender.
http://java.sun.com/docs/co-
Por ejemplo, si el programa ha de escribirse en Java, lo mejor es que todos deconv/index.html
utilicen las "Code Conventions for the Java Programming Language" de Sun
o una adaptacin propia de estas normas.
El hecho de utilizar una nomenclatura comn permite que cualquier perso-

na del equipo entienda con mayor facilidad el cdigo desarrollado por otro
miembro; de esta manera, facilitamos las modificaciones y la refactorizacin.
Por ejemplo, si decidimos que a la hora de poner nombre a nuestras variables

de una funcin seguiremos la siguiente norma:
1) La primera letra ha de ser una "v" si es variable local o una "p" si nos viene
por parmetro de entrada o una "o" si es parmetro de entrada y salida.
2) La segunda letra ha de indicar el tipo de datos "n" si es numrico, "s" si es

una cadena de caracteres, "d" si es una fecha y "b" si es booleano.
3) El resto del nombre ha de ser descriptivo con su contenido lgico, separando

significados con el "_".
Si yo ahora en el cdigo veo la siguiente sentencia:
If (vbPeriodo_no_calculable) { odFinal_Periodo = pdInicio_Periodo;}
tengo mucha ms informacin que si hubiese visto la siguiente:
If (pnc) { fp = ip;}
El funcionamiento es el mismo y ambas sentencias estn bien codificadas,

pero la primera nos da el valor aadido de la comprensin de la codificacin
estndar.
2.3.5. Propiedad colectiva del cdigo
Para poder aplicar la refactorizacin y para asegurarnos de que el diseo es

simple y que se codifican segn los estndares, tenemos que eliminar otra de
las ideas que estn muy arraigadas en el mundo del desarrollo de aplicaciones;
la "propiedad individual" del cdigo.
Frases como "que lo modifique quien lo hizo que seguro que lo entiende mejor"
o "quin ha tocado mi funcin?" dejan de tener sentido en XP, ya que el
diseo simple nos garantiza que ser fcilmente entendible, la refactorizacin
permite que cualquier miembro del equipo rehaga el cdigo para devolverle
su sencillez en el caso de que se haya complicado, los test automatizados nos
garantizan que no hemos modificado el comportamiento esperado del cdigo
con nuestra modificacin, y la codificacin con estndares nos da ese grado
de comprensin adicional.
En XP el cdigo es propiedad de todo el equipo y cualquier miembro

tiene el derecho y la obligacin de modificarlo, para hacerlo ms efi-
ciente o comprensible, sin que nadie se tenga por qu sentir ofendido.
2.3.6. Programacin por parejas
No iramos ms rpido con dos personas programando en lugar de una pro-

gramando y otra mirando? La verdad es que inicialmente puede chocar, la
programacin siempre se ha visto como algo solitario, y tener dos personas
delante de un solo teclado y de un solo monitor sorprende en un inicio. Pero
las ventajas son muchas.
Pensad en cmo funciona la mente humana: nos es muy complicado pensar a

nivel abstracto y luego pasar a pensar a nivel concreto, y si lo hacemos de for-
ma continua, acabamos desconcentrados y cometemos errores. Es por esto por
lo que, cuando programamos, primero pensamos la estrategia de codificacin
que vamos a seguir y luego nos ponemos a codificar cada una de las partes,
sin pensar de nuevo a nivel estratgico hasta que no finalizamos alguna de
las partes o a veces la totalidad del cdigo, y entonces vemos los errores o las
cosas que nos hemos dejado en la estrategia de codificacin original.
Pensar a lo grande y en detalle a la vez nos es imposible con un solo

cerebro. Pues pongamos dos.
En la programacin en parejas uno de los miembros debe esta pensando a ni-

vel tctico y el otro a nivel estratgico de manera que esos dos procesos siem-
pre estn activos reduciendo as los errores y mejorando la calidad del pro-
grama. Obviamente, estos dos roles deben intercambiarse cada poco tiempo
entre los miembros de la pareja para abarcar todas las posibilidades tcticas
y estratgicas.
El nivel de los miembros de la pareja ha de ser equivalente, no sirve que uno

sepa mucho y otro no tenga ni idea, deben de estar equilibrados y obviamente
llevarse bien para que tenga xito.
Tambin la rotacin ha de ser muy importante, cada miembro del equi-

po ha de ser capaz de trabajar en cualquier rea de la aplicacin que se
est desarrollando. De esta manera no provocaremos cuellos de botella
cuando asignemos las tareas.
El hecho de que asignemos las tareas por parejas hace que el tiempo de apren-
dizaje se reduzca casi a cero, simplemente sustituyendo uno de los miembros
por otro nuevo. As pues, la rotacin de reas y de parejas nos garantiza que
podremos hacer un reparto ms equitativo del trabajo sin tener que depender
de una sola persona para un trabajo especfico.
Otro efecto que produce la programacin en parejas es el psicolgico, dismi-

nuye la frustracin de la programacin en solitario, tienes a alguien que en-
tiende el problema justo al lado, y con el que compartir el problema. Adems,
muchas veces los problemas vienen por falta de concentracin y se tiene la
solucin delante de las narices y no se ve, y se pierde mucho tiempo. La pro-
gramacin por parejas disminuye la necesidad del "Efecto ttem".
''Efecto ttem''
El programador lleva varias horas intentando solucionar un problema, decide llamar a

un compaero para ver si l ve la solucin. Empieza a explicarle el problema y automati-
camente encuentra la solucin sin que el segundo compaero haya pronunciado palabra
alguna. Recibe este nombre porque podramos sustituir al segundo compaero por un
"ttem" indio con exactamente los mismos resultados.
2.3.7. Integracin continua
En XP no esperamos a que todas las partes estn desarrolladas para integrarlas

en el sistema, sino que a medida que se van creando las primeras funcionali-
dades ya se ensamblan en el sistema, de manera que ste puede ser construido
varias veces durante un mismo da. Esto se hace para que las pruebas de inte-
gracin vayan detectando los errores desde el primer momento y no al final
de todo. El impacto es mucho menor.
Es responsabilidad de cada equipo publicar lo antes posible cada funcionalidad

o cada modificacin. La idea es que todos los miembros del equipo trabajen
con la ltima versin del cdigo.
2.3.8. 40 horas semanales
No se pueden trabajar durante 14 horas seguidas y hacerlo con calidad. Las

semanas de 70 horas de trabajo son contraproducentes. Los equipos de XP
estn diseados para ganar, no para morir en el intento. Al final de la semana
se tiene que llegar cansado pero satisfecho, nunca exhausto ni desmotivado.
Trabajar horas extra mina la moral y el espritu del equipo. Si durante dos
semanas hay que hacer horas extras, entonces es que el proyecto va mal y se
debe replantear alguna de las cuatro variables.
2.3.9. Metfora del negocio
Para que dos o ms personas se puedan comunicar de forma eficiente, deben

tener el mismo vocabulario y compartir el mismo significado. El modelo de
negocio que entiende el usuario final seguramente no se corresponder con
el que cree entender el programador. Es por esto por lo que en los equipos de
XP se debe crear una"metfora"conlaqueelusuariofinalseencuentre
cmodo y que le sirva al equipo de desarrollo a la hora de modelizar las clases
y mtodos del sistema.
La metfora es una historia comn compartida por el usuario y el equipo

de desarrollo que describe cmo deben comportarse las diferentes partes
del sistema que se quiere implementar.
2.3.10. Cliente in situ
En ms de una ocasin, cuando estamos programando o analizando el sistema,

nos surge una duda y pensamos en que cuando veamos al usuario final se la
preguntaremos. Posiblemente tengamos que seguir trabajando sin solventar
esa duda y, si nuestra suposicin ha sido errnea, mucho del trabajo realizado
se puede perder.
XP necesita que el cliente final forme parte del equipo de desarrollo y est
ubicado fsicamente en el mismo sitio para que as se agilice el tiempo de res-
puesta y se puedan validar todas las funcionalidades lo antes posible.
En XP, el cliente siempre tiene que estar disponible para el resto del
equipo, formando parte de l y fomentando la comunicacin cara a
cara, que es la ms eficiente de las comunicaciones posibles.
2.3.11. Entregas frecuentes
Se deben desarrollar lo antes posible versiones pequeas del sistema, que aun-
que no tengan toda la funcionalidad, nos den una idea de cmo ha de ser la
entrega final y que nos sirvan para que el usuario final se vaya familiarizando
con el entorno y para que el equipo de desarrollo pueda ejecutar las pruebas
de integridad.
Las nuevas versiones tienen que ser tan pequeas como sean posibles,
pero tienen que aportar unnuevovalordenegocioparaelcliente.
Dar valor al negocio es lo que har que la visin final del cliente sea la mejor
posible.
2.3.12. Planificacin incremental
La planificacin nunca ser perfecta, variar en funcin de cmo varen las

necesidades del negocio y en cada ciclo de replanificacin se volvern a esta-
blecer las cuatro variables de la metodologa XP.
Asumir una planificacin esttica no corresponde con la agilidad que quere-

mos dar, ya que las necesidades del negocio pueden cambiar drsticamente
mientras estamos desarrollando el aplicativo. En XP la planificacin se va re-
visando continuamente, de forma incremental, priorizando aquellas necesi-
dades de negocio que nos aporten mayor valor.
La planificacin se plantea como un permanente dilogo entre los res-

ponsables de la perspectiva empresarial y de la perspectiva tcnica del
proyecto.
2.4. El ciclo de vida de la metodologa XP
Las doce prcticas haban dado por separado muy buenos resultados a Kent
Beck y compaa. Unificarlas en el ciclo de vida de una metodologa es lo que
dio origen a XP.
La mejor forma de comunicacin es la presencial. Cuando tenemos algo im-

portante que decir, nos gusta "decirlo a la cara", para que no haya equvocos.
La expresin, la entonacin y las miradas son muy importantes.
El ciclo de vida de XP se organiza como si fuese una conversacin clien-

te-desarrollador.
ste sera el desarrollo ideal de un proyecto XP. Para acercarnos a esto, estable-
cemos un ciclo de vida dividido en seis fases.
CiclodevidadeunproyectoXP
1) Fase de exploracin
2) Fase de planificacin
3) Fase de iteraciones
4) Fase de produccin
5) Fase de mantenimiento
6) Fase de muerte del proyecto
2.4.1. La fase de exploracin
La fase de exploracin es la primera fase del ciclo de vida de la metodologa

XP. En ella se desarrollan tres procesos:
1) Las historias de usuario.

2) El spike arquitectnico.
3) La metfora del negocio.
Todo comienza con las "historias de usuario". En esta fase los usuarios plan-
tean a grandes rasgos las funcionalidades que desean obtener del aplicativo.
Las historias de usuario tienen el mismo propsito que los casos de uso, salvo
en un punto crucial; las escriben los usuarios y no el analista. Han de ser des-
cripciones cortas y escritas en el lenguaje del usuario sin terminologa tcnica.
Estas historias son las que guiarn la creacin de los tests de aceptacin que
han de garantizar que dichas historias se han comprendido y se han imple-
mentado correctamente.
No debemos confundir las historias de usuario con el anlisis de requisitos,

la principal diferencia est en la profundidad de anlisis, con los requisitos
queremos llegar al ltimo detalle para no "pillarnos las manos ante el cliente",
pero en XP el cliente forma parte del equipo y le podemos preguntar ms
cosas durante la implementacin, as que el nivel de detalle en las historias de
usuario ha de ser el mnimo imprescindible para que nos hagamos una idea
general de la funcionalidad.
Las historiasdeusuario han de ser:
Escritas por el cliente final; en su lenguaje y sin tecnicismos.

Descripciones cortas de la usabilidad y funcionalidad que se espera del
sistema.
Paralela y conjuntamente se empieza con el spike arquitectnico, en el que el

equipo de desarrollo empieza a familiarizarse con la metodologa, herramien-
tas, lenguaje y codificaciones que se van a usar en el proyecto.
En el spikearquitectnico del equipo de desarrollo:
Prueba la tecnologa.
Se familiariza con la metodologa.
Se familiariza con las posibilidades de la arquitectura.
Realiza un prototipo que demuestre que la arquitectura es vlida para el
proyecto.
Una vez finalizadas las historias de usuario y el spike arquitectnico, se pasa a Ved tambin
desarrollar conjuntamente la metfora del negocio.
Como ya vimos en el apartado
"Metfora del negocio" de este
La metforadelnegocio: mdulo, esta metfora es una
de las 12 prcticas bsicas de
XP.
Es una historia comn compartida por el usuario y el equipo de desarrollo.
Debe servir para que el usuario se sienta a gusto refirindose al sistema en

los trminos de ella.
Debe servir a los desarrolladores para implementar las clases y objetos del
sistema.
2.4.2. La fase de planificacin
El resultado ha de ser una planificacin (recordemos que siempre flexi-

ble) del proyecto.
El procedimiento es el siguiente:
El cliente entrega al equipo de desarrollo las historiasdeusuario que ha

confeccionado, pero priorizndolas de mayor a menor importancia.
El equipo de desarrollo las estudia y estimaelcoste de implementarlas:

Si el equipo de desarrollo considera que la historia de usuario es de-
masiado compleja, entonces el usuario final debe descomponerla en
varias historias independientes ms sencillas.
Si el equipo de desarrollo no ve claro cmo implementar una parte

de la historia, el usuario puede realizar un spiketecnolgico para ver
cmo se podra implantar y as poder evaluar el coste.
Una vez tenemos la lista de historias priorizadas junto con su coste de

implementacin, pasamos a convocar la reunindelplandeentregas.
El plan de entregas se compone de una serie de planes de iteracin en

el que se especifica qu funcionalidades se van a implementar en cada
vuelta de la fase de iteraciones.
Participan de esta reunin tanto los usuarios como el equipo tcnico

y cada uno debe aportar su visin del negocio de manera que se ob-
tengan ms rpidamente aquellas funcionalidades que den el mayor
beneficio para el negocio posible.
A cada iteracin se le asigna un tiempo intentando que todas sean ms

o menos idnticas (aunque no es necesario).
Se determina el alcance del proyecto.
2.4.3. La fase de iteraciones
Como hemos dividido el proyecto en iteraciones, esta fase se repetir tantas

veces como iteraciones tengamos. Generalmente, cada iteracin suele ser de
dos a tres semanas.
El Plandeiteracin se trata de la manera siguiente:
Se recogen las historias de usuario asignadas a esta iteracin.
Se detallan las tareasarealizar por cada historia de usuario.

Las tareas deben ser de uno o tres das de desarrollo. Si son ms grandes,
deberamos intentar dividirlas en varias ms sencillas.
Se estima el coste de cada tarea. Si el total es superior al tiempo de

iteracin, se deber prescindir de alguna historia de usuario que se
pasara a la siguiente iteracin. Si son muchas las historias de usuario
desechadas, entonces hay que volver a estimar las cuatro variables de
la metodologa y volver a planificar el proyecto.
Si el tiempo total estimado de las tareas es inferior al tiempo de itera-

cin, se puede asumir una historia de usuario que correspondiese a la
siguiente iteracin.
Se priorizan las tareas que ms valor darn al negocio, intentando que se

finalicen historias de usuario lo antes posible.
Se reparten las primeras tareas al equipo de desarrollo y el resto se deja en

una coladetareassinasignar de dnde se irn cogiendo.
Se convocan reuniones de seguimiento diarias para ver si nos vamos

retrasando en las estimaciones o nos vamos adelantando a ellas y as poder
desechar o incorporar historias de usuario.
Lo ms importante es que en cada momento de cada iteracin estemos

realizando la tarea que ms valor posible da al negocio de entre las que
tenemos pendientes, de manera que, si tenemos que reducir el alcance
del proyecto, slo afecte a las funcionalidades secundarias de nuestro
aplicativo.
2.4.4. La fase de produccin
Llegamos a esta fase al alcanzar la primera versin que el usuario final decida
que puede ponerse en produccin.
Pasaremos el aplicativo a produccin cuando alcance las funcionalida-

des mnimas que aporten un valor real al negocio y una operativa ar-
quitectnica estable.
Es decir, no esperamos a tener todas las funcionalidades implementadas, sino

que en cuanto tenemos algo que los usuarios pueden utilizar y que ayuda al
negocio, pasamos la primera versin a produccin.
Paralelamente, se sigue con las iteraciones finales de proyecto, pero fijaos que
antes de que finalice ya estamos dando valor a la organizacin, el ROI (retorno
de la inversin) del proyecto empieza a generarse antes de que ste finalice
su versin final.
En la etapa de produccin se realizan tambin iteraciones como en la anterior

etapa, pero el ritmo de stas ya no es de dos a tres semanas, sino mensuales.
Esta fase se mantiene hasta que realizamos la ltima entrega, con la que fina-
lizamos el mbito del aplicativo y pasamos al mantenimiento del mismo.
Durante la fase de produccin, el ritmo de desarrollo decae debido a que el

equipo debe solventar las incidencias de los usuarios. Es por esto por lo que a
veces es necesario incorporar nuevo personal al equipo.
2.4.5. La fase de mantenimiento
Una vez el alcance del proyecto se ha conseguido, y tenemos todas las funcio-
nalidades en produccin, se revisan con el usuario aquellas nuevas historias
de usuario que se han producido tras la puesta en produccin del proyecto.
Estas nuevas funcionalidades se van incorporando segn su valor de negocio
y el presupuesto adicional del que se disponga.
El equipo de desarrollo se reduce a la mnima expresin, dejando algunos

miembros para el mantenimiento.
2.4.6. La fase de muerte del proyecto
Cuando no existen ms historias de usuario para introducir en nuestro siste-

ma o cuando se reduce progresivamente valor de las historias de usuario im-
plementadas en l, el proyecto entra en la fase de muerte.
Se ir desinvirtiendo en l hasta abandonarlo totalmente cuando no aporte

valor al negocio o cuando sus historias de usuario hayan sido absorbidas por
otro sistema de informacin.
2.5. Los diferentes roles dentro de XP
Cada rol tiene unas funciones claras dentro de la metodologa XP. Cada per-
sona del equipo puede ejecutar uno o varios roles, o incluso cambiar de rol
durante las diferentes fases del proyecto.
Son muchas las extensiones que se han hecho de los roles de la propuesta ori-
ginal de Beck, pero los roles que permanecen siempre en cualquier implemen-
tacin de la metodologa XP son los siguientes:
Programador:
Escribe las pruebas unitarias.

Produce el cdigo del programa.
Cliente:
Escribe las historias de usuario.

Disea las pruebas de aceptacin.
Prioriza las historias de usuario.
Aporta la dimensin de negocio al equipo de desarrollo.
Representa al colectivo de usuarios finales.
Est siempre disponible para consultas.
Encargadodepruebas(tester):
Ayuda al cliente a disear pruebas de aceptacin.

Ejecuta las pruebas de aceptacin.
Ejecuta las pruebas de integracin.
Difunde los resultados entre el equipo de desarrollo y el cliente.
Es el responsable de las herramientas automatizadoras de las pruebas.
Encargadodeseguimiento(tracker):
Se encarga de realimentar todo el proceso de XP, midiendo las desviaciones

con respecto a las estimaciones y comunicando los resultados para mejorar
las siguientes estimaciones.
Realiza el seguimiento de cada iteracin del proceso de XP tanto en la
etapa de iteraciones como en la de produccin.
Revala la posibilidad de incorporar o eliminar historias de usuario.
Entrenador(coach):
Se encarga del proceso global.

Garantiza que se sigue la filosofa de XP.
Conoce a fondo la metodologa.
Provee guas y ayudas a los miembros del equipo a la hora de aplicar las
prcticas bsicas de XP.
Consultor:
No forma parte del equipo.

Tiene un conocimiento especfico de un rea en concreto.
Ayuda a resolver un problema puntual, ya sea de spike tecnolgico o de
valor de negocio.
Gestor(boss):
Es el mximo responsable del proyecto.

Hace de enlace con los clientes.
Se encarga de coordinar y de garantizar las condiciones necesarias para el desa-

rrollo del trabajo.
2.6. El entorno de trabajo
XP necesita, adems, de un entorno que favorezca la comunicacin. De nada

sirve tener a nuestro equipo disperso por diferentes plantas y edificios, o que
el cliente se encuentre a cinco minutos por el pasillo principal de la oficina.
Las barreras arquitectnicas y visuales deben eliminarse en la medida de lo
posible de un proyecto de XP. La comunicacin verbal es fundamental.
Una posible distribucin de un equipo de XP podra ser la siguiente:
A este esquema final sera conveniente aadirle una sala de desconexin don-
de los programadores fatigados pudieran hacer un descanso, tomarse un re-
fresco, picar algo o simplemente mirar por la ventana.
Otro punto importante es que el cliente debe estar cerca y disponible pero
debe tener un entorno que le permita desarrollar su trabajo habitual. Por esta
razn, en el esquema se encuentra un poco apartado del grueso del equipo.
2.7. Qu dicen los detractores de XP
No todo es un camino de rosas para la metodologa XP. Mucho se ha escrito

tambin en contra de esta forma de entender la creacin de software. Veamos
los principales argumentos en contra.
a) XP slo funciona con equipos "brillantes" de gente disciplinada y con visin

de negocio. Si tenemos a programadores "normales", al aplicar XP obtendre-
mos el efecto contrario, desarrollo mucho ms lento y plagado de errores.
b) Las empresas no dejarn que un cliente se integre al proyecto de desarrollo,

y si conseguimos que lo consientan, seguramente ser aquel usuario final que
tenga menor valor para el negocio y que no represente los problemas de la
empresa. As, las historias de usuario y su asignacin de prioridades no sern
representativas y construiremos nuestro aplicativo sobre una falacia.
c) Cuando se va a hacer un proyecto en una empresa, lo primero que se pide es

saber el tiempo y el alcance, antes de aceptar un proyecto. Y con XP ambas son
variables a lo largo del proyecto. Sin haberlas prefijado, no se pueden hacer
proyectos para terceras empresas y menos optar a un concurso pblico.
d) XP se basa en las pruebas y los tests, pero en un "entorno real", con la presin
que suelen sufrir los proyectos de desarrollo, lo primero que se reduce a su
mnima expresin son las pruebas. XP no es aplicable a un entorno de una
organizacin real.
e) La programacin en parejas es una utopa. Al final deriva en que uno trabaja

y el otro descansa. Adems, es de difcil justificacin de cara al cliente que paga
el software, ya que la medida hora/hombre es la que impera en el mercado.
Cmo facturaremos si se ve que de cada dos personas, una slo apunta cosas
a la otra?
f) Los equipos XP han de ser pequeos, no se podra realizar con equipos de

proyectos grandes.
g) Deja de lado la documentacin, algo fundamental para controlar la alta

rotacin en las empresas servicios de TI.
Como podemos ver, argumentos no faltan, saber si son slidos o no, depende
ya de vuestro espritu crtico. Pero eso s, recordad que, antes de criticar o alabar
esta metodologa de proyectos, quizs sera conveniente que empezramos a
aplicarla en algn proyecto poco importante, para as podernos formar una
opinin fundamentada en nuestra experiencia.
2.8. Un ejemplo de XP
Java es sin duda el lenguaje de programacin ms accesible a los estudiantes

y programadores no profesionales. Adems, JEE es la plataforma de desarrollo
ms extendida entre los movimientos de las comunidades de software libre.
Por esta razn, unida a que ambos movimientos estn muy vinculados entre
s, hemos credo conveniente realizar un ejemplo de lo que sera un proyecto
XP en un entorno puramente JEE.
Para ello tenemos como "voluntaria" a la ya famosa "tienda de mascotas" que

junto con el "Hola, mundo" son los dos ejemplos ms utilizados en la historia
reciente de la informtica.
Por desgracia no podemos extendernos demasiado en la descripcin detallada

de la codificacin, pero s que intentaremos mostrar las decisiones ms impor-
tantes durante el ciclo de vida del proyecto.
2.8.1. Fase de exploracin
El cliente se pone en contacto con nosotros y nos comunica que necesita crear
una web de su tienda de mascotas, para lo que cuenta con un presupuesto
limitado. El equipo de desarrollo lo compondrn una o dos personas, que rea-
lizarn todos los roles dentro de la metodologa XP.
Lo primero que vamos a hacer es darle un nombre al proyecto: Proyecto Ex-

tremo de Tienda de Animales y vamos a esperar que las siglas no sean un in-
dicativo del resultado final.
El segundo paso es solicitar y ayudar al cliente a escribir las historiasdeusua-

rio.
Historia de usuario 1: Presencia en Internet

Quiero que la gente que busque mi tienda de mascotas pueda encontrarla bus-
cando en el Google, y as hallar mi direccin, mi correo electrnico, y los te-
lfonos de contacto.
Historia de usuario 2: Catlogo de productos

Adems, me gustara que los clientes pudieran ver mis productos y los precios
en la web.
Historia de usuario 3: Pedidos de productos

Y comprarlos.
Historia de usuario 4: Carrito de la compra

No de uno en uno, sino varios a la vez.
Historia de usuario 5: Listas de productos

Y que el programa se acordase de los productos que ms compra.
Historia de usuario 6: Productos vinculados

Y que le sugiriese nuevos productos para comprar, segn los que haya com-
prado.
Historia de usuario 7: Ofertas y promociones

Y poder destacar las ofertas de la semana y descuentos al comprar varios pro-
ductos a la vez.
Historia de usuario 8: Tarjetas cliente

Y que acumulasen puntos por comprar por Internet para descuentos o regalos.
Historia de usuario 9: Pago por mvil

Y que pudieran pagar el pedido con una llamada de mvil en lugar de poner
la tarjeta de crdito.
Paralelamente hemos iniciado el spikearquitectnico basado en JEE. JEE
Ved JEE, JavaBeans y los Enter-

Los dos miembros del equipo de desarrollo se decantan por una arquitectura prise JavaBeans en la asigna-
clsica en tres capas para el proyecto web. tura Ingeniera del software de
componentes y sistemas distri-
buidos del Grado de Ingeniera
en Informtica.
La nica duda la tenan en si utilizar slo JavaBeans o Enterprise JavaBeans a la
hora de la persistencia de los datos de las transacciones econmicas. Para ello
contactan con varios bancos que realizan pagos on-line y descubren que en la
mayora de los casos lo nico que deben hacer es redireccionar a las pginas
propias del banco cuando se vaya a realizar el pago y una vez finalizado, el
banco redireccionar el cliente a la pgina de la tienda que les indiquen. Con
esta informacin, hacen algunas pruebas y se decantan por JavaBeans simpli-
ficando as la arquitectura.
Los dos miembros del equipo de desarrollo estn familiarizados con las herra- Webs complementarias
mientas OpenSource y tras hacer varias pruebas, eligen las siguientes:
Para ampliar informacin
sobre las herramientas Ope-
Ant. Herramienta OpenSource de codificacin y compilacin de progra- nSource, podis ver: http://
ant.apache.org
mas Java. http://www.junit.org
http://tomcat.apache.org/
Junit. Herramienta OpenSource de creacin y ejecucin automatizada de http://www.jboss.org/
tests unitarios sobre clases Java y especializada en Extreme Programming.
Tomcat. Como servidor web, OpenSource, donde residir la aplicacin,

permite el uso de Java Server Pages. Se ha descartado Jboss, ya que hemos
decidido que no necesitaremos EJBs.
Todas las herramientas elegidas son compatibles entre s y estn plena-

mente integradas.
El ltimo paso es desarrollar la metforadelnegocio para que usuario y equi-

po de desarrollo se sientan a gusto y se sepa que se est hablando en los mis-
mos trminos.
Dominio. Nombre por el que se conocer nuestra tienda en Internet por

ejemplo: "tiendadeanimales".
Tienda on-line. Se trata de la pgina web que ser nuestra representacin en

Internet del negocio de la tienda de mascotas. Es el punto de entrada. Al
poner la direccin en el navegador http://www.tiendadeanimales.es apa-
recer nuestra tienda.
Men. Son las diferentes opciones que tendremos a la hora de ver la infor-
macin de la tienda. Sera como las diferentes puertas de acceso a la tienda
normal.
Secciones. La tienda on-line est organizada en secciones, igual que la tienda

fsica. En cada seccin encontraremos productos.
Barra de navegacin. Sera como caminar por la tienda fsica. En la tienda

on-line pondremos una zona que permitir ir al siguiente producto, ver
todos los productos de la seccin, cambiar de seccin, etc.
Catlogo de productos. Lo componen todos los productos que tendremos

en la tienda on-line. Sera como el catlogo impreso, pero con la capacidad
de poder cambiar las pginas fcilmente.
Productos. Corresponden a los productos que venderemos en la tienda on-

line. Al igual que en la tienda fsica, un producto puede exponerse en una
o ms secciones.
Carrito de la compra. Corresponde a la zona de la tienda on-line donde ire-

mos depositando los productos que queremos comprar.
Proceso de pago. Su funcionamiento es muy parecido a la siguiente idea.

Imagina que en la tienda real los clientes no nos pagan a nosotros en la
caja registradora, sino que se van con el carrito de la compra al banco,
pagan en el banco, y el banco luego nos lo paga a nosotros. El intercambio
de dinero no lo hacemos en nuestra tienda on-line sino en la del banco.
Dems conceptos. Que el usuario y el equipo de desarrollo crean necesitar

con tantas analogas y/o metforas como se crea necesarias.
2.8.2. Fase de planificacin
El cliente prioriza las historias de usuario.
Historia de usuario 1: Presencia en Internet

Historia de usuario 2: Catlogo de productos
Historia de usuario 6: Productos vinculados
Historia de usuario 3: Pedidos de productos
Historia de usuario 7: Ofertas y promociones
Historia de usuario 4: Carrito de la compra
Historia de usuario 8: Tarjetas cliente
Historia de usuario 5: Listas de productos
Historia de usuario 9: Pago por mvil
El equipo de desarrollo evalaelcoste de implementacin de cada una de

ellas en jornadas de ocho horas por pareja de programadores.
Historia de usuario 1: Presencia en Internet (10 jornadas)

Historia de usuario 2: Catlogo de productos (20 jornadas)
Historia de usuario 6: Productos vinculados (4 jornadas)
Historia de usuario 3: Pedidos de productos (6 jornadas)
Historia de usuario 7: Ofertas y promociones (10 jornadas)
Historia de usuario 4: Carrito de la compra (10 jornadas)
Historia de usuario 8: Tarjetas cliente (4 jornadas)
Historia de usuario 5: Listas de productos (4 jornadas)
Historia de usuario 9: Pago por mvil (2 jornadas)
Tras la reunin del plandeentregas se establece que la iteracin ser bisema-

nal (10 jornadas) y que los miembros del equipo efectivamente sern dos.
La planificacin es la siguiente:
Iteracin 1
Historia de usuario 1: Presencia en Internet (10 jornadas)
Primer paso a produccin
Iteracin 2
Historia de usuario 2: Catlogo de productos con las secciones ms impor-
tantes (10 jornadas)
Iteracin 3
Historia de usuario 2: Catlogo de productos con las secciones restantes
(10 jornadas)
Segundo paso a produccin
Iteracin 4
Iteracin 5
Historia de usuario 7: Ofertas y promociones (10 jornadas)
Tercer paso a produccin
Iteracin 6
Cuarto paso a produccin
Quedanfueradelmbito del proyecto las siguientes historias de usuario:

Historia de usuario 5: Listas de productos (4 jornadas)
Historia de usuario 9: Pago por mvil (2 jornadas)
Es decir, seis iteraciones de dos semanas cada una, con cuatro pases a produc-
cin. En esta planificacin a partir de la segunda semana de inicio del proyec-
to ya estaremos dando valor al negocio, al haber implementado la historia de
usuario 1 que era la ms importante en la priorizacin del cliente.
2.8.3. Fase de iteraciones
En el ejemplo actual, esta fase finalizara en la primera iteracin, ya que en

ese momento pasaramos a la fase de produccin. Lo ms importante de esta
primera fase es crear el armazn del aplicativo final, sobre el que iremos cons-
truyendo todo; es decir, adems de la pgina web que cubrira la historia de
usuario 1, deberamos crear tambin las clases Java: Tienda, Seccin, Catlogo,
Producto, Carrito, y crear sus primeros tests unitarios y sus primeros tests de
integracin.
Si nos centramos en la clase Producto, una posible primera implementacin

podra ser esta:
/* Clase producto */
/* Versin 1.0 */
package uoc.tienda;
public abstract class Producto {
public void setPrecio(double precio) {this.precio = precio; }
public double getPrecio(){ return precio }
protected double precio;
}>
Tras finalizar de implementar el otro miembro de la pareja, podra decir que la

funcin setPrecio no es del todo clara, que sera mejor utilizar la nomenclatura
del proyecto.
La primera letra ha de ser una "v" si es variable local o una "p" si nos viene
por parmetro de entrada o una "o" si es parmetro de entrada y salida.
La segunda letra ha de indicar el tipo de datos "n" si es numrico, "s" si es

una cadena de caracteres, "d" si es una fecha y "b" si es booleano.
El resto del nombre ha de ser descriptivo con su contenido lgico, sepa-

rando significados con el "_".
As, la clase Producto quedara de la siguiente manera.

/* Versin 1.1 */
package uoc.tienda;
public abstract class Producto {

public void setPrecio(double pnPrecio) {this.vnPrecio = pnPrecio; }
public double getPrecio(){ return vnPrecio }
protected double vnPrecio;
}
Por supuesto esto no se queda aqu, porque recordemos que uno de los dos
programadores ha de estar pensando en estratgico, as que ve de forma clara
que todos los objetos del proyecto tendrn tres propiedades fijas: Identificador,
Nombre y Descripcin, e incita a crear un clase con estas tres propiedades de
las que herede el resto.
/* Versin 1.2 */
package uoc.tienda;
public abstract class Producto extends ObjetoBasico{

protected double vnPrecio;
public void setPrecio(double pnPrecio) {this.vnPrecio = pnPrecio; }
public double getPrecio(){ return vnPrecio }
}
/* Clase Objeto Bsico*/

/* Versin 1.0 */
package uoc.tienda;
public abstract class ObjetoBasico {

protected int vnIdentificador;
protected String vsNombre;
protected String vsDescripcion;
/* Propiedad Identificador */
public void setIdentificador(int pnIdentificador)
throws Exception { this.vnIdentificador =
pnIdentificador; }
public int getIdentificador(){ return vnIdentificador; }
/* Propiedad Nombre*/
public void setNombre(String psNombre){ this.vsNombre = psNombre; }
public String getNombre(){ return vsNombre; }
/* Propiedad Descripcion*/
public void setDescripcion(String psDescripcion)
{ this.vsDescripcion = psDescripcion; }
public String getDescripcion(){ return vsDescripcion; }
No debemos olvidarnos de hacer los tests unitarios para cada uno de los ob- Web complementaria
jetos. Para ello, utilizaremos las clases de JUnit, en especial la clase abstracta
La jerarqua de la clase Assert
Assert que nos permite gran variedad de comprobaciones, y de su implemen- la podemos encontrar en:
tacin en la clase TestCase. Otra clase interesante es TestSuite, que nos permite http://junit.sourceforge.net/
javadoc/org/junit/packa-
automatizar una gran cantidad de tests unitarios. ge-tree.html
Siguiendo con el ejemplo, la primera versin del test unitario de la clase Pro-
ducto sera la siguiente:
package uoc.tienda.test;
import.uoc.tienda.Producto;
import junit.framework.TestCase;
public class TestUnitarioProductoextends TestCase {

public void testProducto( Producto pPTest) {
// Creo otra instancia de un producto
final Producto producto1 = new Producto;
// Compruebo la creacin de objetos para ver que se han
instanciado bien
assertNotSame(producto1, pPTest);
assertSame(producto1, producto1);
assertSame(pPTest, pPTest);
// Le asigno las propiedades a producto 1 los mtodos set
producto1.setPrecio(pPTest.getPrecio());
// correcto y concordante con el mtodo set
assertEquals(pPTest.getPrecio(), producto1.getPrecio());
//Por ltimo compruebo las propiedades lgicas que ha de cumplir la
clase Producto
// Propiedad 1: Precio nunca ha de ser menor que cero.
assertFalse(pPTest.getPrecio() < 0);
// Propiedad 2: Precio nunca ha de ser mayor que 999.999.
assertTrue(pPTest.getPrecio() < 999999);
}
}
Al finalizar esta primera iteracin, tendramos que tener la pgina de entrada

inicial y un armazn de todo el aplicativo, as como los tests unitarios y de
integracin, y las automatizaciones de dichos tests.
La ultima parte de esta primera fase son los testsdeaceptacin creados por
el cliente ayudado por el miembro del equipo con el rol de tester. Si se pasan
con xito, pondremos esta iteracin en produccin. En nuestro caso, los tests
de aceptacin deberan reflejar las necesidades de la Historia de usuario 1:
Presencia en Internet.
La creacin de tests y los algoritmos de testeo daran para todo un apartado

de este libro, pero por desgracia est fuera del alcance de esta introduccin.
2.8.4. Fase de produccin
Durante esta fase se realizaran las iteraciones 2 a la 6, segn el plan de en-

tregas que habamos diseado. Hacia la mitad de la segunda iteracin, nos
damos cuenta de que estamos avanzando ms de lo esperado y que en lugar
de tardar las 10 jornadas previstas, tardaremos 8 jornadas, de manera que nos
planteamos asumir ciertas tareas de la siguiente iteracin de la que estimamos
ahora que tardaremos tambin 8 jornadas en lugar de 10. De manera que la
planificacin queda as.
Iteracin 1
Finalizada
Iteracin 2
Historia de usuario 2: Catlogo de productos con las secciones ms impor-
tantes (8 jornadas)
Historia de usuario 2: Catlogo de productos con las secciones restantes.

Parte1 (2 jornadas)
Iteracin 3
Historia de usuario 2: Catlogo de productos con las secciones restantes.
Parte 2 (6 jornadas)
Segundo paso a produccin
Iteracin 4
Historia de usuario 7: Ofertas y promociones. Parte 1 (4 jornadas)
Iteracin 5
Iteracin 6
Cuarto paso a produccin
Nos queda ahora una iteracin 5 con slo 6 jornadas y con un hueco para 4
jornadas adicionales. Despus de hablar con el cliente, decidimos incluir en ese
hueco una de las funcionalidades que haban sido descartadas, la historia de
usuario 8: Tarjetas cliente (4 jornadas). As, la iteracin 5 queda de la siguiente
manera.
Iteracin 5
Durante las siguiente iteraciones no hay ninguna incidencia y el proyecto fi-

naliza tal y como se haba replanteado en la iteracin 2.
2.8.5. Fase de mantenimiento
Durante los dos primeros meses, tras la finalizacin de la fase de produccin se

fueron subsanando algunas deficiencias, sobre todo de rendimiento del apli-
cativo, ya que en XP se prima que las cosas funcionen primero y que luego
sean eficientes. Una vez realizadas estas mejoras y debido a que el nmero de
visitas a la tienda real haba crecido de forma espectacular, se decide invertir un
poco ms e implementar la historia de usuario 9: Pago por mvil (2 jornadas).
2.8.6. Fase de muerte
Durante cinco aos la web funcion hasta que la empresa fue absorbida por
una multinacional de la venta de mascotas.
3. Ser giles no es solo programar giles
De qu nos servira poseer una gran elasticidad en las piernas si no pudira-

mos doblar las rodillas? Exactamente lo mismo nos pasa en el desarrollo de
sistemas de informacin. De nada nos sirve ser giles en la creacin de soft-
ware si no los somos en el resto de facetas organizativas de nuestro trabajo.
La agilidad est llegando a todas las facetas de la ingeniera del software:
Agile Modeling nos permite realizar modelos que se adaptan a las meto- Web complementaria
dologas aqu vistas. El xito le viene dado por su gran adaptabilidad, ya
Agile Modeling (http://
que puede ser usada tanto en metodologas RUP, como en XP o cualquier www.agilemodeling.com)
otra metodologa de desarrollo de software. pretende ser "una gua para el
arte de modelar ", nunca para
la ciencia de modelar.
Agile Data Method nos ayuda en la creacin y mantenimiento de las bases
de datos que dan soporte a los proyectos giles en los que el cambio es
Web complementaria
constante y a veces traumtico para los administradores de las mismas.
http://www.agiledata.org/
Agile Documentation nos ayuda a centrarnos en la documentacin fun- Web complementaria

damental de los proyectos giles que utilicen Agile Modeling.
http://
www.agilemodeling.com/es-
Agile Legacy Integration Modeling nos permite disear de forma gil mo- says/agileDocumentation.htm
delos de aplicaciones que se integren con sistemas heredados tipo host.
Agile Cualquiercosa. Son muchas las iniciativas que se estn desarrollan-

do en torno a los diferentes aspectos que faltan por cubrir, pero sin duda
muchos autores estn aprovechando el tirn de las metodologas giles
para poder dotar sus proyectos de la etiqueta de moda. Slo el tiempo dir
quines eran visionarios y quines eran simples oportunistas.
Resumen
En este mdulo hemos visto cmo cada proyecto (o parte de l) puede realizar-
se con una metodologa diferente. Es responsabilidad nuestra elegir la mejor
adaptada a cada situacin en concreto. Muchas son las metodologas giles,
pero hemos visto que todas tienen caractersticas y objetivos similares. Unas
hacen ms hincapi en la comunicacin humana de los proyectos, otras en
dar valor al negocio lo antes posible, otras en asumir que todo es cambiante,
pero todas son tiles en determinados proyectos, cubren una necesidad o ca-
rencia que se ha detectado en las metodologas de desarrollo de aplicaciones.
De entre ellas hemos conocido la que ms fuerza ha cobrado: la metodologa

Extreme Programming. Los cuatro valores sobre los que se fundamenta, las
doce prcticas que propone y las cuatro variables de los proyectos nos han
hecho constatar que se trata de una metodologa muy madura, nada despre-
ciable y perfectamente aplicable en una gran variedad de proyectos. Tambin
hemos visto que XP es compatible con otras metodologas ya sean giles como
DSDM, o clsicas como RUP.
Nos hemos asomado a los diferentes mbitos en los que la agilidad est irrum-
piendo con fuerza, siendo el ms prometedor de ellos el Agile Modeling. Co-
nocer todos los mbitos y todas las propuestas nos da un punto de referencia
para la reflexin, nos permite saber en qu pueden fallar las metodologas y
as poder aplicarlas con mayor criterio.
Con este mdulo, hemos vislumbrado todo un nuevo abanico de posibilida-

des a la hora de disear, implementar y gestionar proyectos de ingeniera del
software. De vosotros depende ahora ponerlas o no en prctica.
Actividades
1. Describid tres proyectos en los que trabajarais con metodologas giles. Elegid cul de ellas
utilizarais y comentad en qu fundamentarais esa decisin.
2. De los tres proyectos de la actividad anterior, elegid uno para desarrollarlo mediante XP.
Disead las historias de usuario, la metfora del negocio y planificad las fases.
3. Cread una metodologa propia que se adapte al manifiesto gil y explicad cmo la aplica-
rais en otro de los proyectos de la primera actividad.
Ejercicios de autoevaluacin
1. Las metodologas giles son siempre la mejor opcin para la mayora de proyectos?
2. Las metodologas clsicas y las metodologas giles son incompatibles?
3. Cundo no deberamos aplicar una metodologa gil?
4. De las doce prcticas de XP, cules tienen relacin con una metodologa de equipo? Cu-
les son las tres ms importantes?
5. En XP, en qu consiste el spike arquitectnico de la fase de exploracin?
6. Cules son los cuatro valores del "manifiesto gil"?

Solucionario
Ejercicios de autoevaluacin
1. Las metodologas giles no son la gran solucin a todos los problemas del desarrollo de
aplicaciones, ni tan siquiera se pueden aplicar en todos los proyectos, pero s que nos aportan
otro punto de vista de cmo se pueden llegar a hacer las cosas, de forma ms rpida, ms
adaptable y sin tener que perder la rigurosidad de las metodologas clsicas.
2. Rotundamente no. Se pueden compaginar perfectamente, incluso en un mismo proyecto;

de hecho, existen mltiples estudios de cmo aplicar DSDM y XP con RUP en un mismo
proyecto.
3. En los casos siguientes:
Con un equipo muy grande y/o formado mayoritariamente por gente sin experiencia.
Si el cliente final no est involucrado y/o impone barreras de comunicacin.
Si los requisitos son apenas cambiantes.
Si es un proyecto crtico.
Si es un proyecto demasiado grande.
Si no os apetece probar una metodologa gil.
4. Las prcticas que tienen relacin con la parte metodolgica de trabajo en equipo son:
propiedad colectiva del cdigo, programacin en parejas, integracin continua, 40 horas
semanales y metfora del negocio.
Las tres ms importantes de las doce prcticas son el diseo simple, el test y la refactoriza-
cin. Incluso, si no queremos adoptar la totalidad de las prcticas de XP, adoptando estas
tres a nuestra metodologa habitual podemos tener una sustancial mejora en los resultados
obtenidos.
5. En el spike arquitectnico, el equipo de desarrollo:
Prueba la tecnologa.
Se familiariza con la metodologa.
Se familiariza con las posibilidades de la arquitectura.
Realiza un prototipo que demuestre que la arquitectura es vlida para el proyecto.
6. Los cuatro valores del "manifiesto gil" son los siguientes:
Valorar ms al individuo y sus interacciones ms que al proceso y las herramientas.

Valorar ms el desarrollo de software que funciona que obtener una buena documenta-
cin.
Valorar ms la colaboracin con el cliente que la negociacin de un contrato.
Valorar ms responder a los cambios que seguir una planificacin.
Glosario
caracterstica fFuncionalidad simple y poco costosa de desarrollar que aporta valor al
cliente del software a utilizar.
en feature
historias de usuario f pl Descripciones cortas de la usabilidad y funcionalidad que se

espera del sistema, escritas por el cliente final, en su lenguaje y sin tecnicismos.
Manifiesto gil m Manifiesto que recoge los valores que deberan cumplir las metodolo-
gas de desarrollo de software. Fue firmado por Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, An-
drew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwa-
ber, Jeff Sutherland y Dave Thomas.
metfora del negocio f Historia comn compartida por el usuario y el equipo de desa-
rrollo que describe cmo deben comportarse las diferentes partes del sistema que se quiere
implementar.
metodologas giles f pl Metodologas que cumplen el manifiesto gil.
refactorizacin f Modificar el cdigo para dejarlo en buen estado, volviendo a escribir las
partes que sean necesarias, pero siempre desde un punto de vista global a la funcionalidad
independientemente del cambio que hagamos.
spike arquitectnico m Periodo durante el cual el equipo de desarrollo, prueba la tecno-

loga y se familiariza con la metodologa que se aplicar durante el proyecto
test de aceptacin m Test creado conjuntamente con el cliente final que debe reflejar las
necesidades funcionales del primero.
test de integridad m Test creado por el equipo de desarrollo para probar que todo el
conjunto funciona correctamente con la nueva modificacin.
test unitario m Test creado por el programador para ver que todos los mtodos de la clase
funcionan correctamente.
Bibliografa
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley.
Beck, K.; Martin F. (2001). Planning Extreme Programming. Boston: Addison-Wesley.
Burke, E. M.; Coyner, B. M. (2003). Java Extreme Programming Cookbook. Sebastopol:

O'Reilly & Associates Inc.
Cans, J. H.; Letelier, P.; Penads, M. C. (2004). Metodologas giles en el desarrollo del
software. Valencia: Universidad de Valencia.
Cockburn, A. (2001). Agile Software Development. Boston: Addison-Wesley.
Cronin, G. (2003). eXtreme Solo: A Case Study in Single Developer eXtreme Programming. Auc-
kland: University of Auckland.
Highsmith, J. (2002). Agile Software Development Ecosystems. Boston: Addison-Wesley.
Hightower, R; Lesiecki, N. (2002). Java Tools for Extreme Programming. Nueva York: Wiley
& Sons Inc.
Reynoso, C. (2004). Mtodos heterodoxos en desarrollo del software. Buenos Aires: Universidad
de Buenos Aires.
Salo, J. H.; Abrahamson, P.; Ronkainen, J.; Warsta, J. (2002). Agile Software Develop-
ment Methods - Review And Analysis. Universidad de Oulu: VTT Publications.
Schwaber, K.; Beedle, M. (2002). Agile Software Development with Scrum. Nueva Jersey:
Prentice Hall.
Wake, W. C. (2000). Extreme Programming Explored. Boston: Addison-Wesley.
Wallace, D.; Raggett, I.; Aufgang, J. (2002). Extreme Programming for Web Projects. Bos-
ton: Addison Wesley.

Modificacion de Metodologia

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modificacion de Metodologia

Hochgeladen von

Copyright:

Verfügbare Formate

Metodologas giles en el

Taller realizado en el marco de las VIII Jornadas de Ingeniera del

Metodologas giles en el Desarrollo de Software

Mutacin de casos de prueba de JUnit

Experiencias de formacin en metodologas giles

Brief eXPERT Aproach Description

eXPERT: Result from seven pilot projects

Formal Agility. How much of each?

PALABRAS CLAVE. Procesos de Software, Metodologas giles, Programacin Extrema (XP)

2.1. El Manifiesto gil.

3. PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)

Menos nfasis en la arquitectura del software La arquitectura del software es esencial y se

3.1. Las Historias de Usuario

Figura 1. Las prcticas se refuerzan entre s

Resumen. En la actualidad existen multitud de plataformas de explotacin para los

Palabras clave: Procesos giles, metodologas giles, metodologas de desarrollo.

3. Proceso metodolgico de MIDAS

Solution Domain Abstract Stability

Agile, incremental, waterfall

Problem Domain Abstract Stability

Aspectos Agil Dirigido por modelos

Modelo Negocio Modelo Dominio

<<Transformacin PIM - PIM>>

<< Transformacin PIM-PSM>>

CONTENIDO HIPERTEXTO FUNCIONALIDAD

<<Transformacin PSM - PSM>>

Fig. 3.- Proceso de desarrollo de MIDAS

4. Conclusiones y Trabajos Futuros

Figura 1. Un programa y dos ejemplares de su conjunto de mutantes

2 Mutacin de casos de prueba JUnit

TestCase TestSiute TestResult

Figura 3. Clases proporcionadas por JUnit para la automatizacin de la fase de pruebas

Como se observa en la figura, dentro de cada mtodo creamos un objeto

Figura 5. Algunos de los mutantes generados para el caso de la Figura 4

public void comprobarTS_284_23() {

try { TS_284_23= testTS_284_23(); }

if (TS_284_23==null && TS_284_23_m0==null) mVivos++;

Por ltimo, se guardan los resultados de forma tabulada en un fichero de texto

4 Conclusiones y trabajo futuro

Patricio Letelier, Jos Hilario Cans, M Carmen Penads y Juan Snchez

LDS se impartir en el segundo cuatrimestre de tercer ao en la ETSIA y dispone de 1.5 crditos de

Fin Fase de Exploracin Fin de la Fin de la Fin de la

Figura 1: Hitos en la planificacin de la entrega

En la Figura 1 se muestra la planificacin global de la entrega, preestablecida de acuerdo con las

En LSI se aplica un sistema de evaluacin continua. Coincidiendo con cada presentacin de

4. Conclusiones y trabajo futuro

En LSI al principio se tiene un gran inconveniente: los alumnos no conocen la metodologa y no se

Para las estimaciones y el seguimiento de la planificacin result efectiva la utilizacin de puntos. Un

- Estamos realizando trabajos en control de versiones para historias de usuario y en herramientas

- Finalmente, estamos preparando un seminario en metodologa giles para desarrolladores de

[6] Proyecto EUROPA: Una Enseanza Orientada al Aprendizaje. Vicerrectorado de Coordinacin

Abstract: This document introduces a light method for software development

Figure 1 eXPERT Process Architecture

eXPERT Organisational Structure (Roles)

Customer Requirements Management

Completion criteria: Customer requirements are granulated to such an extent that

Completion criteria: Project maintained on track, i.e. iterations and releases

Measures: Overall designing effort, Defects found during Design Inspection

Productivity Size / Effort Work/Time Size [KLOC] Measure Productivity

Effort [Man month]

develop software and a is 120

introduce this practice.

Weekly efforts % ratio

Angel Herranz and Juan Jose Moreno-Navarro