PRCTICA 3 - OTRAS METODOLOG AS GILES Anlisis y Especificacin de Sistemas Multimedia Ingeniera Multimedia

Javier Navarro Pastor Ivn Riveiro Martnez Marco Antonio Agero Caldern Antonio Mart Vicedo

Crystal Clear Crystal es una metodologa de desarrollo de Software gil, ms que una metolodoga se la considera una familia de metodologas, debido a que se subdivide en varios tipos de metodologas en funcin a la cantidad de persona que vayan a estar en el proyecto. Es una metodologa que ha sido creada por una persona en particular (Alistair Cockburn ) el cul llego la cre en base al anlisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cul fusionando ambos aspectos dio lugar a una metodologa bastante interesante, la cual se presenta a continuacin. Crystal est orientado principalmente en las personas que participan en el proyecto de desarrollo de software, ya que Cockburn entiende que en ellas est la clave para que el proyecto tenga oportunidades de xito. Concretamente el autor indica que Crystal est centrado en: 1.- Las personas 2.- La Interaccin 3.- La comunidad 4.- Las habilidades 5.- Los talentos 6.- Las comunicaciones Es decir, orientado al equipo de trabajo y a las personas que lo componen tanto a nivel individual como de su pertenencia a un grupo. Para Cockburn los procesos pese a ser importantes son secundarios, respecto a los principios en que est orientado este conjunto de metodologas, ya que la propia complejidad de la gestin de los equipos para obtener de los mismos el mximo rendimiento, teniendo en cuenta que estn formados por un conjunto diverso de personalidades, experiencias, talentos y habilidades, es de por s el principal problema que hay que resolver en el desarrollo de software. Si extendemos esto a otras personas que participan en el proyecto, como pueden ser los usuarios que hacen las especificaciones del sistema, as como los responsables tcnicos del cliente (en el caso de servicios de desarrollo que se prestan a terceros), la complejidad crece exponencialmente ya que a todo lo anterior hay que sumar los intereses de organizaciones distintas o incluso de departamentos distintos dentro de una organizacin. Antes de entrar a realizar una breve descripcin de las metodologas Crystal, que analizaremos en el prximo artculo, voy a exponer una serie de principios que defini Cockburn en 1999 y que definen el comportamiento de las personas dentro de los equipos de proyecto (o equipos de trabajo en general): - Las personas son seres comunicativos, hacindolo mejor cara a cara, en persona, con preguntas y respuestas en tiempo real. - Las personas tienen problemas para actuar de manera consistente todo el tiempo. - Las personas son altamente variables (cambiantes), varan de un da a otro y de un lugar a otro.

- Las personas generalmente quieren ser buenos ciudadanos, son buenos observando, tomando iniciativas y haciendo todo lo que sea necesario para el proyecto funcione. En primer lugar, por qu reciben el nombre de metodologas Crystal? La denominacin Crystal no est elegida al azar, qu es un cristal sino un ncleo comn con diferentes caras?. Las metodologas Crystal se basan en el hecho de que hay que tener en cuenta las caractersticas del proyecto para aplicar una metodologa (para Cockburn son un conjunto de elementos entre los que se encuentran las prcticas y las herramientas) u otra, no es lo mismo un proyecto en el que intervienen pocas personas que otros en donde intervienen muchas. Entender que todos los proyectos son iguales independientemente de su tamao es un error que puede derivar desde prdidas econmicas hasta el fracaso completo. Tambin es fundamental tener en cuenta la criticidad del proyecto, no es lo mismo el desarrollo de sistemas de los que pueden depender la vida de personas o la propia subsistencia de una organizacin que otros desarrollados para informatizar procesos de gestin pero que no resultan realmente crticos. Como consecuencia de la consideracin de estas dos dimensiones: tamao del equipo y criticidad surgi la escala Cockburn de clasificacin de proyectos software cuyo utilidad va ms all de definir en qu condiciones aplicar una metodologa Crystal u ota, sino que tambin puede ser utilizado para definir la aplicabilidad de otras metodologas diferentes a estas en funcin de la naturaleza del proyecto. Las metodologas Crystal van, en funcin del tamao del equipo de proyecto, denominndose con colores ms oscuros y en funcin de la criticidad, de manera que tenemos: -En funcin del tamao del equipo: metodologa Crystal Clear (equipos hasta seis personas), Crystal Yellow (equipos entre seis y veinte personas), Crystal Orange (equipos entre veinte y cuarenta personas), Crystal Orange Web, Crystal Red (equipos entre cuarenta y ochenta personas), Crystal Maroon (equipos entre ocheta y doscientas personas). - En funcin de la criticidad del proyecto: metodologa Diamond y Sapphire en funcin de si del sistema depende la vida de las personas o la subsistencia de la organizacin. Las metodologas Crystal tienen, por lo general, los siguientes puntos en comn: - Entregas frecuentes: Se basan por tanto en una estrategia de desarrollo iterativa e incremental. En funcin de las caractersticas del proyecto se pueden establecer entregas desde semanales hasta trimestrales. Esta caracterstica va en consonancia con la naturaleza adaptativa del proceso de desarrollo de software, permitiendo ajustar progresivamente el sistema a las necesidades de los usuarios. - Mejora reflexiva: La existencia de un desarrollo iterativo e incremental, favorece la mejora del sistema y de los procesos a travs del feedback que se obtiene tanto de los usuarios como del

