Autores principales: Dick Fairley, Kevin Forsberg, Autor colaborador: Ray Madachy
Hay un gran número de modelos de procesos de ciclo de vida. Como se discute en el artículo System Life Cycle Process Drivers and Choices, estos modelos se dividen en tres categorías principales: (1) procesos principalmente preespecificados y secuenciales; (2) procesos principalmente evolutivos y concurrentes (por ejemplo, el proceso racional unificado y varias formas de los modelos Vee y espiral); y (3) procesos principalmente interpersonales y sin restricciones (por ejemplo, desarrollo ágil, Scrum, programación extrema (XP), el método de desarrollo de sistemas dinámicos y los procesos basados en la innovación).
Este artículo se centra específicamente en el modelo Vee como el principal ejemplo de procesos preespecificados y secuenciales. En esta discusión, es importante notar que el modelo Vee, y las variaciones del modelo Vee, todos abordan el mismo conjunto básico de actividades de ingeniería de sistemas (SE). La diferencia clave entre estos modelos es la forma en que agrupan y representan las mencionadas actividades de SE.
Las implicaciones generales del uso del modelo Vee para el diseño y desarrollo de sistemas se discuten a continuación; para una comprensión más específica de cómo este modelo de ciclo de vida impacta en las actividades de ingeniería de sistemas, por favor vea las otras áreas de conocimiento (KAs) en la Parte 3.
- Un Modelo de Proceso Principalmente Preespecificado y Secuencial: El Modelo Vee
- Aplicación del Modelo Vee
- Fundamentos de las etapas del ciclo de vida y la fase de gestión del programa
- Etapas del ciclo de vida
- Etapa de investigación exploratoria
- Etapa de concepto
- Etapa de desarrollo
- Etapa de producción
- Etapa de Utilización
- Etapa de soporte
- Etapa de retiro
- Revisiones del ciclo de vida
- Trabajos citados
- Referencias principales
- Referencias adicionales
- Vídeos relevantes=
Un Modelo de Proceso Principalmente Preespecificado y Secuencial: El Modelo Vee
La versión secuencial del Modelo Vee se muestra en la Figura 1. Su núcleo implica una progresión secuencial de planes, especificaciones y productos que se basan y se someten a la gestión de la configuración. La flecha vertical de dos puntas permite a los proyectos realizar análisis simultáneos de oportunidades y riesgos, así como una validación continua durante el proceso. El Modelo Vee abarca las tres primeras etapas del ciclo de vida enumeradas en la tabla «Etapas genéricas del ciclo de vida» del Manual de Ingeniería de Sistemas del INCOSE: investigación exploratoria, concepto y desarrollo (INCOSE 2012).
El Modelo Vee hace suya la definición del Manual de Ingeniería de Sistemas de INCOSE (INCOSE 2012) de las etapas del ciclo de vida y sus propósitos o actividades, como se muestra en la Figura 2 siguiente.
El INCOSE Systems Engineering Handbook 3.2.2 contiene una versión más detallada del diagrama Vee (2012, Figuras 3-4, p. 27) que incorpora las actividades del ciclo de vida en el modelo Vee más genérico. Un diagrama similar, desarrollado en la Universidad de Adquisición de Defensa (DAU) de Estados Unidos, puede verse en la Figura 3 siguiente.
Aplicación del Modelo Vee
Lawson (Lawson 2010) profundiza en las actividades de cada etapa del ciclo de vida y señala que es útil considerar la estructura de un modelo genérico de etapas del ciclo de vida para cualquier tipo de sistema de interés (SoI) como se representa en la Figura 4. Este modelo (T) indica que una o más etapas de definición preceden a una(s) etapa(s) de producción en las que se ha llevado a cabo la implementación (adquisición, provisión o desarrollo) de dos o más elementos del sistema.
La figura 5 muestra las etapas genéricas del ciclo de vida para una variedad de partes interesadas, desde una organización de estándares (ISO/IEC) hasta organizaciones comerciales y gubernamentales. Aunque estas etapas difieren en detalle, todas tienen un formato secuencial similar que hace hincapié en las actividades principales, como se indica en la figura 2 (definición, producción y utilización/retiro).
Es importante señalar que muchas de las actividades a lo largo del ciclo de vida son iteradas. Este es un ejemplo de recursión (glosario)recursión (glosario) como se discute en la Parte 3 Introducción.
Fundamentos de las etapas del ciclo de vida y la fase de gestión del programa
Para esta discusión, es importante tener en cuenta que:
- El término etapa se refiere a los diferentes estados de un sistema durante su ciclo de vida; algunas etapas pueden superponerse en el tiempo, como la etapa de utilización y la etapa de apoyo. El término «etapa» se utiliza en la norma ISO/IEC/IEEE 15288.
- El término fase se refiere a los diferentes pasos del programa que apoyan y gestionan la vida del sistema; las fases normalmente no se solapan. El término «fase» se utiliza en muchos modelos bien establecidos como equivalente al término «etapa».
Gestión de programasLa gestión de programas emplea fases, hitosmilestones y puertas de decisióndecision gates que se utilizan para evaluar la evolución de un sistema a través de sus distintas etapas. Las etapas contienen las actividades realizadas para alcanzar los objetivos y sirven para controlar y gestionar la secuencia de etapas y las transiciones entre cada una de ellas. Para cada proyecto, es esencial definir y publicar los términos y las definiciones relacionadas que se utilizan en los respectivos proyectos para minimizar la confusión.
Un programa típico se compone de las siguientes fases:
- La fase de estudio previo, en la que se identifican las posibles oportunidades para abordar las necesidades de los usuarios con nuevas soluciones que tengan sentido desde el punto de vista empresarial.
- La fase de viabilidad consiste en estudiar la viabilidad de los conceptos alternativos para llegar a una segunda puerta de decisión antes de iniciar la etapa de ejecución. Durante la fase de viabilidad, se identifican los requisitos de las partes interesadas y los requisitos del sistema, se identifican y estudian soluciones viables y se pueden implementar prototipos virtuales (glosario)prototipos (glosario). Durante esta fase, la decisión de avanzar se basa en:
- si un concepto es viable y se considera capaz de contrarrestar una amenaza identificada o explotar una oportunidad;
- si un concepto está lo suficientemente maduro como para justificar el desarrollo continuado de un nuevo producto o línea de productos; y
- si se aprueba una propuesta generada en respuesta a una solicitud de propuesta.
- La fase de ejecución incluye actividades relacionadas con cuatro etapas del ciclo de vida del sistema: desarrollo, producción, utilización y soporte. Normalmente, hay dos puertas de decisión y dos hitos asociados a las actividades de ejecución. El primer hito ofrece la oportunidad de que la dirección revise los planes de ejecución antes de dar el visto bueno. El segundo hito ofrece la oportunidad de revisar el progreso antes de tomar la decisión de iniciar la producción. Las puertas de decisión durante la ejecución pueden utilizarse para determinar si se produce el SoI desarrollado y si se mejora o se retira.
Estos puntos de vista de gestión de programas se aplican no sólo al SoI, sino también a sus elementos y estructura.
Etapas del ciclo de vida
Las variaciones del modelo Vee tratan las mismas etapas generales de un ciclo de vida:
- Los nuevos proyectos suelen comenzar con una fase de investigación exploratoria que generalmente incluye las actividades de definición del concepto, específicamente los temas de análisis del negocio o de la misión y la comprensión de las necesidades y requisitos de las partes interesadas. Éstas maduran a medida que el proyecto pasa de la fase exploratoria a la fase de concepto y a la fase de desarrollo.
- La fase de producción incluye las actividades de definición y realización del sistema, así como el desarrollo de los requisitos del sistema (glosario)requisitos (glosario) y la arquitectura (glosario)arquitectura (glosario) a través de la verificación y la validación.
- La fase de utilización incluye las actividades de despliegue y funcionamiento del sistema.
- La fase de soporte incluye las actividades de mantenimiento del sistema, la logística y la gestión de la vida útil del producto y del servicio, que puede incluir actividades como la extensión de la vida útil o las actualizaciones de las capacidades, las mejoras y la modernización.
- La fase de retiro incluye las actividades de eliminación y retiro, aunque en algunos modelos, las actividades como la extensión de la vida útil o las actualizaciones de la capacidad, las mejoras y la modernización se agrupan en la fase de «retiro».
Puede encontrarse información adicional sobre cada una de estas etapas en las secciones siguientes (ver los enlaces a los artículos adicionales de la Parte 3 arriba para más detalles). Es importante tener en cuenta que estas etapas del ciclo de vida, y las actividades en cada etapa, se apoyan en un conjunto de procesos de gestión de ingeniería de sistemas.
Etapa de investigación exploratoria
El análisis y acuerdo de los requisitos del usuario es parte de la etapa de investigación exploratoria y es fundamental para el desarrollo de sistemas exitosos. Sin una comprensión adecuada de las necesidades del usuario, cualquier sistema corre el riesgo de ser construido para resolver los problemas equivocados. El primer paso en la fase de investigación exploratoria es definir los requisitos y las limitaciones del usuario (y de las partes interesadas). Una parte fundamental de este proceso es establecer la viabilidad de satisfacer los requisitos del usuario, incluida la evaluación de la preparación tecnológica. Al igual que con muchas actividades de SE, esto se hace a menudo de forma iterativa, y las necesidades y requisitos de las partes interesadas se revisan a medida que se dispone de nueva información.
Un estudio reciente del Consejo Nacional de Investigación (National Research Council 2008) se centró en la reducción del tiempo de desarrollo de los proyectos de la Fuerza Aérea de Estados Unidos. El informe señala que, «en pocas palabras, la ingeniería de sistemas es la traducción de las necesidades de un usuario en una definición de un sistema y su arquitectura a través de un proceso iterativo que da lugar a un diseño eficaz del sistema». La participación iterativa con las partes interesadas es fundamental para el éxito del proyecto.
A excepción de la primera y la última puerta de decisión de un proyecto, las puertas se realizan simultáneamente. Véase la figura 6 más abajo.
Etapa de concepto
Durante la etapa de concepto, se crean conceptos alternativos para determinar el mejor enfoque para satisfacer las necesidades de las partes interesadas. Al prever alternativas y crear modelos, incluidos los prototipos adecuados, se aclaran las necesidades de las partes interesadas y se ponen de relieve los problemas que las impulsan. Esto puede conducir a un enfoque incremental o evolutivo del desarrollo del sistema. Pueden explorarse varios conceptos diferentes en paralelo.
Etapa de desarrollo
El concepto o conceptos seleccionados identificados en la etapa de concepto se elaboran en detalle hasta el nivel más bajo para producir la solución que satisfaga los requisitos de las partes interesadas. A lo largo de esta etapa, es vital continuar con la participación del usuario a través de la validación en el proceso (la flecha hacia arriba en los modelos Vee). En el hardware, esto se lleva a cabo con revisiones frecuentes del programa y con un representante o representantes residentes del cliente (si procede). En el desarrollo ágil, la práctica es tener el representante del cliente integrado en el equipo de desarrollo.
Etapa de producción
La etapa de producción es donde se construye o fabrica el SoI. Pueden ser necesarias modificaciones del producto para resolver problemas de producción, para reducir los costes de producción o para mejorar las capacidades del producto o del SoI. Cualquiera de estas modificaciones puede influir en los requisitos del sistema y puede requerir la recalificación del sistema, la recalificación de la verificación o la recalificación de la validación. Todos estos cambios requieren una evaluación de SE antes de que se aprueben los cambios.
Etapa de Utilización
Un aspecto importante de la gestión del ciclo de vida del producto es el suministro de sistemas de apoyo que son vitales para mantener la operación del producto. Mientras que el producto o servicio suministrado puede considerarse como el sistema de interés restringido (NSOI) para un adquirente, el adquirente también debe incorporar los sistemas de apoyo en un sistema de interés más amplio (WSOI). Estos sistemas de apoyo deben considerarse como activos del sistema que, cuando se necesitan, se activan en respuesta a una situación que ha surgido con respecto al funcionamiento del NSOI. El nombre colectivo para el conjunto de sistemas de apoyo es el sistema de apoyo logístico integrado (ILS).
Es vital tener una visión holística al definir, producir y operar los productos y servicios del sistema. En la figura 7, se representa la relación entre el diseño y el desarrollo del sistema y los requisitos de las NITs.
Los requisitos de fiabilidad, que se traducen en la necesidad de mantenibilidad y comprobabilidad, son factores impulsores.
Etapa de soporte
En la etapa de soporte, el SoI recibe servicios que permiten la operación continua. Se pueden proponer modificaciones para resolver problemas de sustentabilidad, para reducir los costos operativos o para extender la vida útil de un sistema. Estos cambios requieren la evaluación de la SE para evitar la pérdida de las capacidades del sistema mientras está en funcionamiento. El proceso técnico correspondiente es el proceso de mantenimiento.
Etapa de retiro
En la etapa de retiro, el SoI y sus servicios relacionados son retirados de la operación. Las actividades de SE en esta etapa se centran principalmente en asegurar que se satisfagan los requisitos de eliminación. De hecho, la planificación de la eliminación es parte de la definición del sistema durante la etapa de concepto. Las experiencias del siglo XX demostraron repetidamente las consecuencias cuando el retiro y la eliminación del sistema no fueron considerados desde el principio. A principios del siglo XXI, muchos países han cambiado sus leyes para responsabilizar al creador de un SoI de la correcta eliminación del sistema al final de su vida útil.
Revisiones del ciclo de vida
Para controlar el progreso de un proyecto, se planifican diferentes tipos de revisiones. Las más utilizadas son las siguientes, aunque los nombres no son universales:
- La revisión de los requisitos del sistema (SRR) se planifica para verificar y validar el conjunto de requisitos del sistema antes de iniciar las actividades de diseño detallado.
- La revisión preliminar del diseñola revisión preliminar del diseño (PDR) se planifica para verificar y validar el conjunto de requisitos del sistema, los artefactos de diseño y los elementos de justificación al final del primer bucle de ingeniería (también conocido como la puerta de «diseño a»).
- La revisión crítica del diseñoLa revisión crítica del diseño (CDR) se planifica para verificar y validar el conjunto de requisitos del sistema, los artefactos de diseño y los elementos de justificación al final del último bucle de ingeniería (los diseños «build-to» y «code-to» se liberan después de esta revisión).
- Las revisiones de integraciónintegración, verificaciónverificación y validación se planifican a medida que los componentes se ensamblan en subsistemas y elementos de nivel superior. Se lleva a cabo una secuencia de revisiones para garantizar que todo se integra correctamente y que hay pruebas objetivas de que se han cumplido todos los requisitos. También debe haber una validación durante el proceso de que el sistema, a medida que evoluciona, cumplirá los requisitos de las partes interesadas (véase la figura 7).
- La revisión de validación final se lleva a cabo al final de la fase de integración.
- Pueden planificarse y llevarse a cabo otras revisiones relacionadas con la gestión para controlar el correcto progreso del trabajo, en función del tipo de sistema y los riesgos asociados.
Trabajos citados
Eichmueller, P. y B. Foreman. 2010. S3000LTM. Bruselas, Bélgica: Asociación de Industrias Aeroespaciales y de Defensa de Europa (ASD)/Asociación de Industrias Aeroespaciales (AIA).
Faisandier, A. 2012. Arquitectura y diseño de sistemas. Belberaud, Francia: Sinergy’Com.
Forsberg, K., H. Mooz, y H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA: J. Wiley & Sons.
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, versión 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
Lawson, H. 2010. Un viaje a través del paisaje de los sistemas. Londres, Reino Unido: College Publications, Kings College, Reino Unido.
Referencias principales
Beedle, M., et al. 2009. «El Manifiesto Ágil: Principles behind the Agile Manifesto». en The Agile Manifesto . Consultado el 04 de diciembre de 2014 en www.agilemanifesto.org/principles.html
Boehm, B. y R. Turner. 2004. Balancing Agility and Discipline. New York, NY, USA: Addison-Wesley.
Fairley, R. 2009. Managing and Leading Software Projects. New York, NY, USA: J. Wiley & Sons.
Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management. 3rd ed. New York, NY, USA: J. Wiley & Sons.
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, versión 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
Lawson, H. 2010. Un viaje a través del paisaje de los sistemas. Kings College, Reino Unido: College Publications.
Pew, R., y A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC, USA: The National Academies Press.
Royce, W.E. 1998. Software Project Management: A Unified Framework. Nueva York, NY, EE.UU.: Addison Wesley.
Referencias adicionales
Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.
Baldwin, C. y K. Clark. 2000. Design Rules: The Power of Modularity. Cambridge, MA, USA: MIT Press.
Beck, K. 1999. Extreme Programming Explained. New York, NY, USA: Addison Wesley.
Beedle, M., et al. 2009. «The Agile Manifesto: Principles behind the Agile Manifesto». en The Agile Manifesto . Consultado en 2010. Disponible en: www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, y P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, USA: Springer.
Boehm, B. 1988. «A Spiral Model of Software Development» (Un modelo espiral de desarrollo de software). IEEE Computer 21(5): 61-72.
Boehm, B. 2006. «Algunas tendencias futuras e implicaciones para los procesos de ingeniería de sistemas y software». Systems Engineering. 9(1): 1-19.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, y R. Madachy. 1998. «Using the WinWin Spiral Model: A Case Study». IEEE Computer. 31(7): 33-44.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (en prensa). Abrazando el modelo espiral: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.
Castellano, D.R. 2004. «Los cinco mejores proyectos de software de calidad». CrossTalk. 17(7) (julio de 2004): 4-19. Disponible en: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf
Checkland, P. 1981. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.
Crosson, S. y B. Boehm. 2009. «Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context». Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.
Dingsoyr, T., T. Dyba. y N. Moe (eds.). 2010. «Agile Software Development: Current Research and Future Directions». Capítulo en B. Boehm, J. Lane, S. Koolmanjwong y R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.
Dorner, D. 1996. The Logic of Failure. Nueva York, NY, EE.UU.: Basic Books.
Forsberg, K. 1995. «‘If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment». Actas del quinto simposio internacional anual del Consejo Internacional de Ingeniería de Sistemas (INCOSE). 22-26 de julio de 1995. Louis, MO, USA.
Forsberg, K. 2010. «Los proyectos no comienzan con los requisitos». Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.
Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.
Goldratt, E. 1984. The Goal. Great Barrington, MA, USA: North River Press.
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. New York, NY, USA: Wiley.
Holland, J. 1998. Emergence. New York, NY, USA: Perseus Books.
ISO/IEC. 2010. Ingeniería de sistemas y software, Parte 1: Guía para la gestión del ciclo de vida. Ginebra, Suiza: Organización Internacional de Normalización (ISO)/Comisión Electrotécnica Internacional (IEC), ISO/IEC 24748-1:2010.
ISO/IEC/IEEE. 2015. Ingeniería de sistemas y software — Procesos del ciclo de vida del sistema. Ginebra, Suiza: Organización Internacional de Normalización / Comisiones Electrotécnicas Internacionales / Instituto de Ingenieros Eléctricos y Electrónicos. ISO/IEC/IEEE 15288:2015.
ISO/IEC. 2003. Ingeniería de sistemas – Guía para la aplicación de los procesos del ciclo de vida del sistema ISO/IEC 15288. Ginebra, Suiza: Organización Internacional de Normalización (ISO)/Comisión Electrotécnica Internacional (IEC), ISO/IEC 19760:2003 (E).
Jarzombek, J. 2003. «Los cinco mejores proyectos de software de calidad». CrossTalk. 16(7) (julio de 2003): 4-19. Disponible en: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
Kruchten, P. 1999. The Rational Unified Process. New York, NY, USA: Addison Wesley.
Landis, T. R. 2010. Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.
Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA: Wiley.
Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. «Revisiones de arquitectura: Práctica y experiencia». IEEE Software. 22(2): 34-43.
National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering. Washington, DC, USA: The National Academies Press.
Osterweil, L. 1987. «Los procesos de software también son software». Actas de la SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
Poppendeick, M. y T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, USA: Addison Wesley.
Rechtin, E. 1991. System Architecting: Creating and Building Complex Systems. Upper Saddle River, NY, EE.UU.: Prentice-Hall.
Rechtin, E., y M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.
Schwaber, K. y M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, USA: Prentice Hall.
Spruill, N. 2002. «Los cinco mejores proyectos de software de calidad». CrossTalk. 15(1) (enero de 2002): 4-19. Disponible en: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.
Stauder, T. 2005. «Los cinco mejores premios de programas del Departamento de Defensa». CrossTalk. 18(9) (septiembre de 2005): 4-13. Disponible en http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: Wiley.
Womack, J. y D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.
Vídeos relevantes=
- Introducción básica a la ingeniería de sistemas (método V)
- Introducción básica a la ingeniería de sistemas (método V) Parte 2 de 2