Modelos del ciclo de vida

Autores principales: Kevin Forsberg, Rick Adcock, Autor colaborador: Alan Faisandier

El modelo de ciclo de vida es uno de los conceptos clave de la ingeniería de sistemas (SE). El ciclo de vida de un sistema consiste generalmente en una serie de etapas reguladas por un conjunto de decisiones de gestión que confirman que el sistema es lo suficientemente maduro para salir de una etapa y entrar en otra.

Temas

Cada parte del SEBoK se divide en áreas de conocimiento (KAs), que son agrupaciones de información con un tema relacionado. Las KAs, a su vez, se dividen en temas. Esta KA contiene los siguientes temas:

• Motores y opciones del proceso del ciclo de vida del sistema
• Modelos del proceso del ciclo de vida del sistema: Vee
• Modelos de procesos del ciclo de vida del sistema: Iterativo
• Integración de Modelos de Proceso y Producto
• Ingeniería Lean

Vea el artículo Matriz de Ejemplos de Implementación para un mapeo de los casos de estudio y viñetas incluidos en la Parte 7 a los temas cubiertos en la Parte 3.

Tipo de Productos/Servicios de Valor Agregado

El Modelo Genérico de Ciclo de Vida muestra sólo el enfoque de un solo paso para proceder a través de las etapas del ciclo de vida de un sistema. Añadir valor (como producto, como servicio, o como ambos), es un propósito compartido por todas las empresas, ya sean públicas o privadas, con o sin ánimo de lucro. El valor se produce al proporcionar e integrar los elementos de un sistema en un producto o servicio de acuerdo con la descripción del sistema y su transición a un uso productivo. Estas consideraciones sobre el valor darán lugar a diversas formas del enfoque genérico de gestión del ciclo de vida de la figura 1. Algunos ejemplos son los siguientes (Lawson 2010):

• Una empresa manufacturera produce tuercas, tornillos y arandelas de seguridad y luego vende sus productos como elementos de valor añadido para ser utilizados por otras empresas; a su vez, estas empresas integran estos productos en su sistema de valor añadido más amplio, como un avión o un automóvil. Sus requisitos suelen estar preestablecidos por el cliente o por las normas del sector.

• Una empresa mayorista o minorista ofrece productos a sus clientes. Sus clientes (particulares o empresas) adquieren los productos y los utilizan como elementos de sus sistemas. El sistema de soporte de la empresa probablemente evolucionará de forma oportuna, a medida que surjan nuevas capacidades de infraestructura o patrones de demanda.

• Una empresa de servicios comerciales, como un banco, vende una variedad de productos como servicios a sus clientes. Esto incluye cuentas corrientes, cuentas de ahorro, préstamos y gestión de inversiones. Estos servicios añaden valor y se incorporan a los sistemas de clientes de particulares o empresas. El sistema de apoyo de la empresa de servicios también evolucionará probablemente de forma oportunista, a medida que surjan nuevas capacidades de infraestructura o patrones de demanda.

• Una empresa de servicios gubernamentales proporciona a los ciudadanos servicios que varían ampliamente, pero que pueden incluir servicios como la atención sanitaria, las autopistas y carreteras, las pensiones, la aplicación de la ley o la defensa. En su caso, estos servicios se convierten en elementos de infraestructura utilizados en sistemas más amplios de interés para los individuos y/o las empresas. Las iniciativas más importantes, como un sistema de control del tráfico aéreo de nueva generación o un sistema de gestión de crisis en el área metropolitana (huracanes, tifones, terremotos, tsunamis, inundaciones, incendios), serán lo suficientemente complejas como para seguir un enfoque evolutivo de desarrollo y puesta en marcha. A nivel elemental, es probable que haya ciclos de vida preestablecidos de una sola pasada.

• Para los sistemas de aeronaves y automóviles, es probable que haya un ciclo de vida preestablecido de múltiples pasadas para capitalizar las primeras capacidades en la primera pasada, pero con una arquitectura que permita añadir más capacidades de valor añadido en pasadas posteriores.

• Una empresa de desarrollo de software diversificado proporciona productos de software que cumplen con los requisitos (necesidades) de las partes interesadas, proporcionando así servicios a los usuarios del producto. Deberá desarrollarse para tener capacidades que puedan adaptarse para ser utilizadas en los diferentes enfoques del ciclo de vida de los clientes y también con capacidades de línea de productos que puedan aplicarse rápida y fácilmente a desarrollos de sistemas de clientes similares. Su modelo de negocio también puede incluir el suministro al cliente de capacidades de soporte y evolución del ciclo de vida del sistema.

