Universidad Tecnológica

Nacional

2010
Facultad Regional

Crystal Clear Methodology

Melisa Guzmán – Legajo:

26.107
Víctor Alberto Soria – Legajo:
Contenido
Metodologías Ágiles........................................................................................3
¿Qué significa ser ágil?................................................................................3
Los cuatro principios del manifiesto ágil.....................................................4
Metodología Crystal........................................................................................5
¿Qué es Crystal Clear?...................................................................................6
Propiedades................................................................................................6
Estrategias.................................................................................................. 8
Técnicas......................................................................................................9
Proceso......................................................................................................10
Roles......................................................................................................... 10
Caso de Estudio............................................................................................13
Introducción..............................................................................................14
Cronología del Proyecto............................................................................14
Roles......................................................................................................... 14
Exploración...............................................................................................15
Reunión de Planeación..............................................................................17
Incremento 1: Esqueleto Caminante.........................................................18
Incremento 2: Tratamiento de Documentos..............................................20
Incremento 3: Multihilo.............................................................................20
Incremento 4: Búsqueda...........................................................................22
Conclusiones................................................................................................22
Evaluación de Crystal Clear.......................................................................23
Bibliografía y Sitios Web Recomendados......................................................24
Metodologías Ágiles
Las metodologías ágiles surgen como una alternativa, una reacción a las
metodologías tradicionales y principalmente a su burocracia. Muchas ideas
que se plantean en las metodologías ágiles no son nuevas, gran parte de
ellas ya fueron reflejadas por Brooks en su mítico libro, The Mythical Man
Month y en gran parte responden al sentido común. Algunos autores
consideran que se ha cumplido un círculo que empezó con una reacción
provocada por múltiples factores y señalada temporalmente por el
manifiesto de Dijkstra, en el cual se hacía un llamamiento a la disciplina y
que se cierra con el ya famoso Manifest for Agile Software Development,
una petición por la relajación de los procesos en pro de las personas.

La aparición de las metodologías ágiles no puede ser asociada a una única

causa, sino a todo un conjunto, bien es cierto que la mayoría de autores nos
indicarán que son una reacción a las metodologías tradicionales, pero
¿cuáles fueron las causas de esta reacción?, los factores que comúnmente
más se mencionan que hicieron realidad esta nueva manera de desarrollar
software son:

• “Plumbing”. La traducción al castellano sería pesadez, lentitud

de reacción, exceso de documentación, en definitiva, falta de
agilidad de los modelos de desarrollo existente.

• Las metodologías existentes no cumplieron las expectativas

planteadas inicialmente.

• Explosión de la red y las aplicaciones Web.

• Movimiento open source.

Definitivamente, las metodologías tradicionales exigen un sobreesfuerzo por

parte del equipo de desarrollo en fases poco productivas, como es la
documentación y debido a su estructuración (típicamente siguiendo el
modelo en cascada o más actualmente UP) son poco flexibles a los cambios,
de requisitos, de nuevas funcionalidades, etc. Si a todo esto le añadimos
que las metodologías tradicionales no han sido capaces de eliminar todos
los fallos, que persiguen al desarrollo de proyectos software prácticamente
desde sus inicios, obtenemos un clima un poco escéptico respecto a las
metodologías. A todo lo planteado, además debemos añadir un cambio
bastante importante, en cuanto a la demanda del mercado del software,
cada vez más orientada a la Web, con uno requisitos muy volátiles, que
requieren tiempos de desarrollo cada vez más cortos y con una comunidad
“in crescendo”, la comunidad del software libre.

¿Qué significa ser ágil?

Jim Highsmith dice que ser Agile significa ser capaz de “Deliver quickly,
Change quickly, Change often”. Mientras que las técnicas ágiles pueden
variar en su ejecución y en su énfasis, todas ellas comparten características,
incluyendo el desarrollo iterativo y que están centradas en la interacción,
comunicación, y en la reducción de la creación de artefactos intermedios.
Desarrollar mediante iteraciones permite al equipo de desarrollo adaptarse
a los cambios de los requisitos. Trabajar con un alto grado de comunicación
permite que el equipo pueda tomar decisiones y aplicarlas inmediatamente.
La reducción de artefactos intermedios que no dan valor añadido al
producto final, nos permite asignar más recursos al producto en sí y podrá
ser acabado antes. Cockburn y Highsmith nos explican que lo que es
realmente nuevo de los métodos ágiles, no son las prácticas que ellos
utilizan, sino el reconocimiento de las personas como principales valedoras
para que un proyecto triunfe, en conjunto con una gran orientación a la
efectividad y la manejabilidad. La mayoría de seguidores de las
metodologías ágiles están de acuerdo en que ser ágil, es algo más que
seguir las guías que se supone que hacen un proyecto ágil. La verdadera
agilidad es más que un conjunto de prácticas, es un estado de ánimo.

Los cuatro principios del manifiesto ágil

En marzo de 2001, Kent Beck convocó a 17 críticos de los modelos de
mejora basados en procesos, justo un par de años antes Kent había
publicado el libro "Extreme Programming Explained" en el que exponía una
nueva metodología denominada Extreme Programming, se reunieron en Salt
Lake City para discutir sobre el desarrollo de software.

En la reunión se acuñó el término “Métodos Ágiles” para definir los métodos

que estaban surgiendo como alternativa a las metodologías formales,
consideradas excesivamente “pesadas” y rígidas por su carácter normativo
y su fuerte dependencia de planificaciones detalladas, previas al desarrollo.
De esta reunión surgiría un resumen en forma de cuatro principios, que
actualmente conocemos como “Manifiesto Ágil”, que básicamente son los
principios sobre los que se basan los métodos reconocidos como ágiles.

Manifiesto ágil (http://www.agilemanifesto.org)

Estamos poniendo al descubierto mejores métodos para desarrollar
software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo
hemos llegado a valorar:

• A los individuos y su interacción, por encima de los procesos y

las herramientas.
• El software que funciona, por encima de la documentación
exhaustiva.
• La colaboración con el cliente, por encima de la negociación
contractual.
• La respuesta al cambio, por encima del seguimiento de un
plan.
Firmado por: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries,
Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland,
Dave Thomas.
Metodología Crystal
La familia de metodologías Crystal es un conjunto de diferentes
metodologías que podemos seleccionar en función de la adecuación al
proyecto en el que nos encontremos. Crystal también incluye un conjunto
de principios para adaptar las diferentes metodologías según las
circunstancias del proyecto. Cada una de las metodologías de la familia
Crystal tiene asignado un color, cuanto más oscura sea su tonalidad, más
compleja es la metodología.

Crystal sugiere que escoger un color de la metodología para un proyecto en

función de su criticidad y tamaño. Los proyectos más grandes suelen
necesitar una mayor coordinación y metodologías más complejas que los
proyectos más pequeños. Cuanto más crítico sea el sistema que queremos
desarrollar, más rigurosidad necesitamos disponer en el desarrollo del
proyecto. En la figura anterior aparecen unos caracteres (C, D, E y L) e
indican las pérdidas potenciales por fallos del sistema, y lo hacen de la
siguiente manera:

• C, indica pérdida de confort debido a un fallo del sistema

• D, indica pérdida de dinero discrecional, es decir del que

podemos disponer, generalmente nuestro.

• E, indica pérdida de dinero esencial, es decir dinero que

probablemente no es nuestro y no podemos disponer de él
libremente.
 • L, de Life en ingles, vida. Indica la pérdida de vidas por el fallo
del sistema.

Las dimensiones de criticidad y tamaño, son representadas por un símbolo

de la categoría del producto, que aparece en la figura. Por ejemplo, D6
indica un proyecto con un máximo de 6 personas, de máxima criticidad de
dinero discrecional.

Crystal Clear no es una metodología en si misma sino una familia de

metodologías con un “código genético” común. La idea es poder armar
distintas metodologías para distintos tipos de proyectos. Cada proyecto y
organización usará este código genético para generar su propia
metodología.

Las metodologías que integran la familia Crystal tienen en común un

conjunto de características. Primero, los proyectos siempre usan ciclos de
desarrollo incrementales, de una longitud máxima de cuatro meses, siendo
preferibles periodos de un mes a tres meses. Segundo, se hace énfasis en la
comunicación y la cooperación de la gente. Tercero, las metodologías
Crystal permiten el uso de prácticas y herramientas de otras metodologías
ágiles como XP o Scrum.

¿Qué es Crystal Clear?

Crystal Clear está diseñada para pequeños proyectos, proyectos de
categoría D6, pudiendo contar con un equipo de desarrolladores formado
por 6 personas como máximo. Algunas modificaciones nos permitirían
utilizar Crystal Clear con proyectos de tipo E8 o D10. Dada las limitaciones
de comunicación de la estructura, el equipo debería encontrarse ubicado en
una oficina común.

Reuniones
Grupos de
en un Proyectos Proyectos
hasta 8
mismo pequeños no críticos
personas
espacio
Propiedades
Entrega frecuente. Consiste en entregar software a los clientes con
frecuencia, no solamente en compilar el código. La frecuencia dependerá
del proyecto, pero puede ser diaria, semanal o mensual.

Al hacer esto aseguramos que nuestro proyecto no se despegara mucho de

lo que el cliente necesita realmente, pues cada entrega formal, resultara en
correcciones a los malentendidos que surgen continuamente en el análisis
del sistema.

Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada

semana o una vez al mes) para pensar bien qué se está haciendo, cotejar
notas, reflexionar, discutir.

Eso se llama hacer un "Taller de reflexión", obteniendo una lista de

prácticas o hábitos de desarrollo que nos gustaría mantener, una lista de lo
que nos gustaría intentar, y probablemente, una lista de lo que queremos
evitar, todo esto escrito y publicado de alguna manera, a la vista de todos.

Esto nos genera una mejora continua en nuestro proyecto y nos da el

tiempo para corregir el camino, acelerar el desarrollo y mejorar nuestros
hábitos y conocimiento de desarrollo.

Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante

especial es disponer en la sala de un experto diseñador senior y discutir
respecto del tema que se trate.

