Modelo V (desarrollo de software)

En el desarrollo de software, el modelo en V representa un proceso de desarrollo que puede considerarse una extensión del modelo en cascada y es un ejemplo del modelo en V más general. En lugar de avanzar linealmente, los pasos del proceso se curvan hacia arriba después de la fase de codificación, para formar la típica forma de V. El modelo en V demuestra las relaciones entre cada fase del ciclo de vida del desarrollo y su fase asociada de prueba. Los ejes horizontal y vertical representan el tiempo o la completitud del proyecto (de izquierda a derecha) y el nivel de abstracción (la abstracción de grano más grueso en la parte superior), respectivamente.

En la fase de análisis de requisitos, el primer paso del proceso de verificación, se recopilan los requisitos del sistema mediante el análisis de las necesidades de los usuarios. Esta fase se ocupa de establecer qué debe hacer el sistema ideal, pero no determina cómo se diseñará o construirá el software. Por lo general, se entrevista a los usuarios y se genera un documento denominado documento de requisitos del usuario.

El documento de requisitos del usuario normalmente describe los requisitos funcionales, de interfaz, de rendimiento, de datos, de seguridad, etc. del sistema tal como los espera el usuario. Los analistas de negocios lo utilizan para comunicar su comprensión del sistema a los usuarios. Los usuarios revisan este documento con atención, ya que servirá como guía para los diseñadores del sistema en la fase de diseño del sistema. Las pruebas de aceptación del usuario se diseñan en esta fase. Consulte también Requisitos funcionales.

Existen diferentes métodos para recopilar requisitos, tanto de metodologías blandas como duras, entre ellos: entrevistas, cuestionarios, análisis de documentos, observación, prototipos descartables, casos de uso y vistas estáticas y dinámicas con usuarios.

El diseño de sistemas es la fase en la que los ingenieros de sistemas analizan y comprenden el negocio del sistema propuesto mediante el estudio del documento de requisitos del usuario. Descubren las posibilidades y técnicas mediante las cuales se pueden implementar los requisitos del usuario. Si alguno de los requisitos no es factible, se informa al usuario sobre el problema. Se encuentra una solución y se edita el documento de requisitos del usuario en consecuencia.

Se genera el documento de especificaciones del software que sirve como modelo para la fase de desarrollo. Este documento contiene la organización general del sistema, las estructuras de menú, las estructuras de datos, etc. También puede contener ejemplos de escenarios comerciales, ventanas de muestra e informes para facilitar la comprensión. En esta fase también se producirá otra documentación técnica, como diagramas de entidades y diccionarios de datos. Se preparan los documentos para las pruebas del sistema.

La fase de diseño de la arquitectura informática y de la arquitectura de software también se puede denominar diseño de alto nivel. La base para seleccionar la arquitectura es que debe incluir todo lo que normalmente consiste en la lista de módulos, una breve funcionalidad de cada módulo, sus relaciones de interfaz, dependencias, tablas de bases de datos, diagramas de arquitectura, detalles tecnológicos, etc. El diseño de pruebas de integración se lleva a cabo en la fase particular.

La fase de diseño del módulo también se puede denominar diseño de bajo nivel. El sistema diseñado se divide en unidades o módulos más pequeños y se explica cada uno de ellos para que el programador pueda comenzar a codificar directamente. El documento de diseño de bajo nivel o las especificaciones del programa contendrán una lógica funcional detallada del módulo, en pseudocódigo:

• tablas de bases de datos, con todos los elementos, incluyendo su tipo y tamaño
• todos los detalles de interfaz con referencias completas de API
• todas las cuestiones relativas a la dependencia
• listados de mensajes de error
• entradas y salidas completas para un módulo.

En esta etapa se desarrolla el diseño de la prueba unitaria.

En el modelo V, cada etapa de la fase de verificación tiene una etapa correspondiente en la fase de validación. A continuación se presentan las fases típicas de validación en el modelo V, aunque pueden conocerse con otros nombres.

En el modelo V, los planes de pruebas unitarias (UTP) se desarrollan durante la fase de diseño del módulo. Estos UTP se ejecutan para eliminar errores a nivel de código o de unidad. Una unidad es la entidad más pequeña que puede existir de forma independiente, por ejemplo, un módulo de programa. Las pruebas unitarias verifican que la entidad más pequeña pueda funcionar correctamente cuando está aislada del resto de los códigos/unidades.

