DYNAMIC SYSTEMS DEVELOPMENT METHOD

Índice

IntroducciónEl desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo.

Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos.

Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas.

Las metodologías ágiles están 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 metodologías tradicionales.

Desarrollo Agil de SoftwareSe han venido descubriendo formas mejores para desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través 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 documentación extensiva. Aunque se parte de la base de que el software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”.

Colaboración con el cliente sobre de negociación contractual. Las características particulares del desarrollo de software hace que muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al inicio del mismo, según 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 tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo.

Principios AgilesLos valores anteriores inspiran los doce principios del manifiesto. Estos principios son las características que diferencian un proceso ágil de uno tradicional. Los dos primeros son generales y resumen gran parte del espíritu á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 más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. 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 documentación de análisis o de diseño.

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 interacción 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 demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado.

6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. 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 documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento.

8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima.

Finalmente los últimos principios están más directamente relacionados con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo.

9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto.

10. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir.

11. Las mejores arquitecturas, requisitos y diseños 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 cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil.

Características 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 están formados por miles de

funciones con interfaces complejas entre ellas. Es excesivamente maleable.

El Software se desarrolla, no se fabrica.

En cualquier sistema de producción podemos observar dos fases la de desarrollo y la de fabricación.

El desarrollo es lento y costoso. La fabricación en serie y con costes estables.

Con el Software ocurre lo mismo pero...

Muchas aplicaciones se desarrollan a medida, sin usar componentes existentes.

La fabricación no se considera tal.

El software es excesivamente maleable.

Todo el mundo exige que se realicen cambios sobre el Software como respuesta a pequeños cambios del entorno.

Clasificaciones del software desde diversos puntos de vista:

La utilización que se hace de él. El tratamiento comercial que tiene. En relación con la funcionalidad que aporta a la maquina. Exigencia en eficiencia y los factores críticos que se le exigen.

Según la utilización del software:

De Gestión: Se trata del software que da soporte a los procesos comerciales y manejo de información que tienen por objetivo permitir a las gestiones una mejor gestión.

Producción y control de procesos: Es el software que da soporte a los procesos productivos y conducentes a desarrollar las actividades propias de cada negocio.

Robótica: Software que se centra en controlar y automatizar el comportamiento de engendros mecánicos que colaboran con los seres humanos en diversos campos, desde la ortopedia hasta la exploración de otros planetas.

De ingeniería y Científico: Da soporte a los procesos creativos y de diseño de las personas, se caracteriza por cálculos matemáticos complejos. Ejemplo de ello son las herramientas CAD o el soporte a seguimiento de acontecimientos en el espacio.

Ofimático: Software que permite a las personas utilizar los ordenadores en las tareas que habitualmente se realizan en oficinas.

De Formación y divulgación: Software que tiene por objetivo el transferir conocimientos al ser humano.

Domótico: Software que se utiliza para controlar el hábitat del ser humano, a pequeña escala. Va desde las alarmas hasta el control de temperaturas de un hogar.

Ocio y Juegos: En esta categoría 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 softwareEl desarrollo de software es una actividad problemática, frecuentemente caracterizada por la frase "codifica y compilar".

Tradicionalmente los proyectos se dividen en etapas bien definidas:

Análisis de factibilidad. Análisis de requerimientos. Diseño Programación. Testeo.

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

Costo de los Cambios en la Construcción de SW

En la siguiente figura se muestra el costo de producir cambios en el software que se desarrolla mediante una metodología tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologías ágiles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construcción mediante una metodología tradicional.

Los problemas y errores comunes de los métodos no ÁgilesLos desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clásicos 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 fáciles de predecir. Y los errores rara vez producen los resultados que la gente espera.

Personal Motivación débil. Empleados problemáticos incontrolados. Añadir más 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 participación de los implicados. Falta de participación del usuario. Política antes que desarrollo.

Proceso Planificación excesivamente optimista Gestión de riesgos insuficiente. Planificación insuficiente. Abandono de planificación bajo presión

Pérdida de tiempo en el inicio difuso Escatimar en las actividades iniciales. Diseño inadecuado Escatimar en el control de calidad Control insuficiente de la directiva Convergencia prematura o excesivamente frecuente Omitir tareas necesarias en la estimación Planificar ponerse al día más adelante

Características del desarrollo ágil.En los proyectos con desarrollo ágil se busca que todos los esfuerzos se usen en la creación 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. Además los usuarios o clientes reciben periódicamente 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 través de la creación de contextos con alto nivel de empowerment y feedback.

Cuando es conveniente usar desarrollo ágil ?En tareas incrementales: producto del proyectoVamos 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 ágilLas mejoras obtenidas por usar el método de desarrollo ágil dependen de la situación.

Pero hay algunas mejoras que típicamente se tienen con el desarrollo ágil: Desarrollo guiado por valor. Mejor manejo de riesgos e incertidumbre. Mejora de la productividad.

Antes de resumir algunas metodologías ágiles, vamos a enumerar las principales diferencias respecto de las metodologías tradicionales (“no ágiles”). La siguiente tabla muestra esquemáticamente estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.

