archivo

Archivo de la etiqueta: DSDM

Tras la revisión del ciclo de vida expuesta en el anterior artículo se podría llegar a la conclusión de que esta metodología dista de ser ágil.

Si se hace una lectura al pie de la letra sí que puede parecerlo, pero hay que tener en cuenta que básicamente lo que se obtiene en cada fase es:

Preproyecto. ¿Qué se pretende conseguir y quiénes van a participar para conseguirlo?

Ciclo de vida del proyecto.

– Estudio de la viabiliadad (Feasability study). Lo que se pretende conseguir, ¿se puede obtener realmente con los recursos con los que se van a contar?, ¿es DSDM una metodología adecuada para llevarlo a cabo?, ¿qué problemas pueden provocar que el proyecto no evolucione adecuadamente?.

– Estudio del negocio (Business study). ¿Qué procesos se van a informatizar?, ¿qué requisitos se deben cumplir en los mismos (no se requiere entrar en detalle)?, ¿cuáles son más prioritarios?, ¿cuál se el plan de desarrollo iterativo e incremental?.

– Iteración del modelo funcional (Functional Model Iteration). En esta fase se perfeccionan y cierran los requisitos. Se puede apoyar en la realización de un prototipo. Se define una calendario para la realización de las distintas tareas que comprenden la fase.

– Iteración del diseño y de la construcción (Design and Build Iteration). Se realiza el proceso de diseño y construcción. Se define una calendario para la realización de las distintas tareas que comprenden la fase.

– Implementación (Implementation). Se realiza la aceptación del sistema, formación, la implantación y se realiza un análisis sobre la evolución e impacto del sistema, condicionando las próximas iteraciones a desarrollar.

Postproyecto. Comprendería lo que es la fase posterior a la entrega de un producto finalista (resultado de sucesivas iteraciones), de manera que haría referencia al mantenimiento del sistema de información que se puede hacer siguiendo DSDM o no.

Por tanto, la metodología, vista desde más arriba no tiene por qué resultar pesada.

Una vez analizados los principios y asunciones que sirven de base a la metodología, es el turno de repasar su ciclo de vida.

La metodología está compuesta por tres fases que se realizan de forma secuencial:

Preproyecto. Se define el alcance global, quiénes son los departamentos y personas implicadas, los compromisos de las distintas partes y quién o quienes financiarán el proyecto.

Ciclo de vida del proyecto. Está compuesto por cinco fases:

– Estudio de la viabiliadad (Feasability study). Se estudia la adecuación de DSDM al proyecto y se identifican los riesgos del mismo. En esta fase se realiza un informe de viabilidad, un prototipo de viabilidad (el prototipo tiene sentido si se quieren evaluar algunos aspectos técnicos o funcionales y se puede utilizar para obtener información adicional del proyecto) y plan general del proyecto (plan de desarrollo + registro de riesgos).

– Estudio del negocio (Business study). Si DSDM se ha considerado adecuado para el proyecto, el siguiente paso consiste en realizar un análisis más en profundidad del proceso o procesos de negocio que se van a informatizar. La participación e implicación del usuario resulta fundamental en esta fase, si en la misma no se consigue, habría que replantear la realización del proyecto siguiendo DSDM o con cualquier otra metodología.

En esta fase se obtiene un modelo de procesos identificando los usuarios clave en cada uno de ellos, un catálogo de requisitos priorizado (algo lógico para una metodología iterativa e incremental), la arquitectura del sistema y el plan de prototipado.

– Iteración del modelo funcional (Functional Model Iteration). Se divide en 4 fases: Identificación del prototipo funcional (se definen las funcionalidades que cubrirá el prototipo y se elabora un modelo funcional del mismo), Definición del calendario (se acuerda el plan de trabajo para la realización de este modelado funcional), Obtención del prototipo funcional y Revisión del prototipo funcional (se determina el grado de aceptación del prototipo desarrollado, mediante pruebas realizadas por el usuario y/o la revisión de documentación, es muy importante la obtención del feedback del usuario para que las especificaciones del producto a obtener con esta iteración se acerquen lo máximo posible a las necesidades del usuario).

