Modelo W

El modelo en W es una evolución del Modelo V.

Más que aportar algo nuevo lo que pretende es aclarar ciertos aspectos que el modelo en V no termina de dejar claros (si bien bastantes de las características del modelo en W ya eran de aplicación en el modelo en V).

Existen diferentes implementaciones del modelo en W, es este artículo me voy a centrar en la propuesta por Paul Herzlich.

En el modelo en V tenemos dos secuencias de pasos, una se consideraba que era de carácter constructivo, la primera recta de la V y la segunda de carácter destructivo (en el mejor de los casos, si ha pasado el test se continua hacia adelante), lo cual seguía marginando en cierto modo las actividades de testing, algo que precisamente intentaba evitar el modelo en V, al situar las mismas a la misma altura y a la vez que las de desarrollo.

En este caso tenemos dos V, una correspondiente al proceso de desarrollo y otra correspondiente al proceso de testing. Hay quienes piensan y tal vez no les falte razón que añadir una V específica para el testing lo único que ha hecho es trasladar el mismo defecto a otra dimensión, ya que vamos a seguir teniendo un caso donde se construye y otro donde se “fiscaliza”, si bien, el hecho de que este modelo integre explícitamente las vueltas a atrás acerca más ambos tipos de tareas.

Y es lógico que sea así porque todos sabemos que es muy complicado (por no decir casi imposible) acertar a la primera, por lo que el proceso de verificación, feedback y ajuste debe entenderse como un proceso integrado en el desarrollo y no como tareas independientes y enfrentadas.

Entonces, si tenemos ahora dos V, qué representa el lado creciente de cada una de ellas. Pues realmente lo que hace el modelo en W es diferenciar cláramente cuáles son los hitos de un proyecto software (algo que podía resultar confuso en el modelo en V) de manera que en la primera recta están los hitos previos a la construcción del software (con las pruebas y verificaciones correspondientes a los hitos documentales) y en la segunda los posteriores a la construcción del software (verificación sobre el producto software).