Modelo V

El modelo V es una representación gráfica del ciclo de vida de desarrollo de sistemas. Se utiliza para producir modelos rigurosos de ciclo de vida de desarrollo y modelos de gestión de proyectos. El modelo V se divide en tres categorías amplias: el V-Modell alemán, un modelo de prueba general y el estándar del gobierno de EE. UU.

El modelo V resume los pasos principales que se deben tomar junto con los entregables correspondientes dentro del marco de validación del sistema computarizado o el desarrollo del ciclo de vida del proyecto. Describe las actividades a realizar y los resultados que deben producirse durante el desarrollo del producto.

El lado izquierdo de la "V" representa la descomposición de requisitos y la creación de especificaciones del sistema. El lado derecho de la "V" representa una integración de partes y su validación. 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 como la validación de modelos de sistemas. Esto también se puede hacer parcialmente en el lado izquierdo. Afirmar que la validación sólo ocurre en el lado derecho puede no ser correcto. La forma más sencilla es decir que la verificación siempre se realiza según los requisitos (términos técnicos) y la validación siempre se realiza según el 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 garantizar que los cumpla.

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

Tipos

Hay tres tipos generales de modelo V.

Modelo V

"Modelo V" es el método oficial de gestión de proyectos del gobierno alemán. Es aproximadamente equivalente a PRINCE2, pero más directamente relevante para el desarrollo de software. El atributo clave de usar una "V" La representación debía exigir pruebas de que los productos del lado izquierdo de la V eran aceptables por la organización de prueba e integración apropiada que implementaba el lado derecho de la V.

Pruebas generales

En toda la comunidad de pruebas de todo el mundo, el modelo V se considera ampliamente como una descripción ilustrativa más vaga del proceso de desarrollo de software tal como se describe en el plan de estudios de la Fundación de la Junta Internacional de Cualificaciones de Pruebas de Software para probadores de software. No existe una definición única de este modelo, que se trata más directamente en el artículo alternativo sobre el V-Model (desarrollo de software).

Estándar del gobierno de EE. UU.

Estados Unidos también tiene un modelo V estándar del gobierno que data de hace unos 20 años, al igual que su homólogo alemán. Su alcance es un modelo de ciclo de vida de desarrollo de sistemas más limitado, pero mucho más detallado y riguroso de lo que la mayoría de los profesionales y evaluadores del Reino Unido entenderían por el modelo V.

Validación versus verificación

A veces se dice que la validación se puede expresar mediante la pregunta "¿Estás construyendo lo correcto?" y verificación por "¿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 Systems Engineering Research Council SERC y IEEE Computer Society) los define de la siguiente manera en su 4ª edición:

• "Validación. La garantía de que un producto, servicio o sistema satisface las necesidades del cliente y otros interesados identificados. A menudo implica aceptación y idoneidad con clientes externos. Contraste con Verificación."
• "Verificación. La evaluación de si un producto, servicio o sistema cumple con una regulación, requisito, especificación o condición impuesta. A menudo es un proceso interno. Contraste con validación."

Objetivos

El modelo V proporciona orientación para la planificación y realización de proyectos. Se pretende alcanzar los siguientes objetivos mediante la ejecución de un proyecto:

• Minimización de los riesgos del proyecto: El modelo V mejora la transparencia del proyecto y el control del proyecto especificando enfoques estandarizados y describiendo los resultados correspondientes y las funciones responsables. Permite un reconocimiento temprano de las desviaciones y riesgos de planificación y mejora la gestión de procesos, reduciendo así el riesgo de proyecto.
• Mejora y garantía de calidad: Como modelo de proceso estandarizado, el modelo V garantiza que los resultados a proporcionar sean completos y tengan la calidad deseada. Los resultados provisionales definidos se pueden comprobar en una etapa temprana. El contenido uniforme del producto mejorará la legibilidad, la comprensión y la verificabilidad.
• Reducción del costo total en todo el ciclo de vida del proyecto y del sistema: El esfuerzo para el desarrollo, producción, funcionamiento y mantenimiento de un sistema se puede calcular, estimar y controlar de manera transparente aplicando un modelo de proceso estandarizado. Los resultados obtenidos son uniformes y fácilmente retratados. Esto reduce la dependencia del comprador del proveedor y el esfuerzo por actividades y proyectos posteriores.
• Mejora de la comunicación entre todos los interesados: La descripción estandarizada y uniforme de todos los elementos y términos pertinentes es la base para el entendimiento mutuo entre todos los interesados. Así, la pérdida friccional entre el usuario, el comprador, el proveedor y el desarrollador se reduce.

Temas del modelo V

Ingeniería y verificación de sistemas

El proceso de ingeniería de sistemas (SEP) proporciona un camino para mejorar la eficacia en función de los costos de los sistemas complejos que experimenta el propietario del sistema durante toda la vida del sistema, desde la concepción hasta la jubilación.

