Está en la página 1de 29

Metodologas giles: - FDD - AUP - Crystal Clear - DSDM

lvaro Yuste Torregrosa Carlos Sanchs Server Javier Snchez Riquelme Carlos Meca Lpez

Featured Driven Development (FDD)

Introduccin.

La iniciativa de Desarrollo Dirigida por Rasgos es un tipo de metodologa gil que rige su arquitectura por las funcionalidades del programa a implementar. Como cualquier otra metodologa de esta corriente, quiere romper con la nocin de planea el trabajo y trabaja el plan, y sigue un progreso ms adaptativo y dinmico. No enfatiza los requerimientos y la generacin de documentacin previa, si no que se centra en realizar las fases de diseo y construccin. Sin embargo se preocupa mucho de la calidad del producto, ya que insiste en el monitoreo constante. De su historia podemos remarcar que fue desarrollado por Peter Coad, Eric Lefebvre y Jeff DeLuca, siendo este ltimo en que lo llev a cabo por primera vez en un caso real de misin crtica. Se le encomend la tarea de rescatar un proyecto que haba durado dos aos desde su inicio. Pero ste todava no posea ni una sola lnea de cdigo, teniendo ya 3500 pginas de documentacin. El rescate fue un xito. Sin embargo no comenz a utilizarse de manera considerablemente asidua hasta finales de los 90, para implementar grandes aplicaciones bancarias.

Caractersticas.

Como algunas otras metodologas giles, se basa en un proceso iterativo, pero en este caso es parcial, como ya describiremos en el apartado de Fases. Sin embargo, como hemos dicho, la principal propiedad del FDD es la orientacin de su arquitectura dirigida los rasgos o funcionalidades del programa a producir. As nos centraremos en definir este concepto de feature para aclarar por extensin cmo trabaja la metodologa. En FDD, las funcionalidades son lo que en Extreme Programing eran las historias de usuario, son el eje de trabajo. Se escriben utilizando el lenguaje del dominio, de manera especfica, sin cabida a ambigedades y usando una estructura similar a: <accin> [un|el] <resultado> [de|a|para|por|] <objeto> [con|para|de] <parmetros>. El <objeto> identifica la clase en el modelo de dominio, el agente que realiza la operacin, la <accin>; que es el mtodo o la funcin encapsulada en dicha clase y que tiene como valor de salida el <resultado>. Cada una de las funcionalidades equivale a un requisito estipulado previamente por el patrocinador del producto. Tiene siempre un significado empresarial y describe algn valor de negocio. Normalmente tambin es posible expresarlos como secuencia, cuando existan requisitos para la disponibilidad de unos respecto de otros (el documento que se genera en este caso, como veremos en los artefactos es el Diagrama Secuencial UML). El paradigma de programacin que se suele usar en esta clase de metodologas es el FOP (Feature-Oriented Programming), o Programacin orientada a rasgos. Este enfoque para sintetizar productos software convierte los programas en una pila de capas, de las cuales, cada una aporta una funcionalidad nueva al conjunto de capas que envuelve. Siempre se trabaja aadiendo nuevo cdigo a un programa ya existente, para que finalmente el resultado sea una composicin de transformaciones con la superposicin de capas. Las capas son lo que se pas a denominar features o funcionalidades, para dar nombre al paradigma.

Fases.

Una de las principales peculiaridades de este mtodo de desarrollo de sistemas software gil, con respecto al resto de sus anlogos, es que no requiere la presencia del cliente todo lo asiduamente que se suele demandar a lo largo de sus etapas. El peso de estas recae casi ntegramente en los desarrolladores. Las fases iniciales del progreso son secuenciales y nicas en el ciclo de vida. La primera de todas ellas, cuando comienza el desarrollo, es la realizacin de un modelo global. Aqu, los expertos del dominio, tienen en cuenta el contexto y los requerimientos del sistema para, aportando su visin, modelar el dominio dividindolo en las diferentes clases. Estas reas seccionales se analizan detalladamente por separado construyendo un diagrama de objetos para cada una. A continuacin, los desarrolladores elaboran una lista de funcionalidades (con la estructura que hemos explicado en el apartado de caractersticas) que en conjunto engloban la funcionalidad total del sistema. Se puede subdividir la lista en conjuntos dependiendo de la semejanza y la dependencia entre funcionalidades. Esta lista posteriormente se revisa por el cliente y por los encargados de validacin. Una vez se posee la lista repasada y confirmada, se comienza a desarrollar la planificacin por funcionalidad. En esta etapa ya se ordenan en un diagrama, jerrquicamente los conjuntos de rasgos segn su prioridad en el desarrollo, y se asignan a su vez a los programadores jefes. Una vez llegado a este punto, como algunas otras metodologas giles, se basa en un proceso iterativo. Aunque a diferencia del resto, cada iteracin solo engloba las dos fases finales, y no todas ellas. Estas fases son el diseo y la construccin. En ellas, en cada iteracin, se selecciona un subconjunto de rasgos a realizar de la lista y se despliega primero diseando y revisando el diseo. Posteriormente se implementa la funcionalidad y se realizan pruebas unitarias dentro de la construccin (no hay una fase especifica y definida para las pruebas, como ocurre en la mayora de metodologas). Para finalizar integrando el cdigo e inspeccionndolo. As una y otra vez, en iteraciones que pueden durar desde unos pocos das hasta un mximo de dos semanas.