propio equipo de proyecto. Si algo no funciona saldr a la luz ms pronto que tarde. Pero no solo es necesario esperar al resultado de las entregas para pensar en posibles mejoras en los procesos, por eso, es frecuente encontrarse con reuniones cada dos o tres semanas del equipo de proyecto especficas para detectar e intentar corregir aspectos de la dinmica del proyecto y del proceso de desarrollo que no estn funcionando como debieran. - Comunicacin cerrada u osmtica: El equipo de proyecto debe encontrarse en una misma ubicacin fsica, si es posible compartiendo la misma habitacin, mejor. De esta forma se reducen las distracciones y se mejora la concentracin, la informacin fluye ms rpidamente dentro del equipo de proyecto, las dudas se resuelven ms pronto, se favorece la colaboracin entre los miembros del equipo de proyecto. Por otro lado disminuye el overhead inherente a la comunicacin a distancia, es decir, se reduce la comunicacin por correo electrnico, la necesidad de documentacin extra, etc - Seguridad personal: En el equipo de proyecto todos tienen derecho a expresas sus ideas y opiniones (dentro de un orden), cada integrante debe tener la seguridad de que no va a ser ridiculizado o no tenido en cuenta sin sopesar siquiera lo que est comentando. - Enfoque: El enfoque en las metodologas Crystal tiene dos vertientes. Por un lado el enfoque en conseguir que se pueda dedicar tiempo suficiente sin interrupciones en las diferentes tareas de un proyecto para que progrese adecuadamente y por otro el enfoque en la direccin del proyecto. En el primer caso se establecen perodos de no interrupcin a los desarrolladores (por regla general dos horas) y por otro garantizar la continuidad en el desarrollo de las tareas superponiendo desarrolladores con antelacin al cambio de proyecto de uno de ellos. En el segundo caso para conseguir que la direccin del proyecto sea adecuada es necesario que los desarrolladores tengan totalmente claros los objetivos del mismo y que el responsable del proyecto priorice en cada momento los mismos para permitir al equipo de proyecto centrarse en tareas concretas. - Fcil acceso a usuarios expertos: La participacin e implicacin de usuarios expertos en el proyecto resulta esencial. Estas metodologas no exigen que los usuarios expertos tengan presencia continua en el equipo de proyecto (se es consciente de que no todas las organizaciones pueden poner personal de estas caractersticas al servicio del proyecto), pero s que como mnimo semanalmente se deben mantener encuentros de al menos un par de horas con ellos y existir accesibilidad para tener comunicaciones telefnicas si fuera necesario.

Agile Unified Process (Proceso Unificado gil)

