Modelo V

El modelo V es una representación gráfica del ciclo de vida del desarrollo de sistemas . Se utiliza para generar modelos rigurosos del ciclo de vida del desarrollo y modelos de gestión de proyectos. El modelo V se divide en tres grandes categorías: el modelo alemán V-Modell , un modelo de pruebas general y el estándar del gobierno estadounidense. ^{[ 2 ]}

El modelo V resume los pasos principales que deben seguirse junto con los entregables correspondientes dentro del marco de validación de sistemas informatizados o del ciclo de vida del proyecto. Describe las actividades que deben realizarse y los resultados que deben obtenerse durante el desarrollo del producto.

El lado izquierdo de la "V" representa la descomposición de los requisitos y la creación de especificaciones del sistema. El lado derecho de la "V" representa la integración de las partes y su validación. ^{[ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ]} Sin embargo, los requisitos deben validarse primero con respecto a los requisitos de nivel superior o las necesidades del usuario. Además, también existe algo llamado validación de modelos del sistema. Esto también puede hacerse parcialmente en el lado izquierdo. Afirmar que la validación solo ocurre en el lado derecho puede no ser correcto. La forma más sencilla es decir que la verificación siempre se realiza con respecto a los requisitos (términos técnicos) y la validación siempre se realiza con respecto al mundo real o las necesidades del usuario. El estándar aeroespacial RTCA DO-178B establece que los requisitos se validan —se confirma que son verdaderos— y el producto final se verifica para asegurar que satisface esos requisitos.

La validación se puede expresar con la pregunta "¿Estás construyendo lo correcto?" y la verificación con "¿Lo estás construyendo bien?".

Existen tres tipos generales de modelo V.

A veces se dice que la validación se puede expresar con la pregunta "¿Estás construyendo lo correcto?" y la verificación con "¿Lo estás construyendo bien?". En la práctica, el uso de estos términos varía.

La guía PMBOK , también adoptada por el IEEE como estándar (mantenida conjuntamente por INCOSE, el Consejo de Investigación de Ingeniería de Sistemas SERC y la Sociedad de Computación del IEEE), las define de la siguiente manera en su cuarta edición: ^{[ 17 ]}

• Validación . La garantía de que un producto, servicio o sistema satisface las necesidades del cliente y de otras partes interesadas identificadas. A menudo implica la aceptación y la idoneidad por parte de clientes externos. Contrasta con la verificación .
• " Verificación . La evaluación de si un producto, servicio o sistema cumple o no con una normativa, requisito, especificación o condición impuesta. Suele ser un proceso interno. Contrasta con la validación ."

El modelo V proporciona orientación para la planificación y realización de proyectos. Los siguientes objetivos se pretenden alcanzar mediante la ejecución de un proyecto:

• Minimización de riesgos del proyecto : El modelo V mejora la transparencia y el control del proyecto al especificar enfoques estandarizados y describir los resultados correspondientes y las responsabilidades de cada uno. Permite la detección temprana de desviaciones en la planificación y de riesgos, y optimiza la gestión de procesos, reduciendo así el riesgo del proyecto.
• Mejora y garantía de calidad : Como modelo de proceso estandarizado, el modelo V asegura que los resultados sean completos y de la calidad deseada. Los resultados intermedios definidos pueden verificarse en una etapa temprana. La uniformidad del contenido del producto mejora la legibilidad, la comprensión y la verificabilidad.
• Reducción del coste total a lo largo de todo el ciclo de vida del proyecto y del sistema : El esfuerzo necesario para el desarrollo, la producción, la operación y el mantenimiento de un sistema puede calcularse, estimarse y controlarse de forma transparente mediante la aplicación de un modelo de proceso estandarizado. Los resultados obtenidos son uniformes y fácilmente verificables. Esto reduce la dependencia del comprador respecto al proveedor y el esfuerzo requerido para actividades y proyectos posteriores.
• Mejora de la comunicación entre todas las partes interesadas : La descripción estandarizada y uniforme de todos los elementos y términos relevantes constituye la base para el entendimiento mutuo entre todas las partes interesadas. De este modo, se reduce la fricción entre el usuario, el comprador, el proveedor y el desarrollador.

El modelo V se utiliza para regular el proceso de desarrollo de software dentro de la administración federal alemana. Actualmente, sigue siendo el estándar para los proyectos de la administración federal y de defensa alemanas, así como para los desarrolladores de software de la región.

El concepto del modelo en V se desarrolló simultáneamente, pero de forma independiente, en Alemania y en Estados Unidos a finales de la década de 1980:

• El modelo V alemán fue desarrollado originalmente por IABG en Ottobrunn, cerca de Múnich, en cooperación con la Oficina Federal de Tecnología y Adquisiciones de Defensa en Coblenza, para el Ministerio Federal de Defensa. Fue asumido por el Ministerio Federal del Interior para el ámbito de las autoridades públicas civiles en el verano de 1992. ^{[ 19 ]}
• El modelo V de EE. UU., tal como se documenta en las actas de 1991 del Consejo Nacional de Ingeniería de Sistemas (NCOSE; ahora INCOSE desde 1995), ^{[ 7 ]} se desarrolló para sistemas satelitales que involucran hardware, software e interacción humana.
• El modelo V apareció por primera vez en Hughes Aircraft alrededor de 1982 como parte del esfuerzo de prepropuesta para el programa del Sistema Avanzado de Automatización (AAS) de la FAA. Finalmente, constituyó la estrategia de prueba para la propuesta de la Fase de Competencia de Diseño (DCP) del AAS de Hughes. Fue creado para mostrar el enfoque de prueba e integración, impulsado por nuevos desafíos para descubrir defectos latentes en el software. La necesidad de este nuevo nivel de detección de defectos latentes surgió del objetivo de comenzar a automatizar los procesos de pensamiento y planificación del controlador de tráfico aéreo, tal como lo preveía el programa de control de tráfico aéreo en ruta automatizado (AERA). La razón por la que la V es tan poderosa proviene de la cultura de Hughes de vincular todo el texto y el análisis con imágenes multidimensionales. Fue la base de la Organización Temática Secuencial de Publicaciones (STOP) ^{[ 20 ]} , creada por Hughes en 1963 y utilizada hasta que Hughes fue vendida por el Instituto Médico Howard Hughes en 1985. ^{[ 21 ]}
• El Departamento de Defensa de los Estados Unidos coloca las interacciones del proceso de ingeniería de sistemas en una relación de modelo V. ^{[ 22 ]}

Ahora ha encontrado una amplia aplicación tanto en programas comerciales como de defensa. Su uso principal es en la gestión de proyectos ^{[ 3 ] [ 4 ]} y a lo largo de todo el ciclo de vida del proyecto.

Una característica fundamental del modelo V estadounidense es que el tiempo y la madurez se mueven de izquierda a derecha y no se puede retroceder en el tiempo. Toda iteración se realiza a lo largo de una línea vertical hacia niveles superiores o inferiores en la jerarquía del sistema, como se muestra en la figura. ^{[ 3 ] [ 4 ] [ 7 ]} Esto ha demostrado ser un aspecto importante del modelo. La expansión del modelo a un concepto de doble V se trata en la referencia. ^{[ 3 ]}

Dado que el modelo V es de acceso público, muchas empresas lo utilizan. En la gestión de proyectos, es un método comparable a PRINCE2 y describe tanto métodos de gestión de proyectos como de desarrollo de sistemas . Si bien el modelo V es rígido en su proceso, puede ser muy flexible en su aplicación, especialmente en lo que respecta al alcance que se encuentra fuera del ámbito de los parámetros normales del ciclo de vida del desarrollo de sistemas.

Estas son las ventajas que ofrece el modelo V frente a otros modelos de desarrollo de sistemas:

• Los usuarios del modelo V participan en su desarrollo y mantenimiento. Un comité de control de cambios mantiene públicamente el modelo V. Este comité se reúne con una frecuencia que varía de diaria a semanal y procesa todas las solicitudes de cambio recibidas durante el desarrollo y las pruebas del sistema. ^{[ 23 ]}
• El modelo V proporciona asistencia concreta sobre cómo implementar una actividad y sus pasos de trabajo, definiendo explícitamente los eventos necesarios para completar un paso de trabajo: cada esquema de actividad contiene instrucciones, recomendaciones y explicaciones detalladas de la actividad. ^{[ 24 ]}

Los siguientes aspectos no están cubiertos por el modelo V, deben regularse adicionalmente o el modelo V debe adaptarse en consecuencia: ^{[ 25 ] [ 26 ]}

• La formalización de contratos de servicios no está regulada.
• La organización y ejecución de la operación, el mantenimiento, la reparación y la eliminación del sistema no están contempladas en el modelo V. Sin embargo, la planificación y la elaboración de un concepto para estas tareas sí están reguladas en dicho modelo.
• El modelo V aborda el desarrollo de software dentro de un proyecto, en lugar de en toda una organización.

• Gestión de la información de ingeniería (EIM)
• ARCADIA (como método de modelado de sistemas de apoyo)
• Proceso Unificado Rational de IBM (como proceso de software de soporte)
• Modelo de desarrollo de software en cascada
• Arquitectura de sistemas
• Diseño de sistemas
• Ingeniería de sistemas basada en modelos
• Teoría U

• "INCOSE G2SEBOK 3.30: Modelo Vee de Diseño e Integración de Ingeniería de Sistemas" . g2sebok.incose.org . Consejo Internacional de Ingeniería de Sistemas . Archivado del original el 27 de septiembre de 2007.
• "Das V-Modell XT" . cio.bund.de (en alemán). Oficina Federal de Seguridad de la Información (BMI). Archivado del original el 18 de noviembre de 2016. Consultado el 6 de noviembre de 2016 .
• "Uso de modelos V para pruebas" . insights.sei.cmu.edu . Instituto de Ingeniería de Software , Universidad Carnegie Mellon . 11 de noviembre de 2013.