El por qué de que muchos proyectos fracasen III: V-Model y sistemas complejos

Continuamos hablando sobre V-Model, aunque lo que hablemos en este artículo puede ser aplicado sin lugar a dudas a cualquier otra variación del mismo como por ejemplo RUP. Si no conoces V-Model, recomiendo que leas el artículo anterior De Waterfall a V-Model.

yourplan

Recordemos que los argumentos utilizados para aplicar el modelo en V al desarrollo software fueron los siguientes:

  • Saber el estado de nuestra versión liberada de producto. Esto era un problema en Waterfall, ya que pasar de una fase a otra sin tener conocimiento objetivo de que estaba completa podía traer consecuencias graves en siguientes etapas.
  • Tratar de detectar errores de forma temprana. Varios estudios indicaban que aproximadamente el 60% de los errores eran debidos a errores en etapas previas a la codificación. Es una de las cosas que intenta evitar ya que hay que tener en cuenta que el coste de un cambio en etapas más avanzadas del desarrollo es muy superior que si se detecta antes o durante el mismo (imagina toda la gestión que puede llevar resolver un error detectado en una versión si es un error en requisitos y la gente involucrada, o si un error de programación es detectado durante la validación con cliente).
  • Poder garantizar al cliente que lo entregado estaba de acuerdo a lo pactado en requisitos. La verificación y trazabilidad al final garantizaban que lo descrito en los requisitos de sistema que estaban en contrato con el cliente se cumplían. De esta manera se facilitaba la fase de aceptación del hito en cuestión.

office-227168_640-free

Este modelo, al igual que Waterfall, es un modelo totalmente lógico y que desde un primer vistazo parece optimizar el coste del desarrollo software, por un lado  optimizando la minimización de error debido a las fases previas a desarrollo y por otro lado verificando y dándonos el estado de las fases para facilitar la toma de decisiones. Si tan lógico parece, ¿dónde está el problema? En un informe publicado en 1994 por el Standish Group se decía que en la aplicación de Waterfall en proyectos software de los últimos años, el 31,1% de los proyectos fracasaron y fueron cancelados, el 52,7% tuvieron un sobrecoste en tiempo y/o dinero y el 16,2% de los proyectos tuvieron éxito.

gesture-free

A día de hoy, a pesar de haber un crecimiento en el éxito de proyectos hasta un 39%, sigue habiendo un 18% de cancelación y un 43% de proyectos que finalizan con sobrecoste. Esto a nivel general, pero si comparamos proyectos de tamaño grande (más de 10 millones de euros) con proyectos de tamaño más pequeño (menos de 1 millón de euros) nos encontramos con la sorpresa de que en el caso de los proyectos grandes que normalmente utilizan V-Model (o algo similar) sólo un 10% tienen éxito y el resto o se cancelan o simplemente acaban con sobrecoste. ¿Pero qué ocurre con esos proyectos más pequeños? Parece ser que el porcentaje de éxito es del 76%, algo bastante aceptable.

smallLargeprojects

 

Hay un hecho y es el siguiente “los requisitos siempre cambian”, resolvemos problemas con el desarrollo software de una gran incertidumbre donde ni nosotros ni el cliente sabemos exactamente qué es lo que necesita: no somos adivinos. Probablemente en proyectos muy pequeños es más sencillo controlar esta incertidumbre porque el problema a resolver es mucho más pequeño y evidentemente en proyectos más grandes al aumentar la complejidad y la variabilidad, aumenta el riesgo.thumb-440352_640-free

En mi opinión el enfoque de V-Model es un problema: Mejorar Waterfall, garantizando la calidad de cada etapa y demostrando a cliente que cumple con lo contratado. Es un problema porque no se atacan las causas raíces del problema Watefall, si no que trataron de mejorar algo que por base tendría muchas limitaciones en el desarrollo software porque los requisitos son cambiantes y por tanto nunca podremos pasar de etapa a etapa con garantías de que no tengamos que volver a hacer otra vez el mismo trabajo. Imagina un error en requisitos que ya entrada fase de desarrollo, nos damos cuenta que es incorrecto. Habría que cambiar esa funcionalidad, todas las funcionalidades relacionadas y todos los errores que saldrían con todos esos cambios. ¿se puede llevar un proyecto así? Sí, pero no de forma óptima. Quizá un enfoque iterativo del problema sería lo más lógico si no sabemos exactamente lo que quiere el cliente.

Iteration_Mona_Lisa

