Dynamic Systems Development Method
El método DSDM es un método de desarrollo ágil que se apoya en una continua interacción con el usuario, consiguiendo una gran implicación. Esto produce un sistema sensible a los requisitos cambiantes del usuario, y que será capaz de adaptarse mucho mejor a las necesidades de la empresa. Fue creado para ser un sistema de resolución sencilla de tareas complejas, para ello se utilizan una serie de principios y valores, junto a una organización de equipo específica y con roles, y una serie de fases y etapas a seguir durante el desarrollo del software.
DSDM y el consorcio DSDM: Orígenes
editarEl consorcio DSDM fue fundado en 1994 por un conjunto de vendedores y expertos en el sector de la Ingeniería de Software. Se creó con el objetivo de un "Desarrollo conjunto promocionando un entorno de trabajo de desarrollo ágil", combinando las mejores experiencias obtenidas en práctica.
Principios y Valores
editarLos métodos de desarrollo ágiles tienen una serie de valores como son dar más valor a los individuos en lugar de a las herramientas, o valorar mejor un software que funciona bien en lugar de una buena documentación. El método DSDM utiliza 9 principios para aplicar estos valores.
1.- La obligación del usuario de implicarse:
Es considerado el más importante de los principios. Esto es debido a que la implicación del usuario en el desarrollo reduce en gran parte el número de errores y, por consiguiente, el dinero y tiempo utilizado para corregir los mismos. Por lo general, se trabaja con un pequeño número de usuarios selectos, haciendo pequeñas revisiones periódicas. Estos usuarios se mantendrán durante el desarrollo del Software consiguiendo así una imagen más fiel del software deseado. La continuidad, por otra parte, es uno de los valores que se aplican en los principios.
2.- Los equipos deben de tener el poder de tomar decisiones.
Para poder proceder de la manera más rápida posible y sin depender de otras personas, todos deben de tener poder para tomar decisiones independientemente de los demás integrantes del equipo. Requerir la autorización de otras personas para poder proceder a actuar según decisiones tomadas ralentiza el proceso de creación del software, por ello, a todos los trabajadores se les da permiso para tomar decisiones que afectan a: Requisitos en desarrollo. Requisitos cuya funcionalidad se necesita en futuras interacciones. Priorización de requisitos y características. Detalles técnicos.
3.- Realización de entregas tempranas.
Las entregas tempranas garantizan la detección rápida de errores para que sean corregidos y revertidos rápidamente antes de que el coste de reparación sea demasiado elevado. Estas entregas afectarán tanto al software como a la documentación que se entregará junto al software terminado.
4.- Las entregas que se acepten han de ser adaptadas a la empresa.
El software que entreguemos ha de ser capaz de satisfacer las necesidades de la empresa. Por lo general, la Refactorización, el diseño y la mejora de las funciones son tareas que en los sistemas de modelado de software solo realizan una vez, al comienzo como es el diseño, o al final como es la refactorización o mejora de las funciones. Sin embargo, el DSDM sostiene que estas tareas han de formar parte del ciclo de vida del software y han de ser tareas que se deben de repetir una vez con cada una de las entregas que la empresa haya aceptado para así conseguir una mayor adaptación a la empresa y, como hemos dicho antes, que los errores no se hagan mucho más grandes y su coste de reparación no se eleve demasiado. Por otra parte, repitiendo estas fases una y otra vez se consigue una mucho mejor aproximación al software que desea la empresa.
5.- El desarrollo es Iterativo e Incremental.
El desarrollo Iterativo e Incremental es el que mejor se adapta a todos los principios anteriores, y además facilita la división de las tareas para una mejor y más fácil organización del trabajo. En este desarrollo el software se va haciendo más grande con cada iteración hasta conseguir con la última que el software se haya adaptado completamente a lo que la empresa necesitaba. Este principio se basa en el concepto de que todo software está sujeto a cambios. Por último, cuanto más pequeñas sean las iteraciones, más fácil será identificar y realizar los cambios que hay que realizar.
6.- Todos los cambios que se hagan durante el desarrollo han de ser reversibles.
Como el propio título indica, cualquier cambio que nosotros realicemos debe de poder ser revertido con facilidad y sin suponer excesivos costes. Esto es debido a que los principios anteriores hacen que los cambios surjan continuamente y si no se tiene un control sobre ellos puede que el tiempo que tardemos en realizarlos sea excesivo. Por ello todos los cambios que se realicen han de ser escritos ideando que sean sencillos de eliminar o revertir. Es cierto que este principio pueda hacer que realicemos trabajo para nada si nuestros cambios se revierten al final, pero sin ello, los principios que sigue el método DSDM no sería aplicable dado que generaría trabajo muy grande procedente de la continua comunicación con usuario y cliente.
7.- Los requisitos se describen en alto nivel y tendrán una línea base.
El DSDM hasta el momento propone que haya una gran libertad a la hora de cambiar los requisitos. Para limitarlos se establecen una serie de requisitos en alto nivel al comenzar el proyecto, formando una Línea Base sobre la que desarrollar. Así se forma una idea del alcance que deben tener los requisitos y nos aseguramos que los cambios no alteran demasiado la funcionalidad del ECS.
8.-Las pruebas se integran a lo largo del ciclo de vida.
Por lo general, las pruebas es una de las últimas fases que forman proceso de ingeniería del software, siendo estas las que se realizan después de la codificación. Sin embargo, el modelo DSDM defiende que para conseguir una rápida corrección de los errores, las pruebas deben integrarse dentro de las fases más tempranas de la elaboración y repetirse en múltiples ocasiones durante el ciclo de vida del software.
9.- Enfoque cooperativo y colaborativo. La programación cooperativa es comúnmente utilizada en métodos de desarrollo ágil. Estas técnicas aceleran la resolución de problemas y la construcción de un software más eficiente y con menos errores. La más común es la programación por parejas en la que, mientras una de las dos personas codifica, la otra piensa y resuelve como realizar el algoritmo o la clase que hay que escribir a continuación además de revisar y ayudar a su compañero y viceversa.
Organización y Roles
editar
En todo equipo de modelado de software existen diferentes roles que adoptan los integrantes del equipo. El DSDM identifica un total de 12 roles, aunque, estos son variantes según las necesidades del equipo de desarrollo en función del software que se desarrolle:
- Patrocinador ejecutivo: Es el rol más alto que adopta la organización. Es la fuente que proporciona fondos y recursos al proyecto. Es la posición más alta que toma decisiones.
- Visionario: Es el que tiene la responsabilidad de iniciar el proyecto. El visionario es el que proporciona las necesidades que tiene la empresa del software. El visionario tiene también la tarea de supervisar que el proyecto se desarrolla correctamente.
- Usuario “Embajador”: Proporciona al proyecto la información proveniente de la comunidad de usuarios. Tiene la obligación de asegurar que los desarrolladores reciben suficiente información de la comunidad de usuarios durante la fase de desarrollo.
- Usuario “Consejero”: Es cualquier usuario que proporcione al proyecto un buen punto de vista de la aplicación.
- Jefe de Proyecto: Es la persona encargada de gestionar el proyecto en general.
- Coordinador Técnico: Es el responsable de organizar la arquitectura del proyecto y controlar la calidad del software generado.
- Lider de Equipo: Se asegura de que el equipo funciona correctamente.
- Desarrollador: Interpreta los requisitos de sistema y los modela y desarrolla el código.
- Probador “Tester”. Es el encargado de comprobar que el software funciona correctamente así como de generar la documentación.
- Escriba: Toma nota de todos los requisitos, acuerdos y cambios que se realizan.
- Facilitator: Es la persona que se encarga de controlar el progreso facilitar y potenciar la comunicación y el desarrollo.
Roles especiales: Business Architect, Quality Manager, System Integrator, etc.
Fases y Etapas
editar
Como todo modelo de proceso de Ingeniería de software, el DSDM está dividido en fases y etapas para organizar mejor las tareas a realizar en el desarrollo del software. El modelo DSDM consta de 3 grandes fases, El pre-proyecto, Ciclo de vida del software, y Post-Proyecto.
1.- El Pre-Proyecto:
En esta fase se producen varias sugerencias de proyectos candidato, entre las cuales se elige una candidata. Además en esta fase se realiza una estimación de los fondos necesarios para desarrollar el proyecto y se decide si el proyecto se va a realizar o no.
2.- El Ciclo de vida del Software:
El objetivo de esta fase es la construcción del proyecto planteado en la fase de Pre-Proyecto. Esta fase está subdividida en fases:
2.1- Estudio de Viabilidad y de Negocio.
Los estudios que se plantean a continuación han de ser lo más cortos y esquemáticos posibles pero con la mayor completitud posible, dado que la creación de un documento demasiado complejo retrasaría el proyecto, pero unos buenos estudios nos ayudarán a enfocarlo mejor.
2.1.1- Estudio de Viabilidad:
En esta fase se realizan reuniones para determinar aquellas ideas que no tienen que ver con el proyecto en sí, sino con la gestión del proyecto. Las respuestas ayudarán a direccionar el desarrollo del proyecto determinando sus costes, la adaptación de este al modelo DSDM, los riesgos que existen, etc... Produciendo un documento de Viabilidad.
2.1.2- Estudio de negocio:
Es un documento que extiende al estudio de flexibilidad y que se realiza únicamente se haya decidido que el proyecto se puede desarrollar mediante DSDM. En esta fase se intentarán definir características del proyecto, así como las necesidades que esperan los usuarios de él. Al final del estudio se determinará una lista de requisitos, que se priorizarán según su necesidad para el desarrollo del resto de requisitos.
2.2- Iteración de Modelo Funcional (Functional Model Iteration)
En esta fase se recogen los requisitos identificados en fases anteriores y se transforman en Modelos Funcionales. Para ello se crean prototipos funcionales de los requisitos que dan una idea al usuario de cómo va a funcionar la aplicación y así satisfacer el principio número 1. Los prototipos funcionales son revisados por diferentes grupos de usuarios que valoran y certifican la calidad del prototipo.
2.3- Iteración de diseño y desarrollo (Design & Build Iteration) La principal tarea de esta fase es transformar los Modelos funcionales obtenidos de la fase anterior y completarlos para que satisfagan totalmente las necesidades del usuario. Para ello, crearemos Prototipos de diseño, y al igual que en la fase anterior, los verificaremos con los usuarios.
2.4- Implementación
Por último, en la fase de implementación, los usuarios verifican que los prototipos cumplen con lo deseado y se realiza la implementación de los mismos, así como el entrenamiento de los futuros usuarios para que sepan utilizar la aplicación.
3.- El Post-Proyecto.
Esta fase se utiliza para comprobar que el producto funciona correcta y eficientemente. En esta fase se realizan tareas de mantenimiento, y de mejora del software si son requeridas. Por lo general esta fase se produce durante los 6 meses siguientes a la entrega del proyecto al cliente.