Universidad Tecnolgica Nacional Facultad Regional

2010

Crystal Clear Methodology

Melisa Guzmn Legajo: 26.107 Vctor Alberto Soria Legajo:

ContenidoMetodologas giles........................................................................................3 Qu significa ser gil?................................................................................3 Los cuatro principios del manifiesto gil.....................................................4 Metodologa Crystal........................................................................................5 Qu es Crystal Clear?...................................................................................6 Propiedades................................................................................................6 Estrategias.................................................................................................. 8 Tcnicas......................................................................................................9 Proceso......................................................................................................10 Roles......................................................................................................... 10 Caso de Estudio............................................................................................13 Introduccin..............................................................................................14 Cronologa del Proyecto............................................................................14 Roles......................................................................................................... 14 Exploracin...............................................................................................15 Reunin de Planeacin..............................................................................17 Incremento 1: Esqueleto Caminante.........................................................18 Incremento 2: Tratamiento de Documentos..............................................20 Incremento 3: Multihilo.............................................................................20 Incremento 4: Bsqueda...........................................................................22 Conclusiones................................................................................................22 Evaluacin de Crystal Clear.......................................................................23 Bibliografa y Sitios Web Recomendados......................................................24

Metodologas gilesLas metodologas giles surgen como una alternativa, una reaccin a las metodologas tradicionales y principalmente a su burocracia. Muchas ideas que se plantean en las metodologas giles no son nuevas, gran parte de ellas ya fueron reflejadas por Brooks en su mtico libro, The Mythical Man Month y en gran parte responden al sentido comn. Algunos autores consideran que se ha cumplido un crculo que empez con una reaccin provocada por mltiples factores y sealada temporalmente por el manifiesto de Dijkstra, en el cual se haca un llamamiento a la disciplina y que se cierra con el ya famoso Manifest for Agile Software Development, una peticin por la relajacin de los procesos en pro de las personas. La aparicin de las metodologas giles no puede ser asociada a una nica causa, sino a todo un conjunto, bien es cierto que la mayora de autores nos indicarn que son una reaccin a las metodologas tradicionales, pero cules fueron las causas de esta reaccin?, los factores que comnmente ms se mencionan que hicieron realidad esta nueva manera de desarrollar software son: Plumbing. La traduccin al castellano sera pesadez, lentitud de reaccin, exceso de documentacin, en definitiva, falta de agilidad de los modelos de desarrollo existente. Las metodologas existentes no cumplieron las expectativas planteadas inicialmente. Explosin de la red y las aplicaciones Web. Movimiento open source.

Definitivamente, las metodologas tradicionales exigen un sobreesfuerzo por parte del equipo de desarrollo en fases poco productivas, como es la documentacin y debido a su estructuracin (tpicamente siguiendo el modelo en cascada o ms actualmente UP) son poco flexibles a los cambios, de requisitos, de nuevas funcionalidades, etc. Si a todo esto le aadimos que las metodologas tradicionales no han sido capaces de eliminar todos los fallos, que persiguen al desarrollo de proyectos software prcticamente desde sus inicios, obtenemos un clima un poco escptico respecto a las metodologas. A todo lo planteado, adems debemos aadir un cambio bastante importante, en cuanto a la demanda del mercado del software, cada vez ms orientada a la Web, con uno requisitos muy voltiles, que requieren tiempos de desarrollo cada vez ms 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 tcnicas giles pueden

variar en su ejecucin y en su nfasis, todas ellas comparten caractersticas, incluyendo el desarrollo iterativo y que estn centradas en la interaccin, comunicacin, y en la reduccin de la creacin de artefactos intermedios. Desarrollar mediante iteraciones permite al equipo de desarrollo adaptarse a los cambios de los requisitos. Trabajar con un alto grado de comunicacin permite que el equipo pueda tomar decisiones y aplicarlas inmediatamente. La reduccin de artefactos intermedios que no dan valor aadido al producto final, nos permite asignar ms recursos al producto en s y podr ser acabado antes. Cockburn y Highsmith nos explican que lo que es realmente nuevo de los mtodos giles, no son las prcticas que ellos utilizan, sino el reconocimiento de las personas como principales valedoras para que un proyecto triunfe, en conjunto con una gran orientacin a la efectividad y la manejabilidad. La mayora de seguidores de las metodologas giles estn de acuerdo en que ser gil, es algo ms que seguir las guas que se supone que hacen un proyecto gil. La verdadera agilidad es ms que un conjunto de prcticas, es un estado de nimo.