La colocación física del equipo de desarrollo es de lo más importante, y la

comunicación osmótica se refiere a llevar la comunicación al máximo nivel:
Nos debe tomar menos de 30 segundos llevar nuestras dudas a los ojos u
oídos de quien puede resolvérnoslas, debemos sentarnos en el mismo
cuarto o en cubículos contiguos. Captar algo relevante de la conversación
entre otros miembros del equipo al menos cada pocos días.

El hecho de tener que levantarnos de nuestro escritorio, cruzar el pasillo y

abrir una puerta, con toda seguridad nos distrae de nuestro tren de
pensamiento. Irrumpir en la oficina de otro miembro del equipo y hacerle
preguntas, a si sean de lo más simple, terminara por retrasar bajar nuestra
productividad de manera crítica.

Comparado con hacer una pregunta a una persona que está

constantemente conectada en nuestro mismo tren de ideas, nos da la
diferencia entre comunicación cerrada y la mejor, comunicación osmótica.

Seguridad personal. Hablar con los compañeros cuando algo molesta

dentro del grupo. Fomentar la confianza y el respeto entre el entre el
equipo, de manera que todos tengan claro que lo importante es lograr los
objetivos del proyecto de manera conjunta. Así, las equivocaciones e
incapacidades de unos, pueden ser cubiertas por los demás, los miembros
no temen exponerse, y el equipo respeta estas exposiciones.

Tres exposiciones en particular son importantes

 • Revelar nuestra ignorancia

• Revelar nuestros errores

• Revelar nuestra incapacidad en una tarea asignada

Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para

hacerlo. Cada quien debe saber cuáles son los dos elementos de más alta
prioridad sobre los cuales trabaja en todo momento. Además, deberíamos
tener garantizado todos por lo menos dos días seguidos y dos horas
ininterrumpidas por día para trabajar en un proyecto.

Fácil acceso a usuarios expertos. Tener alguna comunicación con

expertos desarrolladores. Nos debería de tomar menos de tres días en
promedio, desde que surge una duda respecto al uso del sistema, hasta que
un usuario experto la resuelve. Inclusive lo deseable, es poder obtener las
respuestas en unas cuantas horas cuando mucho.

Si surge una duda sobre en el desarrollo de la funcionalidad, y podemos

levantar el teléfono para comunicarnos con el usuario experto en el
dominio, hacerle algunas preguntas y seguir con el desarrollo, entonces
estamos del otro lado. Esto no es siempre posible, pero por lo menos será
importante poder agendar una cita para visitar o ser visitado por nuestro
usuario experto.

Ambiente técnico con pruebas automatizadas, gestión de la

configuración e integración frecuente. Poder dejar corriendo las
pruebas de nuestro desarrollo hasta el final sin estar físicamente presente
nos ahorra el tiempo que no tenemos, sin mencionar las ventajas de
depuración inmediata y de probar el código indiscriminadamente.

Todos los desarrolladores deberían ingresar el código en el que trabajan en

un sistema de administración de la configuración, de manera que este se
encargue de llevar el control de versiones, documentos, etc. y escribir una
nota útil sobre el código cuando lo ingresan.

El sistema se debería integrar por lo menos dos veces a la semana,

juntando el código de todos, compilándolo, y haciéndolo pasar por todas las
pruebas automáticas posibles, y obteniendo de esta manera código
ejecutable constantemente.

El sistema funciona más o menos así: Se diseñan los test antes del
desarrollo. El sistema se integra frecuentemente en el sistema de manejo
de configuración y se pasa por todos los test, mostrando los resultados de
inmediato.

Estrategias
Exploración de 360°. Verificar o tomar una muestra del valor de negocios
del proyecto, los requerimientos, el modelo de dominio, la tecnología, el
plan del proyecto y el proceso.
 Éxito temprano. Es mejor buscar pequeños triunfos iniciales que aspirar a
una gran victoria tardía.

Esqueleto caminante. Es una transacción que debe ser simple pero

completa.

Rearquitectura incremental. Se ha demostrado que no es conveniente

interrumpir el desarrollo para corregir la arquitectura. Más bien la
arquitectura debe evolucionar en etapas, manteniendo el sistema en
ejecución mientras ella se modifica.

Radiadores de información. Es una lámina pegada en algún lugar que el

equipo pueda observar mientras trabaja o camina. Tiene que ser
comprensible para el observador casual, entendida de un vistazo y
renovada periódicamente para que valga la pena visitarla.

Explorar
360º

Radiador Éxitos
es de
informaci tempran
ón os
Estrateg
ias

Re Esquelet
arquitectur
a
o
increment camina
al nte

Técnicas
Entrevistas de proyectos. Se suele entrevistar a más de un responsable
para tener visiones más ricas.

Talleres de reflexión. El equipo debe detenerse treinta minutos o una

hora para reflexionar sobre sus convenciones de trabajo, discutir
inconvenientes y mejoras y planear para el período siguiente.

Planeamiento Blitz. Se escriben las funciones del programa en tarjetas y

los programadores estiman tiempos para cada una de forma independiente
entre las mismas.