Fases de FDD

Roles.

Una de las principales crticas que propinan a este tipo de metodologa es la excesiva jerarquizacin dentro de sus roles. Algunos consideran que para conservar su carcter gil ste debera de ser ms liviana o sencilla. An as, las responsabilidades que recaen sobre los desarrolladores se pueden clasificar en tres grandes grupos segn su peso en el supuesto organigrama empresarial de desarrollo.

El primer grupo lo forman los roles clave que como su nombre indica son indispensables para el progreso del sistema. En este grupo se encuentra el administrador de proyecto, que es quien siempre tiene la ltima palabra en visin, cronograma y seleccin del personal. De la parte ms tcnica est encargado el arquitecto jefe, que controla el diseo global y la implementacin de las diferentes funcionalidades desde el nivel ms alto. Quien se preocupa de que todas se desarrollen correctamente es el manager de desarrollo, encargndose de los conflictos en el equipo y de resolver problemas referentes a los recursos.

A un nivel ms bajo, pero en el mismo grupo, se encuentra el programador jefe, quien analiza los requerimientos y tras acabar el diseo, selecciona los rasgos que se desarrollarn en cada iteracin. ste est al mando de los propietarios de clase, a quienes les asigna rasgos propios para que se responsabilicen de su implementacin, y participen en la decisin de incluirlos o no en la siguiente iteracin. Y por ltimo, para completar los roles clave se tiene el experto de dominio, que puede personificarse en el cliente, el patrocinador o un analista de negocio. Su tarea es controlar los requerimientos y su correcta cobertura en el desarrollo.

Para complementar a estos cargos, tambin son necesarios los llamados roles de soporte. Aqu se encuentra el administrador de entrega, que es quien se rene con el programador jefe para revisar sus reportes y transmitrselos al manager de desarrollo. Controla en general el avance y se lo comunica al cliente semanalmente. Por otro lado se tiene al gur del lenguaje, que es quien conoce a la perfeccin la tecnologa de codificacin que se est utilizando, y est a disposicin de los desarrolladores para aclarar cualquier cuestin referente a ella.

En este grupo tambin existe el rol de manager de dominio, es quien organiza y lidera al grupo de expertos de dominio, y resuelva sus diferencias a la hora de concretar los requerimientos del sistema. Adems, otro rol de soporte es el ingeniero de construccin, que se encarga de preparar, mantener e impulsar el proceso de construccin a la vez que controla las versiones resultado de cada iteracin y publica la documentacin relevante. Tambin se cuenta con el rol del herramentista para la creacin de herramientas de soporte especficas y la gestin tanto de bases de datos como de las webs. Por ltimo el administrador del sistema es quien controla el ambiente de trabajo y empaqueta el producto para cada entrega.

Para finalizar, el ltimo grupo es el de roles adicionales. En l se encuentran los verificadores (personas que pueden llegar a ser independientes del equipo del proyecto, que testean el sistema para comprobar que cumple los requisitos del cliente), los encargados del despliegue (son quienes adaptan la documentacin previa a la requerida por el nuevo sistema a desarrollar y contribuyen a su lanzamiento) y los escritores de documentos tcnicos (que preparan la documentacin relevante para los usuarios).

Artefactos.
A lo largo del proceso, el primero y principal documento que se genera es en el que se definen todas las funcionalidades de la aplicacin, el Modelo de Dominio. ste se elabora utilizando la tcnica llamada Unifieid Modeling Languaje (UML), como diagrama de clases, aunque posteriormente fue mejorado por Peter Coad dando lugar al Domain Neutral Component (DNC) y arquetipos de clase. A continuacin observamos un ejemplo que modela el dominio de un hotel y las conferencias que se realizan en l, en formato DNC.

DNC

Como hemos dicho, cada modelo funcionalidades se puede traducir al instante en el artefacto llamado Diagrama Secuencial UML. En el caso del ejemplo anterior, la conversin sera la siguiente:

Conclusin

Concluimos definiendo al FDD como una metodologa de desarrollo gil destinada a proyectos cortos y de reducido personal, pero muy escalable por otra parte. A diferencia de otras, no define explcitamente una fase para la obtencin de requisitos ni para la realizacin de pruebas. Sin embargo, al dividir el proyecto en unidades pequeas (rasgos), esta metodologa es la ms adecuada para realizar un seguimiento y una monitorizacin del progreso. Respecto a la carga de trabajo que recae sobre los desarrolladores, FDD podemos decir que es un proceso intermedio, basndonos en genera ms documentacin que algunas metodologas giles, pero no tanta como otras, y es en la fase de diseo, con sesiones de trabajo conjuntas donde se decide la estructura de la arquitectura. En cuanto a la relacin con el cliente, esta es fluida y sin excesivos formalismos, basada en controles propios y una comunicacin constante. Como puntos flacos de este tipo de desarrollo software observamos la necesidad de poseer expertos en el equipo de trabajo que marquen desde el principio el camino a seguir, con el modelo global. Adems, como ya hemos comentado, existe demasiada jerarquizacin entre los roles. Estos hechos pueden restarle fluidez al desarrollo. Pero sus principales puntos fuertes son que disminuye en gran medida el riesgo de los proyectos, con la constante monitorizacin de su calidad (sencilla gracias a la divisin en rasgos) y las peridicas entregas tangibles (gracias a la estructura iterativa de sus fases), y que adems es muy adaptativo y permite cambios de ltimo momento.