Implica la identificación temprana y completa de objetivos, un concepto de operaciones que describe las necesidades del usuario y el entorno operativo, requisitos del sistema exhaustivos y comprobables, diseño detallado, implementación y pruebas de aceptación rigurosas del sistema implementado para garantizar que cumple con los requisitos establecidos. (verificación del sistema), midiendo su eficacia para abordar los objetivos (validación del sistema), operación y mantenimiento continuos, actualizaciones del sistema a lo largo del tiempo y eventual retiro.

El proceso enfatiza el diseño y las pruebas basadas en requisitos. Todos los elementos de diseño y pruebas de aceptación deben ser trazables a uno o más requisitos del sistema y cada requisito debe ser abordado por al menos un elemento de diseño y prueba de aceptación. Este rigor garantiza que no se haga nada innecesariamente y que se cumpla todo lo necesario.

Las dos corrientes

Flujo de especificaciones

El flujo de especificaciones consta principalmente de:

• Especificaciones del requisito del usuario
• Especificaciones funcionales del requisito
• Especificaciones de diseño

Secuencia de prueba

El flujo de pruebas generalmente consta de:

• Clasificación de la instalación (IQ)
• Clasificación operacional (OC)
• Rendimiento (PQ)

El flujo de desarrollo puede consistir (según el tipo de sistema y el alcance del desarrollo) en personalización, configuración o codificación.

Aplicaciones

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

El concepto del modelo V se desarrolló simultáneamente, pero de forma independiente, en Alemania y Estados Unidos a finales de los años 1980:

• El modelo alemán V fue desarrollado originalmente por IABG en Ottobrunn, cerca de Munich, en cooperación con la Oficina Federal de Tecnología de Defensa y Adquisiciones en Koblenz, para el Ministerio Federal de Defensa. Fue asumido por el Ministerio Federal del Interior para las autoridades públicas civiles en el verano de 1992.
• El modelo V estadounidense, como se documenta en los procedimientos de 1991 para el Consejo Nacional de Ingeniería de Sistemas (NCOSE; ahora INCOSE a partir de 1995), fue desarrollado para sistemas de satélites 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 pre-propuesta para el programa FAA Advanced Automation System (AAS). Finalmente formó la estrategia de prueba para la propuesta de Hughes AAS Design Competition Phase (DCP). Se creó para mostrar el enfoque de prueba e integración que fue impulsado por nuevos desafíos a los defectos superficiales latentes en el software. La necesidad de este nuevo nivel de detección de defectos latentes fue impulsada por el objetivo de comenzar a automatizar los procesos de pensamiento y planificación del controlador de tráfico aéreo según lo previsto por el programa automatizado de control de tráfico aéreo (AERA). La razón por la que el V es tan poderoso proviene de la cultura Hughes de acoplar todo el texto y el análisis a imágenes dimensionales. Fue la fundación de la Organización Temática Secuencial de Publicaciones (STOP) creada por Hughes en 1963 y utilizada hasta que Hughes fue sumergido por el Instituto Médico Howard Hughes en 1985.
• El Departamento de Defensa de EE.UU. pone las interacciones de procesos de ingeniería de sistemas en una relación V-model.

Ahora ha encontrado una aplicación generalizada en programas comerciales y de defensa. Su uso principal es la gestión de proyectos y durante todo el ciclo de vida del proyecto.

Una característica fundamental de la V-model estadounidense es que el tiempo y la madurez se mueven de izquierda a derecha y no se puede mover de nuevo en el tiempo. Toda la iteración es a lo largo de una línea vertical a niveles superiores o inferiores en la jerarquía del sistema, como se muestra en la figura. Esto ha demostrado ser un aspecto importante del modelo. La expansión del modelo a un concepto de doble vee se trata en referencia.

Como el V-model está disponible públicamente muchas empresas también lo utilizan. En la gestión de proyectos es un método comparable al PRINCE2 y describe métodos para la gestión de proyectos, así como métodos para el desarrollo de sistemas. El modelo V, aunque rígido en proceso, puede ser muy flexible en la aplicación, especialmente porque se refiere al alcance fuera del reino de los parámetros normales del ciclo de vida del sistema.

Ventajas

Estas son las ventajas que ofrece V-model frente a otros modelos de desarrollo de sistemas:

• Los usuarios del modelo V participan en el desarrollo y mantenimiento del modelo V. Una junta de control de cambio mantiene públicamente el modelo V. La junta de control del cambio se reúne cada día a cada semana y procesa todas las solicitudes de cambio recibidas durante el desarrollo y la prueba del sistema.
• 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.

Limitaciones

Los siguientes aspectos no están cubiertos por el modelo V, deben regularse adicionalmente o adaptarse el modelo V en consecuencia:

• La colocación de contratos para servicios no está regulada.
• La organización y ejecución del funcionamiento, mantenimiento, reparación y eliminación del sistema no están cubiertas por el modelo V. Sin embargo, la planificación y preparación de un concepto para estas tareas están reguladas en el modelo V.
• El modelo V aborda el desarrollo de software dentro de un proyecto en lugar de una organización entera.