Metodologia DSDM
•Descargar como PPT, PDF•
0 recomendaciones•4,989 vistas
DSDM (Dynamic System Development Method) es un marco de trabajo para el desarrollo rápido de software mediante un enfoque iterativo e incremental. Se basa en la colaboración estrecha entre el equipo de desarrollo y los usuarios, con entregas frecuentes y ajustes a los objetivos del negocio. DSDM surgió en 1994 para unificar las diferentes metodologías RAD existentes y ha evolucionado a través de comentarios de usuarios, siendo útil especialmente para proyectos con restricciones de tiempo o requisitos cambiantes.
![CONTENIDOS ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],04/02/03](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Metodologia DSDM
Similar a Metodologia DSDM (20)
Metodologia DSDM
- 8. El Ciclo de Vida 04/02/03 Visión General Pre-Project Post-Project
- 12. Mecanismos de DSDM 04/02/03 Timeboxes Cada timebox tiene una fecha de finalización y un conjunto de requerimientos a satisfacer indicando la prioridad de cada uno. 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. Si algo no funciona se ignoran los requisitos con menos prioridad.
- 16. Aplicaciones 04/02/03 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.
- 19. Conclusiones 04/02/03 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
Notas del editor
- DSIC - FI - UPV Diciembre 2002 Juan Morató Moscardó
- 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.