Agile Unified Process


El AUP o Proceso Unificado Agil de Scott Ambler es una versin simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fcil de entender la forma de desarrollar aplicaciones de software de negocio usando tcnicas giles y conceptos que an se mantienen vlidos en RUP. El AUP aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Agil, Gestin de Cambios Agil, y Refactorizacin de Base de Datos para mejorar la productividad. (RUP).

Disciplinas:
A diferencia del RUP, el AUP tiene tan solo 7 disciplinas: 1. Modelo. Entender el problema planteado por el proyecto e identificar una solucin para abordar el problema. 2. Implementacin. Transformar el modelo(s) en cdigo ejecutable y realizar pruebas de nivel bsico en concreto prueba de unidad. 3. Pruebas. Realizar una evaluacin objetiva para asegurarse la calidad. Esto incluye encontrar defectos, asegurarse de que el sistema funciona como debera y verificar que cumple los requisitos. 4. Desarrollo. Planificar la entrega del sistema y ejecutar el plan para hacer que el sistema este disponible para el usuario final. 5. Administrar la Configuracin. Administrar el acceso a los artefactos del proyecto. Esto incluye Esto incluye el seguimiento de versiones de artefactos a travs del tiempo, asi como el control y la gestin de los cambios a los mismos. 6. Administracin del Proyecto. Dirigir las actividades que toman parte en el proyecto. Esto incluye la administracin de riesgos, dirigir personas (asignarles tareas, llevar el seguimiento de su progreso, etc), y coordinarse con personas y sistemas fuera del mbito del proyecto para asegurarse que se entrega a tiempo y dentro del presuspuesto 7. Medio Ambiente. Apoyar el resto del esfuerzo, garantizando que el proceso es adecuado, las guias (normas y directrices), y las herramientas (hardware, software, etc) estn disponibles para el equipo segn sea necesario.

Entrega de versiones incrementales con el tiempo:


En lugar del enfoque Big Bang de entregar el software todo en una entrega en vez de entregar porciones (por ejemplo, la versin 1, versin 2, y as sucesivamente), los equipos AUP suelen ofrecer versiones de desarrollo al final de cada iteracin en las fases de pre-produccin. Una versin de desarrollo de

una aplicacin es algo que podra ser potencialmente lanzado si pasara los controles de calidad de pre-produccin, pruebas y procesos de desarrollo. En la imagen se observa que la primera versin de produccin suele tomar mas tiempo de desarrollo que las dems; en la primera versin de un sistema el equipo tiene que establecer las bases, lo que lleva mucho tiempo, pero permitir que las versiones siguiente sean lanzadas mas rpido. La entrega de la primera produccin puede tomar doce meses, la segunda entrega, nueve meses, y luego, las siguientes versiones, se entregan cada seis meses.

Un enfoque inicial en los problemas de implementacin no slo te permite evitar los problemas, adems tambin te permite aprovechar la experiencia obtenida durante el desarrollo. Por ejemplo, cuando se va a implementar el software en tu rea de preparacin debes tomar notas de lo que funciona y de lo que no, esas notas pueden servir como eje de las secuencias de comandos de instalacin.

Principios:
1. Tus empleados saben que estn haciendo. Los empleados no van a leerse los detalles de la documentacin del proceso, pero necesitarn alguna orientacin de alto nivel y / o formacin de vez en cuando. El producto del AUP propone enlaces para muchos de los detalles, si estas interesados en ellos, pero no te fuerza a usarlos. 2. Simplicidad. Todo es descrito con precisin usando un puado de paginas, pero sin pasarse. 3. Agilidad. El AUP se ajusta a los valores y principios del desarrollo gil de software y de la Alianza gil. 4. Centrarse en actividades de alto valor. La atencin se centra en las actividades que realmente cuentan, y no en cada cosa que pudiera pasar a lo largo del desarrollo del proyecto. 5. Independecia de las Herramientas. Con la AUP se pueden utilizar cualquier conjunto de herramientas que quiera el desarrolador. La recomendacin es que utilice las herramientas que se adapten mejor para el trabajo, que a menudo son herramientas simples. 6. Adaptar el AUP para que cumpla tus necesidades. Bibliografa http://www.ambysoft.com/unifiedprocess/agileUP.html http://en.wikipedia.org/wiki/Agile_Unified_Process

Introduccin
DSDM (Dynamic System Development Method) es considerada la primera metodologa gil y es la nica de ellas que ha sido declarada en un Consorcio formado por 17 personas en Gran Bretaa en el ao 1994. El origen de esta metodologa surgi como resultado de la bsqueda de una metodologa pblica que se ajustase a cualquier herramienta de desarrollo de software y que pudieras ser usado en proyectos RAD (Rapid Agile Development). Creado con la experiencia de los fundadores en las prcticas que se llevaban a cabo en la industria del software el primer modelo DSDM fue liberado en el ao 1995. Su involucracin en la industria fue positivo por lo tanto el presidente del Consenso decidi que sera til crear un libro sobre la aplicacin real del mtodo a los proyectos de software. Esta metodologa se basa en 9 principios que se apoyan en la ideologa RAD: 1. Es obligatoria la involucracin del usuario en el proyecto. 2. Los equipos de trabajo que desarrollen el proyecto deben de poder tomar decisiones. 3. Se deben de producir entregas frecuentemente para comprobar el estado del proyecto. 4. Las entregas deben cumplir los propsitos de modelo que se indicaron. 5. La solucin del negocio requiere un ciclo de desarrollo iterativo e incremental. 6. Cualquier cambio en el desarrollo es posible, ya que este mtodo permite la reversibilidad. 7. Los requerimientos del proyecto estn especificados a un alto nivel. 8. El testeo se integra en el mismo ciclo de vida. 9. La colaboracin y cooperacin entre los miembros interesados en el proyecto es esencial.

Fases
El DSDM tiene un ciclo de desarrollo dividido en 5 fases: Estudio de factibilidad: en esta fase se comprueba que la metodologa se ajuste al proyecto que se va a llevar a cabo. Estudio de negocio: Se establece la temprana comunicacin con el cliente para llegar a las bases del sistema que deber de desarrollarse y como debern de operarse. Se encuentran las necesidades de ms alto nivel del software y se sientan las bases del desarrollo a su alrededor, junto a los costes de tiempo y capital Iteracin del modelo funcional: como su nombre indica es la primera iteracin que se lleva a cabo en ella se deben de crear prototipos que puedan ser usados y vaya supliendo necesidades del sistema a desarrollar en cada iteracin. Esta iteracin se divide en 4 subfases principales: Acordar Plan, Crear Prototipo, Revisar Prototipo e Identificar Prototipo funcional. Iteracin de Diseo y Construccin: Crea el diseo de la aplicacin y se construir atendiendo a este empleando el prototipo generado en la fase anterior. Tambin est dividido en 4 subfases principales: Acordar plan, Crear prototipos de diseo, Revisar los prototipos de diseo e Identificar estos prototipos. Implementacin e implantacin: En esta fase se produce el beta-testing adems de ensear a los usuarios a usarla, se crean los manuales de uso de la aplicacin, se encuentran errores en el uso si es que existen, se restablecen los criterios del negocio y si hay errores se vuelve a comenzar el ciclo de vida, en caso contrario se implantar el software entregndoselo al cliente (empresa o usuarios).

El creador del modelo de desarrollo XP ha aceptado que la imagen corporativa de DSDM es mejor que la de su modelo y se ha creado una especie de fusin entre ambos llamada EnterpriseXP.

Roles de trabajo
La gente que trabaja junta de manera efectiva son el fundamento de un proyecto exitoso. El DSDM reconoce esta necesidad y asigna papeles y responsabilidades claros a cada persona en el proyecto, ya sean clientes o proveedores. Estas dos comunidades deben trabajar hombro con hombro en los proyectos DSDM rompiendo toda barrera que impida la comunicacin. Los principales roles a desempear son:

Patrocinador de negocio:
Es el nivel ms alto en la parte del proyecto. Se encarga de resolver las dudas de negocio a cualquier persona y decidir las decisiones financieras. Tiene la gran responsabilidad de que el proyecto se desarrolle a la velocidad adecuada y eficazmente. Sus responsabilidades son: Se encarga del caso de negocio del proyecto. Asegura la viabilidad del proyecto con respecto al plan establecido. Regula los fondos y otros recursos disponibles conforme a las necesidades. Controla que las tomas de decisiones de proceso solucionan las dudas de manera efectiva y rpida. Responde rpidamente ante problemas de tamao considerable y encuentra soluciones eficaces.

Visionario de Negocio
Uno de los niveles ms altos del proyecto. Est involucrado de manera ms activa que el Patrocinador, es el responsable de interpretar las necesidades del Patrocinador y comunicar estas necesidades al equipo intentando fielmente el plan de proyecto. Adems, aprovisionar al equipo de desarrollo con una direccin estratgica y asegurndose de que la solucin escogida a la hora de solucionar un problema conseguir los beneficios estimados.

Sus responsabilidades son: Posee la mayor implicacin en el proceso de desarrollo de los papeles organizativos. Define la visin de proyecto. Comunica y promueve la visin de negocio a todas las partes interesadas. Monitoriza el progreso del proyecto en la lnea de la visin de progreso. Contribuye a los requerimientos, diseo y reseas clave. Provee cambios a los requisitos de alto nivel. Asegura la colaboracin entre los clientes y el rea de trabajo. Comprueba que existan los recursos necesario. Promociona la traduccin de la visin de negocio al mbito del trabajo. Acta como rbitro definitivo entre desacuerdos de los miembros del equipo.

Analista de Negocio
Est ntegramente integrado con el equipo de desarrollo de soluciones y es el centro de las relaciones entre los encargados de gestionar el negocio y los tcnicos, proveyendo una direccin acertada y decisiva provista por el equipo de desarrollo de soluciones en una base diaria. Es el encargado de comprobar que todas las necesidades se analizan correctamente y se reflejan en el plan de desarrollo. Otras de sus responsabilidades son: Asegura la implicacin da a da de las decisiones de negocio en el proyecto de manera fiel. Controla el desarrollo, distribucin y base de la documentacin y productos que tienen relacin con los requerimientos de negocio y su interpretacin.

Desarrollador de soluciones
Interpreta los requerimientos de negocio y los traduce a una posible solucin que logra solucionar las necesidades funcionales y no funcionales. Debera de estar a tiempo completo desarrollndose en un nico proyecto. Sus responsabilidades son: Trabaja con los encargados del negocio y el equipo de pruebas de soluciones con el fin de desarrollar iterativamente:

Una solucin desplegable. Modelos requeridos para el apropiado control del desarrollo de soluciones. Modelos y documentacin requerida para el fin de sostener la solucin en tiempo real de uso.

Escucha e interpreta los detalles de cambios en requerimientos, soluciones, definiciones Hacen sus propias pruebas y les dan ms prioridad que a las pruebas de otros equipos. Participa en cualquier trabajo de estimacin de calidad para asegurar que los productos desarrollados se ajustan al plan.

Probador de soluciones
El probador de soluciones est totalmente integrado con el equipo de desarrollo de soluciones y ejerce pruebas en relacin a la estrategia de pruebas tcnicas plasmadas en el proyecto. Sus responsabilidades son: Trabaja con los encargados del negocio para definir los escenarios y casos de prueba para la solucin propuesta. En compromiso con la Estrategia Tcnica de Pruebas: Visiona todos los tipos de soluciones como uno. Crea productos de pruebas. Reporta los resultados de las actividades de prueba al coordinador tcnico de propsitos de calidad y seguridad. Mantiene al lder del equipo informado de los resultados de las pruebas. Ayuda al Embajador y al Consejero de Negocio a asegurar que pueden planear y llevar a cabo sus pruebas lo suficientemente bien como para asegurar algunos puntos para asegurar que ciertas reas estn cubiertas.

Consejero de Negocio:
Acta como compaero del Embajador de Negocio, el consejero es quien provee de ayudas especficas y especialistas al desarrollo de soluciones o a la prueba de estas. Normalmente ser un usuario con buenos conocimientos o un beneficiario de la solucin, aunque quizs simplemente ofrece un apoyo a las bases legales del proyecto.

Sus responsabilidades son: Provee ayudas y aportes especialistas campos relevantes como el entrenamiento de usuarios, decisiones da a da en proyectos, organizando y controlando la aceptacin de los resultados de las pruebas en el negocio.

Facilitador de Taller
Es el responsable de controlar el proceso de taller y el catalizador en la preparacin y comunicacin. Tambin es el responsable del proceso en el taller, aunque no del contenido de este. Sus responsabilidades son: Para cada taller: Acepta el campo del que se ocupar el taller con el propietario de este. Planea el uso del taller. Familiariza a los sujetos con el rea de trabajo. Comprueba las capacidades de los trabajadores en el campo. Asegura que comprender los objetivos del trabajo. Anima a lo largo del proceso de trabajo.

Coach
El papel de Coach es una ayuda para el equipo con limitada experiencia que usa DSDM para obtener todo el provecho del equipo posible. Debera de ser una persona con certificacin acreditada para estar capacitado para llevar a cabo el trabajo y tener los conocimientos necesarios. Sus responsabilidades son: Provee detallado conocimiento y experiencia sobre la metodologa y el tema a tratar. Confecciona el proceso de trabajo para adaptarlo a las necesidades individuales del proyecto y el ambiente en el que se est operando. Ayuda al equipo a usar tcnicas de la metodologa y prcticas, y ayuda a aquellos fuera del equipo a apreciar la filosofa DSDM y su valor. Ayuda al equipo de trabajo a adentrarse en la colaboracin y la cooperacin demandada por la metodologa DSDM y gil. Mejora las aptitudes del equipo en DSDM.

Roles de especialistas:
Se encargan de aportar todo lo posible al campo de conocimiento del proyecto en el cual son expertos e intentar trabajar con total eficacia siguiendo las indicaciones de las capas superiores y adaptndose al plan de desarrollo. La decisin de que todo acabe bien es suya al ser la mano de obra principal el proyecto. Si su forma de trabajo no es la correcta sufren en mayor medida la capacidad de ser sustituidos.

Esquema de Roles de Atern (ltimo DSDM)

Conclusin:
Como hemos podido comprobar en este trabajo el DSDM es una metodologa que tiene en mente la limitacin de recursos y que la velocidad es importante. Adems, se preocupa en gran medida por la colaboracin entre la empresa de desarrollo y el cliente. Se interesa mucho por la coordinacin y el control sobre la comunicacin colocndola en el centro de la metodologa. En el DSDM se mezclan las bases para el desarrollo gil y una organizacin estricta del equipo y la planificacin. Debera ser utilizado en proyectos que puedan tener especificaciones cambiantes o que necesiten desarrollarse en poco tiempo. Y lo ms importante es que fue creado en un consenso de expertos lo que hace que sea una metodologa ideal y de utilidad bien demostrada, adems puede ser utilizada junto con otras metodologas. La metodologa sufri una importante atencin debido a los beneficios del feedback que se obtena de los usuarios que trabajaban codo con codo en el proyecto.

Metodologa Crystal:
Introduccin: La familia de metodologas Crystal nace a principios de los 90 por uno desarrollador de software llamado Alistair Cockburn en base a sus distintos proyectos y experiencia. Es un tipo de metodologa gil cuyo nombre viene de su comparacin de los grupos con los minerales segn su color o dureza. Se caracteriza por su gran nfasis en la comunicacin y su tolerancia, que la hace ideal en casos en los que XP es inaplicable o para proyectos pequeos. Crystal se define con mucho nfasis en la comunicacin y de forma muy ligera en relacin a los productos peridicos entregables. Aneja interacciones cortas con feedback frecuente por parte del cliente, minimizando los productos intermedios. Tambin cuenta con usuarios reales que participan en la definicin del producto como tal. Esta familia dispone de unos cdigos de color para marcar la complejidad de cada una de las metodologas que la componen: de ms oscuro y pesado a ms claro y ligero; y de mayor criticidad y rigor a menor. Situadas en una grfica, estas metodologas siguen los parmetros de Comodidad, Dinero Discrecional y Esencial y Vidas. Segn este cdigo de colores, el Clear es para equipos de 8 o menos personas, el Amarillo para equipos de entre 10 y 20 personas, el Naranja para equipos de entre 20 y 50 personas, el Rojo de 50 a 100 y el Azul de 100 a 200. Valores o Propiedades: Como casi todos los mtodos, Crystal Clear consiste en valores, tcnicas y procesos. Los siete valores o propiedades de esta metodologa son: Entrega frecuente a los clientes, lo cual no consiste tan solo en compilar, sino en evaluarlo. La frecuencia de esto depender de la complicacin del proyecto. Al hacer esto aseguramos que el proyecto cumple las condiciones que espera el cliente, evitando malentendidos en el anlisis del sistema. Comunicacin osmtica, es decir, todos los integrantes del grupo debern estar desarrollando en la misma sala, con peridicas reuniones separadas para que los concurrentes se concentren mejor.

Mejora reflexiva, es decir, periodos de reflexin para que los desarrolladores puedan pensar, tomar notas, reflexionar, relajarse, discutir... Se obtienen as una serie de hbitos o prcticas de desarrollo que nos gustara mantener, una lista de lo que nos gustara intentar y de lo que queremos evitar, generando as una mejora continua en nuestro proyecto. Comunicacin Osmtica, es decir, todos juntos en el mismo cuarto. La posicin fsica de los desarrolladores es muy importante en Crystal, ya que nos permite no tomarnos demasiado tiempo en solucionar las dudas y contrastarlas con otros miembros del equipo. Seguridad personal y buena comunicacin entre los integrantes cuando algo molesta o no est bien, en lugar de encubrirlo, para as poder mejorarlo y desarrollar un software libre de errores. Foco, saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre direccin y prioridades con el Patrocinador Ejecutivo; lo segundo de un ambiente en el que la gente no se vea compelida a hacer otras cosas incompatibles. Fcil acceso a usuarios expertos, ya que es muy importante el contacto directo con expertos en el desarrollo de un proyecto, y un encuentro semanal y llamadas telefnicas adicionales o el entrenamiento de los desarrolladores como usuarios pueden resultar muy beneficiosos. Ambiente tcnico con pruebas automatizadas, management de configuracin e integracin frecuente. Debern integrarseun mnimo de dos veces por semana. Tcnicas: Adems comparte algunas tcnicas con el resto de metodologas giles, que a pesar de no ser obligatorias como en otras como el XP, si es conveniente utilizarlas. Estas son: Exploracin de 360, tomando muestras del valor de negocio del proyecto, sus requerimientos, su modelo de dominio, tecnologa, plan de proyecto y proceso entre otros. Victoria temprana, ya que es mejor tener pequeos entregables peridicos cada poco tiempo que entregar el producto terminado al cabo de mucho.

Esqueleto ambulante, una transaccin debe ser simple pero estar completa, no dejarla a medio programar, ya que al volver a mejorarla al cabo de un tiempo puede habrsenos olvidado el cdigo y ser incapaces de mejorarla sin mermar sus funcionalidades. Rearquitectura incremental, es decir, la arquitectura del proyecto debe mejorar en etapas, manteniendo el sistema en ejecucin mientras se modifica. Radiadores de informacin, unos paneles con la evolucin del proyecto y sus requisitos para que los integrantes del grupo puedan tenerlo disponible en cualquier momento para ser observado y recordado o modificado. Crystal sigue una serie de tcnicas para completar el proyecto. Estas son: Entrevistas de proyectos a ms de un responsable para tener varias visiones del software que se va a desarrollar. Talleres de reflexin para que el equipo discuta sobre el trabajo, pros y contras, mejoras, planes para las siguientes interacciones, etc. Planeamiento relmpago o Poker, tal y como se utiliza en XP, con tarjetas con valores segn la dificultad de las tareas a realizar. Estimaciones de pericia mediante el proceso Delphi.

Encuentros diarios breves para la identificacin de problemas o fallos. Programacin por parejas, que establece proximidad.

Procesos: Esta metodologa no especifica ningn ciclo ciclo de vida o modelo de procesos, pero determina una gua estndar de las prcticas ms utilizadas. Estas son: Planificacin por etapas del siguiente incremento del sistema. Debe finalizar con una versin ejecutable cada tres o cuatro meses. El equipo selecciona los requisitos que sern implementados en cada incremento y planifican lo que harn. Revisiones y resmenes de cada iteracin de cada incremento

segn sus actividades: construccin, demostracin y resmenes de los objetivos del incremento. Monitorizacin de los progresos a partir de las entregas del equip durante el desarrollo. Se mide con los hitos clave y la estabilidad de las fases. Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un estado estable para su revisin se pasa a la siguiente tarea. Los equipos de seguimiento y arquitectura deben revisar sus planes de trabajo, su estabilidad y su sincronizacin para llevar esto a cabo.

