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).
