2012

DYNAMIC SYSTEMS DEVELOPMENT METHOD

Miguel Angel Alor Ham Marquez Maria Salgado Heladia Hernandez Carlos Alberto Lpez Mondragn UPEMOR 17/03/2012

Ernesto

ndice

Introduccin El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Estas propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, pero tambin han presentado problemas en otros muchos. Otra aproximacin es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofa de las metodologas giles, las cuales dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Las metodologas giles estn revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologas tradicionales.

Desarrollo Agil de Software Se han venido descubriendo formas mejores para desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs este trabajo se ha aprendido a valorar: Individuos en interacciones sobre procesos y herramientas. La gente es el principal factor de xito de un proyecto software Software funcionando sobre documentacin extensiva. Aunque se parte de la base de que el software sin documentacin es un desastre, la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Colaboracin con el cliente sobre de negociacin contractual. Las caractersticas particulares del desarrollo de software hace que muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al inicio del mismo, segn los requisitos que el cliente manifestaba en ese momento. Respuesta ante el cambio sobre seguir un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo.

Principios Agiles Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros son generales y resumen gran parte del espritu gil. Son:

1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Un proceso es gil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender ms, a la vez que logran una mayor satisfaccin del cliente. Este principio implica adems que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste aadido. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad.