Metodologías Ágiles de DesarrolloA principios de la década 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 ingeniería de software con el nombre de Rapid Application Development.RAD consistía en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de programadores utilizando herramientas que generaban código en forma automática 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 metodologías ágiles no inventaron la noción de los procesos iterativos e incrementales, los cuales eran usados desde décadas pasadas inclusive en momentos en que el modelo en cascada era el estándar.

Entre las metodologías ágiles más 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 metodología DSDM – Dynamic Sustems Development Method

Dynamic Systems Development Method (DSDM)DSDM es la única de las metodologías aquí planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo delConsorcio era producir una metodología de dominio público que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las mejores prácticas que se conocían en la industria y la experiencia traída por sus fundadores, liberó la primera versión de DSDM a principios de 1995. A partir de ese momento el método fue bien acogido por la industria, que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM. Debido a este éxito, el Consorcio comisionó al Presidente del Comité Técnico, Jennifer Stapleton, la creación de un libro que explorara la realidad de implementar el método.

Dado el enfoque hacia proyectos de características RAD esta metodología encuadra perfectamente en el movimiento de metodologías ágiles. La estructura del método 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 propósitos del negocio es el criterio esencial para la aceptación de los entregables.5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio.6. Todos los cambios durante el desarrollo son reversibles.7. Los requerimientos están especificados a un alto nivel.8. El testing es integrado a través del ciclo de vida.9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

DSDM define cinco fases en la construcción de un sistema. Las mismas son:

1. Estudio de factibilidad.2. Estudio del negocio.3. Iteración del modelo funcional.4. Iteración del diseño y construcción.5. Implantación.

El estudio de factibilidad es una pequeña fase que propone DSDM para determinar si la metodología se ajusta al proyecto en cuestión. 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 diseño de los mismos, se construirán los componentes de software, y se implantará el sistema en producción previa aceptación del cliente.

DSDM tiene sus orígenes en 1994 y desde entonces se ha convertido en uno de los frameworks de desarrollo rápido de aplicaciones más utilizados y conocidos. DSDM es un framework sin ánimo de lucro y sin propietarios para el desarrollo rápido 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 después 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 diseño y construcción e implementación.

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 también

finalizan. El tiempo de duración de una iteración se decide de antes de iniciarla y normalmente va desde unos pocos días, 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 técnicas 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 tecnología 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 características principales del negocio y la tecnología, son evaluados. La manera recomendada del levar a cabo esta fase es mediante la realización de talleres, donde participaran los clientes más 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 describirán en la definición del área de negocio. Descripciones de alto nivel de los procesos de negocio se incluyen en la definición 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 definición 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 iteración los contenidos y el enfoque son planificados, la iteración continua y los resultados son analizados para mejorar las futuras iteraciones. Se realizan las tareas tanto de análisis como de codificación, se construyen prototipos, y las experiencias extraídas de ellos son para mejorar los modelos de análisis. 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 código del prototipo y los modelos de análisis. Otra tarea que se realiza en cada una de las iteraciones es la realización de pruebas. Otros artefactos que se generan en esta fase son una lista ordenada en función de la prioridad de las funciones que son entregadas al final de la iteración y documentación del prototipo funcional, que incluyen comentarios de los usuarios sobre la iteración actual. También se genera un listado con los requisitos no funcionales y un análisis de los riegos que pueden surgir a lo largo del desarrollo

Iteraciones de diseño y construcción.

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 mínimos requisitos establecidos. Esta fase es iterativa e incremental y el diseño y los prototipos funcionales son revisados por los clientes, ocasionando los cambios que sean necesarios en el sistema con sus aportaciones y comentarios.

Implementación.

En esta fase se pasa del entorno de desarrollo al entorno de producción. Se da formación a los usuarios y finalmente se abre el sistema para que lo utilicen. En esta fase, además de la liberación del sistema, también se deben entregar un manual de usuario y un informe de revisión 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 críticas sin implementar, entonces se vuelve a la fase de modelo funcional de iteraciones. La última situación es que algunos problemas técnicos no han podido ser resueltos debido a falta de tiempo, ahora se corregirán realizando las iteraciones que hagan falta desde la fase de diseño e implementación.

Fases en la construcción 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 demás fases presentan las características 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 cuestión 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 aplicación computacionalmente compleja?¿Es la aplicación potencialmente grande? Si lo es, ¿puede ser particionada en componentes funcionales más pequeños?¿Está el proyecto realmente acotado en el tiempo?¿Son los requerimientos flexibles y sólo especificados a un alto nivel?

Las mismas refieren a las características que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construcción. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas

preguntas tendrán las siguientes características 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 más pequeños si la

aplicaciónes de gran tamaño. 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 análisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodología no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma específico, funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. Algo que sí sugiere el método es la generación de un conjunto mínimo de modelos necesarios para la sana progresión de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales deberán ser definidos antes que comience el desarrollo, y deberán 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 metodologías ágiles, en las cuales también se conocen como iteración, 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. También permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo más precisas. Asimismo, cada timebox está compuesta por actividades definidas en relación 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: Investigación, Refinamiento y Consolidación. Durante la Investigación se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carácter exploratorio, en la que se fijan los objetivos de la iteración, los entregables a ser producidos, efectuándose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la producción 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 Consolidación consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalización del timebox se demostrará que se satisficieron los requerimientos

