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.
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.
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.
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.
http://jummp.wordpress.com/2011/04/13/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-i/
http://jummp.wordpress.com/2011/04/14/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-ii/
http://jummp.wordpress.com/2011/04/15/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-iii/
http://jummp.wordpress.com/2011/04/16/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-iv/
No hay comentarios.:
Publicar un comentario