En estos ejemplos, hay sistemas que permanecen estables durante periodos de tiempo razonablemente largos y otros que cambian rápidamente. La diversidad que representan estos ejemplos y sus procesos ilustra por qué no existe un proceso único que pueda utilizarse para definir un ciclo de vida de sistemas específico. Los enfoques de gestión y liderazgo deben tener en cuenta el tipo de sistemas en cuestión, su longevidad y la necesidad de una rápida adaptación a cambios imprevistos, ya sea en la competencia, la tecnología, el liderazgo o las prioridades de la misión. A su vez, los enfoques de gestión y liderazgo influyen en el tipo y el número de modelos de ciclo de vida que se despliegan, así como en los procesos que se utilizarán dentro de cualquier ciclo de vida en particular.

Hay varios enfoques incrementales y evolutivos para secuenciar las etapas del ciclo de vida para hacer frente a algunas de las cuestiones planteadas anteriormente. El área de conocimiento de Modelos de Ciclo de Vida resume una serie de modelos de ciclo de vida incrementalesincrementales y evolutivos-evolutivos, incluyendo sus principales fortalezas y debilidades y también discute los criterios para elegir el enfoque más adecuado.

Categorías de Modelo de Ciclo de Vida

El Modelo Genérico de Ciclo de Vida del Sistema de la Figura 1 no se ajusta explícitamente a todas las situaciones. Un sistema simple, precedente y de seguimiento puede necesitar sólo una fase en la etapa de definición, mientras que un sistema complejo puede necesitar más de dos. En el caso de los sistemas construidos (frente a los desechables) prototiposprototipos, una buena parte del desarrollo puede tener lugar durante la etapa de definición. La integración del sistemaintegración, verificaciónverificación y validaciónvalidación pueden seguir a la implementación o adquisición de los elementos del sistema. En el caso del software, sobre todo en el caso de las pruebas y las construcciones diarias, la integración, la verificación y la validación se entrelazan con la implementación de los elementos. Además, con la próxima Tercera Revolución Industrial de la impresión tridimensional y la fabricación digital (Whadcock 2012), no sólo el desarrollo inicial, sino también la producción inicial puede hacerse durante la etapa de concepto.

El software es un medio flexible y maleable que facilita el análisis iterativo, el diseño, la construcción, la verificación y la validación en mayor medida de lo que suele ser posible para los componentes puramente físicos de un sistema. Cada repetición de un modelo de desarrollo iterativo añade material (código) a la creciente base de software, en la que la base de código ampliada se prueba, se reelabora según sea necesario y se demuestra que satisface los requisitos de la línea de base.

El software puede comprarse, venderse, entregarse y actualizarse electrónicamente en cualquier lugar del mundo al alcance de la comunicación digital, lo que hace que su logística sea significativamente diferente y más rentable que el hardware. No se desgasta y sus correcciones cambian su contenido y comportamiento, lo que hace que las pruebas de regresión sean más complejas que con las correcciones de hardware. Su naturaleza discreta hace que sus pruebas no puedan contar con una continuidad analítica como en el caso del hardware. La adición de 1 a 32767 en un registro de 15 bits no produce 32768, sino 0 en su lugar, como se experimenta en situaciones graves, como con el uso del misil Patriot.

Hay un gran número de modelos de proceso de ciclo de vida potenciales. Se dividen en tres categorías principales:

1. Principalmente procesos preespecificados y secuenciales (por ejemplo, el modelo de cascada de un solo paso)
2. Principalmente procesos evolutivos y concurrentes (por ejemplo, el desarrollo ágil, el proceso racional unificado y diversas formas de los modelos en V y en espiral)
3. Principalmente procesos interpersonales y emergentes (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)

