Dynamic Systems Development Method

1. Introducción
Las metodologías de hoy buscan la manera de poder guiar a las personas en el
desarrollo de aplicaciones, llevando cada día un sin fin de investigaciones que apunten a
un mejor desempeño de estas prácticas y así crear nuevas metodologías. Dynamic System
Development Method (Método de desarrollo de Sistemas Dinámico) es un framework que
se encarga de dar los conocimientos acerca de la gestión del proyecto. En 1995 DSDM
consortium liderado por Tony Mobbs, Jennifer Stapleton, Gary Hodsdon, Paul Herzlich y
Peter Constable, publicó la 1ª versión de DSDM. Desde entonces a la fecha han mejorado
mucho gracias al énfasis que se puso en obtener feedback de los usuarios. Versión actual es la 4.1
y es el método más usado en el Reino Unido y va extendiéndose por Europa y Estados Unidos
DSDM está arraigado en el desarrollo de software en comunidad, pero la
convergencia del software, la Ingeniería de procesos y el desarrollo de procesos de
negocios ha cambiado el framework DSDM para convertirse en un framework general
para resolver tareas complejas.

2. Principios
El DSDM puede ser implementado para un proceso de desarrollo ágil y tradicional.
Para mostrar como DSDM se relaciona con la metodología ágil es necesario entender
como los principios de DSDM se relacionan con el desarrollo ágil de procesos de valores.
Los 9 Principios.
Los siguientes 9 principios son necesarios para cualquier implementación de DSDM, si se
ignora uno de ellos se quebraría la filosofía del framework y aumentaría
significativamente el riesgo del proyecto.
1. La implicación del usuario activo es de gran importancia.
Este principio es considerado el más importante, porque la involucración del
usuario a lo largo del proyecto efectivamente reduce los errores en términos de
percepción del usuario, y por lo tanto reduce costos por error. En vez de trabajar
con muchos usuarios DSDM recomienda trabajar con un número limitado de ellos.
2. Los equipos deben estar facultados para tomar decisiones.
Para proceder lo más rápido posible y evitar solicitar la autorización de incluso
escasos recursos, o el simple cambio de un requisito ralentizará un proyecto de
manera significativa. El no poder hacer frente a estas ineficiencias por parte de los
usuarios y otros participantes de DSDM debido a la autoridad limitada para tomar
decisiones relacionadas con:
• Requisitos en la Práctica.
• Qué funcionalidad debe estar en un determinado incremento.
• Priorización de las necesidades y características.
• Afinar detalles de la solución técnica.
3. Centrarse en las entregas frecuentes
Entregas frecuentes de los resultados garantizan que los errores se detectan
rápidamente, se revierten fácilmente y se soluciona el error. Esto es bueno tanto
2

3. para el código del programa, así como para los documentos como los requisitos o
los modelos de datos.
4. Saludable para el negocio es el criterio de aceptación de los entregables
DSDM no promueve a escribir ad-hoc el software, pero sugieren satisfacer las
necesidades del negocio en primer lugar, y para adquirir timeboxes de
refactorización y actividades conexas en una iteración más tarde. Incluso en un
proyecto DSDM es fundamental para identificar las cuestiones claves, se requiere
un diseño robusto. Los métodos ágiles
de hecho requieren una buena comprensión de los patrones y la arquitectura.
5. El desarrollo es Iterativo e Incremental
A fin de mantener la complejidad del proyecto manejable, este debe ser
descompuesto en paquetes pequeños, con cada nueva versión añade nuevas
características hasta completar el conjunto de requisitos del negocio. Este principio
exige aceptar el hecho de
de que cualquier sistema de software está sujeto a cambios. Este principio puede
ser fácilmente introducido incluso en el comienzo de un proyecto ya que las
especificaciones y otros resultados se pueden ir produciendo de manera
sistemática también. Cuanto menor es el incremento más fácil será una respuesta
a las necesidades.
6. Todos los cambios realizados en el desarrollo son reversibles
Ser sensible a los cambios que requieren configuraciones de sistemas que están
cambiando durante el desarrollo de cualquier incremento debido a las prioridades
de cambio en los requisitos. Las herramientas de software actuales son
compatibles con una configuración dinámica de los proyectos que requieren este
principio. A menudo se teme que la inversión de un proceso de desarrollo dará
lugar a perder el trabajo previo pero desde el punto de vista de DSDM la pérdida
total de trabajo es muy limitada.
3

