Gráfico del ciclo de vida del desarrollo de sistemas
El modelo V del proceso de ingeniería de sistemas. [1]
El modelo V es una representación gráfica del ciclo de vida del desarrollo de sistemas . Se utiliza para producir modelos rigurosos del ciclo de vida del 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. [2]
El modelo V resume los pasos principales que se deben seguir en relación con los resultados correspondientes dentro del marco de validación del sistema informático o el desarrollo del ciclo de vida del proyecto. Describe las actividades que se deben realizar y los resultados que se deben producir 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 una integración de partes y su validación. [3] [4] [5] [6] [7] Sin embargo, los requisitos deben validarse primero frente a los requisitos de nivel superior o las necesidades del usuario. Además, también existe algo llamado validación de modelos de sistema. Esto también se puede hacer parcialmente en el lado izquierdo. Afirmar que la validación solo ocurre en el lado derecho puede no ser correcto. La forma más fácil es decir que la verificación siempre se realiza en relación con los requisitos (términos técnicos) y la validación siempre se realiza en relación con el mundo real o las necesidades del usuario. La norma aeroespacial RTCA DO-178B establece que los requisitos se validan (se confirma que son verdaderos) y el producto final se verifica para garantizar 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 correctamente?".
Tipos
Hay tres tipos generales de modelo V.
Modelo V
"V-Modell" 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. [8] El atributo clave de usar una representación en "V" era exigir una prueba de que los productos del lado izquierdo de la V eran aceptables para la organización de prueba e integración adecuada que implementaba el lado derecho de la V. [9] [10] [11]
Pruebas generales
En toda la comunidad de pruebas en todo el mundo, el modelo V se considera ampliamente como una representación ilustrativa más vaga del proceso de desarrollo de software como se describe en el Programa de estudios básico de la Junta Internacional de Calificaciones de Pruebas de Software para probadores de software. [12] No existe una definición única de este modelo, que se cubre de manera más directa en el artículo alternativo sobre el modelo V (desarrollo de software) .
Norma 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 [ ¿cuándo? ] , como su contraparte alemana. Su alcance es un modelo de ciclo de vida de desarrollo de sistemas más estrecho, pero mucho más detallado y más riguroso de lo que la mayoría de los profesionales y evaluadores del Reino Unido entenderían por el modelo V. [13] [14] [3] [4] [15] [16]
Validación vs. verificación
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 correctamente?". 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 IEEE Computer Society) los 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 otras partes interesadas identificadas. A menudo implica la aceptación y la idoneidad por parte de los clientes externos. Contrasta con la verificación ."
" Verificación . La evaluación de si un producto, servicio o sistema cumple o no con una reglamentación, requisito, especificación o condición impuesta. Suele ser un proceso interno. Contrasta con validación ."
Objetivos
El modelo V proporciona una guía para la planificación y la realización de proyectos. Con la ejecución de un proyecto se pretenden alcanzar los siguientes objetivos:
Minimización de los riesgos del proyecto : El modelo V mejora la transparencia y el control del proyecto al especificar enfoques estandarizados y describir los resultados correspondientes y los roles responsables. Permite un reconocimiento temprano de las desviaciones y los riesgos de la planificación y mejora 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 garantiza que los resultados que se deben proporcionar sean completos y tengan la calidad deseada. Los resultados intermedios definidos se pueden verificar en una etapa temprana. Los contenidos uniformes del producto mejorarán 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 para el desarrollo, producción, operación y mantenimiento de un sistema se puede calcular, estimar y controlar de forma transparente aplicando un modelo de proceso estandarizado. Los resultados obtenidos son uniformes y fácilmente rastreables. Esto reduce la dependencia del comprador respecto del proveedor y el esfuerzo 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 es la base para el entendimiento mutuo entre todas las partes interesadas. De esta manera, se reduce la pérdida de fricción entre el usuario, el adquirente, el proveedor y el desarrollador.
Temas del modelo V
Ingeniería de sistemas y verificación. [18]
Ingeniería y verificación de sistemas
El proceso de ingeniería de sistemas (SEP) proporciona un camino para mejorar la relación costo-beneficio de los sistemas complejos tal como lo experimenta el propietario del sistema durante toda la vida útil del sistema, desde la concepción hasta el retiro. [1]
Implica la identificación temprana y completa de los 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, pruebas de aceptación rigurosas del sistema implementado para garantizar que cumple con los requisitos establecidos (verificación del sistema), medición de su eficacia para abordar los objetivos (validación del sistema), operación y mantenimiento continuos, actualizaciones del sistema a lo largo del tiempo y retiro final. [1] [3] [4] [7]
El proceso pone énfasis en el diseño y las pruebas basados en requisitos. Todos los elementos de diseño y las pruebas de aceptación deben poder rastrearse hasta uno o más requisitos del sistema y cada requisito debe ser abordado por al menos un elemento de diseño y una prueba de aceptación. Este rigor garantiza que no se haga nada innecesariamente y que se logre todo lo necesario. [1] [3]
Las dos corrientes
Flujo de especificaciones
El flujo de especificaciones consta principalmente de:
Especificaciones de requisitos del usuario
Especificaciones de requisitos funcionales
Especificaciones de diseño
Flujo de prueba
El flujo de pruebas generalmente consta de:
Calificación de instalación (IQ)
Cualificación operacional (OQ)
Calificación de desempeño (PQ)
El flujo de desarrollo puede consistir (dependiendo del tipo de sistema y el alcance del desarrollo) en personalización, configuración o codificación.
Aplicaciones
Alternativas fuera del núcleo (que ilustran iteraciones ascendentes y descendentes y la dimensión de tiempo y madurez). Fuente: K. Forsberg y H. Mooz 2004 [3] [7]
El modelo V se utiliza para regular el proceso de desarrollo de software dentro de la administración federal alemana. Hoy en día [ ¿cuándo? ] sigue siendo el estándar para los proyectos de la administración federal alemana y de defensa, así como para los desarrolladores de software dentro de la región.
El concepto del modelo V se desarrolló simultáneamente, pero de forma independiente, en Alemania y en Estados Unidos a finales de los años 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 de Defensa y Adquisiciones de Coblenza, para el Ministerio Federal de Defensa. En el verano de 1992, el Ministerio Federal del Interior lo asumió para el ámbito de las autoridades públicas civiles. [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 a partir de 1995), [7] fue desarrollado 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 previo a la propuesta para el programa del Sistema de Automatización Avanzada (AAS) de la FAA. Finalmente, formó 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 que fue impulsado por nuevos desafíos para descubrir defectos 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 como lo imaginó el programa de control de tráfico aéreo automatizado en ruta (AERA). La razón por la que el V es tan poderoso proviene de la cultura de Hughes de acoplar todo el texto y el análisis a 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 desinvertida por el Instituto Médico Howard Hughes en 1985. [21]
El Departamento de Defensa de los EE. UU. coloca las interacciones del proceso de ingeniería de sistemas en una relación de modelo V. [22]
En la actualidad, se ha utilizado ampliamente en programas comerciales y de defensa. Su uso principal es en la gestión de proyectos [3] [4] y durante todo el ciclo de vida del proyecto.
Una característica fundamental del modelo en V de EE. UU. es que el tiempo y la madurez se mueven de izquierda a derecha y no es posible 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]
Como el modelo V está disponible públicamente, muchas empresas también lo utilizan. En la gestión de proyectos, es un método comparable a PRINCE2 y describe métodos para la gestión de proyectos, así como métodos para el desarrollo de sistemas . El modelo V, si bien 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 del sistema.
Ventajas
Estas son las ventajas que ofrece el modelo V frente a otros modelos de desarrollo de sistemas:
Los usuarios del modelo V participan en el desarrollo y mantenimiento del mismo. Un comité de control de cambios se encarga del mantenimiento público del modelo V. El comité de control de cambios se reúne todos los días o semanalmente y procesa todas las solicitudes de cambio recibidas durante el desarrollo y la prueba 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]
Limitaciones
Los siguientes aspectos no están cubiertos por el modelo V, deben regularse además, o el modelo V debe adaptarse en consecuencia: [25] [26]
La contratación de contratos de servicios no está regulada.
La organización y ejecución de la operación, mantenimiento, reparación y eliminación del sistema no están cubiertas por el modelo V. Sin embargo, la planificación y la 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 completa.
^ abcd Concepto de operaciones de Clarus Archivado el 5 de julio de 2009 en Wayback Machine , publicación n.º FHWA-JPO-05-072, Administración Federal de Carreteras (FHWA), 2005.
^ "El peligroso y seductor modelo V" Archivado el 15 de septiembre de 2019 en Wayback Machine. , consultado el 9 de enero de 2013.
^ abcdefgh Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3.ª edición, John Wiley and Sons, Nueva York, NY, 2005. Páginas 108-116, 242-248, 341-360.
^ abcde Consejo Internacional de Ingeniería de Sistemas (INCOSE), Manual de Ingeniería de Sistemas Versión 3.1, agosto de 2007, páginas 3.3 a 3.8
^ Forsberg, K., Mooz, H. (1998). "Ingeniería de sistemas para una mayor rapidez, un menor coste y una mejor calidad" (PDF) . Centro de Gestión de Sistemas. Archivado desde el original (PDF) el 20 de abril de 2003. {{cite journal}}: Requiere citar revista |journal=( ayuda )CS1 maint: multiple names: authors list (link)
^ "El SE VEE". SEOR, Universidad George Mason. Archivado desde el original el 18 de octubre de 2007. Consultado el 26 de mayo de 2007 .
^ abcde Forsberg, K. y Mooz, H., "La relación de la ingeniería de sistemas con el ciclo del proyecto" Archivado el 27 de febrero de 2009 en Wayback Machine , Primer Simposio Anual del Consejo Nacional de Ingeniería de Sistemas (NCOSE), octubre de 1991
^ "Sitio web de V-Modell (en alemán)", consultado el 10 de julio de 2020.
^ Directiva alemana 250, Norma de desarrollo de software para las Fuerzas Armadas Federales Alemanas, Modelo V, Modelo de proceso de ciclo de vida del software, agosto de 1992
^ "Fundamentos del modelo V" . Consultado el 14 de abril de 2016 .
^ "V-Modell XT, Parte 1: Fundamentos del V-Modell" (PDF) . Consultado el 14 de abril de 2016 .
^ "Junta Internacional de Calificaciones de Pruebas de Software – Programa de estudios de nivel básico", consultado el 9 de enero de 2013.
^ "Ingeniería de sistemas para sistemas de transporte inteligentes" (PDF) . Departamento de Transporte de los Estados Unidos. pág. 10. Consultado el 9 de junio de 2007 .
^ "Departamento de Transporte de Estados Unidos, Administración Federal de Carreteras. Guía de ingeniería de sistemas para ITS", consultado el 9 de enero de 2013.
^ "CONSTRUYENDO SOBRE UN LEGADO: ENFOQUE RENOVADO EN LA INGENIERÍA DE SISTEMAS EN ADQUISICIONES DE DEFENSA" (PDF) . Consultado el 14 de abril de 2016 .
^ "Uso de modelos V para pruebas". 10 de noviembre de 2013. Consultado el 14 de abril de 2016 .
^ Guía IEEE: Adopción del estándar del Project Management Institute (PMI(R)) Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK(R)) - Cuarta edición. Junio de 2011. pág. 452. doi :10.1109/IEEESTD.2011.6086685. ISBN978-0-7381-6817-3. Recuperado el 25 de mayo de 2021 .
^ Fundamentos de ingeniería de sistemas. Defense Acquisition University Press, 2001.
^ "Modelo de proceso de ciclo de vida V-Model". v-modell.iabg.de. Archivado desde el original el 3 de marzo de 2016 . Consultado el 24 de diciembre de 2015 .
^ "Organización temática secuencial de publicaciones (STOP)". Archivado desde el original el 3 de febrero de 2008. Consultado el 24 de diciembre de 2015 .
^ Sobkiw, Walter (1 de enero de 2008). El desarrollo sostenible es posible gracias a la ingeniería de sistemas creativos . Lulu.com. ISBN978-0615216300.
^ "Un nuevo modelo de ingeniería de sistemas y un viejo amigo familiar; Figura 2 Interacciones de procesos V-9" (PDF) . Defense AT&L. Abr 2006. p. 51 . Consultado el 7 de abril de 2016 .
^ "Desarrollo posterior del modelo V (enlace roto)". v-modell.iabg.de. Archivado desde el original el 23 de abril de 2011. Consultado el 24 de diciembre de 2015 .
^ "Descripción general del modelo de actividad del V-Modell (enlace roto)". v-modell.iabg.de. Archivado desde el original el 19 de julio de 2011. Consultado el 24 de diciembre de 2015 .
^ "Límites del VModel". v-modell.iabg.de. Archivado desde el original el 21 de mayo de 2011. Consultado el 24 de diciembre de 2015 .
^ Christian Bucanac, El modelo V
Enlaces externos
Wikimedia Commons alberga una categoría multimedia sobre Modelos V.
"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 desde el original el 27 de septiembre de 2007.
