¿Qué es el modelo V?

El modelo V o modelo en cuatro niveles es un modelo empleado en diversos procesos de de­sa­rro­llo, por ejemplo, en el de­sa­rro­llo de software. En los años 90 apareció su primera versión, pero con el tiempo se ha ido pe­r­fe­c­cio­na­n­do y adaptando a los métodos modernos de de­sa­rro­llo. La idea básica, sin embargo, se remonta a los años 70 y fue concebida como una especie de de­sa­rro­llo posterior del modelo de cascada.

Además de las fases de de­sa­rro­llo de un proyecto, el modelo V también define los pro­ce­di­mie­n­tos de gestión de la calidad que lo acompañan y describe cómo pueden in­ter­ac­tuar estas fases in­di­vi­dua­les entre sí. Su nombre se debe a su es­tru­c­tu­ra, que se asemeja a la letra V.

En primer lugar, el modelo V define el curso de un proyecto en fases in­di­vi­dua­les cada vez más de­ta­lla­das:

• Al principio del proyecto, el modelo prevé un análisis de las es­pe­ci­fi­ca­cio­nes del sistema pla­ni­fi­ca­do (fase de es­pe­ci­fi­ca­cio­nes).
• El proyecto se completa después con re­qui­si­tos fu­n­cio­na­les y no fu­n­cio­na­les para la ar­qui­te­c­tu­ra del sistema (fase funcional).
• A esta fase le sigue el diseño del sistema, en el que se pla­ni­fi­can los co­m­po­ne­n­tes y las in­te­r­fa­ces de este (fase de diseño).
• Una vez co­m­ple­ta­das estas fases, se puede diseñar en detalle la ar­qui­te­c­tu­ra del software (co­di­fi­ca­ción).

Es ahora cuando, de acuerdo con estos planes, comienza el de­sa­rro­llo en sí del software. A co­n­ti­nua­ción, tendrán lugar las fases de control de la calidad, también llamadas de ve­ri­fi­ca­ción o va­li­da­ción, que siempre están re­la­cio­na­das con cada una de las fases de de­sa­rro­llo. El método V abarca las si­guie­n­tes tareas:

• Pruebas de unidad
• Pruebas de in­te­gra­ción
• In­te­gra­ción del sistema
• Va­li­da­ción

La “V” del nombre del modelo hace re­fe­re­n­cia a la forma como el modelo compara las fases de de­sa­rro­llo con las fases de control de la calidad co­rre­s­po­n­die­n­tes. El brazo izquierdo de la letra V contiene las tareas de diseño y de­sa­rro­llo del sistema, y el derecho las medidas de control de calidad de cada fase. En la unión entre los dos brazos, se sitúa la im­ple­me­n­ta­ción del producto. En los proyectos de software, esto se refiere a la pro­gra­ma­ción del software.

La im­ple­me­n­ta­ción correcta de la ar­qui­te­c­tu­ra de software pla­ni­fi­ca­da se comprueba mediante pruebas de unidad. Aquí se verifica en detalle si los módulos in­di­vi­dua­les del software cumplen exac­ta­me­n­te las funciones re­que­ri­das y pro­po­r­cio­nan realmente los re­su­l­ta­dos que se esperan. Para evitar errores, se re­co­mie­n­da realizar estas pruebas en paralelo al de­sa­rro­llo.

Las pruebas de in­te­gra­ción examinan el diseño del sistema. Aquí se verifica si cada uno de los co­m­po­ne­n­tes in­ter­ac­túa con el resto según lo pla­ni­fi­ca­do –por ejemplo, si todos los procesos pro­po­r­cio­nan los re­su­l­ta­dos esperados. En este punto, un resultado in­co­rre­c­to podría indicar un problema de interfaz.

La prueba del sistema verifica si se han cumplido los re­qui­si­tos generales del sistema definidos al diseñar la ar­qui­te­c­tu­ra del sistema. En general, estas pruebas tienen lugar en un entorno de pruebas que simula las co­n­di­cio­nes reales del cliente con la mayor precisión posible.

Al final del proyecto, al análisis de los re­qui­si­tos se co­n­tra­po­ne la va­li­da­ción del producto terminado. En ella, el cliente comprueba si se cumplen las es­pe­ci­fi­ca­cio­nes durante el fu­n­cio­na­mie­n­to. Como regla general, solo se prueba el re­n­di­mie­n­to del software de forma su­pe­r­fi­cial, es decir, se comprueba lo que el cliente ve durante el uso diario. Esto también se conoce como prueba de va­li­da­ción.

En 2006, se revisó el modelo V para que reflejara nuevos pri­n­ci­pios como el de­sa­rro­llo ágil. El resultado fue el modelo V XT. XT se refiere a Extreme Tailoring y describe la nueva po­si­bi­li­dad de adaptar el modelo a los re­qui­si­tos de cada proyecto.

