En el desarrollo de software , el modelo V [2] representa un proceso de desarrollo que puede considerarse una extensión del modelo en cascada y es un ejemplo del modelo V más general . En lugar de moverse linealmente hacia abajo, los pasos del proceso se doblan hacia arriba después de la fase de codificación , para formar la forma típica de V. El modelo 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 (abstracción de grano más grueso en la parte superior), respectivamente.
En la fase de análisis de requisitos , primer paso del proceso de verificación, se recogen 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. Normalmente, se entrevista a los usuarios y se genera un documento denominado documento de requisitos del usuario.
El documento de requisitos del usuario generalmente 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 este documento 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 de metodologías tanto 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 los 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 de la computadora y la arquitectura del software también se puede denominar diseño de alto nivel. La base para seleccionar la arquitectura es que debe realizar todo lo que normalmente consiste en la lista de módulos, la funcionalidad breve de cada módulo, sus relaciones de interfaz , dependencias , tablas de base de datos , diagramas de arquitectura, detalles de tecnología, etc. El diseño de pruebas de integración se lleva a cabo en la fase particular. [3]
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 :
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. [4] Las siguientes son las fases típicas de validación en el modelo V, aunque pueden conocerse por 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 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. [5] [6] [7] Las críticas incluyen:
Los partidarios del modelo V sostienen que ha evolucionado y que favorece la flexibilidad y la agilidad durante todo el proceso de desarrollo. [8] 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. [9] [10]