4. 7. Los requisitos se establecen a nivel general
Para limitar el grado de libertad en que los requisitos pueden ser alterados durante
el proceso de desarrollo, algunos requisitos de alto nivel deben ser establecidos.
Esta línea de base que ha de ser interpretado como un requisito "congelado" es
acordada en la fase de estudio del proceso de negocio.
8. Las pruebas forman parte del ciclo de Desarrollo
Muchos se preguntan el desarrollo de métodos para la prueba tan tarde como el
diseño o la fase de ejecución. DSDM requiere la prueba temprana del proceso de
desarrollo. Incluso los documentos testing interview por una comprobación
cruzada de ellos con un grupo de control, o técnicas similares.
9. Trabajar con espíritu de colaboración con todos los agentes implicados en el
sistema que se desarrolla.
Evitar la separación y el fomento de la colaboración de personal técnico y de
negocio en un proyecto es obligatorio en los proyectos de DSDM, porque la
cooperación es crucial para tener éxito en un proyecto de DSDM. Sin un clima de
confianza y honestidad que será difícil reunir los requisitos, y más tarde obtener
retroalimentación honesta de los productos resultantes.
REQUISITOS PREVIOS PARA EL USO DE DSDM.
Para el éxito del desarrollo se deberá tener interactividad entre los usuarios y los jefes de
Desarrollo. Otra de las cosas con las que se debe tomar en cuenta es la motivación y
participación entre las partes (humanas) que integran el equipo. La falta de uno de estos
requisitos puede causar el fracaso del proyecto ya que si no hay comunicación o
4

5. discrepancias entre las partes no podrán intercambiarse ideas o funcionalidades
necesarias para entregar un proyecto de calidad.
DIAGRAMA DEL CICLO DE VIDA DEL PROYECTO
La manera en que el proyecto presenta sus datos de la aplicación se basa en el siguiente
diagrama, este muestra características de este método como lo es la forma iterativa de
desarrollar el proyecto.
El siguiente diagrama muestra de manera clara que este método utiliza como base
modelos similares como por ejemplo prototipos para poder realizar tomas de
requerimientos.
FASES DEL DSDM
5

6. FASE 1: PRE-PROYECTO
En esta fase se identifican los proyectos propuestos, quien financiara el proyecto,
compromiso por parte de los equipos, usuarios y clientes.
OBJETIVO: Evitar Problemas en etapas siguientes.
FASE 2: CICLO DE VIDA DEL PROYECTO
Para crear un sistema de información esta fase se representa en 5 etapas las cuales se
describirán a continuación. Las etapas muestran en términos generales la
retroalimentación que necesita cada etapa como consecuencia de la anterior. Para
entender mejor eso se describirán cada una de las etapas que corresponden al ciclo de
vida del Proyecto.
ETAPAS DEL CICLO DE VIDA DEL PROYECTO
ETAPA 1: ESTUDIO DE VIABILIDAD.
Se examinan requisitos previos, en esta etapa se suelen hacer preguntas como las
siguientes: ¿El proyecto satisface la demanda del negocio?, ¿Se puede ajustar el proyecto
a este método?, ¿Qué riesgos implica la elaboración de este proyecto?
OBJETIVO: Utilizar el método de prototipo para poder realizar tomas de requerimientos e
identificación de riesgos.
ETAPA 2: ESTUDIO DEL NEGOCIO
Esta etapa se realiza únicamente si se ha identificado que el proyecto es viable utilizando
este método.
Aquí en esta etapa se determina como trabaja la empresa, que espera la empresa de
nuestro trabajo, saber si los clientes saben que quieren o no, hay participación de los
usuarios.
OBJETIVO: utilizar técnicas que faciliten y aseguren un proyecto de calidad, timeboxing es
una de las técnicas esencial para determinar tiempo, presupuesto y garantía deseada.
6