Una idea fu­n­da­me­n­tal detrás de esta revisión era pro­po­r­cio­nar un modelo que pudiera adaptarse de forma versátil a proyectos de di­fe­re­n­tes tamaños. En los proyectos más pequeños, en pa­r­ti­cu­lar, el método antiguo era a menudo demasiado costoso y, por lo tanto, in­e­fi­cie­n­te, pero con el Modelo V XT es posible eliminar ciertas fases que re­que­ri­rían esfuerzo extra.

Además, el nuevo modelo también incluye bloques de tareas ajustadas ex­plí­ci­ta­me­n­te al cliente. El modelo antiguo solo se ocupa de la gestión del proyecto por parte del proveedor antes de la ace­p­ta­ción de­fi­ni­ti­va. En el nuevo modelo, el cliente está más in­vo­lu­cra­do.

El modelo se seguirá revisando pe­rió­di­ca­me­n­te para que refleje las in­no­va­cio­nes en el proceso de de­sa­rro­llo de programas in­fo­r­má­ti­cos y mejorar su idoneidad para su uso práctico. La última versión del Modelo V XT es la versión 2.3.

El modelo V XT es un modelo muy arraigado en la industria ya que está di­s­po­ni­ble pú­bli­ca­me­n­te. En la mayoría de las ofertas de nuevos proyectos de software de las au­to­ri­da­des públicas, el uso del modelo V es incluso obli­ga­to­rio y, por lo tanto, es un pilar esencial, es­pe­cia­l­me­n­te en las empresas que de­sa­rro­llan software para las au­to­ri­da­des públicas y los mi­ni­s­te­rios. Se puede im­ple­me­n­tar en proyectos de software de cualquier tamaño, ya sea en empresas, en el sector militar o en el sector público. Es una he­rra­mie­n­ta que facilita la or­ga­ni­za­ción e im­ple­me­n­ta­ción del de­sa­rro­llo, ma­n­te­ni­mie­n­to y de­sa­rro­llo de una amplia variedad de sistemas de TIC.

Asimismo, el modelo V también puede uti­li­zar­se en otras áreas de de­sa­rro­llo, por ejemplo, para sistemas ele­c­tró­ni­cos o mecánicos en in­ve­s­ti­ga­ción y ciencia. En estos ámbitos de apli­ca­ción, existen algunas variantes adaptadas que reflejan los pasos de proceso típicos de la di­s­ci­pli­na.

El motivo principal de la po­pu­la­ri­dad del modelo V es que garantiza un alto grado de tra­n­s­pa­re­n­cia y propone unos procesos cla­ra­me­n­te definidos y co­m­pre­n­si­bles. A co­n­ti­nua­ción, te damos un resumen de las pri­n­ci­pa­les ventajas y puntos me­jo­ra­bles.

• Op­ti­mi­za­ción de la co­mu­ni­ca­ción entre las partes in­vo­lu­cra­das a través de términos y re­s­po­n­sa­bi­li­da­des cla­ra­me­n­te definidos.
• Mi­ni­mi­za­ción de riesgos y mejor pla­ni­fi­ca­ción a través de roles, es­tru­c­tu­ras y re­su­l­ta­dos fijos y pre­de­te­r­mi­na­dos.
• Mejora de la calidad del producto gracias a medidas de control de la calidad fi­r­me­me­n­te in­te­gra­das.
• Ahorro de costes gracias al pro­ce­sa­mie­n­to tra­n­s­pa­re­n­te a lo largo de todo el ciclo de vida del producto.

En general, el modelo puede ayudar a evitar ma­le­n­te­n­di­dos y trabajo in­ne­ce­sa­rio. También garantiza que todas las tareas se completen en el plazo y orden adecuado y mantiene los periodos de inac­ti­vi­dad al mínimo.

El modelo en cuatro niveles puede ser demasiado simple para mapear todo el proceso de de­sa­rro­llo desde el punto de vista de los de­sa­rro­lla­do­res. Está sobre todo centrado en la gestión de proyectos. Además, su es­tru­c­tu­ra re­la­ti­va­me­n­te rígida permite una respuesta poco flexible a los cambios durante el de­sa­rro­llo, y, por lo tanto, promueve un curso lineal del proyecto. Sin embargo, si el modelo se entiende y se utiliza co­rre­c­ta­me­n­te, es posible utilizar el modelo V para el de­sa­rro­llo ágil.

En el de­sa­rro­llo de software hay muchos modelos que, en función del proyecto y el equipo, pueden tomarse en co­n­si­de­ra­ción como métodos de de­sa­rro­llo de software. Hay una variedad re­la­ti­va­me­n­te grande de modelos de proceso, como, por ejemplo, los populares modelos de cascada y en espiral. El modelo en cascada es pa­r­ti­cu­la­r­me­n­te adecuado para proyectos pequeños y lineales, mientras que el modelo en espiral se re­co­mie­n­da para proyectos de es­tru­c­tu­ra iterativa.