Los planes de pruebas de integración se desarrollan durante la fase de diseño arquitectónico. Estas pruebas verifican que las unidades creadas y probadas de forma independiente puedan coexistir y comunicarse entre sí. Los resultados de las pruebas se comparten con el equipo del cliente.

Los planes de pruebas del sistema se desarrollan durante la fase de diseño del sistema. A diferencia de los planes de pruebas unitarias y de integración, los planes de pruebas del sistema los elabora el equipo comercial del cliente. Las pruebas del sistema garantizan que se cumplan las expectativas de la aplicación desarrollada. Se prueba toda la aplicación para comprobar su funcionalidad, interdependencia y comunicación. Las pruebas del sistema verifican que se hayan cumplido los requisitos funcionales y no funcionales. Las pruebas de carga y rendimiento, las pruebas de estrés, las pruebas de regresión, etc., son subconjuntos de las pruebas del sistema.

Los planes de pruebas de aceptación del usuario (UAT) se desarrollan durante la fase de análisis de requisitos. Los planes de prueba son elaborados por los usuarios comerciales. Las UAT se realizan en un entorno de usuario que se asemeja al entorno de producción, utilizando datos realistas. Las UAT verifican que el sistema entregado cumple con los requisitos del usuario y que el sistema está listo para su uso en tiempo real.

El modelo V ha sido criticado por los defensores de Agile y otros como un modelo inadecuado de desarrollo de software por numerosas razones. Las críticas incluyen:

1. Es demasiado simple para reflejar con precisión el proceso de desarrollo de software, y puede llevar a los administradores a un falso sentido de seguridad. El V-Model refleja una visión de gestión de proyectos del desarrollo de software y se ajusta a las necesidades de los directores de proyectos, contadores y abogados en lugar de desarrolladores de software o usuarios.
2. Aunque es fácil de entender por los novicios, esa comprensión temprana es útil sólo si el novicio continúa adquiriendo una comprensión más profunda del proceso de desarrollo y cómo el V-Model debe ser adaptado y ampliado en la práctica. Si los practicantes persisten con su visión ingenua del V-Model tendrán grandes dificultades para aplicarlo con éxito.
3. Es inflexible y alienta una visión rígida y lineal del desarrollo del software y no tiene capacidad inherente para responder al cambio.
4. Proporciona sólo una ligera variante en el modelo de cascada y por lo tanto está sujeto a las mismas críticas que ese modelo. Se hace mayor hincapié en los ensayos, y en particular en la importancia de la planificación temprana de los ensayos. Sin embargo, una crítica práctica común del V-Model es que conduce a las pruebas que se exprimen en ventanas estrechas al final del desarrollo cuando las etapas anteriores se han superado, pero la fecha de aplicación sigue fijada.
5. Es coherente con los enfoques ineficientes e ineficaces de las pruebas y, por consiguiente, fomenta implícitamente. Promueve implícitamente escribir scripts de prueba de antemano en lugar de pruebas exploratorias; anima a los probadores a buscar lo que esperan encontrar, en lugar de descubrir lo que es realmente allí. También fomenta un vínculo rígido entre los niveles equivalentes de cada pierna (por ejemplo, los planes de prueba de aceptación del usuario que se derivan de documentos de requisitos del usuario), en lugar de alentar a los evaluadores a seleccionar la forma más eficaz y eficiente de planificar y ejecutar pruebas.
6. Falta coherencia y precisión. Hay confusión generalizada sobre lo que es exactamente el V-Model. Si uno lo hierve a aquellos elementos que la mayoría de las personas estarían de acuerdo en ello se convierte en una representación trita e implacable del desarrollo del software. El desacuerdo sobre los méritos del V-Model a menudo refleja una falta de comprensión compartida de su definición.

Los partidarios del modelo V sostienen que ha evolucionado y que favorece la flexibilidad y la agilidad durante todo el proceso de desarrollo. Argumentan que, además de ser un enfoque altamente disciplinado, promueve un diseño, desarrollo y documentación meticulosos, necesarios para crear productos de software estables. Últimamente, lo está adoptando la industria de dispositivos médicos.

• Gestión del ciclo de vida del producto
• Ciclo de vida de desarrollo de sistemas

• Roger S. Pressman:Ingeniería de software: enfoque de un profesional, The McGraw-Hill Companies, ISBN 0-07-301933-X
• Mark Hoffman y Ted Beaumont: Desarrollo de la aplicación: Gestión del Ciclo de Vida del Proyecto, Mc Press, ISBN
• Boris Beizer: Técnicas de pruebas de software. Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3