2. CONTENIDOS
1. INTRODUCCIÓN
2. HISTORIA
3. DESCRIPCIÓN
4. APLICACIONES
5. COMPARACIÓN CON OTRAS METODOLOGÍAS
6. CONCLUSIONES
7. BIBLIOGRAFÍA Y LINKS
2
3. INTRODUCCIÓN A DSDM
DSDM
(Dynamic System Development Method)
Framework en el que desarrollar un proceso de
producción de software.
Combinación eficiente del conocimiento de las
personas y técnicas para realizar proyectos
rápidamente.
4. ... INTRODUCCIÓN A DSDM
El equipo de desarrollo y usuarios trabajan juntos.
Evitar producir sistemas que:
1. No cumplan los requerimientos
2. No funcionen correctamente
3. Caigan en desuso.
Proceso iterativo e incremental.
Satisfacción a tiempo de los requerimientos del
negocio.
4
5. HISTORIA DE DSDM
A principios de los 90 surgió el concepto de RAD
(Rapid Application Development).
Cada desarrollador ofrecía una solución totalmente
distinta.
DSDM nació en enero del 94 con el objetivo de crear
una metodología RAD unificada.
5
6. ... HISTORIA DE DSDM
DSDM consortium liderado por Tony Mobbs,
Jennifer Stapleton, Gary Hodsdon, Paul Herzlich y
Peter Constable, publicó en Febrero del 95 la 1ª
versión de DSDM.
Mejoraron 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.
6
7. DESCRIPCIÓN DE DSDM
Los Principios Fundamentales
Participación del usuario activo (reducción costos de error).
El equipo toma decisiones (optimización del tiempo).
Frecuentes entregas del producto (minimización de errores).
Ajustarse a los objetivos del negocio (satisfacer las
necesidades del negocio).
Desarrollo iterativo e incremental (complejidad manejable).
Cambios reversibles (pérdida del total del trabajo limitada).
Especificar requerimientos globales (requisitos de alto nivel
congelados).
Pruebas integradas durante todo el ciclo de vida.
Cooperación entre el equipo y usuarios es esencial.
7
8. FASES DEL DSDM
Fase 1. Pre-Proyecto
En esta fase se identifican los proyectos
propuestos, quien financiará el proyecto,
compromiso por parte de los equipos, usuarios y
clientes.
8
10. FASE 2. EL CICLO DE VIDA
Estudio de viabilidad y de negocio
Las dos primeras fases son secuenciales.
Estudio de viabilidad:
Calcular los costes
Ver si es técnicamente viable
Asegurarse de que DSDM sea el enfoque
adecuado
Estudio de negocio:
Modelado del proceso del negocio
Fuerte colaboración cliente-equipo de
desarrollo.
10
11. FASE 2. EL CICLO DE VIDA
Iteración funcional del modelo e Iteración de diseño y construcción
Iteración funcional del modelo:
Refinar aspectos funcionales del negocio.
Iteración de diseño y construcción:
El producto se vuelve apto para los usuarios.
Las dos fases consisten en ciclos de 4 actividades:
Identificación
Planificación
Producción
Validación
11
12. FASE 2. EL CICLO DE VIDA
Implementación
Implementación, entrenamiento, revisión y aceptación
de usuarios y revisión del negocio.
Al final puede ocurrir:
1. Falta una parte técnica
Iteración de diseño y construcción
2. Se ha descubierto una nueva funcionalidad
Estudio del negocio
3. Falta una funcionalidad secundaria
Iteración funcional del modelo
4. Todos los requerimientos cumplidos
Fin
12
13. 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.
13
14. MECANISMOS DE DSDM
Timeboxes
La rapidez de DSDM se basa en seleccionar las
funcionalidades más prioritarias para el negocio. El
mecanismo para manejar esto en DSDM es el
timebox.
Cada timebox tiene una fecha de finalización y un
conjunto de requerimientos a satisfacer indicando la
prioridad de cada uno.
Si algo no funciona se ignoran los requisitos con
menos prioridad.
14
15. MECANISMOS DE DSDM
MoSCow
Rules
Para dar prioridades a los requisitos DSDM usa las
MoSCoW rules.
Tenemos 4 clases de requisitos:
M “Must Have” vitales para el proyecto
o
S “Should Have” para obtener el máximo
beneficio
C “Could Have” deben implementarse si el
tiempo lo permite
o
W “Would” pueden dejarse para otro momento
15
16. MECANISMOS DE DSDM
Prototipado
El prototipado evolutivo es una de las técnica en las
que se basa DSDM.
Encontramos los siguientes prototipos :
Bussines
Usability
Performance
Capability
16
17. APLICACIONES
DSDM para e-business
Entornos web especialmente sensibles al tiempo.
Necesidad de método RAD.
DSDM se centra en:
La colaboración entre los departamentos
implicados en el proyecto web.
Descubrir e implementar los requisitos a medida
que avanza el sistema.
17
18. APLICACIONES
Experiencias en DSDM
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.
Hay casos en los que DSDM no ha funcionado.
18
19. COMPARACIÓN
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.
19
20. COMPARACIÓN
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.
20
21. 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.
21
22. CONCLUSIONES
DSDM es un framework en el que pueden entrar una
gran variedad de metodologías.
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.
DSDM es muy útil para proyectos con restricciones
temporales o requerimientos cambiantes
22
23. BIBLIOGRAFÍA Y LINKS
Glinz, M., Dynamic System Development Method, Department of
Information Technology University of Zurich, 2004
23
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Hoy por hoy las organizaciones no solo necesitan nuevos sistemas informáticos sino que además, los necesitan para ayer. DSDM, que son las siglas de Dynamic System Development Method, proporciona un marco o framework en el que desarrollar un proceso de producción de software. Un proceso que utilice eficientemente el conocimiento de las personas y las técnicas para realizar proyectos en cortos periodos de tiempo.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó DSDM se centra en ayudar a la gente del equipo de desarrollo y a los usuarios a trabajar juntos de forma más eficiente y así evitar producir sistemas que no cumplan los requerimientos, no funcionen correctamente o que caigan en desuso. DSDM es un proceso iterativo e incremental donde en cada paso se implementan los requerimientos que son más importantes en el momento actual para la organización. Así se consigue satisfacer a tiempo los verdaderos requerimientos del negocio.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Pero ¿de dónde viene DSDM? Pues bien, a principios de los 90 surgió el concepto de RAD (Rapid Application Development), que criticaba el ciclo de vida en cascada por su lentitud, pero cada desarrollador ofrecía una solución totalmente distinta lo que produjo un caos de metodologías. Sin embargo, de esta maraña surgieron 16 desarrolladores que en enero del 94 formaron el “DSDM consortium” con el objetivo de crear una metodología RAD unificada.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Y así el DSDM consortium liderado por Tony Mobbs, Jennifer Stapleton, Gary Hodsdon, Paul Herzlich y Peter Constable, publicó en Febrero del 95 la 1ª versión de DSDM. La siguientes versiones, es decir, la 2ª en el 96, la 3ª en el 97 y la 4ª en el 2001. Mejoraron mucho gracias al énfasis que se puso en obtener feedback de los usuarios. La versión actual es la 4.1 y es el método más usado en el Reino Unido y comienza a extenderse por Europa y Estados Unidos.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Ahora que ya sabemos más o menos que es DSDM ya podemos entrar en materia y definir sus principios fundamentales. Que son: Participación del usuario activo. Lo que garantiza desarrollar la herramienta adecuada y que sea utilizada. El equipo toma decisiones. Esto es necesario para motivar al equipo y mantener una alta velocidad de desarrollo. Frecuentes entregas del producto. Decidiendo que partes son más importantes y construyéndolas en cada iteración. Ajustarse a los objetivos del negocio. Esto es esencial para la aceptación del producto. Desarrollo iterativo e incremental. Así se utiliza el feedback de los usuarios. Cambios reversibles. Es decir, saber donde estamos en cada momento para dar la posibilidad de deshacer y probar otro camino si este no funciona. Especificar requerimientos globales. Aunque más adelante se deben ir refinando. Pruebas integradas durante todo el ciclo de vida. No como una actividad separada. La colaboración y cooperación entre el equipo, usuarios y stakeholders es esencial.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Lo que estáis viendo ahora es el ciclo de vida de DSDM, tiene 5 fases: el estudio de viabilidad, el estudio del negocio, la iteración funcional del modelo, la iteración de diseño y construcción y la fase de implementación. Además, antes de todas estas fases hay una fase “Pre-Proyecto” en la que nos aseguramos de que el proyecto es útil para la organización, tiene los fondos necesarios, etc. Al final de las cinco fases hay otra fase “Post-Proyecto” cuyo objetivo es mantener el producto funcionando y asegurarse de que los beneficios esperados se hayan logrado.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Las dos primeras fases, el estudio de viabilidad y el estudio del negocio, se hacen secuencialmente. El estudio de viabilidad consiste en calcular los costes, ver si es técnicamente viable y sobre todo en asegurarse de que DSDM sea el enfoque adecuado para este problema en concreto. Como estamos utilizando un método RAD esta fase no debería durar más de unas pocas semanas. El estudio del negocio se centra en el proceso del negocio a modelar y requiere una fuerte colaboración entre el cliente y el equipo de desarrollo. El resultado de esta fase será la “Definición del Area de Negocio” que identificará los procesos del negocio y los usuarios afectados.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó La iteración funcional del modelo se centra en refinar aspectos funcionales del negocio y en la iteración de diseño y construcción es donde el producto se ha vuelve apto para los usuarios. Estas dos fases consisten en ciclos de cuatro actividades: Identificar qué producir, Acordar cuando y cómo hacerlo, Producirlo y Validarlo. Así conseguimos que las pruebas se vayan realizando durante todo el desarrollo. Al final de estas fases obtenemos el producto ya probado.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó La fase de implementación consiste en llevar el sistema a los usuarios. A parte de la implementación, en esta fase se realiza el entrenamiento de los usuarios, la revisión y aceptación de los usuarios y la revisión del negocio. Para ello se revisan todos los requerimientos identificados viendo cuales de ellos se han cumplido. Aquí pueden ocurrir cuatro cosas: Que se haya dejado sin hacer una parte técnica por falta de tiempo, lo que nos lleva a la iteración de diseño y construcción. Que se haya descubierto una nueva área de funcionalidad, esto significa que hemos devolver al estudio del negocio. Que se haya tenido que ignorar una funcionalidad secundaria por falta de tiempo, así que tenemos que volver a la iteración funcional del modelo. O bien que se hayan cumplido todos los requerimientos y por lo tanto se haya terminado el desarrollo.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Hasta ahora hemos visto un nuevo enfoque para el desarrollo de software pero con esto no podríamos decir por qué DSDM debe ser más rápido que otras metodologías. La rapidez de DSDM se basa, al igual que XP, en seleccionar las funcionalidades más prioritarias para el negocio, haciendo que sean variables los requisitos pero no el tiempo. El mecanismo para manejar esto en DSDM es el timebox. Cada timebox tiene una fecha de finalización inamovible y un conjunto de requerimientos a satisfacer. Entre estos requerimientos debe haber unos que sean de vital importancia y otros que tengan menos prioridad para que así, si las cosas no van bien quede “sitio para maniobrar” ignorando los requisitos con menos prioridad.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Así que el nuevo problema que tenemos ahora es como dar prioridades a los requisitos y la solución que nos da DSDM es usar las MoSCoW rules. Con estas reglas tenemos 4 clases de requisitos: los “Must Have” que son vitales para el proyecto, los “Should Have” que son importantes para obtener el máximo beneficio, los “Could Have” deben implementarse si el tiempo lo permite y los “Won’t Have” que pueden dejarse para otro momento.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Otra de las técnicas en las que se basa DSDM es en el prototipado evolutivo, así podemos encontrar el prototipo del negocio (que especifica la funcionalidad), el de usabilidad (que especifica la interfaz), el de “Performance” (o rendimiento) (que especifica la cantidad o velocidad de datos que deben procesarse) y el de “Capability” (que está enfocado desde el punto de vista del diseño).
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Ahora que ya sabemos como funciona DSDM podemos hablar de donde se usa y precisamente uno de los tipos de proyectos donde más se usa es en los de web. Y se usa tanto debido a que en la web la presión del tiempo es aún más patente. Así que DSDM se centra en la colaboración entre los departamentos implicados en el proyecto web y en ir descubriendo e implementando los requisitos a medida que avanza el sistema, en lugar de intentar conocerlos todos al principio del proyecto, para poder obtener la funcionalidad que buscábamos a tiempo.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó La verdad es que resulta increíble que no se haya oído más por aquí porque en cuanto buscas un poco ves que en el reino unido lo ha utilizado todo el mundo, desde British Airways hasta el propio gobierno. Sin ir más lejos, el centro de reparaciones europeo de Fujitsu aplicó DSDM para renovar su sistema y en siete meses consiguió pasar de atender 500 unidades mensuales a 4000. Sin embargo también hay casos en los que DSDM no ha funcionado pero como dicen ellos: “Un loco con una herramienta, sigue siendo un loco”.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Mucha gente ve a DSDM y XP como competidores pero en realidad pueden ser complementarios. Los principios fundamentales de DSDM son muy parecidos a los de XP así que no hay un gran cambio en el enfoque del problema. Las diferencias radican en que 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. Así que combinando XP y DSDM podemos obtener un proceso tan ágil como XP pero más fácilmente escalable gracias a la gestión de DSDM.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Entre DSDM y RUP pasa algo parecido ya que RUP podría considerarse una implementación de DSDM. Aquí la diferencia radica en que RUP está más orientado a la arquitectura y a la calidad y DSDM tiene como objetivo el desarrollo rápido de aplicaciones, sin embargo esto no es un impedimento para combinarlos porque incluso se pueden relacionar todas las fases y artefactos de RUP con los de DSDM. Así que al combinarse podemos obtener un sistema con una arquitectura fuertemente definida en un tiempo récord.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó Finalmente y como conclusión tenemos que DSDM no es una metodología, sino un framework en el que pueden entrar una gran variedad de metodologías. DSDM combina el punto de vista de las metodologías ágiles con una especificación más rigurosa de la arquitectura y la gestión del proyecto, lo que le da una mayor estabilidad. Sin embargo, en la práctica hemos de combinar DSDM con prácticas a bajo nivel que son más específicas. Además, uno de los mayores potenciales de DSDM es el de funcionar como una especie diseñador de procesos, así, dependiendo del proyecto con el que nos enfrentemos podemos diseñar un proceso específico. En cualquier caso, DSDM ha demostrado ser muy útil y debería ser considerado para cualquier proyecto con restricciones temporales o requerimientos cambiantes.
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó
DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó