Modelo V (desarrollo de software)

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "V-model" software development – news · newspapers · books · scholar · JSTOR (September 2018) (Learn how and when to remove this message)

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 :

• Tablas de base de datos, con todos los elementos, incluido su tipo y tamaño.
• Todos los detalles de la interfaz con referencias API completas
• todos los problemas de dependencia
• listados de mensajes de error
• Entrada 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. ^[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:

1. Es demasiado simple para reflejar con precisión el proceso de desarrollo de software y puede llevar a los gerentes a una falsa sensación de seguridad. El modelo V refleja una visión de gestión de proyectos del desarrollo de software y se adapta a las necesidades de gerentes de proyectos, contadores y abogados, más que a las de desarrolladores o usuarios de software.
2. Aunque los principiantes lo entienden fácilmente, esa comprensión temprana sólo es útil si el principiante adquiere una comprensión más profunda del proceso de desarrollo y de cómo debe adaptarse y extenderse el Modelo V en la práctica. Si los profesionales persisten en su visión ingenua del Modelo V, tendrán grandes dificultades para aplicarlo con éxito.
3. Es inflexible y fomenta una visión rígida y lineal del desarrollo de software y no tiene capacidad inherente para responder al cambio.
4. Este modelo sólo ofrece una pequeña variante del modelo en cascada y, por lo tanto, está sujeto a las mismas críticas que este último. Hace mayor hincapié en las pruebas y, en particular, en la importancia de la planificación temprana de las pruebas. Sin embargo, una crítica práctica común al modelo V es que hace que las pruebas se reduzcan a períodos muy cortos al final del desarrollo, cuando las etapas anteriores se han extendido pero la fecha de implementación sigue siendo fija.
5. Es coherente con los enfoques ineficientes e ineficaces de las pruebas y, por lo tanto, los fomenta implícitamente. Promueve implícitamente la redacción de guiones de prueba con antelación en lugar de pruebas exploratorias; alienta a los evaluadores a buscar lo que esperan encontrar, en lugar de descubrir lo que realmente está ahí. También fomenta un vínculo rígido entre los niveles equivalentes de cada rama (por ejemplo, planes de prueba de aceptación del usuario derivados 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 las pruebas.
6. Carece de coherencia y precisión. Existe una gran confusión sobre qué es exactamente el modelo V. Si se reduce a los elementos en los que la mayoría de la gente estaría de acuerdo, se convierte en una representación trivial e inútil del desarrollo de software. El desacuerdo sobre los méritos del modelo V 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. ^[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]}

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

• Roger S. Pressman: Ingeniería de software: un enfoque práctico , The McGraw-Hill Companies, ISBN 0-07-301933-X 
• Mark Hoffman y Ted Beaumont: Desarrollo de aplicaciones: gestión del ciclo de vida del proyecto , Mc Press, ISBN 1-883884-45-4 
• Boris Beizer: Técnicas de prueba de software. Segunda edición, International Thomson Computer Press, 1990, ISBN 1-85032-880-3 

Wikimedia Commons alberga una categoría multimedia sobre Modelos V.