Estimación Delphi con estimaciones de pericia. Los expertos se reúnen y

definen el tamaño del proyecto, fecha de entrega, etc.

Encuentros diarios de pie. Cinco a diez minutos como máximo. No se

trata de discutir problemas, sino de identificarlos.
Miniatura de procesos. Una forma de presentar Crystal Clear puede
consumir entre 90 minutos y un día. La idea es que la gente pueda
“degustar” la nueva metodología.

Gráficos de quemado. Son gráficas en las cuales se observan retrasos en

las tareas, este gráfico sirve para tener un control del proyecto y ver en que
funciones deben tener mayor prioridad.

Programación lado a lado. Establece proximidad, pero cada quien se

enfoca a su trabajo asignado, prestando un ojo a lo que hace su
compañero, quien tiene su propia máquina. Esta es una ampliación de la
Comunicación Osmótica al contexto de la programación.

Proceso
La familia de metodologías Crystal no especifica ningún ciclo de vida
concreto, ni ningún modelo de procesos, en vez de eso lo que hace es
determinar una guía de las políticas estándar, productos de trabajo, asuntos
locales, herramientas, estándares y roles.

A continuación veremos las prácticas más comunes de las metodologías

Crystal:

Planificación por etapas. Básicamente consiste en la planificación del

siguiente incremento del sistema. La planificación debe finalizar con una
versión ejecutable cada tres o cuatro meses como máximo. El equipo
selecciona los requisitos que serán implementados en el incremento y
planifican lo que creen que serán capaces de hacer.

Revisiones y resúmenes. Cada incremento consta de diferentes

iteraciones y cada iteración incluye las siguientes actividades: construcción,
demostración y resumen de los objetivos del incremento.

Monitorización. Los progresos del proyecto son monitorizados a partir de

las diferentes entregas del equipo durante el proceso de desarrollo. El
progreso se mide con los hitos clave y la estabilidad de las fases (muy
inestable, fluctúa y lo suficiente estable para revisar).

Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un estado

lo suficientemente estable para su revisión, entonces es el momento para
pasar a la siguiente tarea. Con tal de poder llevar esto a cabo, los equipos
de seguimiento y arquitectura deben revisar sus planes de trabajo, su
estabilidad y sincronización.
Roles
• Sponsor: persona que se encarga de poner y hasta defender su
inversión en el proyecto. Es quien tiene en mente la visión a largo
plazo. Esta persona es quién creará la visibilidad externa para el
proyecto y proveerá al equipo de decisiones cruciales a nivel de
negocio. Si el costo del desarrollo sobrepasa la inversión disponible,
debe tomar la decisión de seguir o no con el proyecto; si continúa,
deberá replantear las funciones restantes para recuperar la inversión.
Parte de la metodología involucra dar buena información al sponsor
para que tome sus decisiones.

• Usuario Experto: Esta es la persona que se supone está familiarizada

con los procedimientos operativos del sistema en uso (si es que
existe uno), conociendo cuáles son los modos de operación más y
menos frecuentemente utilizados, qué atajos son necesarios, y qué
información necesita verse en conjunto en una misma pantalla. Es
una base de conocimiento diferente de la que se espera que posea el
Experto en Negocio. De la persona que asume el rol de Usuario
Experto, se espera que conozca las reglas de negocio necesarias para
el sistema, qué políticas son estables frente a las que son propensas
al cambio. No se espera que el Experto en Negocios tenga una íntima
familiaridad con las actividades minuto a minuto de la población de
usuarios, a diferencia del Usuario Experto.

• Líder de Diseño: Esta persona es el líder técnico, se supone que tiene

experiencia en el desarrollo de software, que es capaz de realizar la
mayor cantidad de diseño del proyecto y de encaminar al equipo
cuando sea necesario. En términos de niveles de competencia, se
espera que el líder diseñador sea un diseñador de nivel 3. Partiendo
 de que en un proyecto Crystal Clear hay sólo de tres a ocho personas,
al menos una de ellas debe ser competente y experimentada, esto
significa de nivel 3. Usualmente, hay un par de aprendices o juniors
entre los miembros del proyecto. Como medida de seguridad, se
designa el rol de líder diseñador, separado de los otros roles. Se
espera que el líder diseñador desempeñe tareas tanto de diseño
como de programación, al igual que un programador diseñador.
Usualmente, no siempre, el líder diseñador es la persona más
experimentada del equipo y que también debe asumir las
asignaciones de programación más difíciles. Esto es común, y de
hecho representa un riesgo para el proyecto. El líder diseñador tiende
a estar sobrecargado, teniendo roles como coordinador, arquitecto,
mentor y programador más experimentado. Cualquier cosa que
pueda hacerse para liberarlo de tareas, mejorará el perfil de riesgo
del proyecto. La opción obvia es elegir a alguien que interprete el rol
de coordinador, total o parcialmente.

• Diseñador Programador: Es una persona que reúne las características

de un diseñador, como de un programador. El diseño sin
programación, representa fallas durante la retroalimentación (en
proyectos de todos los tamaños). Es raro que esto se dé en un
proyecto del tipo Crystal Clear. La programación natural involucra
diseñar.

• Experto en Negocios: Es el experto que indica cómo va el negocio,

qué estrategias o políticas deben arreglarse, qué tiende a variar
pronto, seguido o nunca. Esta persona responderá variadas preguntas
a los desarrolladores acerca del corazón del sistema. Provee
información diferente de la que entrega el Usuario Experto, de hecho,
en algunos casos puede suceder que el usuario experto, es también
el experto en negocios. En muchas situaciones se ha visto que el
sponsor, el líder de diseño o el usuario experto actúen como expertos
en negocios. Algunas veces, una persona externa es traída para
desempeñar esta tarea.

• Coordinador: El coordinador es, probablemente, una ocupación

parcial de alguno de los miembros del equipo; los proyectos con
cuatro a ocho personas tienen una persona dedicada a manejar el
proyecto. Puede darse que una persona maneje varios proyectos y
juegue el papel de coordinador en cada uno de ellos.
Alternativamente, el sponsor o el líder de diseño asumen este rol, o
incluso otras personas se turnan para éste.

• Tester: encargado de las pruebas

• Escritor: encargado de redactar la documentación (manuales de

usuario, de entrenamiento y ayuda)
Caso de Estudio
En el presente caso de estudio, se explicará de manera clara y fácil de
entender cómo se implementa la metodología en un determinado proyecto.
Esperando conocer sobre el desarrollo ágil como parte de una actividad de
innovación del proceso corporativo, se decidió probar Crystal Clear en el
desarrollo de un proyecto denominado “Indexación Automática de Orígenes
de Datos (crawl o auto-indexing)”.

El sistema tiene como propósito permitir la auto-indexación de la

información almacenada en diversos documentos (el sistema queda limitado
a la indexación de archivos de Microsoft Word 97 – 2003, con extensión
DOC; archivos de texto, con extensión TXT; archivos de Microsoft
PowerPoint 97 – 2003, con extensión PPT; archivos de Microsoft Excel 97 –
2003, con extensión XLS y archivos PDF). El proceso de indexación de toda
la información se iniciará automáticamente, mediante un Scheduler, luego,
la misma podrá ser accedida desde una aplicación de búsqueda. El proceso
de indexación comprende una serie de pasos internos, que implican la
implementación de un Tokenizer para extraer el texto y poder procesarlo. El
siguiente paso consiste en la eliminación de las Stop Words y luego, la
generalización de las palabras mediante Stemming. Esto proporcionará al
usuario búsquedas más intuitivas y con resultados en pocos segundos.

En términos generales, la meta de este sistema es la automatización del

proceso de indexación de archivos. Concretamente, esto incluye:

• Iniciación automática del proceso de indexación

• Agilización de la búsqueda de los archivos necesarios de

manera rápida e intuitiva

• Disminución de tiempo y carga de trabajo de los empleados

• Respuesta rápida a los clientes

El principal beneficio que se obtiene con la implementación de este sistema

es la notable reducción del tiempo de búsqueda de archivos debido a la
automatización del proceso y la implementación de herramientas de
software diseñadas para tal fin.

La prioridad principal del equipo del proyecto era completar el prototipo

antes de que concluya el año 2009. Lo ideal sería tener un producto de
calidad para mostrar inmediatamente a las empresas interesadas en él. De
hecho, se terminó con una demostración de alta calidad que puede ser
transformado en producto en un tiempo razonablemente corto, y fácilmente
integrable con otros productos ya desarrollados.

Crystal Clear es una metodología ágil, y como tal tiene como objetivo
reducir el riesgo de una mala construcción, y ofrecer un valor tan pronto
como sea posible. Crystal Clear fue seleccionado porque hace hincapié en:
 • Eficiencia. Crystal Clear tiene como objetivo minimizar los
residuos, centrándose al mismo tiempo en las características
importantes del equipo.

• Habitabilidad. Crystal Clear está diseñado para ser cómodo

de usar, de modo que los equipos no sientan la necesidad de
evitar que los sigan.

• Seguridad. La metodología tiene como objetivo aumentar la

probabilidad de éxito de la entrega.

Se decidió desarrollar este proyecto con Crystal Clear, porque era pequeño
y no crítico (que es el tipo de proyecto para la que fue diseñada la
metodología), y porque el equipo era reducido (estaba compuesto por cinco
miembros). El cliente en este caso, es la empresa misma, ya que este
proyecto es una prueba piloto para el uso de esta metodología.

Introducción
Básicamente, más allá de brindar la posibilidad de indexación automática de
las imágenes de los documentos escaneados mediante nuestro mediante
OCR, el sistema desea ofrecer la funcionalidad de auto indexación de la
información residente en diversos medios (discos de red, bases de datos,
etc.). De esta manera un "robot de indexación" iniciará, mediante un
proceso programado, la indexación de toda la información existente en los
medios especificados. Luego la misma será accesible desde una aplicación
de consulta.

No se partió de ningún prototipo ni diseño previo. El sistema era una

herramienta completamente nueva para el equipo de desarrollo.

Cronología del Proyecto

