Modelo V


De Wikipedia, la enciclopedia libre
  (Redirigido desde el modelo V )
Saltar a navegación Saltar a búsqueda
El modelo V del proceso de ingeniería de sistemas. [1]

El modelo V es una representación gráfica de un 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 modelo V 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 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 los requisitos y la creación de especificaciones del sistema. El lado derecho de la "V" representa la integración de partes y su validación. [3] [4] [5] [6] [7] Sin embargo, los requisitos deben validarse primero contra los requisitos de nivel superior o las necesidades del usuario. Además, también existe algo como 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 sencilla es decir que la verificación siempre es contra los requisitos (términos técnicos) y la validación siempre contra el mundo real o las necesidades del usuario. El estándar aeroespacial RTCA DO-178B establece que los requisitos están validados (confirmados como verdaderos) y que el producto final se verifica para garantizar que cumple esos requisitos.

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

Tipos

Hay tres tipos generales de modelo en V.

V-Modell

El modelo V alemán "V-Modell", 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 requerir una prueba 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. [9] [ 10] [11]

Pruebas generales

En toda la comunidad de pruebas en todo el mundo, el modelo V se ve ampliamente como una descripción ilustrativa más vaga del proceso de desarrollo de software como se describe en el Programa de estudios de la Fundación de la Junta de Cualificaciones de Pruebas de Software Internacional para probadores de software. [12] 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.

Los EE. UU. También tienen un modelo V estándar del gobierno que se remonta a unos 20 años 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 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 mediante la consulta "¿Está 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 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 4ª 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 aceptación e idoneidad con los clientes externos. Contraste con la verificación ".
  • " Verificación . La evaluación de si un producto, servicio o sistema cumple o no con una regulación, requisito, especificación o condición impuesta. A menudo es un proceso interno. Contrasta con la validación ".

Objetivos

El modelo V proporciona una guía para la planificación y realización de proyectos. Los siguientes objetivos están destinados a ser alcanzados por la ejecución de un proyecto:

  • 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 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 V-Model asegura que los resultados a 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 comprensibilidad 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, operación 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áciles de rastrear. Esto reduce la dependencia del adquirente 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. Por lo tanto, se reduce la pérdida por fricción entre usuario, adquirente, proveedor y desarrollador.

Temas del modelo V

Ingeniería y verificación de sistemas. [18]

Ingeniería y verificación de sistemas

El proceso de ingeniería de sistemas (SEP) proporciona un camino para mejorar la rentabilidad de los sistemas complejos según la experiencia del propietario del sistema durante toda la vida útil del sistema, desde su concepción hasta su retiro. [1]

Implicó 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 completos 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 ), midiendo su efectividad para abordar los objetivos (validación del sistema), operación y mantenimiento continuos, actualizaciones del sistema a lo largo del tiempo y eventual retiro. [1] [3] [4] [7]

El proceso enfatiza el diseño y las pruebas basados ​​en requisitos. Todos los elementos de diseño y las 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 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 consiste principalmente en:

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

Prueba de flujo

El flujo de pruebas generalmente consta de:

  • Calificación de instalación (IQ)
  • Calificación operativa (OQ)
  • Calificación de desempeño (PQ)

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

Aplicaciones

Alternativas fuera del núcleo (que ilustran iteraciones ascendentes y descendentes y 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, sigue siendo el estándar para los proyectos de defensa y la administración federal alemana, 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 en los Estados Unidos a fines de la década de 1980:

  • El modelo V alemán 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 el dominio de las autoridades públicas civiles en el verano de 1992. [19]
  • El modelo V estadounidense, como se documenta en los procedimientos de 1991 para el Consejo Nacional de Ingeniería de Sistemas (NCOSE; ahora INCOSE en 1995), [7] fue desarrollado para sistemas satelitales que involucran hardware, software e interacción humana.
  • El modelo V apareció por primera vez en Hughes Aircraftcirca 1982 como parte del esfuerzo previo a la propuesta para el programa de Sistema de Automatización Avanzado (AAS) de la FAA. Finalmente, formó la estrategia de prueba para la propuesta de la Fase de competencia de diseño (DCP) de Hughes AAS. 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 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 en ruta (AERA). La razón por la que la V es tan poderosa proviene de la cultura 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]creado por Hughes en 1963 y utilizado hasta que Hughes fue despojado por el Instituto Médico Howard Hughes en 1985. [21]
  • El Departamento de Defensa de EE. UU. Coloca las interacciones del proceso de ingeniería de sistemas en una relación de modelo V. [22]

Ahora ha encontrado una aplicación generalizada 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 V de EE. UU. Es que el tiempo y la madurez se mueven de izquierda a derecha y no se puede retroceder en el tiempo. Toda la 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] Este ha demostrado ser un aspecto importante del modelo. La expansión del modelo a un concepto dual-Vee se trata como 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, aunque rígido en el proceso, puede ser muy flexible en la aplicación, especialmente en lo que se refiere al alcance fuera del ámbito de los parámetros normales del ciclo de vida de 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 modelo V. Un tablero de control de cambios mantiene públicamente el V-Model. La junta 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]