La aparición de sistemas de hardware-software integrados e interactivos hizo que los procesos preespecificados fueran potencialmente perjudiciales, ya que las interfaces hombre-sistema más eficaces tendían a surgir con su uso, lo que dio lugar a nuevas variaciones de procesos, como el SE blando (Warfield 1976, Checkland 1981) y los procesos de integración hombre-sistema (Booher 2003, Pew y Mavor 2007). Hasta hace poco, las normas de procesos y los modelos de madurez han tratado de cubrir todas las eventualidades. Han incluido amplios procesos para la gestión de adquisiciones, la selección de fuentes, las revisiones y auditorías, la garantía de calidad, la gestión de la configuración y la gestión de documentos, que en muchos casos resultarían excesivamente burocráticos e ineficaces. Esto condujo a la introducción de enfoques más «lean» (Ohno 1988; Womack et al. 1990; Oppenheim 2011) y ágiles (Beck 1999; Anderson 2010) para los enfoques concurrentes de hardware-software-factores humanos, como los modelos concurrentes en V (Forsberg 1991; Forsberg 2005) y el modelo de espiral de compromiso incremental (Pew y Mavor 2007; Boehm y Lane 2007).

En el siguiente artículo sobre Impulsores y opciones del proceso del ciclo de vida del sistema, se identificarán y presentarán estas variaciones sobre el tema de los modelos del ciclo de vida.

Responsabilidad de la ingeniería de sistemas

Independientemente de los modelos del ciclo de vida desplegados, el papel del ingeniero de sistemas abarca todo el ciclo de vida del sistema de interés. Los ingenieros de sistemas orquestan el desarrollo y la evolución de una solución, desde la definición de los requisitos hasta el funcionamiento y, en última instancia, hasta la retirada del sistema. Se aseguran de que los expertos en la materia participen adecuadamente, de que se aprovechen todas las oportunidades ventajosas y de que se identifiquen todos los riesgos importantes y, cuando sea posible, se mitiguen. El ingeniero de sistemas trabaja en estrecha colaboración con el director del proyecto en la adaptación del ciclo de vida genérico, incluyendo las puertas de decisión clave, para satisfacer las necesidades de su proyecto específico.

Las tareas de ingeniería de sistemas suelen concentrarse al principio del ciclo de vida; sin embargo, tanto las organizaciones comerciales como las gubernamentales reconocen la necesidad de SE a lo largo del ciclo de vida del sistema. A menudo, este esfuerzo continuo es para modificar o cambiar un sistema, producto o servicio después de que entre en producción o se ponga en funcionamiento. En consecuencia, el SE es una parte importante de todas las etapas del ciclo de vida. Durante las etapas de producción, soporte y utilización (PSU), por ejemplo, el SE ejecuta el análisis de desempeño, el monitoreo de la interfaz, el análisis de fallas, el análisis logístico, el seguimiento y el análisis de los cambios propuestos. Todas esas actividades son esenciales para el soporte continuo del sistema.

Todos los gerentes de proyecto deben garantizar que el aspecto comercial (costo, cronograma y valor) y el aspecto técnico del ciclo del proyecto permanezcan sincronizados. A menudo, el aspecto técnico impulsa el proyecto. Es responsabilidad de los ingenieros de sistemas asegurarse de que las soluciones técnicas que se están considerando son coherentes con los objetivos de coste y calendario. Esto puede requerir trabajar con los usuarios y clientes para revisar los objetivos para que se ajusten a los límites de la empresa. Estas cuestiones también impulsan la necesidad de que las puertas de decisión estén adecuadamente espaciadas a lo largo del ciclo del proyecto. Aunque la naturaleza de estas puertas de decisión variará en función de las categorías principales mencionadas, cada una de ellas implicará una validación durante el proceso entre los desarrolladores y los usuarios finales. La validación durante el proceso plantea la siguiente pregunta «¿Lo que estamos planificando o creando satisfará las necesidades de las partes interesadas?» La validación en el proceso comienza en la inicialización del proyecto durante el descubrimiento de las necesidades del usuario y continúa a través de las actividades diarias, las revisiones formales de la puerta de decisiones, la entrega del producto final o de la solución, las operaciones y, en última instancia, el cierre y la eliminación del sistema.

Trabajos citados

Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.

Beck, K. 1999. Extreme Programming Explained. Boston, MA: Addison Wesley.

Boehm, B. y J. Lane. 2007. «Uso del modelo de compromiso incremental para integrar la adquisición de sistemas, la ingeniería de sistemas y la ingeniería de software». CrossTalk. Octubre de 2007: 4-9.