La fecha de inicio del proyecto fue el 15/06/2009 y se planificó, en un
principio, una duración de 3 a 4 meses como máximo.

Los miembros del equipo de desarrollo para el proyecto estaba compuesto

por las siguientes personas:
• Norma, líder de proyecto

• Omar, programador experto en Java

• Carlos, programador junior en Java

• Víctor, programador junior en Java

• Melisa, analista funcional

Roles
Para dar comienzo al inicio del proyecto se establecieron los requisitos
iniciales del mismo, el enfoque de desarrollo, una primera estructura de
división del trabajo, y una estimación para el trabajo. La estimación fue de
120 días de esfuerzo. La asignación inicial de las funciones se muestra a
continuación:

Nombre Roles
Norma Sponsor, Experta en Negocios
Omar Líder de Diseño, Coordinador
Carlos Usuario Experto
Víctor Diseñador-Programador, Tester
Melisa Coordinadora, Escritora, Tester

A pesar de que se tenían los requisitos básicos del sistema, estaba claro que
había cuestiones que teníamos que resolver antes de poder iniciar el
desarrollo iterativo. Así que se tomó la idea de una "fase de exploración" de
XP. Esta fue la primera fase del proyecto.

Exploración
La fase de exploración fue de dos semanas, en el que Omar y Carlos
capturaron los requisitos más detallados, investigaron las principales
cuestiones técnicas, y firmaron la estimación para el proyecto.
Omar y Carlos trabajaron juntos para completar los detalles, Carlos (como
usuario) fue la principal fuente de los requisitos. Capturaron a los requisitos
de uso en una pizarra, y mediante el dibujo de las pantallas se fueron
realizando los primeros diseños.
Las impresiones fueron numeradas y mantenidas juntas en una carpeta. A
partir de los requisitos identificados, Melisa comenzó un documento de
requisitos.
Después de algunas investigaciones, se decidió que la aplicación fuera
desarrollada bajo el lenguaje de programación Java (J2EE), y
complementada con la implementación de una API para recuperación de
información, denominada Lucene. Apache Lucene es una librería de
software libre, una herramienta de desarrollo, no es una aplicación de
búsqueda.
 Nueva Planificación

Seleccione el tipo de planificación Detalle de Planificación

Nombre
Diaria
Directorio Raíz Examinar

Semanal Tipo de Archivo Seleccione una opcion

Día [Lun, Mar, …] Hora [HH:MM]

Mensual
Intervalo [MM] Frecuencia[MM] Guardar

Planificaciones

Nº Nombre Directorio Raíz Tipo de Archivo Tipo de Planificación Hora Intervalo

Modificar

Eliminar

Salir

Reunión de Planeación
Se realizo una reunión de planificación usando la técnica de planificación de
proyectos sugerido en CC. Los miembros del equipo se sientan alrededor de
una mesa y se distribuyen tarjetas de tarea. Cada tarjeta de tarea tenía un
título, una breve descripción, el nombre de la persona, y una estimación en
días-hombre.
Distribuimos las tarjetas de tareas sobre la mesa y se acordó un orden para
cada una, de manera que se maximice las posibilidades de alcanzar los
objetivos del proyecto. A continuación se dio a cada tarjeta una etiqueta (en
la parte inferior de la tarjeta) para que podamos reconstruir el orden.
Después de la reunión, las tareas se han copiado en Microsoft Project, a fin
de tener claramente la planificación para el proyecto.

Indexación Automática de Origenes 100 15/06/2 30/10/2

de Datos días 009 009
10 15/06/20 26/06/20
Fase de Exploración
días 09 09
15/06/20 16/06/20
Determinación de los Requisitos 2 días
09 09
17/06/20 19/06/20
Esbozo de los primeros diseños 3 días
09 09
Armado de carpeta para 22/06/20 23/06/20
2 días
anotaciones 09 09
24/06/20 26/06/20
Generación de la primera ERS 3 días
09 09
29/06/20 01/07/20
Reunión de Planeación 3 días
09 09
29/06/20 29/06/20
Elaboración del diagrama de Gantt 1 día
09 09
30/06/20 30/06/20
Confección de tarjetas de tareas 1 día
09 09
 Estimación de la duración del 01/07/20 01/07/20
1 día
proyecto 09 09
Primer Incremento: Esqueleto 18 02/07/20 27/07/20
Caminante días 09 09
02/07/20 02/07/20
Reunión de Visión y Reflexión 1 día
09 09
Determinación de las herramientas 03/07/20 06/07/20
2 días
a utilizar 09 09
15 07/07/20 27/07/20
Generación del primer Release
días 09 09
Segundo Incremento: Tratamiento 16 28/07/20 18/08/20
de Docum. días 09 09
28/07/20 28/07/20
Reunión de Visión y Reflexión 1 día
09 09
15 29/07/20 18/08/20
Generación del segundo Release
días 09 09
19 19/08/20 14/09/20
Tercer Incremento: Multihilo
días 09 09
19/08/20 19/08/20
Reunión de Visión y Reflexión 1 día
09 09
20/08/20 24/08/20
Redacción de los manuales 3 días
09 09
15 25/08/20 14/09/20
Generación del tercer Release
días 09 09
34 15/09/20 30/10/20
Cuarto Incremento: Búsqueda
días 09 09
15/09/20 15/09/20
Reunión de Visión y Reflexión 1 día
09 09
Elaboración de la versión final de 16/09/20 18/09/20
3 días
los manuales 09 09
30 21/09/20 30/10/20
Generación del último Release
días 09 09