Luego existen una serie de principios que tienen que ver directamente con el proceso de desarrollo de software a seguir:
3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. Las entregas al cliente se insisten en que sean software, no planificaciones, ni documentacin de anlisis o de diseo. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interaccin con el equipo es muy frecuente. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal factor de xito, todo los dems (proceso, entorno, gestin, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, ste es el principal modo de comunicacin. Se pueden crear documentos pero no todo estar en ellos, no es lo que el equipo espera. 7. El software que funciona es la medida principal de progreso. El estado de un proyecto no viene dado por la documentacin generada o la fase en la que se encuentre, sino por el cdigo generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya estn en funcionamiento. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. No se trata de desarrollar lo ms rpido posible, sino de mantener el ritmo de desarrollo durante toda la duracin del proyecto, asegurando en todo momento que la calidad de lo producido es mxima.

Finalmente los ltimos principios estn ms directamente relacionados con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo.
9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. Producir cdigo claro y robusto es la clave para avanzar ms rpidamente en el proyecto. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. Producir cdigo claro y robusto es la clave para avanzar ms rpidamente en el proyecto. 10. La simplicidad es esencial. Tomar los caminos ms simples que sean consistentes con los objetivos perseguidos. Si el cdigo producido es simple y de alta calidad ser ms sencillo adaptarlo a los cambios que puedan surgir. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. Todo el equipo es informado de las responsabilidades y stas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan.

12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento. Puesto que el entorno est cambiando continuamente, el equipo tambin debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organizacin, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo gil.

Caractersticas del Software. Es inmaterial e invisible El comprador lo puede evaluar cuando ya ha sido construido. El Software se desarrolla, no se fabrica. Es complejo. Los sistemas actuales estn formados por miles de funciones con interfaces complejas entre ellas. Es excesivamente maleable. El Software se desarrolla, no se fabrica. En cualquier sistema de produccin podemos observar dos fases la de desarrollo y la de fabricacin. El desarrollo es lento y costoso. La fabricacin en serie y con costes estables.

Con el Software ocurre lo mismo pero... Muchas aplicaciones se desarrollan a medida, sin usar componentes existentes. La fabricacin no se considera tal. El software es excesivamente maleable. Todo el mundo exige que se realicen cambios sobre el Software como respuesta a pequeos cambios del entorno. Clasificaciones del software desde diversos puntos de vista: La utilizacin que se hace de l. El tratamiento comercial que tiene. En relacin con la funcionalidad que aporta a la maquina. Exigencia en eficiencia y los factores crticos que se le exigen.

Segn la utilizacin del software: De Gestin: Se trata del software que da soporte a los procesos comerciales y manejo de informacin que tienen por objetivo permitir a las gestiones una mejor gestin. Produccin y control de procesos: Es el software que da soporte a los procesos productivos y conducentes a desarrollar las actividades propias de cada negocio. Robtica: Software que se centra en controlar y automatizar el comportamiento de engendros mecnicos que colaboran con los seres humanos en diversos campos, desde la ortopedia hasta la exploracin de otros planetas.

De ingeniera y Cientfico: Da soporte a los procesos creativos y de diseo de las personas, se caracteriza por clculos matemticos complejos. Ejemplo de ello son las herramientas CAD o el soporte a seguimiento de acontecimientos en el espacio. Ofimtico: Software que permite a las personas utilizar los ordenadores en las tareas que habitualmente se realizan en oficinas. De Formacin y divulgacin: Software que tiene por objetivo el transferir conocimientos al ser humano. Domtico: Software que se utiliza para controlar el hbitat del ser humano, a pequea escala. Va desde las alarmas hasta el control de temperaturas de un hogar. Ocio y Juegos: En esta categora entran un gran conjunto de aplicaciones que tienen por objetivo el que el ser humano pase algo de tiempo disfrutando con los ordenadores. El desarrollo tradicional del software El desarrollo de software es una actividad problemtica, frecuentemente caracterizada por la frase "codifica y compilar".

Tradicionalmente los proyectos se dividen en etapas bien definidas: Anlisis de factibilidad. Anlisis de requerimientos. Diseo Programacin. Testeo.

Grafica. Muestra como el desarrollo tradicional a impactado en los costos y funcionalidad de los sistemas.

Costo de los Cambios en la Construccin de SW

En la siguiente figura se muestra el costo de producir cambios en el software que se desarrolla mediante una metodologa tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologas giles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construccin mediante una metodologa tradicional.

Los problemas y errores comunes de los mtodos no giles Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clsicos es una de las razones de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas veces, sus consecuencias se han hecho fciles de predecir. Y los errores rara vez producen los resultados que la gente espera. Personal Motivacin dbil. Empleados problemticos incontrolados. Aadir ms personal a un proyecto retrasado Oficinas repletas y ruidosas. Fricciones entre los clientes y los desarrolladores. Expectativas pocos realistas. Falta de un promotor efectivo del proyecto Falta de participacin de los implicados. Falta de participacin del usuario. Poltica antes que desarrollo.

Proceso Planificacin excesivamente optimista Gestin de riesgos insuficiente. Planificacin insuficiente. Abandono de planificacin bajo presin Prdida de tiempo en el inicio difuso Escatimar en las actividades iniciales. Diseo inadecuado Escatimar en el control de calidad Control insuficiente de la directiva

 Convergencia prematura o excesivamente frecuente Omitir tareas necesarias en la estimacin Planificar ponerse al da ms adelante Caractersticas del desarrollo gil. En los proyectos con desarrollo gil se busca que todos los esfuerzos se usen en la creacin de un mejor programa que satisfaga las necesidades del cliente. Esto significa que todos los que forman parte del equipo de trabajo se concentran nicamente en tareas y procesos que agregan valor al cliente del producto que se est realizando, mejorando o implementando. Adems los usuarios o clientes reciben peridicamente prototipos a medida que el producto se va construyendo, lo cual les permite: Evaluar el trabajo realizado. Advertir sobre problemas que se detecten. Sugerir mejoras

Distinguir entre tareas relevantes y las que no agregan valor se consigue a travs de la creacin de contextos con alto nivel de empowerment y feedback. Cuando es conveniente usar desarrollo gil ? En tareas incrementales: producto del proyecto Vamos a comparar la forma en que se planifica los proyectos con la forma en que se planifica los productos, intentando extraer algunas conclusiones tiles. Beneficios de usar desarrollo gil Las mejoras obtenidas por usar el mtodo de desarrollo gil dependen de la situacin. Pero hay algunas mejoras que tpicamente se tienen con el desarrollo gil: Desarrollo guiado por valor. Mejor manejo de riesgos e incertidumbre. Mejora de la productividad. Antes de resumir algunas metodologas giles, vamos a enumerar las principales diferencias respecto de las metodologas tradicionales (no giles). La siguiente tabla muestra esquemticamente estas diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo de software.

Metodologas giles de Desarrollo A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por y se dio a conocer en la comunidad de ingeniera de software con el nombre de Rapid Application Development.RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo como mencionaremos. Cabe mencionar que las metodologas giles no inventaron la nocin de los procesos iterativos e incrementales, los cuales eran usados desde dcadas pasadas inclusive en momentos en que el modelo en cascada era el estndar. Entre las metodologas giles ms destacadas hasta el momento podemos nombrar: XP Extreme Programming Scrum Crystal. DSDM Dynamic Systems Developmemt Method FDD Feature Driven Development ASD Adaptive Software Development Lean software development

Para el caso de Estudio de este documento nos enfocaremos en la metodologa DSDM Dynamic Sustems Development Method
Dynamic Systems Development Method (DSDM)

DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las mejores prcticas que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de implementar el mtodo. Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios: 1. El involucramiento del usuario es imperativo. 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco est puesto en la entrega frecuente de productos. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados a un alto nivel. 8. El testing es integrado a travs del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. DSDM define cinco fases en la construccin de un sistema. Las mismas son: 1. Estudio de factibilidad. 2. Estudio del negocio. 3. Iteracin del modelo funcional. 4. Iteracin del diseo y construccin. 5. Implantacin. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivel que deber contener el software. Posteriormente, se inician las iteraciones durante las cuales: se bajar a detalle los features identificados anteriormente, se realizar el diseo de los mismos, se construirn los componentes de software, y se implantar el sistema en produccin previa aceptacin del cliente.

DSDM tiene sus orgenes en 1994 y desde entonces se ha convertido en uno de los frameworks de desarrollo rpido de aplicaciones ms utilizados y conocidos. DSDM es un framework sin nimo de lucro y sin propietarios para el desarrollo rpido de aplicaciones, mantenido por el DSDM Consortium11. La idea fundamental de DSDM se basa en que en vez de fijar las funcionalidades de un producto y despus el tiempo y el coste, fijar primero el tiempo y el coste y con esto fijado, determinar las funcionalidades que se pueden implementar en el producto. DSDM est formado por las cinco siguientes fases: estudio de viabilidad, estudio de negocio, modelo funcional de las iteraciones, iteraciones de diseo y construccin e implementacin. Las dos primeras fases son secuenciales y se hacen solo una vez, mientras que las otras tres son iterativas e incrementales a lo largo de todo el proceso de desarrollo. DSDM trata las iteraciones como cajas de tiempo y estas duran un predeterminado periodo de tiempo, una vez finalizadas, las iteraciones tambin finalizan. El tiempo de duracin de una iteracin se decide de antes de iniciarla y normalmente va desde unos pocos das, hasta unas pocas semanas. Veamos con mayores detalles cada una de las fases de DSDM: Estudio de viabilidad. En esta fase se estudia la idoneidad de utilizar DSDM en el proyecto que nos ocupa y por tanto, se decide si utilizarlo o no. Otros aspectos que se tienen en cuenta en el estudio de viabilidad son las posibilidades tcnicas de llevar a cabo el proyecto y los riesgos presentes.

De esta fase se obtienen dos artefactos o productos de trabajo, son un reporte de viabilidad y un esbozo del plan de desarrollo del proyecto. A veces, si la tecnologa con la que tratamos es desconocida, se realizar un prototipo para conocerla mejor y ver sus posibilidades. De todos modos, esta fase no debe pasar de unas pocas semanas. Estudio de negocio. Esta es la fase en que las caractersticas principales del negocio y la tecnologa, son evaluados. La manera recomendada del levar a cabo esta fase es mediante la realizacin de talleres, donde participaran los clientes ms expertos en la materia, de tal manera que sean capaces de identificar todas las facetas fundamentales del sistema y acordar unas prioridades de desarrollo. Las procesos de negocio y las clases de usuario afectadas se describirn en la definicin del rea de negocio. Descripciones de alto nivel de los procesos de negocio se incluyen en la definicin del rea de negocio, ya sea usando diagramas ER12 u objetos del modelo de negocio. Otras artefactos que se generan en esta fase son una definicin de la arquitectura del sistema y un esbozo del plan de desarrollo del prototipo. Modelo funcional de las iteraciones. Es la primera de las fases iterativas e incrementales. En cada iteracin los contenidos y el enfoque son planificados, la iteracin continua y los resultados son analizados para mejorar las futuras iteraciones. Se realizan las tareas tanto de anlisis como de codificacin, se construyen prototipos, y las experiencias extradas de ellos son para mejorar los modelos de anlisis. Los prototipos no se descartan por completo, sino que a medida que su calidad va aumentando, se van incluyendo en el sistema final. Se genera un modelo funcional, el cual contiene el cdigo del prototipo y los modelos de anlisis. Otra tarea que se realiza en cada una de las iteraciones es la realizacin de pruebas. Otros artefactos que se generan en esta fase son una lista ordenada en funcin de la prioridad de las funciones que son entregadas al final de la iteracin y documentacin del prototipo funcional, que incluyen comentarios de los usuarios sobre la iteracin actual. Tambin se genera un listado con los requisitos no funcionales y un anlisis de los riegos que pueden surgir a lo largo del desarrollo Iteraciones de diseo y construccin. Estas son las fases en las que principalmente se construye el sistema. El resultado final es un sistema probado, que como al menos satisface los mnimos requisitos establecidos. Esta fase es iterativa e incremental y el diseo y los prototipos funcionales son revisados por los clientes, ocasionando los cambios que sean necesarios en el sistema con sus aportaciones y comentarios. Implementacin. En esta fase se pasa del entorno de desarrollo al entorno de produccin. Se da formacin a los usuarios y finalmente se abre el sistema para que lo utilicen. En esta fase, adems de la liberacin del sistema, tambin se deben entregar un manual de usuario y un informe de revisin del proyecto. En este ltimo entregable, se especifican los futuros desarrollos necesarios, si es que los hay. DSDM define cuatro posibles situaciones una vez en este punto, la primera es que no se necesite realizar mayor desarrollo, la segunda es que se hayan dejado sin realizar un conjunto de requisitos importantes y en este caso se tiene que reiniciar todo el proceso desde el principio. La tercera es que hayan quedado algunas funcionalidades o crticas sin implementar, entonces se vuelve a la fase de modelo funcional de iteraciones. La ltima situacin es que algunos problemas tcnicos no han podido ser resueltos debido a falta de tiempo, ahora se corregirn realizando las iteraciones que hagan falta desde la fase de diseo e implementacin. Fases en la construccin de un sistema Descontando la primera fase que es realizada una nica vez al principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las caractersticas del modelo iterativo e incremental ya tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son

los principios alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en el feedback con el cliente, en las entregas frecuentes de productos. Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr responder las siguientes preguntas: Ser la funcionalidad razonablemente visible en la interfase del usuario? Se pueden identificar todas las clases de usuarios finales? Es la aplicacin computacionalmente compleja? Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en componentes funcionales ms pequeos? Est el proyecto realmente acotado en el tiempo? Son los requerimientos flexibles y slo especificados a un alto nivel? Las mismas refieren a las caractersticas que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes caractersticas que refieren a la aplicabilidad de DSDM: Son proyectos interactivos con la funcionalidad visible en la interfase de usuario. De baja o media complejidad computacional. Particionables en componentes de funcionalidad ms pequeos si la aplicacines de gran tamao. Acotados en el tiempo. Con flexibilidad en los requerimientos. Con un grupo de usuarios bien definidos y comprometidos al proyecto.

De esta forma observamos que DSDM deja las bases sentadas para el anlisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico, funciona tanto para el modelo de orientacin a objetos como para el modelo estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de modelos necesarios para la sana progresin de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su contenido. El concepto de timebox es algo que est embebido en DSDM y en todas las metodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo. La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a los stakeholders para que verifiquen el progreso y puedan tomar acciones correctivas a tiempo. Tambin permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox est compuesta por actividades definidas en relacin a entregables en vez de tareas. Cada entregable generado durante el mismo es testeado/revisado dentro del mismo timebox. En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento y Consolidacin. Durante la Investigacin se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carcter exploratorio, en la que se fijan los objetivos de la iteracin, los entregables a ser producidos, efectundose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la produccin propiamente dicha de los artefactos planificados. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos. Finalmente, la fase de Consolidacin consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalizacin del timebox se demostrar que se satisficieron los requerimientos de calidad definidos durante la Investigacin. DSDM incluye roles claves en relacin al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldra al on-site customer de

XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador tcnico que es la persona encargada de mantener la arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estndares tcnicos. Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realizacin de prototipos para descifrar aquellas ambigedades que se presentan en el relevamiento y tambin para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacin deseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseo. En resumen, encontramos en DSDM una metodologa gil creada en el Reino Unido a partir de un consorcio con participacin de empresas de primera lnea. El mismo contiene las caractersticas principales de las metodologas giles y contiene prcticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptacin en la industria y su refinamiento continuo lo que indica que las metodologas giles no son solo dominio de pequeos grupos de desarrollo sino que estn siendo adoptadas por pesos pesados en las industrias. Roles y responsabilidades. DSDM especfica hasta quince roles diferentes entre usuarios y desarrolladores, a continuacin listamos los ms relevantes: Desarrolladores y desarrolladores senior. Son los nicos roles que establece a nivel de desarrollo y cubren todos los posibles papeles de las tareas de desarrollo como son el anlisis, diseo, implementacin e incluso pruebas. Coordinador tcnico. Es el responsable de la calidad tcnica del proyecto y define la arquitectura del sistema. El usuario embajador. Sus principales tareas son las de aportar el conocimiento de la comunidad de usuarios al proyecto y de informar a los usuarios de los progresos del proyecto. El asesor de los usuarios. Puede ser cualquier usuario que represente un importante punto de vista para el proyecto. Por ejemplo un miembro del departamento de IT o un auditor financiero, etc. Visionario. Es un usuario que participa del proyecto y que tiene una percepcin ms real de los objetivos de negocio del sistema y del proyecto. Normalmente suele ser el valedor del proyecto y el que tuvo la idea inicial para realizarlo. Entre sus tareas se encuentra supervisar que se identifican todos los requisitos de negocio y que se van implementando en el orden de importancia correcto. Sponsor ejecutivo. Es la persona de la compaa que tiene la autoridad financiera y la responsabilidad. Por ende, el sponsor ejecutivo es el que suele tener la ltima palabra en la toma de decisiones.

Prcticas. Existen nueve prcticas que definen la ideologa y las bases de toda actividad en DSDM, en la tabla mostramos estas nueve prcticas o principios de DSDM

Adopcin y experiencias. DSDM ha sido ampliamente utilizado en Reino Unido desde mediados de los aos 90. Stapleton [24] ha documentado hasta ocho casos de aplicacin prctica de DSDM, demostrando que DSDM es una alternativa viable para el desarrollo rpido de aplicaciones. Con tal de facilitar la adopcin de DSDM, el DSDM Consortium public un mtodo que indica la idoneidad de aplicar DSDM a tu proyecto. Entorno de uso. El tamao de los equipos en DSDM vara desde un mnimo de dos integrantes hasta seis, pudiendo coexistir mltiples equipos en un mismo proyecto. La razn de que como mnimo haya dos componentes por equipo radica en que como mnimo deben haber un desarrollador y un cliente. El nmero mximo ha sido extrado de diferentes experiencias con las metodologas. DSDM se puede aplicar tanto a proyectos grandes como pequeos, siempre que los sistemas grandes sean divisibles en componentes que puedan ser desarrollados por equipos pequeos. Stapleton [24] sugiere la utilizacin de DSDM en aplicaciones empresariales antes que en aplicaciones cientficas Estudios actuales. DSDM fue originalmente creada por un consorcio y actualmente sigue gestionada y mantenida por el mismo, el cual est compuesto por diferentes compaas. Si quieres poder acceder a la informacin que este consorcio te proporciona, sus manuales, white papers, avances, etc, es necesario que pagues un cuota de asociado.

Comparativas

Estado actual metodologa. Los criterios para la seleccin de cada una de los estados de las metodologas estn fundamentados en la caracterizacin que hemos realizado de las metodologas De tal manera que una metodologa en estado de: Recin nacida. Es aquella metodologa que tiene un ao o menos y de la cual no tenemos evidencias empricas, ni estudios. En construccin. Aquellas metodologas con ms de una ao de existencia, pero que no disponen de experiencias documentadas ni/o estudios. Activa. Son aquellas metodologas que llevan varios en el desarrollo del software y de las cuales podemos encontrar experiencias y estudios que corroboren su ratio efectividad. Olvidada. Aquellas metodologas que llevan el suficiente tiempo sin ser utilizadas y de las cuales no se encuentran experiencias actuales, ni estudios.

Metodologa

Explicacin

Estado 7/08

Calidad. En la tabla podemos observar la metodologa gil del estudio, para cada una de las cuales indicamos de que maneras tratan la calidad de su producto, si es que lo hacen. Metodologa Calidad de la Metodologia

Herramientas. En la tabla mostramos los principales grupos de herramientas especficos requeridos por la metodologa. No consideramos herramientas tan esenciales para el desarrollo del software como puede ser un IDE2 (Eclipse, NetBeans,...) , herramientas ofimticas (Word, Excel, kate, OpenOffice, ...). Metodologa Herramienta especifica

La Tabla, compara las distintas aproximaciones giles en base a tres parmetros: vista del sistema como algo cambiante, tener en cuenta la colaboracin entre los miembros del equipo y caractersticas ms especficas de la propia metodologa como son simplicidad, excelencia tcnica, resultados, adaptabilidad, etc. Tambin incorpora como referencia no gil el Capability Madurity Model10 (CMM). CMM ASD Crystal DSDM FDD LD Scrum XP

Sistema como cambiante Colaboracin Caractersticas Metodologa (CM) -Resultados -Simplicidad -Adaptabilidad -Excelencia tcnica -Prcticas colaboracin Media CM Media Total

algo

1 2

5 5

4 5

3 4

3 4

4 4

5 5

5 5

2 1 2 4 de 2 2.2 1.7

5 4 5 3 5 4.4 4.8

5 4 5 3 5 4.4 4.5

4 3 3 4 4 3.6 3.6

4 5 3 4 3 3.8 3.6

4 3 4 4 3 3.6 3.9

5 5 4 3 4 4.2 4.7

5 5 3 4 5 4.4 4.8

Tabla 1. Ranking de agilidad (Los valores ms altos representan una mayor agilidad) Como se observa en la Tabla, todas las metodologas giles tienen una significativa diferencia del ndice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP como las ms giles.