Los cuatro principios del manifiesto gilEn marzo de 2001, Kent Beck convoc a 17 crticos de los modelos de mejora basados en procesos, justo un par de aos antes Kent haba publicado el libro "Extreme Programming Explained" en el que expona una nueva metodologa denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la reunin se acu el trmino Mtodos giles para definir los mtodos que estaban surgiendo como alternativa a las metodologas formales, consideradas excesivamente pesadas y rgidas por su carcter normativo y su fuerte dependencia de planificaciones detalladas, previas al desarrollo. De esta reunin surgira un resumen en forma de cuatro principios, que actualmente conocemos como Manifiesto gil, que bsicamente son los principios sobre los que se basan los mtodos reconocidos como giles.

Manifiesto gil (http://www.agilemanifesto.org)Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interaccin, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentacin exhaustiva. La colaboracin con el cliente, por encima de la negociacin 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.

Metodologa CrystalLa familia de metodologas Crystal es un conjunto de diferentes metodologas que podemos seleccionar en funcin de la adecuacin al proyecto en el que nos encontremos. Crystal tambin incluye un conjunto de principios para adaptar las diferentes metodologas segn las circunstancias del proyecto. Cada una de las metodologas de la familia Crystal tiene asignado un color, cuanto ms oscura sea su tonalidad, ms compleja es la metodologa.

Crystal sugiere que escoger un color de la metodologa para un proyecto en funcin de su criticidad y tamao. Los proyectos ms grandes suelen necesitar una mayor coordinacin y metodologas ms complejas que los proyectos ms pequeos. Cuanto ms crtico sea el sistema que queremos desarrollar, ms rigurosidad necesitamos disponer en el desarrollo del proyecto. En la figura anterior aparecen unos caracteres (C, D, E y L) e indican las prdidas potenciales por fallos del sistema, y lo hacen de la siguiente manera: C, indica prdida de confort debido a un fallo del sistema D, indica prdida de dinero discrecional, es decir del que podemos disponer, generalmente nuestro. E, indica prdida 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 prdida de vidas por el fallo del sistema.

Las dimensiones de criticidad y tamao, son representadas por un smbolo de la categora del producto, que aparece en la figura. Por ejemplo, D6 indica un proyecto con un mximo de 6 personas, de mxima criticidad de dinero discrecional. Crystal Clear no es una metodologa en si misma sino una familia de metodologas con un cdigo gentico comn. La idea es poder armar distintas metodologas para distintos tipos de proyectos. Cada proyecto y organizacin usar este cdigo gentico para generar su propia metodologa. Las metodologas que integran la familia Crystal tienen en comn un conjunto de caractersticas. Primero, los proyectos siempre usan ciclos de desarrollo incrementales, de una longitud mxima de cuatro meses, siendo preferibles periodos de un mes a tres meses. Segundo, se hace nfasis en la comunicacin y la cooperacin de la gente. Tercero, las metodologas Crystal permiten el uso de prcticas y herramientas de otras metodologas giles como XP o Scrum.

Qu es Crystal Clear?Crystal Clear est diseada para pequeos proyectos, proyectos de categora D6, pudiendo contar con un equipo de desarrolladores formado por 6 personas como mximo. Algunas modificaciones nos permitiran utilizar Crystal Clear con proyectos de tipo E8 o D10. Dada las limitaciones de comunicacin de la estructura, el equipo debera encontrarse ubicado en una oficina comn.

Grupos de hasta 8 personas

Reuniones en un mismo espacio

Proyectos pequeos

Proyectos no crticos

PropiedadesEntrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. 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 anlisis del sistema. Mejora reexiva. Tomarse un pequeo 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 reflexin", obteniendo una lista de prcticas o hbitos de desarrollo que nos gustara mantener, una lista de lo que nos gustara 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 hbitos y conocimiento de desarrollo. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseador senior y discutir respecto del tema que se trate. La colocacin fsica del equipo de desarrollo es de lo ms importante, y la comunicacin osmtica se refiere a llevar la comunicacin al mximo nivel: Nos debe tomar menos de 30 segundos llevar nuestras dudas a los ojos u odos de quien puede resolvrnoslas, debemos sentarnos en el mismo cuarto o en cubculos contiguos. Captar algo relevante de la conversacin entre otros miembros del equipo al menos cada pocos das. 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 ms simple, terminara por retrasar bajar nuestra productividad de manera crtica. Comparado con hacer una pregunta a una persona que est constantemente conectada en nuestro mismo tren de ideas, nos da la diferencia entre comunicacin cerrada y la mejor, comunicacin osmtica. Seguridad personal. Hablar con los compaeros 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 dems, 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 cules son los dos elementos de ms alta prioridad sobre los cuales trabaja en todo momento. Adems, deberamos tener garantizado todos por lo menos dos das seguidos y dos horas ininterrumpidas por da para trabajar en un proyecto. Fcil acceso a usuarios expertos. Tener alguna comunicacin con expertos desarrolladores. Nos debera de tomar menos de tres das 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 telfono 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 tcnico con pruebas automatizadas, gestin de la configuracin e integracin frecuente. Poder dejar corriendo las pruebas de nuestro desarrollo hasta el final sin estar fsicamente presente nos ahorra el tiempo que no tenemos, sin mencionar las ventajas de depuracin inmediata y de probar el cdigo indiscriminadamente. Todos los desarrolladores deberan ingresar el cdigo en el que trabajan en un sistema de administracin de la configuracin, de manera que este se encargue de llevar el control de versiones, documentos, etc. y escribir una nota til sobre el cdigo cuando lo ingresan. El sistema se debera integrar por lo menos dos veces a la semana, juntando el cdigo de todos, compilndolo, y hacindolo pasar por todas las pruebas automticas posibles, y obteniendo de esta manera cdigo ejecutable constantemente. El sistema funciona ms o menos as: Se disean los test antes del desarrollo. El sistema se integra frecuentemente en el sistema de manejo de configuracin y se pasa por todos los test, mostrando los resultados de inmediato.

EstrategiasExploracin de 360. Vericar o tomar una muestra del valor de negocios del proyecto, los requerimientos, el modelo de dominio, la tecnologa, el plan del proyecto y el proceso.

xito temprano. Es mejor buscar pequeos triunfos iniciales que aspirar a una gran victoria tarda. Esqueleto caminante. Es una transaccin que debe ser simple pero completa. Rearquitectura incremental. Se ha demostrado que no es conveniente interrumpir el desarrollo para corregir la arquitectura. Ms bien la arquitectura debe evolucionar en etapas, manteniendo el sistema en ejecucin mientras ella se modica. Radiadores de informacin. Es una lmina pegada en algn lugar que el equipo pueda observar mientras trabaja o camina. Tiene que ser comprensible para el observador casual, entendida de un vistazo y renovada peridicamente para que valga la pena visitarla.

Explorar 360

Radiador es de informaci n

xitos tempran os Estrateg ias

Re arquitectur a increment al

Esquelet o camina nte

TcnicasEntrevistas de proyectos. Se suele entrevistar a ms de un responsable para tener visiones ms ricas. Talleres de reexin. El equipo debe detenerse treinta minutos o una hora para reexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el perodo 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. Estimacin Delphi con estimaciones de pericia. Los expertos se renen y definen el tamao del proyecto, fecha de entrega, etc. Encuentros diarios de pie. Cinco a diez minutos como mximo. No se trata de discutir problemas, sino de identicarlos.

Miniatura de procesos. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un da. La idea es que la gente pueda degustar la nueva metodologa. Grcos de quemado. Son grficas en las cuales se observan retrasos en las tareas, este grfico sirve para tener un control del proyecto y ver en que funciones deben tener mayor prioridad. Programacin lado a lado. Establece proximidad, pero cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su compaero, quien tiene su propia mquina. Esta es una ampliacin de la Comunicacin Osmtica al contexto de la programacin.

ProcesoLa familia de metodologas Crystal no especifica ningn ciclo de vida concreto, ni ningn modelo de procesos, en vez de eso lo que hace es determinar una gua de las polticas estndar, productos de trabajo, asuntos locales, herramientas, estndares y roles. A continuacin veremos las prcticas ms comunes de las metodologas Crystal: Planificacin por etapas. Bsicamente consiste en la planificacin del siguiente incremento del sistema. La planificacin debe finalizar con una versin ejecutable cada tres o cuatro meses como mximo. El equipo selecciona los requisitos que sern implementados en el incremento y planifican lo que creen que sern capaces de hacer. Revisiones y resmenes. Cada incremento consta de diferentes iteraciones y cada iteracin incluye las siguientes actividades: construccin, demostracin y resumen de los objetivos del incremento. Monitorizacin. 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, flucta y lo suficiente estable para revisar). Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un estado lo suficientemente estable para su revisin, 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 sincronizacin.