Con la suma de los totales de las tarjetas de trabajo, llegamos a una

estimación mejorada para el resto del proyecto: 100 días.

Incremento 1: Esqueleto Caminante

El propósito del primer incremento fue crear una aplicación que fuera el
esqueleto del sistema, incorporando las principales características
arquitectónicas y algunas funciones básicas.

Lo primero que se hizo fue seleccionar y configurar nuestras herramientas.

Las herramientas fueron elegidas por los miembros del equipo, sobre todo
Omar, sobre la base de su experiencia en otros proyectos. Las herramientas
fueron las siguientes:

• Herramienta de diseño. Enterprise Architect 7.0 fue

seleccionado para el diseño de los diagramas UML.

• Herramientas de programación (se eligió como lenguaje de

programación a Java)

o IDE Eclipse
 o Hibernate Framework como herramienta ORM

o Apache Lucene como herramienta para la recuperación

de información

o Log4j como herramienta para el seguimiento de trazas

o Apache POI para el procesamiento de archivos de Office

• Herramienta de pruebas de unidad. Hemos seleccionado JUnit.

• Herramienta de control de versiones. Se utilizó Subversion

Una vez que las herramientas se han seleccionado y configurado, Omar

comenzó a crear la arquitectura del software y a debatir los problemas de
diseño con Norma utilizando una pizarra.

Durante incremento de 1, Víctor comenzó a escribir el código de Java para el

proyecto, contando siempre con la ayuda de Omar.

El equipo continuó para refinar los requisitos, con Carlos y Omar trabajando
juntos para producir borradores de pantalla actualizada.

Al final del incremento 1, el equipo había tenido éxito en crear el esqueleto

caminante. Se logró terminar y entregar al usuario un Scheduler que
consiste en un administrador de planificaciones que permitirá determinar el
día, la hora y la frecuencia para iniciar el proceso de auto-indexación de
documentos. De esta manera, el usuario podrá ingresar, consultar,
modificar o eliminar una planificación para auto indexar archivos. Además,
se generará un módulo de indexación básico que consiste en la capturar los
nombres de archivos DOC y TXT para realizar búsquedas básicas por
nombre.

Hacia el final del incremento, Norma le dio al equipo su declaración de

misión. Este es uno de los productos de los trabajos exigidos por Crystal
Clear. Este producto del trabajo sólo se pide al sponsor. También se celebró
un taller de reflexión y visión.

La reunión se realizó de manera ordenada, y se contó con la presencia de la

totalidad del equipo de desarrollo. Durante la misma, se trataron algunas
cuestiones sobre el primer incremento realizado, identificando los objetivos
alcanzados hasta el momento, y se planteó la visión para el siguiente
incremento. Todos los puntos tratados en la reunión se registraron en una
pizarra, que se encontrará ubicada dentro de la sala de trabajo, de manera
que los miembros del equipo puedan consultar contantemente y tener
siempre presente los objetivos a cumplir.

Al final del incremento 1, el equipo realizó un taller de reflexión. El objetivo

principal de ésta reunión era identificar los aspectos del proceso de trabajo,
de manera que se pudiera determinar qué se necesitaba cambiar y qué
puntos se mantendrían.

Los puntos principales identificados fueron:

• Conocimiento sobre la metodología Crystal Clear. El equipo no

había sido entrenado en el uso de la metodología, ya que
nunca tuvo la oportunidad de aplicarlo. El material de
formación que se empleó fue el libro de CC llamado “Crystal
Clear A Human-Powered Methodology for Small Teams”, por lo
que se propuso y se acordó que cada miembro del equipo debe
realizar una lectura del mismo.

• Toma de decisiones. Omar, como el líder de diseño y miembro

con más experiencia en desarrollo de sistemas en Java, quedó
a cargo de la toma de las principales decisiones técnicas.

• Aspectos a conservar. El equipo encontró mucho acerca de la

metodología que se quería conservar. En particular, los
miembros del equipo estaban trabajando bien juntos. Varios de
los miembros del equipo antes habían trabajado juntos en otros
proyectos, por lo que les resultaba más fácil trabajar juntos en
este proyecto.

Incremento 2: Tratamiento de Documentos

El objetivo del segundo incremento era que el sistema pudiera efectuar el
tratamiento del texto una vez que se indexaron los archivos. Esto
comprende, la tokenización, eliminación de los signos de puntuación,
conversión a minúsculas, eliminación de stop words (palabras irrelevantes)
y stemming (generalización), tanto del título como del contenido de cada
uno de los archivos.

Este tratamiento, permitirá realizar búsquedas más intuitivas y sencillas,

brindando resultados más precisos y significativos al usuario.

