septiembre 6, 2011
Calidad del Software, Gestión de Proyectos
4 comentarios

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