Roles Sponsor: persona que se encarga de poner y hasta defender su inversin en el proyecto. Es quien tiene en mente la visin a largo plazo. Esta persona es quin 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 inversin disponible, debe tomar la decisin de seguir o no con el proyecto; si contina, deber replantear las funciones restantes para recuperar la inversin. Parte de la metodologa involucra dar buena informacin 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 cules son los modos de operacin ms y menos frecuentemente utilizados, qu atajos son necesarios, y qu informacin 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 polticas 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 poblacin de usuarios, a diferencia del Usuario Experto. Lder de Diseo: Esta persona es el lder tcnico, se supone que tiene experiencia en el desarrollo de software, que es capaz de realizar la mayor cantidad de diseo del proyecto y de encaminar al equipo cuando sea necesario. En trminos de niveles de competencia, se espera que el lder diseador sea un diseador de nivel 3. Partiendo

de que en un proyecto Crystal Clear hay slo 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 lder diseador, separado de los otros roles. Se espera que el lder diseador desempee tareas tanto de diseo como de programacin, al igual que un programador diseador. Usualmente, no siempre, el lder diseador es la persona ms experimentada del equipo y que tambin debe asumir las asignaciones de programacin ms difciles. Esto es comn, y de hecho representa un riesgo para el proyecto. El lder diseador tiende a estar sobrecargado, teniendo roles como coordinador, arquitecto, mentor y programador ms experimentado. Cualquier cosa que pueda hacerse para liberarlo de tareas, mejorar el perfil de riesgo del proyecto. La opcin obvia es elegir a alguien que interprete el rol de coordinador, total o parcialmente. Diseador Programador: Es una persona que rene las caractersticas de un diseador, como de un programador. El diseo sin programacin, representa fallas durante la retroalimentacin (en proyectos de todos los tamaos). Es raro que esto se d en un proyecto del tipo Crystal Clear. La programacin natural involucra disear. Experto en Negocios: Es el experto que indica cmo va el negocio, qu estrategias o polticas deben arreglarse, qu tiende a variar pronto, seguido o nunca. Esta persona responder variadas preguntas a los desarrolladores acerca del corazn del sistema. Provee informacin diferente de la que entrega el Usuario Experto, de hecho, en algunos casos puede suceder que el usuario experto, es tambin el experto en negocios. En muchas situaciones se ha visto que el sponsor, el lder de diseo o el usuario experto acten como expertos en negocios. Algunas veces, una persona externa es trada para desempear esta tarea. Coordinador: El coordinador es, probablemente, una ocupacin 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 lder de diseo asumen este rol, o incluso otras personas se turnan para ste. Tester: encargado de las pruebas Escritor: encargado de redactar la documentacin (manuales de usuario, de entrenamiento y ayuda)