7. ETAPA 3: ITERACION DE MODELADO FUNCIONAL
Para realizar esta etapa nos valemos de recursos como el modelo de prototipos, este
modelo forma una parte clave en esta etapa. Una parte importante de esta etapa es que
aquí se realizan las pruebas, que determinan el grado de calidad y efectividad del
proyecto.
OBJETIVO: Realizar un modelado y un prototipo funcional que representen
unificadamente todas las funciones que puede hacer la iteración en la que nos
encontremos trabajando.
ETAPA 4: ITERACION DE DISEÑO Y DESARROLLO.
La construcción del diseño consiste en integrar los componentes realizados en las etapas
anteriores en un solo sistema que satisfaga las necesidades de los usuarios.
OBJETIVO: Entregar a los usuarios un prototipo durante la fase de prueba y final del diseño
de construcción, para que pueda ser aprobado y entregado para la siguiente fase.
ETAPA 5: APLICACIÓN
Se le entrega una versión de prueba al usuario incluyendo la documentación. Esta versión
entregada debe incluir los requerimientos que se han establecido en las etapas iníciales.
OBJETIVO: Entregar una versión del sistema, capacitación de Usuarios y Evaluar
detalladamente los documentos del Sistema.
FASE 3: POST – PROYECTO
7

8. Asegurarse que el sistema operativo acepte de manera eficaz y segura el proyecto. Esta
fase se realiza por mejoras, mantenimiento y correcciones de acuerdo con los principios
del DSDM.
TECNICAS BASICAS DE DSDM
En esta parte recordamos cuando estábamos en la etapa 2 acerca del estudio del negocio,
ya que estas técnicas son implementadas en esta etapa.
Las técnicas vistas en esta investigación son las siguientes:
TIMEBOXING:
Se utiliza para apoyar los objetivos principales del DSDM para realizar un desarrollo de
software en tiempo, costo y calidad deseada. La idea de esta técnica es dividir en partes
cada una con presupuesto y fecha fija de entrega. Cada parte de los requisitos que se
seleccionan son priorizados de acuerdo con el principio MOSCOW. Las únicas variables son
los requisitos.
MOSCOW:
Representa una forma de priorizar los temas, se deben priorizar las necesidades.
Esta es una sigla que significa:
MUST (DEBE) tener este requisito para satisfacer necesidades del negocio.
SHOULD (DEBERÍA) tener este requisito, pero el proyecto no depende de ello.
COULD (PODRIAN) tener este requisito sin que afecte las condiciones del sistema.
WOULD (SE) tiene este requisito en una fecha posterior.
PROTOTIPOS:
Permite descubrir de manera previa deficiencias del sistema.
EXAMENES:
Es una técnica independiente para poder medir el logro de cada iteración.
8

9. TALLER:
Consiste en llevar a las partes interesadas a discutir necesidades, funcionalidades, y
comprensión mutua.
SITUACIONES NO APLICABLES PARA DSDM
FACTOR 1:
Cuando no existe aceptación por parte de la dirección y otros empleados. Falta de
motivación y participación del equipo.
FACTOR 2:
Se deriva del factor 1 y consiste en la falta de motivación y participación impide la buena
gestión de ideas y funcionalidades.
FACTOR 3:
Poca habilidad por parte de los integrantes del equipo. También se pueden incluir las
faltas de herramientas.
FACTOR 4:
Si no hay apoyo entre cliente y proveedor.
EJEMPLOS DE APLICACIÓN EXITOSOS
• Utilizado en todo el mundo, desde British Airways hasta el gobierno del Reino Unido.
• Fujitsu aplicó DSDM para renovar su sistema, en siete meses pasó de atender 500
unidades mensuales a 4.000.
COMPARACIONES
9

10. XP vs DSDM
DSDM y XP pueden ser complementarios. Los principios fundamentales de DSDM son muy
parecidos a los de XP.
En XP la gestión del proyecto no está muy clara y en DSDM son las técnicas de
programación las que no se especifican.
Combinándolos obtenemos un proceso tan ágil como XP pero más escalable gracias a
DSDM.
RUP vs DSDM
RUP podría considerarse una implementación de DSDM.
RUP está más orientado a la arquitectura y a la calidad, DSDM tiene como objetivo el
desarrollo rápido de aplicaciones.
Se pueden relacionar todas las fases y artefactos de RUP con los de DSDM.
CONCLUSIONES
DSDM es un framework en el que pueden entrar una gran variedad de
metodologías.
DSDM busca la combinación eficiente del conocimiento de las personas y técnicas
para realizar proyectos rápidamente.
DSDM combina el punto de vista de las metodologías ágiles con una especificación
más rigurosa de la gestión del proyecto.
Hay que combinar DSDM con prácticas a más bajo nivel.
10

11. DSDM es muy útil para proyectos con restricciones temporales o requerimientos
cambiantes
BIBLIOGRAFÍA
Glinz, M., Dynamic System Development Method, Department of Information Technology
University of Zurich, 2004
11