Roles: En Crystal se establecen unos roles bien definidos para cada integrante del grupo. Estos son: Patrocinador, que consigue recursos y define el proyecto y produce la Declaracin de Misin con Prioridades de Compromis o (Tradeoff). Pone y defiende su inversin en el proyecto. Tiene en mente la visin a largo plazo del mismo. Crea la visibilidad externa para el producto y provee al equipo de decisiones cruciales para el negocio. Tambin puede tomar la decisin de si seguir o no con el proyecto si no lo ve una inversin rentable y, de continuar, deber replantear las funciones restantes para recuperar la inversin. EN Crystalse hace mucho incapi en dar buena informacin al sponsor para que pueda tomar sus decisiones correctamente. Usuario Experto, que produce la Lista de Objetivos y el Archivo de Casos de Uso y Requerimientos. Tambin sugiere maneras de optimizar su uso con macros, modos de visualizacin y navegacin y cualquier otra sugerencia. Es una base de conocimiento para el Experto de Negocio. Se espera que conozca las reglas del negocio necesarias para el sistema, las polticas que son estables y las propensas al cambio. Experto de Negocios, que componen la Lista de Objetivos del proyecto, Archivos de Casos de Uso y Requerimientos. Debe conocer las reglas y polticas del negocio. Es experto en indicar cmo va el negocio. Responder a varias preguntas de los desarrolladores acerca del sistema. Provee informacin diferente de la entrega el Usuario Experto, e incluso puede suceder que el mismo Usuario sea el Experto de Negocios.

Diseador Principal, que produce la arquitectura del producto, llamada Descripcin Arquitectnica. Debe manejar con fluidez, mezclar e inventar procedimientos. Tiene los roles de coordinacin, arquitecto, maestro y programador ms experto. Es por tanto el lder tcnico del equipo. Diseador-Programador, que produce unos borradores de pantallas y el modelo comn, al igual que otra serie de documentos de diseo de software como notas, diagramas de diseo, cdigo fuente, cdigo de migracin, pruebas y sistema de empaquetado. Dado que un programa desarrollado en Crystal es diseo y programa, sus desarrolladores harn las veces tanto de programador como de diseador, por tanto cualquier individuo que no cumpla ambos requisitos no tiene cabida en este tipo de desarrollo de software. Coordinador, que junto con el equipo produce el Mapa del Proyecto y su Plan de Entrega, Lista de Riesgos, el Plan y Estado de Iteracin y la Agenda de Visualizacin. Suele ser una ocupacin parcial en alguno de los dems miembros del equipo. Alternativamente, el Patrocinador o Diseador Principal pueden asumir este rol. Verificador, que produce los reportes de fallos y bugs. Puede ser tanto una sola persona como todo un equipo de programadores. Escritor, que produce el manual para el usuario.

Desarrollo de un proyecto: En el desarrollo de un proyecto en Crystal se deben tener en cuenta para empezar las personas que componen un equipo, el aspecto humano del mismo, la comunicacin entre los componentes, las distintas polticas a seguir y el espacio fsico de trabajo. Especial importancia tiene el tamao del equipo, ya que si es elevado produce una metodologa ms pesada. Tambin es importante una comunicacin cercana para que sea ms barata y efectiva, recomendando el cara a cara. Dado que Crystal no es una metodologa concreta sino ms bien una familia de ellas, todas comparten una serie de caractersticas llamadas cdigo gentico. Estas son: 1. Modelo de Juego Cooperativo, dividiendo a los integrantes del equipo en grupos o partidos cuyos objetivos consisten en inventar y comunicar para mejorar su concentracin. Cada partido es diferente y

tiene como objetivo la entrega de software y preparacin para el siguiente juego. 2. Prioridades, que son - Eficiencia en el desarrollo, para que los proyectos sean rentables econmicamente hablando. - Seguridad en lo que se entrega. - Habilidad para hacer que todos los miembros del equipo adopten las convenciones de trabajo establecidas por el equipo.

3.

Propiedades, que son: - Frecuencia de las entregas usables de entre 2 semanas y un mes. - Comunicacin, que es uno de los pilares de esta familia de metodologas. Por eso el suo de pizarras u otros espacios destinados a la comunicacin y la notificacin del estado del proyecto son prcticas frecuentes. - Creciminento reflexivo, utilizando periodos de reflexin y reuniones entre los integrantes del equipo para mejorar la eficiencia de estos. - Seguridad personal con un equipo en el que todos sus miembros se sientan cmodos con el trabajo y el entorno. - Concentracin - Fcil acceso a los usuarios clave haciendo que sean parte del desarrollo - Entorno tcnico especializado. Mientras que las 3 primeras son obligatorias, Crystal es ms flexible con el resto. 4. Principios, el grado de detalle necesario en la documentacin y ajuste en la forma de trabajo acorde con la personalidad para encajar con los miembros del equipo. 5. Estrategias, ya comentadas anteriormente: Victorias Tempranas, Exploracin de 360, Esqueleto ambulante, Rearquitectura Incremental y Radiadores de Informacin. 6. Tcnicas, tambin comentadas con anterioridad, como las Reuniones Periodicas o las de Reflexin.

Conclusin: Como conclusin podemos remarcar que las metodologas Crystal son altamente recomendables para equipos pequeos. Son flexibles y priorizan la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza entre los integrantes del grupo. Los requisitos se obtienen mediante programacin por parejas. Tambin presta especial atencin al espacio fsico donde se sita el equipo y a la comunicacin. La necesidad de las entregas peridicas, adems, estimulan la concentracin y resalta la importancia de la comunicacin con el cliente junto con las reuniones. Por ltimo, el equipo elige que tcnicas aplicar segn las caractersticas del proyecto.