Caso de EstudioEn el presente caso de estudio, se explicar de manera clara y fcil de entender cmo se implementa la metodologa en un determinado proyecto. Esperando conocer sobre el desarrollo gil como parte de una actividad de innovacin del proceso corporativo, se decidi probar Crystal Clear en el desarrollo de un proyecto denominado Indexacin Automtica de Orgenes de Datos (crawl o auto-indexing). El sistema tiene como propsito permitir la auto-indexacin de la informacin almacenada en diversos documentos (el sistema queda limitado a la indexacin de archivos de Microsoft Word 97 2003, con extensin DOC; archivos de texto, con extensin TXT; archivos de Microsoft PowerPoint 97 2003, con extensin PPT; archivos de Microsoft Excel 97 2003, con extensin XLS y archivos PDF). El proceso de indexacin de toda la informacin se iniciar automticamente, mediante un Scheduler, luego, la misma podr ser accedida desde una aplicacin de bsqueda. El proceso de indexacin comprende una serie de pasos internos, que implican la implementacin de un Tokenizer para extraer el texto y poder procesarlo. El siguiente paso consiste en la eliminacin de las Stop Words y luego, la generalizacin de las palabras mediante Stemming. Esto proporcionar al usuario bsquedas ms intuitivas y con resultados en pocos segundos. En trminos generales, la meta de este sistema es la automatizacin del proceso de indexacin de archivos. Concretamente, esto incluye: Iniciacin automtica del proceso de indexacin Agilizacin de la bsqueda de los archivos necesarios de manera rpida e intuitiva Disminucin de tiempo y carga de trabajo de los empleados Respuesta rpida a los clientes

