Desarrollo de software. Testing. Modelo en W

El modelo en W es una evolución del modelo en 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).

Desarrollo de software. Testing. Modelo en V

El modelo en V se suele entender como una metodología de testing, sin embargo, se trata en realidad de una adaptación del ciclo de vida clásico o en cascada realizado por el gobierno federal alemán (aunque también existen versiones de esta metodología que se desarrollaron en paralelo o independientemente a la misma) en la cual se pretende aliviar algunos de sus problemas, como por ejemplo la validación tardía que se realizaba del producto (generalmente en el momento de la entrega), realizando validaciones y verificaciones en paralelo al proceso de desarrollo, las cuales están adaptadas a la fase del proyecto en la que nos encontremos.

Desde mi punto de vista se trataba de normalizar ciertas buenas prácticas que ya se venían llevando a cabo en desarrollos en cascada como la revisión por etapas de los entregables de las mismas, así como la definición de los casos de prueba específicos en cada una de ellas (se rompía en cierto modo con lo que era estrictamente una cascada pero resultaba totalmente razonable no dejar toda la «suerte» del desarrollo a las etapas finales del ciclo de vida).

Por tanto, se trata de un modelo en cascada con vitaminas, mejorado, pero que arrastra las principales carencias del modelo.

La V del modelo representa a dos secuencias de fases, la primera se corresponde con la secuencia de fases de desarrollo del proyecto y la segunda con la secuencia de fases de testing del proyecto. Las fases de un mismo nivel se realizan en paralelo. Estas dos cascadas se muestran más alejadas cuanto más abstracta es la visión del producto, es decir, en las etapas más tempranas y se acercan hasta tener como punto de unión la codificación o punto más concreto del desarrollo de software.

La V también se puede considerar como la metáfora de una vuelta atrás cuando en el proceso de testing de una fase no se cumple con las expectativas de la misma (si bien, se considera que la representación gráfica del modelo no deja bien claro este hecho, lo que entre otras causas, como por ejemplo que tampoco deja claro que hito software es el que verifica, lo que originó la aparición del modelo en W).

¿Qué defectos presenta este modelo? Al igual que la cascada la diferencia de tiempo existente entre el inicio del proyecto y la puesta en producción, existiendo una ventana de tiempo lo suficientemente importante como para que se produzcan contingencias en el proyecto (cambio en las especificaciones, cambios en los procesos, cambios organizativos, cambios de interlocutores, cambio de prioridades, etc…) que puedan afectar gravemente al proceso de desarrollo.

Además, al igual que la cascada es un modelo predictivo en el que se da por supuesto de que la diferencia entre lo que se entiende que quiere el usuario, el usuario cree que quiere y el producto final es muy pequeña, cuando la realidad indica que por regla general esa diferencia es importante y que cuando antes se ataje, menores serán los costes necesarios para obtener un producto acorde a las expectativas del usuario. Para evitar esto interesa obtener el feedback del usuario cuanto antes, lo que obliga a ir liberando versiones del producto periódicamente (en periodos cortos aunque acordes con las características del proyecto).

Desarrollo de software. Michael Anthony Jackson. Software, percepción, realidad

Michael Anthony Jackson es otro de los padres de la programación estructurada y ha sido un especialista en el campo de la ingeniería del software y de las metodologías de desarrollo (hasta un total de tres llevan su firma). Profesor universitario, autor de libros y artículos e investigador en AT&T, han sido sus principales ocupaciones.

Esta reflexión, es en mi opinión una de las que mejor representa la problemática del desarrollo de software: «El software es solo una interpretación de la realidad del problema que se está resolviendo».

Precisamente ahí es donde estriba la complejidad del desarrollo de software, en alinear la percepción de los usuarios con la de los desarrolladores, teniendo en cuenta que cada usuario tiene su propia percepción y que cada desarrollador también la tiene. Y todo ello con un producto software que hay que desarrollar, por lo que la ejecución también es importante, en unos plazos y en un presupuesto dado.

Esta visión del desarrollo de software nos lleva inevitablemente a las metodologías ágiles y a los desarrollos de carácter iterativo e incremental ya que es la estrategia que más se aproxima a esta realidad, ya que resulta muy complicado en un proceso de análisis acertar con las percepciones del usuario y todavía resulta más complejo si el posterior proceso de construcción se extiende mucho en el tiempo y empiezan a aparecer contingencias que provocan desviaciones respecto a esa interpretación realizada de lo que quiere el usuario (por mucho que la haya aprobado).