de calidad definidos durante la Investigación. DSDM incluye roles claves en relación al management del proyecto.Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer deXP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico 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 estándares técnicos.

Algunas técnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realización de prototipos para descifrar aquellas ambigüedades que se presentan en el relevamiento y también para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilización de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicación deseada. El énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseño.

En resumen, encontramos en DSDM una metodología ágil creada en el Reino Unido a partir de un consorcio con participación de empresas de primera línea. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptación en la industria y su refinamiento continuo lo que indica que las metodologías ágiles no son solo dominio de pequeños grupos de desarrollo sino que están siendo adoptadas por “pesos pesados” en las industrias.

Roles y responsabilidades.DSDM específica hasta quince roles diferentes entre usuarios y desarrolladores, a continuación listamos los más 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 análisis, diseño, implementación e incluso pruebas.

Coordinador técnico. Es el responsable de la calidad técnica 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 percepción más 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 compañía 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.

Prácticas.Existen nueve prácticas que definen la ideología y las bases de toda actividad en DSDM, en la tabla mostramos estas nueve prácticas o principios de DSDM

Adopción y experiencias.DSDM ha sido ampliamente utilizado en Reino Unido desde mediados de los años 90. Stapleton [24] ha documentado hasta ocho casos de aplicación práctica de DSDM, demostrando que DSDM es una alternativa viable para el desarrollo rápido de aplicaciones. Con tal de facilitar la adopción de DSDM, el DSDM Consortium publicó un método que indica la idoneidad de aplicar DSDM a tu proyecto.

Entorno de uso.El tamaño de los equipos en DSDM varía desde un mínimo de dos integrantes hasta seis, pudiendo coexistir múltiples equipos en un mismo proyecto. La razón de que como mínimo haya dos componentes por equipo radica en que como mínimo deben haber un desarrollador y un cliente. El número máximo ha sido extraído de diferentes experiencias con las metodologías. DSDM se puede aplicar tanto a proyectos grandes como pequeños, siempre que los sistemas grandes sean divisibles en componentes que puedan ser desarrollados por equipos pequeños. Stapleton [24] sugiere la utilización de DSDM en aplicaciones empresariales antes que en aplicaciones científicas

Estudios actuales.DSDM fue originalmente creada por un consorcio y actualmente sigue gestionada y mantenida por el mismo, el cual está compuesto por diferentes compañías. Si quieres poder acceder a la información que este consorcio te proporciona, sus manuales, white papers, avances, etc, es necesario que pagues un cuota de asociado.

Comparativas

Estado actual metodología.Los criterios para la selección de cada una de los estados de las metodologías están fundamentados en la caracterización que hemos realizado de las metodologías De tal manera que una metodología en estado de:

Recién nacida. Es aquella metodología que tiene un año o menos y de la cual no tenemos evidencias empíricas, ni estudios.

En construcción. Aquellas metodologías con más de una año de existencia, pero que no disponen de experiencias documentadas ni/o estudios.

Activa. Son aquellas metodologías que llevan varios en el desarrollo del software y de las cuales podemos encontrar experiencias y estudios que corroboren su ratio efectividad.

Olvidada. Aquellas metodologías que llevan el suficiente tiempo sin ser utilizadas y de las cuales no se encuentran experiencias actuales, ni estudios.

Metodología Explicación Estado 7/08

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

Metodología Calidad de la Metodologia

Herramientas.En la tabla mostramos los principales grupos de herramientas específicos requeridos por la metodología. No consideramos herramientas tan esenciales para el desarrollo del software como puede ser un IDE2 (Eclipse, NetBeans,...) , herramientas ofimáticas (Word, Excel, kate, OpenOffice, ...).

Metodología Herramienta especifica

La Tabla, compara las distintas aproximaciones ágiles en base a tres parámetros: vista del sistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo y características más específicas de la propia metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc. También incorpora como referencia no ágil el Capability Madurity Model10 (CMM).

CMM ASDCrystal

DSDM FDD LDScrum

XP

Sistema como algo cambiante

1 5 4 3 3 4 5 5

Colaboración 2 5 5 4 4 4 5 5

Características Metodología

(CM)

-Resultados 2 5 5 4 4 4 5 5

-Simplicidad 1 4 4 3 5 3 5 5

-Adaptabilidad 2 5 5 3 3 4 4 3

-Excelencia técnica

4 3 3 4 4 4 3 4

-Prácticas de colaboración

2 5 5 4 3 3 4 5

Media CM 2.2 4.4 4.4 3.6 3.8 3.6 4.2 4.4

Media Total 1.7 4.8 4.5 3.6 3.6 3.9 4.7 4.8

Tabla 1. Ranking de “agilidad” (Los valores más altos representan una mayor agilidad)

Como se observa en la Tabla, todas las metodologías ágiles tienen una significativa diferencia del índice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP como las más ágiles.