El principal beneficio que se obtiene con la implementacin de este sistema es la notable reduccin del tiempo de bsqueda de archivos debido a la automatizacin del proceso y la implementacin de herramientas de software diseadas para tal fin. La prioridad principal del equipo del proyecto era completar el prototipo antes de que concluya el ao 2009. Lo ideal sera tener un producto de calidad para mostrar inmediatamente a las empresas interesadas en l. De hecho, se termin con una demostracin de alta calidad que puede ser transformado en producto en un tiempo razonablemente corto, y fcilmente integrable con otros productos ya desarrollados. Crystal Clear es una metodologa gil, y como tal tiene como objetivo reducir el riesgo de una mala construccin, 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, centrndose al mismo tiempo en las caractersticas importantes del equipo. Habitabilidad. Crystal Clear est diseado para ser cmodo de usar, de modo que los equipos no sientan la necesidad de evitar que los sigan. Seguridad. La metodologa tiene como objetivo aumentar la probabilidad de xito de la entrega.

Se decidi desarrollar este proyecto con Crystal Clear, porque era pequeo y no crtico (que es el tipo de proyecto para la que fue diseada la metodologa), 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 metodologa.

IntroduccinBsicamente, ms all de brindar la posibilidad de indexacin automtica de las imgenes de los documentos escaneados mediante nuestro mediante OCR, el sistema desea ofrecer la funcionalidad de auto indexacin de la informacin residente en diversos medios (discos de red, bases de datos, etc.). De esta manera un "robot de indexacin" iniciar, mediante un proceso programado, la indexacin de toda la informacin existente en los medios especificados. Luego la misma ser accesible desde una aplicacin de consulta. No se parti de ningn prototipo ni diseo previo. El sistema era una herramienta completamente nueva para el equipo de desarrollo.

Cronologa del ProyectoLa fecha de inicio del proyecto fue el 15/06/2009 y se planific, en un principio, una duracin de 3 a 4 meses como mximo. Los miembros del equipo de desarrollo para el proyecto estaba compuesto por las siguientes personas: Norma, lder de proyecto Omar, programador experto en Java Carlos, programador junior en Java Vctor, programador junior en Java Melisa, analista funcional

RolesPara dar comienzo al inicio del proyecto se establecieron los requisitos iniciales del mismo, el enfoque de desarrollo, una primera estructura de divisin del trabajo, y una estimacin para el trabajo. La estimacin fue de

120 das de esfuerzo. La asignacin inicial de las funciones se muestra a continuacin:

Nombre Norma Omar Carlos Vctor Melisa

Roles Sponsor, Experta en Negocios Lder de Diseo, Coordinador Usuario Experto Diseador-Programador, Tester Coordinadora, Escritora, Tester

A pesar de que se tenan los requisitos bsicos del sistema, estaba claro que haba cuestiones que tenamos que resolver antes de poder iniciar el desarrollo iterativo. As que se tom la idea de una "fase de exploracin" de XP. Esta fue la primera fase del proyecto.

ExploracinLa fase de exploracin fue de dos semanas, en el que Omar y Carlos capturaron los requisitos ms detallados, investigaron las principales cuestiones tcnicas, y firmaron la estimacin 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 diseos.

Las impresiones fueron numeradas y mantenidas juntas en una carpeta. A partir de los requisitos identificados, Melisa comenz un documento de requisitos.

Despus de algunas investigaciones, se decidi que la aplicacin fuera desarrollada bajo el lenguaje de programacin Java (J2EE), y complementada con la implementacin de una API para recuperacin de informacin, denominada Lucene. Apache Lucene es una librera de software libre, una herramienta de desarrollo, no es una aplicacin de bsqueda.

Nueva PlanificacinSeleccione el tipo de planificacin Diaria Detalle de Planificacin Nombre Directorio Raz Semanal Tipo de Archivo Da [Lun, Mar, ] Mensual Intervalo [MM] Seleccione una opcion Hora [HH:MM] Frecuencia[MM] Guardar Examinar

Planificaciones N Nombre Directorio Raz Tipo de Archivo Tipo de Planificacin Hora Intervalo

Modificar

Eliminar

Salir