Las funcionalidades que se obtengan del presente incremento no serán

captadas por el usuario final, ya que las mismas se realizan mediante
procesos internos del sistema. Por lo tanto el usuario final no verá los
resultados hasta el incremento 4, cuando se encuentre concluida la
búsqueda. Sin embargo, estas funcionalidades si podrán ser verificadas por
los miembros desarrolladores del equipo y serán evaluados los resultados.

El incremento 2 comenzó con una reunión de planificación en la que la

programación del proyecto fue reconstruido sobre la base de la situación
actual y se planificaron las cuestiones a ser tratadas en el incremento 3.

Al final del incremento, se contaba con un sistema capaz de indexar y

procesar el texto de cada uno de los archivos indexados, lo cual sería
empleado en el siguiente incremento.

Al igual que en el incremento 1, se realizó una reunión de visión y un taller

de reflexión. Los aspectos tratados fueron registrados en la pizarra, la cual
siempre debe estar actualizada y a la vista de todos los miembros del
equipo.

Incremento 3: Multihilo
En este incremento se buscó agregar la funcionalidad multihilo a la
aplicación. Debido a que durante las pruebas efectuadas, el sistema debía
realizar tareas de manera concurrente (despliegue de la interfaz,
búsquedas, trabajo de planificación, etc.), se decidió luego de la reunión de
reflexión, modificar el sistema para dicho fin.

De esta manera, el sistema no queda “congelado” cuando realice tareas en

paralelo, ya que cada hilo trataría cada tarea de manera independiente. Los
problemas se daban concretamente durante las tareas de indexación,
momento en el cual hay un pico de uso de CPU y memoria.

Aunque el usuario no tendría noción de los resultados de la indexación hasta

el próximo incremento, se mantendrá el módulo generado en el primer
incremento para realizar las búsquedas por nombre de archivo.

Durante este incremento se comenzó con un esbozo de los manuales de

usuario y de instalación y configuración a cargo de Melisa.
Además de este tema, en la reunión de reflexión se marcaron algunas
observaciones en la pizarra y se determinaron las falencias y fortalezas
detectadas.

Incremento 4: Búsqueda
Durante el incremento final, se agregó la funcionalidad de búsqueda para el
contenido de los archivos indexados.

Se trató de hacerla intuitiva, similar a la que implementa Google en su

buscador Web, agregando soporte para comodines (“?”, “*”) y conectores
lógicos (AND, OR). De esta manera se logra una búsqueda fácil y familiar
para el usuario.

El módulo de búsqueda también corre de manera concurrente en un hilo

independiente del resto.

Se finalizó la redacción de los manuales de usuario y de instalación y

configuración. Y se realizaron las integraciones finales del código.
Se corrieron las pruebas unitarias definitivas y las pruebas generales.

Llevamos a cabo un taller de reflexión final. Este se convirtió en una

discusión general acerca de cómo fue la metodología. Las opiniones de los
miembros del equipo fueron en general muy positivas.

Conclusiones
Esta sección presenta nuestra evaluación de Crystal Clear. Se evalúa la
metodología en contra de las afirmaciones que se hacen para ella.
Asimismo, presentamos una serie de cuestiones en las que es necesario
tener cuidado en el uso de la metodología.

Evaluación de Crystal Clear

Las afirmaciones hechas por Crystal Clear es que es eficiente, habitable y
seguro. Sobre la base de nuestro proyecto piloto, se apoyan estas
afirmaciones:

Eficiencia: La metodología ayudó a mantener el desarrollo centrado, y a la

reducción de residuos. De residuos, en este contexto, significa cualquier
cosa que no contribuye al producto final.

Se consiguió una alta productividad, a tal punto de poder reducir el tiempo

estimado en un principio para el sistema, y concluir satisfactoriamente con
el cronograma planificado, en tiempo y en forma.
Habitabilidad: Todos los miembros del equipo estarían felices de usar esta
metodología de nuevo. Varios Se recibieron comentarios positivos por parte
del equipo, incluyendo:

• Carlos (usuario experto). "En general, la participación fue una

experiencia agradable, y uno que me encantaría repetir."

• Omar (Líder de Diseñado). "Por lo general se sentía muy

centrado y con energía.... Me sentí en general, en el control".

• Norma (Sponsor). "Las comunicaciones son excelentes... El

equipo ha trabajado bien juntos... El software fue entregado en
una condición de trabajo satisfactoria".

Seguridad: Una metodología segura es la que aumenta la probabilidad de

éxito del proyecto. El proyecto piloto tuvo éxito, ya que creó un producto
que logro la satisfacción tanto del sponsor como del usuario experto. Más
allá de eso, varios aspectos del proyecto pueden demostrar la seguridad: los
planes siempre se plantearon de acuerdo a las necesidades de cada
momento, los temas difíciles se han resuelto de manera oportuna, y el
equipo siempre se centró en las características más importantes.
Bibliografía y Sitios Web Recomendados
• Alistair Cockburn (2004). Crystal Clear A Human-Powered
Methodology for Small Teams. http://alistair.cockburn.us/

• Agile Manifesto http://www.agilemanifesto.org