Introduccin El Proceso Unificado gil (AUP) es una versin simplificada de el Proceso Unificado Racional, el cual posee las mejores caractersticas del RUP y la Metodologa gil. AUP no es otra cosa que tomar el RUP desde un punto de vista prctico. RUP est considerado como un rigido artefacto conducido al remplazamiento del desarrollo en cascada. Pero su desarrollo de procesos de software y prcticas se pueden hacer ms flexibles para acoplarse al tamao de la metodologa de tu proyecto. La Metodologa gil est caracterizada por un nfasis en las personas, su comunicacin, trabajo en software, y respuestas a los cambios, 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. Caractersticas Iterativo e Incremental. Descomposicin de un proyecto grande en mini-proyectos Cada mini-proyecto es una iteracin Las iteraciones deben estar controladas Cada iteracin trata un conjunto de casos de uso Ventajas del enfoque iterativo Deteccin temprana de riesgos Administracin adecuada del cambio Mayor grado de reutilizacin Mayor experiencia para el grupo de desarrollo Dirigido por Casos de Uso Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interacta con l Casos de uso como el hilo conductor que orienta las actividades de desarrollo Centrado en la Arquitectura Concepto similar a la arquitectura de un edificio Varios planos con diferentes aspectos del edificio Tener una imagen completa del edificio antes que comience la construccin

Arquitectura en software Diferentes vistas del sistema: estructural, funcional, dinmico, etc. plataforma en la que va a operar Determina la forma del sistema Arquitectura: determina la forma del sistema Casos de uso: determinan la funcin del sistema CICLO DE VIDA DEL PROCESO UNIFICADO GIL

Fases del AUP

Fase de Concepcin Objetivo: Definir la razn de ser y el alcance del proyecto. Estudio de oportunidad. Visin = QU + PARA QU + CUNTO Actividades Especificacin de los criterios de xito del proyecto

Definicin de los requisitos Estimacin de los recursos necesarios Cronograma inicial de fases Artefactos (Pieza de informacin producida, modificada y utilizada en un Proceso) Documento de definicin del proyecto Fase de elaboracin Objetivo: Establecer un plan de proyecto y una arquitectura correcta del sistema. Actividades Anlisis del dominio del problema Definicin de la arquitectura bsica Anlisis de riesgos Planificacin del proyecto Artefactos Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura bsica Fase de Construccin Objetivo: Desarrollar el sistema a lo largo de una serie de iteraciones. Actividades Anlisis Diseo Implementacin / Codificacin Pruebas (individuales, de integracin) Fase de Transicin El sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y aceptacin y finalmente se despliega en los sistemas de produccin.

Ventajas y Desventajas del AUP

VENTAJAS El personal sabe lo que esta haciendo: no obliga a conocer detalles. Simplicidad: apuntes concisos. Agilidad: procesos simplificados del RUP Centrarse en actividades de alto valor: esenciales para el desarrollo. Herramientas independientes: a disposicin del usuario. Fcil adaptacin de este producto: de fcil acomodo (HTML). DESVENTAJAS El AUP es un producto muy pesado en relacin al RUP. Como es un proceso simplificado, muchos desarrolladores eligen trabajar con el RUP, por tener a disposicin mas detalles en el proceso.

Conclusiones
AUP se preocupa especialmente de la gestin de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. El proceso AUP establece un Modelo ms simple que el que aparece en RUP por lo que rene en una nica disciplina las disciplinas de Modelado de Negocio, Requisitos y Anlisis y Diseo. El resto de disciplinas (Implementacin, Pruebas, Despliegue, Gestin de Configuracin, Gestin y Entorno) coinciden con las restantes de RUP.

FDD: Feature Driven Development / Desarrollo basado en funciones