Reunin de PlaneacinSe realizo una reunin de planificacin usando la tcnica de planificacin proyectos sugerido en CC. Los miembros del equipo se sientan alrededor una mesa y se distribuyen tarjetas de tarea. Cada tarjeta de tarea tena ttulo, una breve descripcin, el nombre de la persona, y una estimacin das-hombre. de de un en

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 continuacin se dio a cada tarjeta una etiqueta (en la parte inferior de la tarjeta) para que podamos reconstruir el orden. Despus de la reunin, las tareas se han copiado en Microsoft Project, a fin de tener claramente la planificacin para el proyecto. Indexacin Automtica de Origenes de Datos Fase de Exploracin Determinacin de los Requisitos Esbozo de los primeros diseos Armado de carpeta para anotaciones Generacin de la primera ERS Reunin de Planeacin Elaboracin del diagrama de Gantt Confeccin de tarjetas de tareas 100 das 10 das 2 das 3 das 2 das 3 das 3 das 1 da 1 da 15/06/2 009 15/06/20 09 15/06/20 09 17/06/20 09 22/06/20 09 24/06/20 09 29/06/20 09 29/06/20 09 30/06/20 09 30/10/2 009 26/06/20 09 16/06/20 09 19/06/20 09 23/06/20 09 26/06/20 09 01/07/20 09 29/06/20 09 30/06/20 09

Estimacin de la duracin del proyecto Primer Incremento: Esqueleto Caminante Reunin de Visin y Reflexin Determinacin de las herramientas a utilizar Generacin del primer Release Segundo Incremento: Tratamiento de Docum. Reunin de Visin y Reflexin Generacin del segundo Release Tercer Incremento: Multihilo Reunin de Visin y Reflexin Redaccin de los manuales Generacin del tercer Release Cuarto Incremento: Bsqueda Reunin de Visin y Reflexin Elaboracin de la versin final de los manuales Generacin del ltimo Release

1 da 18 das 1 da 2 das 15 das 16 das 1 da 15 das 19 das 1 da 3 das 15 das 34 das 1 da 3 das 30 das

01/07/20 09 02/07/20 09 02/07/20 09 03/07/20 09 07/07/20 09 28/07/20 09 28/07/20 09 29/07/20 09 19/08/20 09 19/08/20 09 20/08/20 09 25/08/20 09 15/09/20 09 15/09/20 09 16/09/20 09 21/09/20 09

01/07/20 09 27/07/20 09 02/07/20 09 06/07/20 09 27/07/20 09 18/08/20 09 28/07/20 09 18/08/20 09 14/09/20 09 19/08/20 09 24/08/20 09 14/09/20 09 30/10/20 09 15/09/20 09 18/09/20 09 30/10/20 09

Con la suma de los totales de las tarjetas de trabajo, llegamos a una estimacin mejorada para el resto del proyecto: 100 das.

Incremento 1: Esqueleto CaminanteEl propsito del primer incremento fue crear una aplicacin que fuera el esqueleto del sistema, incorporando las principales caractersticas arquitectnicas y algunas funciones bsicas. 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 diseo. Enterprise Architect 7.0 fue seleccionado para el diseo de los diagramas UML. Herramientas de programacin (se eligi como lenguaje de programacin a Java) o IDE Eclipse

o o

Hibernate Framework como herramienta ORM Apache Lucene como herramienta para la recuperacin de informacin Log4j como herramienta para el seguimiento de trazas Apache POI para el procesamiento de archivos de Office

o o

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 diseo con Norma utilizando una pizarra. Durante incremento de 1, Vctor comenz a escribir el cdigo 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 haba 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 da, la hora y la frecuencia para iniciar el proceso de auto-indexacin de documentos. De esta manera, el usuario podr ingresar, consultar, modificar o eliminar una planificacin para auto indexar archivos. Adems, se generar un mdulo de indexacin bsico que consiste en la capturar los nombres de archivos DOC y TXT para realizar bsquedas bsicas por nombre.

Hacia el final del incremento, Norma le dio al equipo su declaracin de misin. Este es uno de los productos de los trabajos exigidos por Crystal