Realmente V-Model cumple el objetivo planteado: mejorar el éxito de Waterfall, (crecimiento de un 16,2%  a un 39% de éxito en proyectos en los últimos 20 años), pero con una mayor probabilidad de sobrecoste incremental dependiendo de la complejidad del proyecto (éxito decreciente de un 76% a un 10% dependiendo de la complejidad de proyecto). Este es el mayor error: la definición de “éxito”. Porque si para nosotros la definición de éxito de proyecto es ganar dinero con él y tener al cliente satisfecho para que nos compre más, las premisas de V-Model no son válidas porque:

  • Queremos conocer el estado de cada etapa en base a querer pasar de una etapa a otra con garantías. Sin embargo, debido a que los requisitos son cambiantes, a nivel práctico esto se traduce en saber cuál es “el estado” de proyecto para la liberación de una la versión. Lo cual ayuda a la toma de decisiones pero no a garantizar que podamos desarrollar porque ha terminado la fase de diseño.
  • Queremos detectar errores de forma temprana porque los errores cuestan mucho dinero, muchas horas de trabajo de ingenieros de verificación, gestión, desarrolladores. Si dejamos la verificación para final de una liberación de versión, esos errores costarán mucho dinero y como en  la etapa de Dry Run previa a la entrega formal a cliente se suelen detectar muchos errores, los jefes de proyecto suelen aplicar mitigaciones a ese riesgo detectado dando más tiempo (holgura) a estas etapas de corrección quitando tiempo de desarrollo seguramente, con lo cual muy probablemente llegarán más errores aún o no se llegará con la funcionalidad completa, con lo cual, habrá riesgo de retrasos en la entrega.sin dinero en el bolsillo
  • Los requisitos cambian y el papel que un cliente firmó 2 años atrás probablemente no se corresponda con lo que requiere ahora. Con V-Model sólo garantizas que se cumple el contrato, no que se mantenga satisfecho al cliente.

En definitiva, tenemos los mismos errores que teníamos con Waterfall y aumentamos la calidad del entregable sumando un sobrecoste incremental en función de la complejidad del proyecto. Con lo cual a menores complejidades, menor sobrecoste, a mayores complejidades mayor sobrecoste. Si Royce dijo que Waterfall era un modelo de alto riesgo para desarrollo de productos, de V-Model hubiera dicho que era un modelo de altísimo riesgo para desarrollo de productos de alta complejidad.false-98375_640- free

PDFicono EXTENDIDO

REFERENCIAS:

[1] DOD-STD-2167
[2] MIL-STD-498
[3] Managing the development of large systems
D[4] Das V-Modell – XT
[5] V-Model en Wikipedia
[6]ISTQB
[7] Chaos Manifesto 2013

Anuncios

2 thoughts on “El por qué de que muchos proyectos fracasen III: V-Model y sistemas complejos

  1. Hola Dani,

    genial post como siempre. Muy ameno y muy interesante.

    Últimamente estoy leyendo más sobre las metodologías de desarrollo y procesos software, y en todas partes hacen referencia al estudio de Standish Group como base para un cambio (aunque el estudio ya tiene un tiempo dado el avance general de las tecnologías). No he mirado pero supongo que habrá como en todo estudios contrarios, o actualizaciones.

    También comentar que estoy totalmente de acuerdo en que para proyectos grandes es difícil encajar procesos demasiado compartimentados y estáticos sin asumir un coste posiblemente excesivo y solo permitido en ciertas industrias, pero creo que para proyectos pequeños, la diferencia es pequeña también, y que la metodología a usar da un poco igual, siempre que se siga alguna.

    Muchas gracias por tus entradas!

    Me gusta

  2. El último reporte creo que es del 2013 o eso me ha parecido ver y es el que uso en el artículo. Es curioso, pero en 2013 se produjeron ciertos cambios en el pmbok que es el libro referencia del PMI para la certificación de PMP. Es curioso digo porque se incluyeron dentro nuevos conceptos relacionados con las metodologías ágiles y cuando estudias el rol de project manager empiezan ya hablar del rol “tradicional”, el rol “emergente” y el rol futuro, hablando de facilitador… por lo menos en los cursos que se dan de preparación. Es curioso también de la gran influencia que tiene el software en la gestión de proyectos, ya que en otros áreas distintas del software deben tener muchos problemas similares.

    Gracias a ti por leer los artículos y seguir el blog. Muchas gracias.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s