El FDD es un proceso de desarrollo de software iterativo e incremental, es una metodologa gil para el desarrollo de sistemas y forma parte de Agile Aliance. Se introdujo en el 1999 por medio del libro Java Modeling In Color with UML, una combinacin de los procesos de software seguido por la compaa de los diseadores del FDD, Jeff DeLuca y Peter Coad. FDD mezcla las mejores prcticas reconocidas de la industria, estas prcticas son hechas en la perspectiva de la funcionalidad valorada por el cliente. Su principal objetivo es la entrega concreta, desarrollo de software en repetidas ocasiones, en el momento oportuno. Algunas caractersticas son las siguientes: No hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases de diseo y construccin. Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto. Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Propone tener etapas de cierre cada dos semanas. Se obtienen resultado peridicos y tangibles. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitoriar. Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto. Etapas El proceso FDD consiste de cinco pasos secunciales durante los cuales se disea y se construye el sistema: Desarrollo de un modelo global. Construccin de una lista de funcionalidades. Planificacin por funcionalidad. Diseo por funcionalidad. Construccin por funcionalidad.

Desarrollo de un modelo global Como entrada a este proceso el cliente debe estar listo para comenzar con la construccin del sistema. Adems se debe tener una lista de requerimientos especificada en alguna forma, hecha por los expertos del dominio. Cuando comienza el proceso, los expertos del dominio estn al tanto de la visin, el contexto y los requerimientos del sistema a construir. Se divide el dominio global en reas que son analizadas detalladamente y los desarrolladores construyen un diagrama de clases o de objetos por cada rea. A su vez se construye un modelo global del sistema. Esta etapa termina con el desarrollo del diagrama de clases global del sistema, una lista de funcionalidades o caractersticas, y un modelo global del sistema a construir. Construccin de una lista de funcionalidades Una funcionalidad se define como un tem til a los ojos del cliente.

Basado en el modelo global obtenido en la etapa anterior, y en la lista de funcionalidades informal, se rocedeaelabora una lista de funcionalidades que resuma la funcionalidad general del sistema. Dicha lista debe ser elaborada por los desarrolladores y es evaluada por el cliente. Se divide la lista en subconjuntos segn la afinidad y la dependencia de las funcionalidades. Luego la lista es finalmente revisada por los usuarios y los responsables para su validacin y aprobacin. Planeacin por funcionalidad En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Tambin se debe generar un cronograma donde se especifique la duracin del diseo y la construccin de cada una de las caractersticas.

Diseo por funcionalidades y Construccin por funcionalidades En esta etapa se selecciona un conjunto de funcionalidades de la lista y se procede a disear y construir la funcionalidad mediante un proceso iterativo. Una iteracin puede tomar de unos pocos das a un mximo de dos semanas. El proceso iterativo

incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo. Para cada una de estas iteraciones en la fase de diseo se debe generar: Diagrama de secuencia detallado. Diagrama de clases actualizado. Descripcin de clases y mtodos. Notas adicionales. En la fase de construccin: Implementacion e inspeccion de metodos. Testing unitarios para cada metodo. Check in de las clases. Main Build del sistema y testing de integracin. Diseo por funcionalidades y Construccin por funcionalidades En esta etapa se selecciona un conjunto de funcionalidades de la lista y se procede a disear y construir la funcionalidad mediante un proceso iterativo. Una iteracin puede tomar de unos pocos das a un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo. Para cada una de estas iteraciones en la fase de diseo se debe generar: Diagrama de secuencia detallado. Diagrama de clases actualizado. Descripcin de clases y mtodos. Notas adicionales. En la fase de construccin: Implementacione inspeccion de metodos. Testing unitarios para cada metodo. Check in de las clases. Main Build del sistema y testing de integracin.

Refe encia : h p:// . e 2008.in/Te 2008/pdf/Sidd%20P abh da %20-%20Agile%20Unified%20P oce pdf h p:// .info mi .com/a icle /a icle.a p ?p=345009 h p:// .agileki i.com/o he /agile/c al-clea -me hodolog / h p:// .agile he pa.o g/in o_ o_agile/agile_me hodologie / h p://en. ikipedia.o g/ iki/C al_Clea _( of a e_de elopmen ) h p://c2.com/cgi/ iki?C alClea Me hodolog http://www.featuredrivendevelopment.com/ http://en.wikipedia.org/wiki/Feature-driven_development http://www.scielo.org.pe/scielo.php?pid=S1810-99932010000200009&script=sci_arttext&tlng=es http://www.programania.net/desarrollo-agil/feature-driven-development/ http://www.agilemodeling.com/essays/fdd.htm .