Clear. Este producto del trabajo slo se pide al sponsor. Tambin se celebr un taller de reflexin y visin. La reunin 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 visin para el siguiente incremento. Todos los puntos tratados en la reunin 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 reflexin. El objetivo principal de sta reunin era identificar los aspectos del proceso de trabajo, de manera que se pudiera determinar qu se necesitaba cambiar y qu puntos se mantendran. Los puntos principales identificados fueron: Conocimiento sobre la metodologa Crystal Clear. El equipo no haba sido entrenado en el uso de la metodologa, ya que nunca tuvo la oportunidad de aplicarlo. El material de formacin 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 lder de diseo y miembro con ms experiencia en desarrollo de sistemas en Java, qued a cargo de la toma de las principales decisiones tcnicas. Aspectos a conservar. El equipo encontr mucho acerca de la metodologa que se quera conservar. En particular, los miembros del equipo estaban trabajando bien juntos. Varios de los miembros del equipo antes haban trabajado juntos en otros proyectos, por lo que les resultaba ms fcil trabajar juntos en este proyecto.

Incremento 2: Tratamiento de DocumentosEl objetivo del segundo incremento era que el sistema pudiera efectuar el tratamiento del texto una vez que se indexaron los archivos. Esto comprende, la tokenizacin, eliminacin de los signos de puntuacin, conversin a minsculas, eliminacin de stop words (palabras irrelevantes) y stemming (generalizacin), tanto del ttulo como del contenido de cada uno de los archivos. Este tratamiento, permitir realizar bsquedas ms intuitivas y sencillas, brindando resultados ms precisos y significativos al usuario. Las funcionalidades que se obtengan del presente incremento no sern 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 bsqueda. Sin embargo, estas funcionalidades si podrn ser verificadas por los miembros desarrolladores del equipo y sern evaluados los resultados. El incremento 2 comenz con una reunin de planificacin en la que la programacin del proyecto fue reconstruido sobre la base de la situacin 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 sera empleado en el siguiente incremento. Al igual que en el incremento 1, se realiz una reunin de visin y un taller de reflexin. 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: MultihiloEn este incremento se busc agregar la funcionalidad multihilo a la aplicacin. Debido a que durante las pruebas efectuadas, el sistema deba realizar tareas de manera concurrente (despliegue de la interfaz, bsquedas, trabajo de planificacin, etc.), se decidi luego de la reunin de reflexin, modificar el sistema para dicho fin. De esta manera, el sistema no queda congelado cuando realice tareas en paralelo, ya que cada hilo tratara cada tarea de manera independiente. Los problemas se daban concretamente durante las tareas de indexacin, momento en el cual hay un pico de uso de CPU y memoria.

Aunque el usuario no tendra nocin de los resultados de la indexacin hasta el prximo incremento, se mantendr el mdulo generado en el primer incremento para realizar las bsquedas por nombre de archivo. Durante este incremento se comenz con un esbozo de los manuales de usuario y de instalacin y configuracin a cargo de Melisa.

Adems de este tema, en la reunin de reflexin se marcaron algunas observaciones en la pizarra y se determinaron las falencias y fortalezas detectadas.

Incremento 4: BsquedaDurante el incremento final, se agreg la funcionalidad de bsqueda 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 lgicos (AND, OR). De esta manera se logra una bsqueda fcil y familiar para el usuario. El mdulo de bsqueda tambin corre de manera concurrente en un hilo independiente del resto. Se finaliz la redaccin de los manuales de usuario y de instalacin y configuracin. Y se realizaron las integraciones finales del cdigo.

Se corrieron las pruebas unitarias definitivas y las pruebas generales. Llevamos a cabo un taller de reflexin final. Este se convirti en una discusin general acerca de cmo fue la metodologa. Las opiniones de los miembros del equipo fueron en general muy positivas.

ConclusionesEsta seccin presenta nuestra evaluacin de Crystal Clear. Se evala la metodologa 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 metodologa.

Evaluacin de Crystal ClearLas 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 metodologa ayud a mantener el desarrollo centrado, y a la reduccin 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 estaran felices de usar esta metodologa de nuevo. Varios Se recibieron comentarios positivos por parte del equipo, incluyendo: Carlos (usuario experto). "En general, la participacin fue una experiencia agradable, y uno que me encantara repetir." Omar (Lder de Diseado). "Por lo general se senta muy centrado y con energa.... 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 condicin de trabajo satisfactoria".

Seguridad: Una metodologa segura es la que aumenta la probabilidad de xito del proyecto. El proyecto piloto tuvo xito, ya que cre un producto que logro la satisfaccin tanto del sponsor como del usuario experto. Ms 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 difciles se han resuelto de manera oportuna, y el equipo siempre se centr en las caractersticas ms importantes.

Bibliografa 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