– Iteración del diseño y de la construcción (Design and Build Iteration). Se divide en 4 fases: Identificación del prototipo de diseño (se determinan los requisitos funcionales y no funcionalidades que cubrirá el prototipo), Definición del calendario (se acuerda el plan de trabajo para la construcción de este prototipo), Construcción del prototipo de diseño (será un producto utilizable para los usuarios, tratándose por tanto de un producto finalista en el sentido de que ya podría ser usado para realizar el trabajo cotidiano sobre las funcionalidades implementadas), Revisión del prototipo de diseño.

– Implementación (Implementation). Se divide en 4 fases: Aprobación del usuario (el usuario realiza la aprobación del producto a entregar), Formación (se forma a los usuarios finales de la aplicación), Implementación (se instala el producto en las instalaciones del cliente), Revisión de negocio (se revisa la adecuación del sistema a las necesidades del negocio y a los objetivos iniciales que se habían establecido para el mismo, en función de lo que se decida en esta fase se irá a la fase de Postproyecto o a una de las fases anteriores del ciclo de vida).

Si falta o se detecta algún nuevo aspecto funcional relevante se vuelve a la fase de Estudio del Negocio, si no es relevante se vuelve a la fase de Iteración del modelo funcional, si falta o se detecta algún nuevo aspecto técnico se vuelve a la fase de Iteración del diseño y la construcción.

Postproyecto. Tiene como objetivo la continuidad del sistema en el sentido de que siga siendo útil a las necesidades de los usuarios, comprendería por tanto el mantenimiento del sistema que se realizaría (si se estima conveniente siguiendo el ciclo de vida DSDM).

Es importante señalar que DSDM permite trabajar con varios prototipos simultáneamente siempre y cuando “no se molesten” entre sí, esto permite reducir el tiempo necesario para que los usuarios tengan en producción las distintas evoluciones del producto.

A los principios indicados en el artículo anterior sobre DSDM, hay que asumar otros, que se denominan asunciones (assumptions) y que se van a describir a continuación.

Considero importante indicar los principios y asunciones antes que la metodología en sí, ya que son la base no solo de la misma, sino de prácticamente cualquier metodología de desarrollo que tenga una orientación iterativa e incremental.

Si no se cree en ellos, no se creerá en este tipo de metodologías. Como ya sabéis por los artículos que llevo escritos sobre la materia, considero que proyectos desarrollados de esta manera tienen un porcentaje de éxito mayor que otros desarrollados con metodologías más tradicionales como las basadas en el ciclo de vida clásico o cascada.

Las asunciones son las siguientes:

– Los sistemas no se construyen perfectamente en una solo intento. Sin embargo siguiendo el Principio de Pareto, el 80% de los objetivos de una solución perfecta se puede desarrollar en el 20% del esfuerzo que se requeriría para obtenerlos. Por tanto, la realización de un desarrollo rápido debería centrarse en priorizar funcionalidades importantes para la cobertura de las funcionalidades de negocio dejando con las mismas satisfechos al conjunto de usuarios. Esto debería ser posible ya que la metodología requiere una implicación real de los usuarios.

Intentar construir un sistema perfecto es una utopía e intentar aproximarse demasiado pronto a esa idea de sistema es una pérdida de energía que además pone en riesgo al propio sistema de información, ya que como consecuencia de ello muchos de los inconvenientes de la crisis del software habrán impactado en el proyecto. Si intentamos subir una cuesta a máximo rendimiento desde el principio probablemente tardemos más en alcanzar la cima (si es que llegamos a ella).

– No se puede quitar la vista del objetivo de conseguir proyectos con calidad y dentro de los plazos y presupuestos.

