El por qué de que muchos proyectos fracasen II: de Waterfall a V-Model

El artículo de Waterfall, fue un artículo que recuerdo que me salió “del tirón”. Esto es debido a que es la metodología que más se imparte en las escuelas universitarias y a la vez la más criticada. Sin embargo, muy pocas empresas siguen esta metodología y al final de lo que estamos hablando son de evoluciones que han surgido tratando de solventar los problemas mencionados en el artículo anterior. Un perfil de empresa multinacional dedicada al software parcialmente y que tiene un origen industrial tiene normalmente impuesto una metodología de modelo en V ya que es la más utilizada en desarrollos industriales (empresas en sectores ferroviario, aeronáutico, energía, espacial, etc.). Estas empresas intentan trasladar este modelo a sus departamentos software por uniformidad y en la gran mayoría de los casos tienen problemas.

spiderman camuflajeado

Sin embargo, en resto de perfiles de empresas solemos encontrar un poco de todo, pero normalmente encontramos:

  • Una ausencia de metodología de desarrollo o lo que conocemos como “todos a una” o “sobre la marcha”. Normalmente la empresa de cara a cliente dice que cumple V-Model (o cualquier otro) ya que parece que las grandes empresas lo cumplen y “es como deberíamos hacerlo”, o “hacia donde deberíamos tender”.
  • Una metodología “inventada” que suele coincidir bastante con muchos de los principios ágiles. No son agilistas pero si son ágiles. Normalmente estas metodologías provienen del sentido común de desarrolladores con muchísimos años de experiencia. 
  • Alguna metodología ágil, normalmente SCRUM. Estas empresas normalmente suelen ser dedicadas exclusivamente a software aunque actualmente muchas empresas de origen industrial están tratando de hacer el traslado de sus metodologías tradicionales a metodologías ágiles por la reducción de coste que conlleva y el aumento de calidad.
  • Otras metodologías de ciclo en espiral como por ejemplo RUP. Que es una aproximación a V-Model pero más realista y adaptado al desarrollo software. Mi experiencia con RUP es que al final se hace lo mismo de siempre porque los mismos problemas siguen latentes, pero se documenta con casos de usos y en UML “que es mano de santo”. Lo bueno que tiene RUP es que al menos asume que los requisitos son cambiantes por lo que se hace una aproximación en fases para definir el sistema a través del feedback que da el cliente. Lo malo: documentación innecesaria, que hay que mantener  y las fases de obtención de feedback están acotadas a cuatro. Actualmente RUP ha evolucionado a AUP (Agile Unified Process), donde dejan las cuatro fases de RUP y sustituyen todo el conglomerado interno de V-Model por técnicas ágiles.

Rup_espanolVolviendo al tema del artículo, básicamente V-Model o método en V es un ciclo de desarrollo basado en fases secuenciales al igual que Waterfall. De hecho, algunos lo consideran una extensión de este último. En este modelo, una vez llegada a la fase de codificación, la fase de pruebas se transforma en una cascada inversa tratando de verificar cada una de las fases de desarrollo terminando con una fase de aceptación con cliente (Validación). Realmente esta fase de pruebas se realiza simultáneamente cuando periódicamente se van liberando versiones (versiones de requisitos, versiones de software, etc.).

V-Model

El origen de este modelo es alemán. Algunos cuentan que se desarrolló simultáneamente e independientemente en Estados Unidos y Alemania, pero lo que realmente se hizo simultáneamente fue aplicarlo al desarrollo software ya que antes era el método diseñado por el gobierno alemán de desarrollo de proyectos industriales para el estado alemán. Cuando Estados Unidos trató de remediar el error de Waterfall, desarrolló el V-Model basándose en este concepto. Alemania por su parte hizo lo mismo por la misma época llevando su modelo industrial al mundo del software. Podéis encontrar su última versión aquí (aunque está en alemán, creo que por algún lado puedes descargar la información en inglés). Hoy en día existen muchas versiones de V-Model, a cada cual más compleja. La filosofía es: “cuanto más complejo es el sistema, más compleja es la implementación de V-Model”. Y esta idea, quizá es la pieza angular de su fallo dentro del desarrollo software. Como curiosidad, echad un vistazo a la versión “Dual V Model” que es ideada para sistemas de alta complejidad y entenderéis a lo que me refiero (a los que hayan trabajado con el MIL-STD-498, les sonará). Aunque el dibujo asusta, no deja de hacer lo mismo que hace RUP, un V-Model pero con varias fases con una quality gate asociada a cada fase.

Architecture_and_Entity_Vees_Intersecting

El modelo en V posee el mismo principio que poseía Waterfall: “es óptimo siempre y cuando no pasemos de una fase a otras sin haber finalizado la anterior”. El plus que le da es que además cada etapa posee una etapa de verificación y trazabilidad que garantiza conocer cuál es el estado actual de cada versión liberada, lo cual era un gran problema en Waterfall porque no disponían de nada objetivo que informara si se estaba preparado para pasar a la siguiente fase (como los requisitos son cambiantes, nunca se estaría preparado para pasar a la siguiente fase, por lo que al final  se utiliza esta información para saber “el estado” del producto). Los planes de prueba y la trazabilidad garantizan que si todo está OK realmente todo cumple las expectativas.

cool-freeA pesar que ya en 1970, se hizo una crítica constructiva y con bases a Waterfall, por algún motivo se decide ignorar e implantar como un estándar en Estados Unidos en 1985. Posteriormente tras el fracaso que tiene esta metodología surgen aclaraciones del modelo cuya tendencia les hacía dar mayor peso a las fases de pruebas (aunque todavía no hablan de un modelo en V como tal). Este estándar es cancelado en 1994 y sustituido por el MIL-STD-498. Hay que aclarar que estos estándares no son modelos como tal, sino que describen la documentación debe ser entregada y como debe estar estructurada. Sin embargo, hacen una serie de recomendaciones que lo ligan indirectamente al un modelo de desarrollo concreto. Por ejemplo en el caso del MIL-STD-498, la documentación que establece, obliga a realizar un análisis top-down, con un diseño de arquitectura, diseño detallado, testing a nivel de sistema, a nivel de integración, etc… con lo cual o utilizas RUP o V-Model, o te vuelves loco intentando cumplirlo.

hasta arriba

Con V-Model, tenemos los mismos errores que teníamos con Waterfall y  tratamos de minimizarlos a través de un aumento considerable en cuanto a verificación y validación. Debido a que toda esta ingeniería de pruebas generada alrededor de este modelo genera una complejidad extremadamente difícil de manejar en sistemas complejos, los modelos evolucionan hacia RUP o Dual V Model para poder ir refinando en varias fases esos requisitos contractuales y obtener feedback en cada fase.  Esto puede funcionar relativamente con éxito en proyectos pequeños (de menos de 1 Millón de euros) pero en proyectos grandes (más de 10 Millones de euros) tiende a ser un auténtico desastre, ya que con V-Model, al aumentar la complejidad del proyecto aumentará la complejidad de la gestión. Esta última idea, la desarrollaremos en el siguiente artículo. Os dejo los resultados de éxito, fracaso y sobrecoste de proyectos según el informe por el Standish Group.

smallLargeprojects

waterfall-vs-agile

PDFicono EXTENDIDO

REFERENCIAS:

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

Anuncios

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