Booher, H. (ed.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, USA: Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA: Wiley.

Cusumano, M., and D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA: The Free Press.

Forsberg, K. y H. Mooz. 1991. «The Relationship of System Engineering to the Project Cycle», Proceedings of INCOSE, octubre de 1991.

Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Ingeniería de sistemas y software – procesos del ciclo de vida del sistema.Ginebra, Suiza: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

Lawson, H. 2010. Un viaje a través del paisaje de los sistemas. Londres, Reino Unido: College Publications.

Ohno, T. 1988. Toyota Production System. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean para la ingeniería de sistemas. Hoboken, NJ: Wiley.

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.

Warfield, J. 1976. Systems Engineering. Washington, DC, EE.UU.: US Department of Commerce (DoC).

Whadcock, I. 2012. «Una tercera revolución industrial». The Economist. 21 de abril de 2012.

Womack, J.P., D.T. Jones y D. Roos 1990. La máquina que cambió el mundo: La historia de la producción ajustada. New York, NY, USA: Rawson Associates.

Referencias principales

Blanchard, B.S., y W.J. Fabrycky. 2011. Ingeniería y análisis de sistemas, 5ª ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook, 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.

Pew, R. y A. Mavor (Eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, EE.UU.: The National Academies Press.

Referencias adicionales

Chrissis, M., M. Konrad, y S. Shrum. 2003. CMMI: Guidelines for Process Integration and Product Improvement. Nueva York, NY, EE.UU.: Addison Wesley.

Larman, C. y B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

Los siguientes tres libros no están referenciados en el texto del SEBOK, ni son «textos» de ingeniería de sistemas; sin embargo, contienen importantes lecciones de ingeniería de sistemas, y se recomienda a los lectores de este SEBOK que los lean.

Kinder, G. 1998. Ship of Gold in the Deep Blue Sea. Nueva York, NY, EE.UU.: Grove Press.

Este es un libro excelente que sigue una idea desde su inicio hasta su implementación finalmente exitosa. Aunque no se habla de la ingeniería de sistemas, se ilustra claramente todo el proceso, desde la definición inicial del proyecto hasta el desarrollo de un concepto alternativo, pasando por la exploración por fases y los «experimentos mentales», hasta la resolución de los problemas que surgen en el camino. También muestra el problema de no anticipar los problemas críticos fuera del ámbito habitual del proyecto y la ingeniería. Se tardó unos cinco años en localizar y recuperar las 24 toneladas de lingotes y monedas de oro del barco hundido en el océano a 2.500 metros de profundidad, pero se tardó diez años en ganar la batalla legal con los abogados que representaban a las compañías de seguros que reclamaban la propiedad basándose en las pólizas de 130 años que emitieron a los propietarios del oro en 1857.

McCullough, D. 1977. The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914). Nueva York, NY, EE.UU.: Simon & Schuster.

Aunque no se menciona la «ingeniería de sistemas», este libro pone de relieve muchas cuestiones de ingeniería de sistemas e ilustra la necesidad de la SE como disciplina. El libro también ilustra el peligro de aplicar un concepto previamente exitoso (el canal a nivel del mar utilizado en Suez una década antes) en una situación similar pero diferente. Ferdinand de Lesseps dirigió tanto el proyecto de Suez como el de Panamá. Ilustra el peligro de carecer de un ciclo de proyecto basado en hechos y de puertas de decisión significativas a lo largo del ciclo del proyecto. También pone de manifiesto el peligro de proporcionar un estado del proyecto sin visibilidad. Después de cinco años del proyecto de diez años, se dijo a los inversores que el proyecto estaba completado en más de un 50%, cuando en realidad sólo se había completado el 10% del trabajo. La segunda ronda de desarrollo bajo la dirección de Stevens en 1904 se centró en «mover tierra» en lugar de cavar un canal, un concepto de ingeniería de sistemas clave para la finalización del canal. The Path Between the Seas ganó el National Book Award de historia (1978), el premio Francis Parkman (1978), el premio Samuel Eliot Morison (1978) y el premio Cornelius Ryan (1977).

Shackleton, Sir E.H. 2008. (Publicado originalmente en por William Heinemann, Londres, 1919). South: La última expedición antártica de Shackleton y el Endurance. Guilford, CT, USA: Lyons Press.

Esta es la increíble historia de la última expedición antártica de Shackleton y el Endurance en 1914 a 1917. La lección de ingeniería de sistemas es la evaluación continua y diaria de los riesgos por parte del capitán, el jefe de la expedición y la tripulación mientras permanecían atrapados en el hielo ártico durante 18 meses. Los 28 miembros de la tripulación sobrevivieron.

Vídeos relevantes

• Aproximación de la NASA a la ingeniería de sistemas – Ingeniería de sistemas espaciales 101 con la NASA