Y añado yo, que satisfaga al usuario (eso debería estar ya implícito en el concepto de calidad, pero nunca está de más tener siempre presente que los proyectos y que nuestro trabajo (en la mayoría de los casos) está orientado a informatizar procesos que utilizan personas y que si las mismas no se sientes cómodas y no le sacan rendimiento no serán eficientes en el uso de la aplicación y se resentirá la productividad y la calidad de los datos que se graban.

– Pueden desarrollarse simultáneamente varios incrementos siempre y cuando no se entorpezcan entre sí.

– La metodología es válida más allá de desarrollos que comiencen desde cero. Es igualmente aplicable para mantenimientos incluso de proyectos no desarrollados siguiendo esta metodología o una similar.

¿Por qué no iba a serlo? La clave está en definir adecuadamente los incrementos (aunque sea más o menos difícil). Si estamos ante el mantenimiento de un sistema gigantesco que tiene incendios por todos lados resultará más complicado priorizar y se tardarán bastantes iteraciones en conseguir una cierta estabilidad.

Las bases de la metodología o la metodología en sí no constituyen una piedra filosofal para que todos los proyectos tengan éxito. Esta forma de entender los proyectos de desarrollo de software marcan un camino que desde mi punto de vista es el adecuado, pero generalmente la vía es tan ancha y hay tantas nubes que es fácil perderse.

En DSDM estamos ante otra metodología de naturaleza iterativa e incremental y es considerada la primera metodología ágil (su primera versión es del año 1995 y desde entonces se han realizado diversas actualizaciones de la misma).

DSDM está orientada a combatir los principios de la crisis del software, de manera que se puedan realizar proyectos de desarrollo de software en tiempo y presupuesto, verificando las expectativas del usuario (mediante la existencia de requisitos cambiantes que se tratan en las diferentes evoluciones del producto).

Antes de analizar brevemente las fases que componen el ciclo de vida DSDM, es importante repasar los nueve principios en los que se basa la metodología, ya que delimitan la naturaleza de la misma:

1.- Para llevar a cabo un proyecto eficiente y efectivo es necesario que el grupo de usuarios que participan en su definición estén implicados.

2.- El equipo de proyecto debe tener la capacidad de tomar decisiones importantes para que el proyecto siga avanzando sin necesidad de esperar la aprobación de niveles superiores de la jerarquía.

3.- Orientado a la existencia de frecuentes iteraciones, de manera que entregar algo bueno pronto es siempre mejor que esperar a entregar algo perfecto más tarde. El hecho que desde muy pronto se tenga la oportunidad de utilizar el producto, permite que desde etapas muy tempranas comience el continuo proceso de revisión que permita que en cada paso el producto además de ir asumiendo nuevas funcionales se acerque cada vez más a las expectativas del usuario.

4.- Se parte de lo más crítico y esa es la base para definir las características de las entregas, es decir, una entrega debe satisfacer unas serie de funcionalidades que son importantes o críticas en el sistema. No se trata de cubrir todas las necesidades del sistema (lo cual iría en contra de la naturaleza de este tipo de metodologías) sino de centrarse en las que resultan más necesarias, para que el proceso continuo de revisión empiece desde lo que resulta más importante que funcione de forma adecuada. Se trata de ir al grano, ya tocará en un futuro desarrollar y perfeccionar funcionalidades accesorias.

5.- La estrategia de desarrollo, por tanto, es iterativa e incremental y guiada por las necesidades de los usuarios.

6.- Cualquier cambio realizado en el proceso de desarrollo es reversible. Esto es muy importante. Un usuario se ha podido equivocar al especificar una funcionalidad o la forma en que debe operar la misma, si es así no se debe continuar con el error sino rehacer completamente la funcionalidad si fuera preciso.

7.- Los objetivos y requisitos de alto nivel del proyecto han debido ser pactados y aceptados entre las partes que participan en el proyecto, antes de que el proyecto comience.

8.- Las pruebas se realizan a lo largo de todo el ciclo de vida del proyecto, no solo se realizan entre iteración e iteración sino que están presentes en los diferentes entregables. Esto se realiza para la detección temprana de errores, ya que sabemos que cuánto más se tarde en corregirlos, más costoso resulta.

9.- Resulta fundamental la comunicación y cooperación de todas las partes implicadas en el proyecto.