COMPARATIVA:
- Tamao de los equipos FDD: Pensado para proyectos cortos y equipos pequeos, pero muy escalable. Crystal: Preferiblemente para equipos de tamao reducido, pero modificable segn el peso del proyecto. DSDM:Pensado para proyectos que deben desarrollarse de manera rpida con un equipo ajustado y dirigido. AUP: Preferiblemente aumentar el tamao. - Obtencin de requisitos FDD: No define explicitamente esta parte del proyecto, sino que propone proceder a partir de un momento en el que ya se han recogido de la manera que se quiera, en las 3 primeras fases. Crystal: El equipo elige la manera en la que obtendrn los requisitos, si bien debe haber comunicacin suficiente para debatrilo y que todos los integrantes trabajen a gusto. DSDM: Se definen los requisitos en dos fases iniciales llamadas estudio de factibilidad y estudio de negocio. AUP: Se produce en la primera fase, que est destinada especficamente para ello, y condiciona la siguiente iteracin. - Carga de trabajo FDD: A medio camino entre la documentacin y el desarrollo, bastante libre para los desarrolladores auque con orden, porque estos estn muy jerarquizados. Crystal: Cada componente del equipo tiene su papel, especificando uno concreto para la docuemntacin (Escritor), para la arquitectura (Diseador Principal), la programacin (ProgramadorDiseador), etc. DSDM: El trabajo est muy organizado en niveles muy claros y con funciones definidas, la carga se reparte en la medida de lo posible entre todos los niveles. pequeos, pero con posibilidad de

AUP: Se centra totalmente hacia el desarrollo colocando las cuestiones de documentacin o planificacin en segundo plano.

- Relacin con el cliente FDD: No tiene formalismos en la documentacion, realiza controles propios y una comunicacin fluida con el cliente. ste recibe una muestra al final de ca da iteracion corta. El feedback del cliente ya no marca el progreso, porque ste queda restringido por el modelo de dominio creado en las primeras fases. Crystal: Mucha relacin con el cliente en forma de entregas peridicas y reuniones diarias. DSDM: Trabaja codo con codo con el cliente o los usuarios finales obteniendo el beneficio de un feedback que ayudaban a mejorar el proyecto. Se hacen entregas frecuentes al cliente para comprobar el estado del desarrollo. AUP: El cliente recibe pequeas entregas cada poco tiempo y entregas ms complejas, por lo general, cada 12, o cada 9 meses. - Desarrollo FDD: Proceso iterativo. Se centra en la organizacin global. Y cada iteracin acaba con un producto totalmente completo (con manual de instrucciones, nota..) Crystal: Se realizan gran cantidad de iteraciones con productos completos y usables. DSDM: Tres fases principales con subfases que se ejecutan de manera iterativa. Se integran pruebas durante todo el ciclo de vida del proyecto. AUP: Tambin es iterativo y cada iteracin acaba con un microproducto efectivo que se entrega al cliente. - Cdigos fuente FDD: Es propietario, cada programador trabaja por su cuenta. Aunque definen grupos y sesiones de trabajo, con los propietarios de clases relacionadas.

Crystal: Utiliza la programacin por parejas para trabajar ms dinmicamente y potenciar la comunicacin. DSDM: Cada uno desarrolla su trabajo designado, no se utiliza el Pair Programming normalmente. AUP: Fomenta el trabajo en grupos pequeos cuyos miembros interactan entre s para mejorar el resultado final.

- Conocimiento sobre la arquitectura FDD: Se concreta en la fase de diseo con reuniones conjuntas, para conseguir una arquitectura sencilla y sin errores. Crystal: Existe un papel dentro del equipo llamado Diseador principal que se encarga de la arquitectura, y a la vez todos los programadores son diseadores en si mismos. DSDM: En las fases cada campo decide como se van a organizar, lo aceptan y se sigue el plan creado. AUP: Se decide al principio de cada iteracin, en la fase de diseo.

- Evaluacin del estado del proyecto FDD: Es el mas adecuado para la monitorizacion del progreso, porque se divide en unidades muy peueas (los rasgos). Crystal: Son flexibles y priorizan la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza entre los integrantes del grupo. Tambin presta especial atencin al espacio fsico donde se sita el equipo y a la comunicacin DSDM: Durante todo el ciclo de vida se desarrollan pruebas que comprueban como se va desarrollando, hay un equipo destinado a desarrollar y probar esos tests. AUP: Muy rpido, pero contraindicado para grupos grandes o proyectos que por sus caractersticas no sean de fcil evaluacin.

- Punto fuertes y puntos flacos FDD: Divisin del software pequea y manejable, pero excesiva jerarquizacin del personal. Crystal: Muy eficiente si el equipo tiene buen ambiente de comunicacin y es escalable, pero restringe la ubicacin del grupo a un nico espacio fsico. DSDM: Al ser propuesto por un consenso de expertos es una de las metodologas ms recomendadas, adems se puede utilizar junto con otras metodologas como XP o no giles como RUP, el feedback y la ntima relacin con el cliente le dan seguridad y calidad al proyecto. Su punto flojo puede ser que en proyectos muy cortos puede complicarse la organizacin ya que es medianamente compleja. AUP: Garantiza un rpido progreso de produccin y se centra ms en el cdigo como tal que en el diseo previo de ste.