Limites

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 celebració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 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.

Ver también

  • IBM Rational Unified Process (como proceso de software de soporte)
  • Arquitectura de sistemas
  • Diseño de sistemas
  • Teoría U

Referencias

  1. ^ a b c d Concepto de operaciones de Clarus Archivado el 5 de julio de 2009 en Wayback Machine , Publicación núm. FHWA-JPO-05-072, Administración federal de carreteras (FHWA), 2005.
  2. ^ "The Dangerous & Seductive V Model" , consultado el 9 de enero de 2013.
  3. ^ a b c d e f g h Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, tercera edición, John Wiley and Sons, Nueva York, NY, 2005. Páginas 108-116, 242-248 , 341-360.
  4. ^ a b c d e 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
  5. ^ Forsberg, K., Mooz, H. (1998). "Ingeniería de sistemas para más rápido, más barato y mejor" (PDF) . Centro de Gestión de Sistemas. Archivado desde el original (PDF) el 20 de abril de 2003. Cite journal requiere |journal=( ayuda ) CS1 maint: varios nombres: lista de autores ( enlace )
  6. ^ "El SE VEE" . SEOR, Universidad George Mason. Archivado desde el original el 18 de octubre de 2007 . Consultado el 26 de mayo de 2007 .
  7. ^ a b c d e 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 la Wayback Machine , primer simposio anual del Consejo Nacional de Ingeniería de Sistemas (NCOSE ), Octubre de 1991
  8. ^ "Sitio de V-Modell (en alemán)" , consultado el 10 de julio de 2020.
  9. ^ Directiva alemana 250, estándar de desarrollo de software para las fuerzas armadas federales alemanas, modelo V, modelo de proceso de ciclo de vida del software, agosto de 1992
  10. ^ "Fundamentos del V-Modell" . Consultado el 14 de abril de 2016 .
  11. ^ "V-Modell XT, parte 1: Fundamentos del V-Modell" (PDF) . Consultado el 14 de abril de 2016 .
  12. ^ "Junta de calificaciones de pruebas de software internacional - Programa de estudios de nivel básico" , consultado el 9 de enero de 2013.
  13. ^ "Ingeniería de sistemas para sistemas de transporte inteligentes" (PDF) . Departamento de Transporte de EE. UU. pag. 10 . Consultado el 9 de junio de 2007 .
  14. ^ "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.
  15. ^ "CONSTRUYENDO EN UN LEGADO: ENFOQUE RENOVADO EN INGENIERÍA DE SISTEMAS EN ADQUISICIÓN DE DEFENSA" (PDF) . Consultado el 14 de abril de 2016 .
  16. ^ "Uso de modelos V para pruebas" . Consultado el 14 de abril de 2016 .
  17. ^ IEEE . Guía IEEE - Adopción del estándar del Project Management Institute (PMI) Una guía para el conocimiento de la gestión de proyectos (Guía PMBOK) - Cuarta edición . pag. 452. doi : 10.1109 / IEEESTD.2011.6086685 . ISBN 978-0-7381-6817-3. Consultado el 25 de mayo de 2021 .
  18. ^ Fundamentos de la ingeniería de sistemas. Prensa Universitaria de Adquisición de Defensa, 2001.
  19. ^ "Modelo de proceso de ciclo de vida del modelo V" . v-modell.iabg.de. Archivado desde el original el 3 de marzo de 2016 . Consultado el 24 de diciembre de 2015 .
  20. ^ "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 .
  21. Sobkiw, Walter ( 1 de enero de 2008). Desarrollo sostenible posible con ingeniería de sistemas creativos . ISBN 978-0615216300.
  22. ^ "Un nuevo modelo de ingeniería de sistemas y un viejo amigo familiar; Figura 2 Interacciones de proceso V-9" (PDF) . Defensa AT&L. Abril de 2006. p. 51 . Consultado el 7 de abril de 2016 .
  23. ^ "Mayor desarrollo del V-Modell (enlace roto)" . v-modell.iabg.de. Archivado desde el original el 23 de abril de 2011 . Consultado el 24 de diciembre de 2015 .
  24. ^ "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 .
  25. ^ "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 .
  26. ^ Christian Bucanac, El modelo V

enlaces externos

  • "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.
  • "Das V-Modell XT" . cio.bund.de (en alemán). Oficina Federal de Seguridad de la Información (BMI).
  • "Uso de modelos V para pruebas" . insights.sei.cmu.edu . Instituto de Ingeniería de Software , Universidad Carnegie Mellon . 11 de noviembre de 2013.
Obtenido de " https://en.wikipedia.org/w/index.php?title=V-Model&oldid=1033597698 "