Expo Spanish

Machine Translated by Google
281
Área de conocimiento: Modelos de ciclo de vida del sistema
Modelos de ciclo de vida del sistema
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 generalmente
consta de 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 (KA), que son agrupaciones de información con un tema relacionado. Los KA a su
vez se dividen en temas. Este KA contiene los siguientes temas:
• Impulsores y opciones del proceso del ciclo de vida del
sistema • Modelos de proceso del ciclo de vida del sistema:
Vee • Modelos de proceso del ciclo de vida del sistema:
Iterativo • Integración de modelos de proceso y producto •
Ingeniería ajustada
Consulte el artículo Matriz de ejemplos de implementación para un mapeo de estudios de casos 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 de ciclo de vida genérico muestra solo el enfoque de un solo paso para proceder a través de las etapas del ciclo de vida de un
sistema. Agregar valor (como producto, servicio o ambos) es un propósito compartido entre todas las empresas, ya sean públicas o privadas,
con o sin fines de lucro. El valor se produce proporcionando e integrando los elementos de un sistema en un producto o servicio de acuerdo
con la descripción del sistema y transicionándolo hacia un uso productivo. Estas consideraciones de valor darán lugar a diversas formas del
enfoque genérico de gestión del ciclo de vida de la Figura 1. A continuación, se incluyen algunos ejemplos (Lawson 2010):
• Una empresa manufacturera produce productos de tuercas, pernos y arandelas de seguridad y luego vende sus productos como
elementos de valor agregado para ser utilizados por otras empresas; a su vez, estas empresas integran estos productos en su sistema
de valor agregado más amplio, como un avión o un automóvil. Sus requisitos generalmente serán especificados previamente por el
cliente o por los estándares de la industria.
• Una empresa mayorista o minorista ofrece productos a sus clientes. Sus clientes (personas o empresas) adquieren los productos y los
utilizan como elementos de sus sistemas. Es probable que el sistema de soporte empresarial evolucione de manera oportunista, 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. Este
incluye cuentas corrientes, cuentas de ahorro, préstamos y gestión de inversiones. Estos servicios agregan valor y se incorporan a los
sistemas de clientes de personas físicas o jurídicas. Es probable que el sistema de soporte de la empresa de servicios también evolucione
de manera oportunista, a medida que surjan nuevas capacidades de infraestructura o patrones de demanda.
• Una empresa de servicios gubernamentales brinda a los ciudadanos servicios que varían ampliamente, pero que pueden incluir servicios
como atención médica, carreteras y caminos, pensiones, aplicación de la ley o defensa. En su caso, estos servicios se convierten en
elementos de infraestructura utilizados en sistemas más amplios de interés para las personas y/o
Modelos de ciclo de vida del sistema 282
empresas Las iniciativas importantes, como un sistema de control de tráfico aéreo de próxima 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 desarrollo evolutivo y un enfoque de campo. A nivel elemental, es probable que haya ciclos de vida de un solo paso preespecificados.
• Para los sistemas de aeronaves y automoción, probablemente habría un ciclo de vida preespecificado de varias pasadas para capitalizar las
capacidades iniciales en la primera pasada, pero diseñado para agregar más capacidades de valor añadido en las pasadas posteriores.
• Una empresa de desarrollo de software diversificada proporciona productos de software que satisfacen los requisitos (necesidades) de las
partes interesadas y, por lo tanto, proporciona servicios a los usuarios del producto. Tendrá que desarrollarse para tener capacidades que
se puedan adaptar para ser utilizadas en enfoques de ciclo de vida de diferentes clientes y también con capacidades de línea de productos que
se puedan aplicar rápida y fácilmente a desarrollos de sistemas de clientes similares. Su modelo de negocios también puede incluir proporcionar
al cliente soporte para el ciclo de vida del sistema y capacidades de evolución.
Dentro de estos ejemplos, hay sistemas que se mantienen estables durante períodos de tiempo razonablemente largos y aquellos que cambian
rápidamente. La diversidad representada por estos ejemplos y sus procesos ilustran por qué no existe un proceso único que se pueda usar para
definir un ciclo de vida de sistemas específico. Los enfoques de gestión y liderazgo deben considerar el tipo de sistemas involucrados, su longevidad
y la necesidad de una rápida adaptación a los 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 afectan el tipo y la cantidad de modelos de ciclo de vida que se implementan, así como 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 tratar algunos de los problemas planteados
anteriormente. El área de conocimiento Modelos de ciclo de vida resume una serie de modelos de ciclo de vida incrementales y evolutivos, incluidas
sus principales fortalezas y debilidades, y también analiza los criterios para elegir el enfoque más adecuado.
Categorías del modelo de ciclo de vida
El modelo de ciclo de vida del sistema genérico de la figura 1 no se ajusta explícitamente a todas las situaciones. Un sistema de seguimiento simple,
precedente, puede necesitar solo una fase en la etapa de definición, mientras que un sistema complejo puede necesitar más de dos.
Con los prototipos de sistemas de construcción (vs. desechables), puede ocurrir una gran cantidad de desarrollo durante la etapa de definición. La
integración, verificación y validación del sistema pueden seguir a la implementación o adquisición de los elementos del sistema. Con el software,
particularmente las compilaciones diarias y de prueba primero, la integración, la verificación y la validación están entrelazadas con la implementación
de elementos. Además, con la próxima Tercera Revolución Industrial de impresión tridimensional y fabricación digital (Whadcock 2012), no solo el
desarrollo inicial sino también la producción inicial pueden realizarse 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 agrega
material (código) a la base de software en crecimiento, en la que la base de código expandida se prueba, se vuelve a trabajar según sea necesario y
se demuestra que cumple con los requisitos de la línea de base.
El software se puede comprar, vender, entregar y actualizar electrónicamente en cualquier parte 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 dicta que sus pruebas no pueden contar con la continuidad analítica como con el hardware. Agregar 1 a 32767 en un registro
de 15 bits no produce 32768, sino 0, como se experimenta en situaciones graves, como con el uso de
el misil patriota.
Hay un gran número de posibles modelos de procesos de ciclo de vida. 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, desarrollo lean, el proceso unificado ágil y varios
formas de los modelos en V y 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 procesos basados en la innovación)
El surgimiento de sistemas integrados e interactivos de hardware y software hizo que los procesos preespecificados fueran potencialmente
dañinos, ya que las interfaces hombresistema más efectivas tendieron a surgir con su uso, lo que llevó a más variaciones de procesos,
como SE suave (Warfield 1976, Checkland 1981) y procesos de integración del sistema humano (Booher 2003, Pew y Mavor 2007). Hasta
hace poco, los estándares de proceso y los modelos de madurez han tratado de cubrir todas las eventualidades.
Han incluido extensos procesos para la gestión de adquisiciones, selección de fuentes, revisiones y auditorías, garantía de calidad, gestión
de configuración y gestión de documentos, que en muchos casos se volverían demasiado burocráticos e ineficientes. Esto condujo a la
introducción de enfoques más esbeltos (Ohno 1988; Womack et al. 1990; Oppenheim 2011) y ágiles (Beck 1999; Anderson 2010) para
enfoques concurrentes de hardwaresoftwarefactores humanos, como los modelos en V concurrentes (Forsberg 1991; Forsberg 2005) y
Modelo espiral de compromiso incremental (Pew y Mavor 2007; Boehm, et. al. 2014).
En el próximo 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 de ciclo de vida.
Responsabilidad de Ingeniería de Sistemas
Independientemente de los modelos de ciclo de vida implementados, el rol del ingeniero de sistemas abarca todo el ciclo de vida del sistema
de interés. Los ingenieros de sistemas organizan el desarrollo y la evolución de una solución, desde la definición de los requisitos hasta la
operación y, en última instancia, hasta el retiro del sistema. Aseguran que los expertos del dominio participen adecuadamente, se persigan
todas las oportunidades ventajosas y se identifiquen todos los riesgos significativos y, cuando sea posible, se mitiguen. El ingeniero de
sistemas trabaja en estrecha colaboración con el director del proyecto para adaptar el ciclo de vida genérico, incluidas 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 gubernamentales reconocen la necesidad de SE durante todo el ciclo de vida del sistema. A menudo, este esfuerzo continuo consiste
en modificar o cambiar un sistema, producto o servicio después de que entra en producción o se pone en funcionamiento. En consecuencia,
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,
SE ejecuta análisis de rendimiento, monitoreo de interfaz, análisis de fallas, análisis de logística, seguimiento y análisis de cambios
propuestos. Todas estas actividades son esenciales para el apoyo continuo del sistema. Mantener los requisitos y el diseño dentro de una
herramienta de ingeniería de sistemas basada en modelos (MBSE) permite la gestión y el análisis de la configuración a lo largo del ciclo de
vida de SOI.
Todos los gerentes de proyecto deben asegurarse de 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 sean consistentes con los objetivos de costo y cronograma. Esto
puede requerir trabajar con los usuarios y clientes para revisar los objetivos para que se ajusten a los límites del negocio. Estos problemas
también impulsan la necesidad de que las puertas de decisión estén espaciadas adecuadamente a lo largo del ciclo del proyecto. Aunque la
naturaleza de estas puertas de decisión variará según las principales categorías anteriores, cada una implicará una validación en el proceso
entre los desarrolladores y los usuarios finales. La validación en proceso hace la pregunta: "¿Lo que estamos planeando o creando satisfará
las necesidades de las partes interesadas ?" La validación en proceso comienza con 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 decisión, la entrega del
producto final o la solución, las operaciones y, en última instancia, hasta el cierre y la eliminación del sistema.
Referencias
Trabajos citados
Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.
Beck, K. 1999. Explicación de la programación extrema. Boston, MA: Addison Wesley.
Boehm, B., J. Lane, S. Koolmanojwong y R. Turner. 2014. El Modelo Espiral de Compromiso Incremental: Principios y Prácticas para Sistemas y
Software Exitosos. Indianápolis, IN, EE. UU.: AddisonWesley.
Booher, H. (ed.) 2003. Manual de integración de sistemas humanos. Hoboken, Nueva Jersey, Estados Unidos: Wiley.
Checkland, P. 1999. Systems Thinking, Systems Practice, 2ª ed. Hoboken, Nueva Jersey, Estados Unidos: Wiley.
Cusumano, M. y D. Yoffie. 1998. Competiting on Internet Time, Nueva York, NY, EE. UU.: The Free Press.
Forsberg, K. y H. Mooz. 1991. "La relación de la ingeniería de sistemas con el ciclo del proyecto", Actas de INCOSE, octubre de 1991.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos, 3.ª ed. Hoboken, Nueva Jersey: J. Wiley &
Hijos.
ISO/CEI/IEEE. 2015.Ingeniería de sistemas y software procesos del ciclo de vida del sistema.Ginebra, Suiza: Organización Internacional de
Normalización (ISO)/Comisión Electrotécnica Internacional (IEC), Instituto de Ingenieros Eléctricos y Electrónicos.ISO/IEC 15288:2015.
Lawson, H. 2010. Un viaje a través del panorama de los sistemas. Londres, Reino Unido: Publicaciones universitarias.
Ohno, T. 1988. Sistema de producción de Toyota. Nueva York, NY: Prensa de productividad.
Oppenheim, B. 2011. Lean para Ingeniería de Sistemas. Hoboken, Nueva Jersey: Wiley.
Pew, R. y A. Mavor (eds.). 2007. Integración del sistema humano en el proceso de desarrollo del sistema: una nueva mirada.
Washington, DC, EE. UU.: Prensa de las Academias Nacionales.
Warfield, J. 1976. Ingeniería de Sistemas. Washington, DC, EE. UU.: Departamento de Comercio de EE. UU. (DoC).
Whadcock, I. 2012. “Una tercera revolución industrial”. El economista. 21 de abril de 2012.
Womack, JP, DT Jones y D. Roos 1990. La máquina que cambió el mundo: la historia de la producción ajustada.
Nueva York, NY, EE. UU.: Rawson Associates.
Referencias primarias
Blanchard, BS y WJ Fabrycky. 2011. Ingeniería y Análisis de Sistemas, 5ª ed. Serie PrenticeHall International en Ingeniería Industrial y de Sistemas.
Englewood Cliffs, Nueva Jersey, EE. UU.: PrenticeHall.
Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualización de la gestión de proyectos, 3ra ed. Hoboken, Nueva Jersey: J. Wiley &
Hijos.
INCOSE. 2015. Manual de ingeniería de sistemas, versión 4. San Diego, CA, EE. UU.: Consejo Internacional de Ingeniería de Sistemas (INCOSE).
INCOSETP200300204.
Pew, R. y A. Mavor (Eds.). 2007. Integración del sistema humano en el proceso de desarrollo del sistema: una nueva mirada.
Referencias adicionales
Chrissis, M., M. Konrad y S. Shrum. 2003. CMMI: Pautas para la integración de procesos y la mejora de productos.
Nueva York, NY, EE. UU.: Addison Wesley.
Larman, C. y B. Vodde. 2009. Escalando el desarrollo Lean y Agile. Nueva York, NY, EE. UU.: Addison Wesley.
Los siguientes tres libros no se mencionan en el texto de SEBoK, ni son "textos" de ingeniería de sistemas; sin embargo, contienen importantes
lecciones de ingeniería de sistemas y se anima a los lectores de este SEBOK a leerlas.
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 exitosa. Aunque la ingeniería de sistemas no se analiza, se
ilustra claramente en todo el proceso, desde la definición inicial del proyecto hasta el desarrollo de conceptos alternativos, la exploración por fases y
los "experimentos mentales" para abordar los desafíos en el camino. También muestra el problema de no anticipar problemas críticos fuera del
alcance habitual del proyecto y la ingeniería.
Tomó alrededor de cinco años 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 tomó diez años ganar la batalla legal con los abogados que representan a las compañías de seguros que reclamaron la
propiedad con base en en pólizas de 130 años que emitieron a los propietarios de oro en 1857.
McCullough, D. 1977. El Camino Entre los Mares: La Creación del Canal de Panamá (1870 – 1914).
Nueva York, NY, Estados Unidos: Simon & Schuster.
Aunque no se menciona la "ingeniería de sistemas", este libro destaca muchos problemas de ingeniería de sistemas e ilustra la necesidad de 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ó los proyectos de Suez y Panamá. Ilustra el peligro de carecer de un ciclo
de proyecto basado en hechos y puertas de decisión significativas a lo largo del ciclo del proyecto. También destaca el peligro de proporcionar el
estado del proyecto sin visibilidad.
Después de cinco años en el proyecto de diez años, se les dijo a los inversores que el proyecto estaba completo en más del 50 por ciento cuando,
de hecho, solo el 10 por ciento del trabajo estaba completo. La segunda ronda de desarrollo bajo 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 Premio
Nacional del Libro de Historia (1978), el Premio Francis Parkman (1978), el Premio Samuel Eliot Morison (1978) y el Premio Cornelius Ryan (1977).
Shackleton, Sir EH 2008. (Publicado originalmente en por William Heinemann, Londres, 1919). Sur: La última expedición antártica
de Shackleton y el Endurance. Guilford, CT, EE. UU.: Lyons Press.
Esta es la asombrosa historia de la última expedición antártica de Shackleton y el Endurance entre 1914 y 1917. La lección de ingeniería de sistemas
es la evaluación diaria y continua de los riesgos por parte del capitán, el líder de la expedición y la tripulación mientras permanecían atrapados en el
hielo ártico durante 18 años. meses. Los 28 miembros de la tripulación sobrevivieron.
Vídeos relevantes
[1]
• Enfoque de la NASA para la ingeniería de sistemas Ingeniería de sistemas espaciales 101 con NASA
< Artículo anterior | Artículo principal | Artículo siguiente >
SEBoK v. 2.7, publicado el 31 de octubre de 2022
Referencias
[1] https://www.youtube.com/watch?v=jxT7_NPFjkA
Impulsores y opciones del proceso del ciclo de vida del sistema 286
Impulsores y opciones del proceso del ciclo de vida del sistema
Autores principales: Kevin Forsberg, Rick Adcock
Como se discutió en el artículo Modelo genérico del ciclo de vida, hay muchos factores organizacionales que pueden afectar qué
procesos del ciclo de vida son apropiados para un sistema específico. Además, los factores técnicos también influirán en los tipos de
modelos de ciclo de vida apropiados para un sistema determinado. Por ejemplo, los requisitos del sistema pueden estar
predeterminados o pueden cambiar, según el alcance y la naturaleza del desarrollo de un sistema. Estas consideraciones conducen
a diferentes selecciones de modelos de ciclo de vida. Este artículo analiza diferentes factores técnicos que se pueden considerar al
seleccionar un modelo de proceso de ciclo de vida y proporciona ejemplos, orientación y herramientas de la literatura para respaldar
la selección del modelo de ciclo de vida. El modelo de ciclo de vida seleccionado puede afectar todos los demás aspectos del diseño
y desarrollo del sistema. (Consulte las áreas de conocimiento en la Parte 3 para obtener una descripción de cómo el ciclo de vida
puede afectar los procesos de ingeniería de sistemas (SE).)
Requisitos fijos y procesos de desarrollo evolutivo
Además del proceso de desarrollo tradicional, preespecificado, secuencial y de un solo paso (identificado como requisitos fijos),
existen varios modelos de procesos de desarrollo evolutivo; sin embargo, no existe un enfoque único que sea mejor para todas
las situaciones. Para situaciones de campo rápido, un enfoque de creación de prototipos que sea más fácil primero puede ser el
más apropiado. Para los sistemas duraderos, un enfoque más fácil primero puede producir un sistema no escalable, en el que la
arquitectura es incapaz de lograr altos niveles de rendimiento, seguridad o protección. En general, la evolución del sistema ahora
requiere niveles sostenidos mucho más altos de esfuerzo de SE, integración y pruebas tempranas y continuas, enfoques
proactivos para abordar las fuentes de cambio del sistema, mayores niveles de ingeniería concurrente y revisiones de logros
basadas en evidencia de viabilidad versus planes y descripciones del sistema. .
Los procesos o métodos de desarrollo evolutivo han estado en uso desde la década de 1960 (y quizás antes). Permiten que un
proyecto proporcione una capacidad inicial seguida de entregas sucesivas para alcanzar el sistema de interés (SoI) deseado.
Esta práctica es particularmente valiosa en los casos en que
• se desea una rápida exploración e implementación de parte del sistema; • los
requisitos no están claros desde el principio o están cambiando rápidamente; •
la financiación es limitada; • el cliente desea mantener el SoI abierto a la
posibilidad de insertar nueva tecnología cuando madure;
y
• se requiere experimentación para desarrollar versiones sucesivas.
En el desarrollo evolutivo se desarrolla una capacidad del producto en un incremento de tiempo. Cada ciclo del incremento
subsume los elementos del sistema del incremento anterior y agrega nuevas capacidades al producto en evolución para crear
una versión ampliada del producto en desarrollo. Este proceso de desarrollo evolutivo, que utiliza incrementos, puede
proporcionar una serie de ventajas, entre ellas
• integración, verificación y validación continuas del producto en evolución; •
demostraciones frecuentes de progreso; • detección temprana de defectos; • alerta
temprana de problemas de proceso; y • incorporación sistemática del inevitable
retrabajo que pueda ocurrir.
Modelos primarios de desarrollo incremental y evolutivo
Los modelos primarios de desarrollo incremental y evolutivo se enfocan en diferentes desafíos competitivos y técnicos. La fase
de tiempo de cada modelo se muestra en la Figura 1 a continuación en términos del contenido de incremento (1, 2, 3, …) con
respecto a la definición (Df), desarrollo (Dv) y producción, soporte y utilización (PSU ) etapas en la Figura 1 (Un modelo de ciclo
de vida del sistema genérico) del artículo Modelos de ciclo de vida.
Figura 1. Modelos primarios de desarrollo incremental y evolutivo.
(SEBook original)
Las notaciones de la Figura 1 (Df1..N y Dv1..N) indican que sus etapas iniciales producen especificaciones no solo para el
primer incremento, sino para el conjunto completo de incrementos. Se supone que estos permanecerán estables para el modelo
secuencial preespecificado, pero se espera que impliquen cambios para el modelo concurrente evolutivo. La notación de este
último (Dv1 y Df2R) en el mismo período de tiempo, PSU1, Dv2 y Df3R en el mismo período de tiempo, etc.) indica que los
planes y las especificaciones para el siguiente incremento están siendo reajustados por un equipo de ingeniería de sistemas al
mismo tiempo que el desarrollo del incremento actual y la PSU del incremento anterior. Esto descarga el trabajo de manejar el
tráfico de cambios del equipo de desarrollo y mejora significativamente sus posibilidades de terminar el incremento actual
dentro del presupuesto y el cronograma.
Para seleccionar un modelo de ciclo de vida apropiado, es importante primero comprender los arquetipos principales y dónde
se utilizan mejor. La Tabla 1 resume cada uno de los modelos primarios de desarrollo de un solo paso, incremental y evolutivo
en términos de ejemplos, fortalezas y debilidades, seguido de notas explicativas.
Tabla 1. Modelos primarios de desarrollo incremental y evolutivo (Boehm, et. al. 2014,
página 73).
Modelo Ejemplos ventajas Contras
Preespecificado Productos manufacturados simples: Eficiente, fácil de verificar Dificultades con cambios rápidos, requisitos
Un solo paso Tuercas, pernos, sensores simples emergentes (sensores complejos, sistemas intensivos
en humanos)
Preespecificado Plataforma de vehículos más mejoras de Capacidad inicial temprana, escalabilidad cuando es Requerimientos emergentes o cambios rápidos,
Varios pasos estable
productos planificadas previamente de valor agregado rompedores de arquitectura
(PPPI)
Evolutivo Pequeño: ágil Adaptabilidad al cambio, sistemas Arreglos más fáciles primero, tardíos, costosos, brechas
Secuencial intensivos en humanos más pequeños de tiempo de ingeniería de sistemas, lentos para sistemas

Más grande: fildeo rápido
grandes
Evolutivo Desarrollo estable, tecnología madura Actualizaciones de tecnología madura Requerimientos emergentes o cambios rápidos,
oportunista Intervalos de tiempo SysE
Evolutivo Desarrollo rápido y emergente, sistemas Requerimientos emergentes o cambios rápidos, Exceso en sistemas pequeños o altamente estables

Concurrente de sistemas incrementos estables de desarrollo, continuidad SysE
Los modelos preespecificados de un solo paso y preespecificados de varios pasos de la Tabla 1 no son evolutivos. Los modelos de varios pasos
preespecificados dividen el desarrollo para presentar una capacidad operativa inicial temprana, seguida de varias mejoras de productos planificadas previamente
(P3I). Una versión alternativa divide el trabajo pero no presenta los incrementos intermedios. Cuando los requisitos se entienden bien y son estables, los
modelos preespecificados permiten un proceso fuerte y predecible. Cuando los requisitos son emergentes y/o cambian rápidamente, a menudo requieren una
reelaboración costosa si conducen a la anulación de los compromisos arquitectónicos.
El modelo secuencial evolutivo implica un enfoque en el que la capacidad operativa inicial del sistema se desarrolla rápidamente y se actualiza en función de
la experiencia operativa. El desarrollo de software puro y ágil se ajusta a este modelo.
Si algo no sale como se esperaba y hay que cambiarlo, se arreglará en treinta días en el momento de su próxima publicación. El campo rápido también se
adapta a este modelo para sistemas más grandes o de hardware y software. Su mayor fortaleza es habilitar capacidades de respuesta rápida en el campo. En
el caso de la metodología ágil pura, el modelo puede ser víctima de un conjunto de compromisos arquitectónicos de "primero lo más fácil" que se rompen
cuando, por ejemplo, los desarrolladores de sistemas intentan aumentar la carga de trabajo en un factor de diez o agregar seguridad como una característica
nueva en un incremento posterior. . Para el campo rápido, el uso de este modelo puede resultar costoso cuando las combinaciones rápidas requieren una
revisión extensa para solucionar incompatibilidades o para adaptarse a escenarios de uso fuera de lo nominal, pero los resultados rápidos pueden valer la pena.
El modelo oportunista evolutivo puede adoptarse en casos que impliquen aplazar el siguiente incremento hasta que: se presente una oportunidad lo
suficientemente atractiva, la nueva tecnología deseada esté lo suficientemente madura para agregarse, o hasta que otros habilitadores, como componentes
escasos o personal clave, estén disponibles. También es apropiado para sincronizar actualizaciones de múltiples productos comerciales listos para usar
(COTS). Puede ser costoso mantener juntos a los equipos de desarrollo y SE mientras esperan a los habilitadores, pero nuevamente, puede valer la pena.
El modelo Concurrente Evolutivo involucra a un equipo de ingenieros de sistemas que maneja simultáneamente el tráfico de cambios y vuelve a establecer los
planes y especificaciones para el siguiente incremento, a fin de mantener estabilizado el desarrollo del incremento actual. En la Tabla 2, a continuación, se
proporciona un ejemplo y una discusión.
Tabla de decisiones de desarrollo incremental y evolutivo
La Tabla 2 proporciona algunos criterios para decidir cuál de los procesos asociados con las clases primarias de modelos de desarrollo incremental y evolutivo
usar.
Tabla 2. Tabla de decisiones de desarrollo incremental y evolutivo. (Boehm, et. al., 2014,
página 74). Reimpreso con permiso.
Modelo ¿Requisitos estables y ¿Está bien esperar a que se necesito esperar necesito esperar
preespecificables? desarrolle el sistema completo? prioridades del próximo incremento? habilitadores de siguiente incremento*?
Preespecificado Sí Sí
Un solo paso
Preespecificado Sí No
Varios pasos
Evolutivo No No Sí
Secuencial
Evolutivo No No No Sí
oportunista
Evolutivo No No No No
Concurrente
*Habilitadores de ejemplo: Madurez de la tecnología; Capacidades del sistema externo; Recursos necesarios; Nuevas oportunidades
El proceso de un solo paso preespecificado ejemplificado por el modelo tradicional en cascada o en V secuencial es apropiado si los requisitos del producto
son preespecificables y tienen una baja probabilidad de cambio significativo y si no hay valor o posibilidad de entregar una capacidad parcial del producto. Un
buen ejemplo de esto sería el hardware para un satélite de monitoreo de recursos terrestres que no sería factible modificar después de que entre en órbita.
El proceso de varios pasos preespecificados divide el desarrollo para presentar una capacidad operativa inicial temprana y varios P3I. Es mejor si las
capacidades completas del producto se pueden especificar de antemano y tienen una baja probabilidad de cambio significativo. Esto es útil en los casos en
que esperar a que se desarrolle el sistema completo incurre en una pérdida de capacidades de misión incrementales importantes y entregables. Un buen
ejemplo de esto sería una secuencia bien entendida y priorizada de actualizaciones de software para el satélite de monitoreo de recursos terrestres a bordo.
El proceso secuencial evolutivo desarrolla una capacidad operativa inicial y la actualiza en función de la experiencia operativa, como lo demuestran los métodos
ágiles. Es más necesario en los casos en que es necesario obtener retroalimentación operativa sobre una capacidad inicial antes de definir y desarrollar el
contenido del siguiente incremento. Un buen ejemplo de esto serían las actualizaciones de software sugeridas por las experiencias con la carga útil del satélite,
como qué tipo de capacidades de recopilación y análisis de datos multiespectrales son mejores para qué tipo de agricultura y bajo qué clima.
condiciones.
El proceso oportunista evolutivo difiere el siguiente incremento hasta que sus nuevas capacidades estén disponibles y lo suficientemente maduras para
agregarse. Se utiliza mejor cuando el incremento no necesita esperar comentarios operativos, pero es posible que deba esperar a los habilitadores del próximo
incremento, como la madurez de la tecnología, las capacidades del sistema externo, los recursos necesarios o las nuevas oportunidades de valor agregado.
Un buen ejemplo de esto sería la necesidad de esperar a que el software de análisis de tendencias de anomalías satelitales basado en agentes y de adaptación
de la misión se vuelva predeciblemente estable antes de incorporarlo a un
incremento programado.
El proceso Evolutivo Concurrente , como se realiza en el modelo espiral de compromiso incremental (Pew y Mavor 2007; Boehm, et.al., 2014, página 75) y se
muestra en la Figura 2, tiene un equipo continuo de ingenieros de sistemas que manejan el tráfico de cambios y re establecer los planes y especificaciones de
base para el próximo incremento, al mismo tiempo que se mantiene un equipo de desarrollo estabilizado para la entrega a tiempo y de alta seguridad del
incremento actual y se emplea un equipo de verificación y validación (V&V) concurrente para realizar una detección continua de defectos para permitir incluso
más alto
niveles de aseguramiento. Un buen ejemplo de esto sería el control de misión basado en tierra y el software de manejo de datos del satélite, la nueva
línea de base del próximo incremento para adaptarse a las nuevas versiones de COTS y las continuas solicitudes de los usuarios para las actualizaciones
de procesamiento de datos.
El ejemplo del satélite ilustra las diversas formas en que los sistemas complejos del futuro, las diferentes partes del sistema y su software pueden
evolucionar de varias maneras, afirmando una vez más que no existe un proceso único para el software. evolución. Sin embargo, la Tabla 2 puede ser
muy útil para determinar qué procesos son los más adecuados para hacer evolucionar cada parte del sistema. Además, el modelo de tres equipos en la
Figura 2 proporciona una manera para que los proyectos desarrollen los desafiantes sistemas de uso intensivo de software del futuro que necesitarán
tanto adaptabilidad a cambios rápidos como altos niveles de seguridad.
Figura 2. Manejo de cambio rápido simultáneo evolutivo y alta seguridad (Pew y Mavor 2007, Figura 26). Reimpreso con permiso de la Academia
Nacional de Ciencias, cortesía de National Academies Press, Washington, DC Todos los demás derechos están reservados por el propietario de
los derechos de autor.
Referencias
Trabajos citados
Boehm, B. 2006. "Algunas tendencias e implicaciones futuras para los procesos de ingeniería de sistemas y software". Ingeniería de Sistemas. 9(1): 119.
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". Diafonía. Octubre 2007: 49.
Boehm, B. y J. Lane. 2010. Implicaciones de gestión e ingeniería de sistemas del DoD para la adquisición evolutiva de los principales sistemas de
defensa. Informe SERC RT5, marzo de 2010. USCCSSE2010500.
Boehm, B., J. Lane, S. Koolmanojwong y R. Turner. 2014. El Modelo Espiral de Compromiso Incremental: Principios y Prácticas para Sistemas y
Software Exitosos. Indianápolis, IN, EE. UU.: AddisonWesley.
Cusumano, M. y D. Yoffee. 1998. Compitiendo en tiempo de Internet: lecciones de Netscape y su batalla con Microsoft. Nueva York, NY, EE. UU.: Free
Press.
Washington DC, EE. UU.: Prensa de las Academias Nacionales.
Ninguno.
Modelos de proceso del ciclo de vida del sistema: Vee
Autores principales: Dick Fairley, Kevin Forsberg, autor colaborador: Ray Madachy, Phyllis Marbach
Hay un gran número de modelos de procesos de ciclo de vida. Como se discutió en el artículo Impulsores y opciones del proceso del ciclo de vida del sistema ,
los modelos descritos se dividen en tres categorías principales: (1) principalmente preespecificados de un solo paso o de varios pasos, también conocidos
como procesos tradicionales o secuenciales; (2) secuencial evolutiva (o el modelo Vee) y (3) oportunista evolutiva y concurrente evolutiva (o ágil incremental).
Los procesos concurrentes se conocen por muchos nombres: el proceso unificado ágil (anteriormente, el Proceso Unificado Racional), los modelos en espiral)
e incluyen algunos que son principalmente procesos interpersonales y sin restricciones (por ejemplo, desarrollo ágil, Scrum, programación extrema (XP), el
método de desarrollo de sistemas dinámicos y procesos basados en la innovación).
Este artículo se centra específicamente en el modelo Vee como el ejemplo principal de procesos secuenciales y preespecificados.
En esta discusión, es importante señalar que el modelo Vee y las variaciones del modelo Vee 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 actividades de SE antes mencionadas.
Las implicaciones generales del uso del modelo Vee para el diseño y desarrollo de sistemas se analizan a continuación; para una comprensión más específica
de cómo este modelo de ciclo de vida afecta las actividades de ingeniería de sistemas, consulte las otras áreas de conocimiento (KA) en la Parte 3.
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
establecen como referencia y se ponen bajo gestión de configuración. La flecha vertical de dos puntas permite que los proyectos realicen análisis simultáneos
de oportunidades y riesgos, así como una validación continua durante el proceso. El modelo Vee abarca las dos primeras etapas del ciclo de vida enumeradas
en la tabla "Etapas genéricas del ciclo de vida, sus propósitos y opciones de puerta de decisión" del Manual de ingeniería de sistemas INCOSE: concepto y
desarrollo (INCOSE 2015).
Modelos de proceso del ciclo de vida del sistema: Vee 292
Figura 1. Lado izquierdo del modelo Sequential Vee (INCOSE 2015, adaptado de Forsberg, Mooz y
Cotterman 2005, Reimpreso con permiso de John Wiley & Sons Inc. Todos los demás derechos
están reservados por el propietario de los derechos de autor.
El modelo Vee respalda la definición del Manual de ingeniería de sistemas INCOSE (INCOSE 2015) de las etapas del ciclo de vida y sus propósitos o actividades,
como se muestra en la Figura 2 a continuación. Reemplace la Figura 2 con la figura actualizada que elimina la primera etapa Exploratoria.
Figura 2. Un ejemplo de etapas, sus propósitos y las principales puertas de decisión. (Original SEBoK)
Una versión más detallada del diagrama Vee incorpora actividades del ciclo de vida en el modelo Vee más genérico. Este diagrama Vee, desarrollado en la
Universidad de Adquisición de Defensa de EE. UU. (DAU), se puede ver en la Figura 3 a continuación.
Figura 3. Diagrama de actividad Vee (Prosnik 2010). Publicado por la Universidad de Adquisición de Defensa (DAU)/Departamento de Defensa de EE. UU. (DoD).
Aplicación del Modelo Vee
Lawson (Lawson 2010) desarrolla las actividades en cada etapa del ciclo de vida y señala que es útil considerar la estructura de un modelo genérico de etapa del
ciclo de vida para cualquier tipo de sistema de interés (SoI) como se muestra en la Figura 4. Esto El modelo (T) indica que una o más etapas de definición
preceden a una o más etapas de producción en las que se ha logrado la implementación (adquisición, aprovisionamiento o desarrollo) de dos o más elementos
del sistema.
Figura 4. Estructura de etapas genéricas (T) de los modelos de ciclo de vida del sistema (Lawson 2010). Reimpreso con permiso de Harold Lawson.
Todos los otros derechos están reservados por el propietario de los derechos de autor.
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 detalles, todas tienen un formato secuencial similar que enfatiza las actividades
centrales como se indica en la Tabla 1 (concepto, producción y utilización/retiro).
Figura 5. Comparaciones de modelos de ciclo de vida (Forsberg, Mooz y Cotterman 2005). Reimpreso con permiso de John
Wiley & Sons. Todos los otros derechos están reservados por el propietario de los derechos de autor.
Es importante tener en cuenta que muchas de las actividades a lo largo del ciclo de vida se repiten. Esto es un ejemplo de
recursión como se discutió en la Introducción de la Parte 3.
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 ISO/IEC/IEEE 15288.
• El término fase se refiere a los diferentes pasos del programa que soportan y gestionan la vida del sistema; el
las fases por lo general no se superponen. El término "fase" se usa en muchos modelos bien establecidos como equivalente al término
"etapa".
La gestión de programas emplea fases, hitos y puertas de decisión que se utilizan para evaluar la evolución de un sistema a través de sus
diversas 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 etapa. Para cada proyecto, es esencial definir y publicar los términos y las definiciones relacionadas
utilizadas en los proyectos respectivos para minimizar la confusión.
Un programa típico se compone de las siguientes fases:
• La fase de viabilidad o estudio consiste en estudiar la viabilidad de conceptos alternativos para llegar a un segundo
puerta de decisión antes de iniciar la etapa de ejecución. Durante la fase de factibilidad, 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). Durante esta fase, la decisión de seguir adelante se basa en:
• si un concepto es factible y se considera capaz de contrarrestar una amenaza identificada o aprovechar una oportunidad;
• si un concepto es lo suficientemente maduro para justificar el desarrollo continuo de un nuevo producto o línea de
productos; y
• si aprobar 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.
Por lo general, hay dos puertas de decisión y dos hitos asociados con las actividades de ejecución. El primer hito brinda la oportunidad para que
la gerencia revise los planes de ejecución antes de dar el visto bueno. El segundo hito brinda 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 se pueden utilizar para determinar si producir el SoI
desarrollado y si mejorarlo o retirarlo.
Estos puntos de vista de gestión de programas se aplican no solo al SoI, sino también a sus elementos y estructura.
Etapas del ciclo de vida
Las variaciones del modelo Vee se ocupan de las mismas etapas generales de un ciclo de vida:
• Los proyectos nuevos generalmente comienzan con una fase de investigación exploratoria que generalmente incluye las actividades de definición de
conceptos, específicamente los temas de análisis de negocios o misión y la comprensión de las necesidades y requisitos de las partes interesadas.
Estos maduran a medida que el proyecto pasa de la etapa exploratoria a la etapa de concepto y al desarrollo.
escenario.
• La fase de producción incluye las actividades de definición y realización del sistema, así como la
desarrollo de los requisitos del sistema (glosario) y arquitectura (glosario) a través de la verificación y
validación.
• La fase de utilización incluye las actividades de implementación y operación del sistema. • La fase de soporte incluye
las actividades de mantenimiento del sistema, logística y vida útil y del producto
gestión, que puede incluir actividades como extensión de la vida útil o actualizaciones de capacidad, actualizaciones y
modernización.
• La fase de retiro incluye las actividades de enajenación y retiro, aunque en algunos modelos, actividades como la extensión de la vida útil o las
actualizaciones, mejoras y modernización de la capacidad se agrupan en la fase de "retiro".
Puede encontrar información adicional sobre cada una de estas etapas en las secciones a continuación (consulte los enlaces a los artículos adicionales
de la Parte 3 anteriores para obtener más detalles). Es importante señalar que estas etapas del ciclo de vida y las actividades en cada etapa están
respaldadas por un conjunto de procesos de gestión de ingeniería de sistemas.
Etapa conceptual
El análisis y acuerdo de los requisitos del usuario es parte de la etapa de concepto 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 etapa de concepto es definir los requisitos y restricciones del usuario (y de las partes interesadas). Una parte clave de este proceso
es establecer la viabilidad de cumplir con los requisitos del usuario, incluida la evaluación de la preparación tecnológica. Al igual que con muchas
actividades de SE, esto a menudo se realiza de forma iterativa, y las necesidades y los 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 reducir el tiempo de desarrollo de los proyectos
de la Fuerza Aérea de EE. UU. 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 como resultado un diseño de sistema efectivo". La participación
iterativa con las partes interesadas es fundamental para el éxito del proyecto.
A excepción de las puertas de decisión primera y última de un proyecto, las puertas se realizan simultáneamente. Consulte la Figura 6 a continuación.
Figura 6. Programación de las Fases de Desarrollo. (Original SEBoK)
Durante la etapa de concepto, se crean conceptos alternativos para determinar el mejor enfoque para satisfacer las necesidades de las partes interesadas.
Mediante la visualización de alternativas y la creación de modelos, incluidos los prototipos apropiados, se aclararán las necesidades de las partes interesadas y
se destacarán los problemas impulsores. Esto puede conducir a un enfoque incremental o evolutivo para el desarrollo del sistema. Varios conceptos diferentes
pueden ser explorados en paralelo.
Etapa de desarrollo
Los conceptos seleccionados identificados en la etapa de concepto se elaboran en detalle hasta el nivel más bajo para producir la solución que cumple con 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 proceso (la flecha hacia
arriba en los modelos Vee). En el hardware, esto se hace con revisiones frecuentes del programa y un representante residente del cliente (si corresponde). En el
desarrollo ágil, la práctica es tener al 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. Es posible que se requieran modificaciones del producto para resolver problemas de producción,
reducir los costos de producción o mejorar las capacidades del producto o SoI. Cualquiera de estas modificaciones puede influir en los requisitos del sistema y
puede requerir la recalificación, la reverificación o la revalidación del sistema. 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 aprovisionamiento de sistemas de soporte que son vitales para mantener el funcionamiento
del producto. Si bien el producto o servicio suministrado puede verse como el sistema de interés estrecho (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 verse como activos del sistema que, cuando es
necesario, se activan en respuesta a una situación que ha surgido con respecto a la operación de la 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 productos y servicios del sistema. En la Figura 7, se representa la relación entre el diseño y desarrollo
del sistema y los requisitos del ILS.
Figura 7. Relación de ILS con el ciclo de vida del sistema (Eichmueller y Foreman 2009). Reimpreso con permiso del
Comité Directivo de ASD/AIA S3000L. Todos los otros derechos están reservados por el propietario de los derechos de autor.
Los requisitos de confiabilidad, que dan como resultado la necesidad de mantenibilidad y capacidad de prueba, son factores determinantes.
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 compatibilidad,
reducir los costos operativos o extender la vida útil de un sistema. Estos cambios requieren una evaluación de SE para evitar la pérdida de 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 se retiran de la operación. Las actividades de SE en esta etapa se centran principalmente en garantizar
que se cumplan los requisitos de disposición. De hecho, la planificación de la disposición es parte de la definición del sistema durante la etapa de concepto. Las
experiencias en el siglo XX demostraron repetidamente las consecuencias cuando el retiro y la eliminación del sistema no se consideraron desde el principio. A
principios del siglo XXI, muchos países cambiaron sus leyes para responsabilizar al creador de un SoI por la eliminación adecuada al final de su vida útil.
sistema.
Revisiones del ciclo de vida
Para controlar el progreso de un proyecto, se planifican diferentes tipos de revisiones. Los más utilizados se enumeran a continuación, aunque los nombres no
son universales:
• La revisión de requisitos del sistema (SRR) está planificada para verificar y validar el conjunto de requisitos del sistema antes
iniciar las actividades de diseño detallado.
• La revisión de diseño preliminar (PDR) está planificada 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 ciclo de ingeniería (también conocido como la puerta "diseñoa").
• La revisión crítica del diseño (CDR) está prevista para verificar y validar el conjunto de requisitos del sistema, el diseño
artefactos y elementos de justificación al final del último ciclo de ingeniería (los diseños "construidos" y "codificados" se publican después de esta revisión).
• Las revisiones de integración, verificación y validación se planifican a medida que los componentes se ensamblan en
subsistemas y elementos de nivel. Se lleva a cabo una secuencia de revisiones para garantizar que todo se integre correctamente y que exista evidencia
objetiva 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á con los requisitos de las partes interesadas (consulte la Figura 7).
• La revisión de validación final se lleva a cabo al final de la fase de integración. • Se pueden planificar y
realizar otras revisiones relacionadas con la gestión para controlar el correcto progreso del trabajo, según el tipo de sistema y los riesgos asociados.
Figura 8. Lado derecho del modelo Vee (Forsberg, Mooz y Cotterman 2005). Reimpreso con permiso de John Wiley & Sons Inc.
Todos los demás derechos están reservados por el copyright
dueño.
Referencias
Trabajos citados
Eichmüller, 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. Visualización de la gestión de proyectos, 3.ª ed. Nueva York, NY, Estados Unidos: J.
Wiley & Sons.
INCOSE. 2012. Manual de ingeniería de sistemas: una guía para los procesos y actividades del ciclo de vida del sistema, versión 3.2.2.
San Diego, CA, EE. UU.: Consejo Internacional de Ingeniería de Sistemas (INCOSE),
INCOSETP200300203.2.2.
Lawson, H. 2010. Un viaje a través del panorama de los sistemas. Londres, Reino Unido: Publicaciones universitarias, Kings College,
REINO UNIDO.
Beedle, M., et al. 2009. "El Manifiesto Ágil: Principios detrás del Manifiesto Ágil". en The Agile Manifesto [base de datos en línea].
Consultado el 4 de diciembre de 2014 en www.agilemanifesto.org/principles.html
Boehm, B. y R. Turner. 2004. Equilibrio de agilidad y disciplina. Nueva York, NY, EE. UU.: AddisonWesley.
Fairley, R. 2009. Gestión y liderazgo de proyectos de software. Nueva York, NY, EE. UU.: J. Wiley & Sons.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos. 3ra ed. Nueva York, NY, Estados Unidos: J.
Wiley & Sons.
INCOSE. 2012. Manual de ingeniería de sistemas: una guía para los procesos y actividades del ciclo de vida del sistema, versión 3.2.2.
INCOSETP200300203.2.2.
Lawson, H. 2010. Un viaje a través del panorama de los sistemas. Kings College, Reino Unido: Publicaciones universitarias.
Pew, R. y A. Mavor (eds.) 2007. HumanSystem Integration in the System Development Process: A New Look.
Royce, WE 1998. Gestión de proyectos de software: un marco unificado. Nueva York, NY, EE. UU.: Addison Wesley.
Anderson, D. 2010. Kanban. Sequim, WA, EE. UU.: Blue Hole Press.
Baldwin, C. y K. Clark. 2000. Reglas de diseño: el poder de la modularidad. Cambridge, MA, EE. UU.: MIT Press.
Beck, K. 1999. Explicación de la programación extrema. Nueva York, NY, EE. UU.: Addison Wesley.
Consultado en 2010. Disponible en: www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus y P. Gruenbacher (eds.). 2005. Ingeniería de Software Basada en Valor.
Nueva York, NY, Estados Unidos: Springer.
Boehm, B. 1988. "Un modelo espiral de desarrollo de software". Computadora IEEE 21 (5): 6172.
Boehm, B. 2006. "Algunas tendencias e implicaciones futuras para los procesos de ingeniería de sistemas y software". Sistemas
Ingeniería. 9(1): 119.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah y R. Madachy. 1998. "Uso del modelo espiral WinWin: un estudio de caso". Computadora
IEEE . 31(7): 3344.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (en prensa). Adoptando el Modelo Espiral: Creando Sistemas Exitosos con el
Modelo Espiral de Compromiso Incremental. Boston, MA, EE. UU.: Addison Wesley.
Castellano, DR 2004. “Top Five Quality Software Projects”. Diafonía. 17(7) (julio de 2004): 419. Disponible en : http://
www.crosstalkonline.org/storage/issuearchives/2004/200407/2004070Issue.pdf
Checkland, P. 1981. Pensamiento sistémico, práctica de sistemas. Nueva York, NY, EE. UU.: Wiley.
Crosson, S. y B. Boehm. 2009. "Ajuste de los puntos de anclaje del ciclo de vida del software: lecciones aprendidas en un contexto de
sistema de sistemas". Actas de la Conferencia de Tecnología de Sistemas y Software, 2023 de abril de 2009, Salt Lake City, UT, EE.
UU.
Dingsoyr, T., T. Dyba. y N. Moe (eds.). 2010. "Desarrollo de software ágil: investigación actual y direcciones futuras". Capítulo en B.
Boehm, J. Lane, S. Koolmanjwong y R. Turner, Architected Agile Solutions for SoftwareReliant Systems, Nueva York, NY, EE. UU.:
Springer.
Dorner, D. 1996. La lógica del fracaso. Nueva York, NY, EE. UU.: Libros básicos.
Forsberg, K. 1995. "'Si pudiera hacer eso, entonces podría...' Ingeniería de sistemas en un entorno de investigación y desarrollo".
Actas del Quinto Consejo Internacional Anual de Ingeniería de Sistemas (INCOSE)
Simposio Internacional. 2226 de julio de 1995. St. Louis, MO, EE. UU.
Forsberg, K. 2010. "Los proyectos no comienzan con requisitos". Actas de la Conferencia de Sistemas IEEE, 58 de abril de 2010, San
Diego, CA, EE. UU.
Gilb, T. 2005. Ingeniería competitiva. Maryland Heights, MO, EE. UU.: Elsevier Butterworth Heinemann.
Goldratt, E. 1984. La meta. Great Barrington, MA, EE. UU.: North River Press.
Hitchins, D. 2007. Ingeniería de sistemas: una metodología de sistemas del siglo XXI. Nueva York, NY, EE. UU.: Wiley.
Holanda, J. 1998. Emergencia. Nueva York, NY, EE. UU.: Perseus Books.
ISO/CEI. 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
247481:2010.
ISO/CEI/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/
CEI/IEEE 15288:2015.
ISO/CEI. 2003. Ingeniería de sistemas : una 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”. Diafonía. 16(7) (julio de 2003): 419. Disponible en: http://
www.crosstalkonline.org/storage/issuearchives/2003/200307/2003070Issue.pdf .
Kruchten , P. 1999 . Nueva York, NY, EE. UU.: Addison Wesley.
Landis, TR 2010. Familia Lockheed Blackbird (A12, YF12, D21/M21 y SR71). North Branch, MN, EE. UU.: Prensa especializada.
Madachy, R. 2008. Dinámica de procesos de software. Hoboken, Nueva Jersey, Estados Unidos: Wiley.
Maranzano, JF, SA Rozsypal, GH Zimmerman, GW Warnken, PE Wirth, DW Weiss. 2005. "Revisiones de arquitectura: práctica y
experiencia". Software IEEE . 22(2): 3443.
Consejo Nacional de Investigación de las Academias Nacionales (EE.UU.). 2008. PreHito A e ingeniería de sistemas de fase
temprana. Washington, DC, EE. UU.: Prensa de las Academias Nacionales.
Osterweil, L. 1987. "Los procesos de software también son software". Actas de la SEFM 2011: 9th International Conference on
Software Engineering. Monterrey, CA, Estados Unidos.
Poppendeick, M. y T. Poppendeick. 2003. Desarrollo de software Lean: un kit de herramientas ágil. Nueva York, NY, EE. UU.: Addison
Wesley.
Rechtin, E. 1991. Arquitectura de sistemas: creación y construcción de sistemas complejos. Upper Saddle River, Nueva York, EE. UU.:
Prentice Hall.
Rechtin, E. y M. Maier. 1997. El arte de la arquitectura de sistemas. Boca Ratón, FL, EE. UU.: CRC Press.
Schwaber, K. y M. Beedle. 2002. Desarrollo Ágil de Software con Scrum. Upper Saddle River, Nueva York, EE. UU.:
Prentice Hall.
Spruill, N. 2002. “Los cinco mejores proyectos de software de calidad”. Diafonía. 15(1) (enero de 2002): 419. Disponible en: http://
Stauder, T. 2005. “Los cinco premios principales del programa del Departamento de Defensa”. Diafonía. 18(9) (septiembre de 2005): 413.
Disponible en http://www.crosstalkonline.org/storage/issuearchives/2005/200509/2005090Issue.pdf.
Warfield, J. 1976. Sistemas sociales: planificación, política y complejidad. Nueva York, NY, EE. UU.: Wiley.
Womack, J. y D. Jones. 1996. Pensamiento Lean. Nueva York, NY, EE. UU.: Simon and Schuster.
Vídeos relevantes
• Introducción básica a la ingeniería de sistemas (método V) [Parte 1 de 2 [1]] [2] •
Introducción básica a la ingeniería de sistemas (método V) Parte 2 de 2
Referencias
[1] https://www.youtube.com/watch?v=9b4GYQfUuGE&t=7s
[2] https://www.youtube.com/watch?v=q8vJogfrAnE
Modelos de proceso del ciclo de vida del sistema: incremental 303
Modelos de proceso del ciclo de vida del sistema: incremental
Autor colaborador: Kevin Forsberg
Hay un gran número de modelos de procesos de ciclo de vida. Como se discutió en el artículo Controladores y opciones del proceso del ciclo de vida del
sistema , el paso único preespecificado es como tradicional o en cascada con requisitos fijos; preespecificado, de varios pasos desarrollará una capacidad
operativa inicial temprana y luego seguirá con varias mejoras de productos planificadas previamente. Los siguientes 3 son incrementales y evolutivos y
van desde el campo rápido hasta la tecnología madura y el desarrollo emergente. Hemos agrupado estos modelos en tres categorías principales: (1)
principalmente de un solo paso o de varios pasos preespecificados, también conocidos como procesos tradicionales o secuenciales; (2) secuencial
evolutiva (o el modelo Vee); y (3) oportunista evolutivo y concurrente evolutivo (o ágil incremental). Los procesos concurrentes son conocidos por muchos
nombres: el proceso unificado ágil (anteriormente el Proceso Unificado Racional), los modelos en espiral e incluyen algunos que son principalmente
procesos interpersonales y sin restricciones (por ejemplo, desarrollo ágil, Scrum, programación extrema (XP), sistema dinámico métodos de desarrollo y
procesos basados en la innovación).
Este artículo analiza el oportunismo evolutivo y el concurrente evolutivo, la tercera categoría mencionada anteriormente. Si bien hay varios modelos
diferentes que describen el entorno del proyecto, el modelo en espiral y el modelo en V se han convertido en los enfoques dominantes para visualizar el
proceso de desarrollo. Tanto la Vee como la espiral son modelos útiles que enfatizan diferentes aspectos del ciclo de vida de un sistema.
Las implicaciones generales del uso de modelos incrementales para el diseño y desarrollo de sistemas se analizan a continuación. Para una comprensión
más específica de cómo este modelo de ciclo de vida afecta las actividades de ingeniería de sistemas, consulte las otras áreas de conocimiento (KA) en
la Parte 3. Este artículo se centra en el uso de modelos de procesos de ciclo de vida incrementales en ingeniería de sistemas. (Consulte Ingeniería de
sistemas e Ingeniería de software en la Parte 6 para obtener más información sobre las implicaciones del ciclo de vida en la ingeniería de software).
Desarrollo Evolutivo e Incremental
Descripción general del enfoque evolutivo
Una metodología específica llamada desarrollo evolutivo es común en entornos de investigación y desarrollo (I+D) tanto en el sector gubernamental como
comercial. La figura 1 ilustra este enfoque, que se usó en la evolución de los mosaicos de alta temperatura para el transbordador espacial de la NASA
(Forsberg 1995). En el enfoque evolutivo, se desconoce el estado final de cada fase de desarrollo, aunque el objetivo es que cada fase resulte en algún
tipo de producto útil.
Figura 1. Modelo Genérico Evolutivo (Forsberg, Mooz, Cotterman 2005). Reimpreso con permiso de John Wiley & Sons, Inc. Todos los demás derechos están reservados
por el propietario de los derechos de autor.
El entorno de desarrollo del mundo real es complejo y difícil de mapear porque muchos ciclos de proyectos diferentes están en marcha simultáneamente.
Descripción general del enfoque incremental
Los métodos de desarrollo incremental han estado en uso desde la década de 1960 (y quizás antes). Permiten que un proyecto proporcione una capacidad
inicial seguida de entregas sucesivas para alcanzar el sistema de interés (SoI) deseado.
El enfoque incremental, que se muestra en la Figura 2, se utiliza cuando:
• se desea una rápida exploración e implementación de parte del sistema; • los requisitos no
están claros desde el principio; • la financiación es limitada; • el cliente desea mantener el SoI
abierto a la posibilidad de insertar nueva tecnología en un momento posterior; y/o • se requiere
experimentación para desarrollar sucesivas versiones prototipo (glosario).
Los atributos que distinguen el enfoque incremental del de un solo paso, impulsado por un plan, son la velocidad y la adaptabilidad.
Figura 2. Desarrollo incremental con entregas
múltiples (Forsberg, Mooz y Cotterman 2005).
Reimpreso con permiso de John Wiley & Sons Inc.
Todos los demás derechos están reservados por
el propietario de los derechos de autor.
El desarrollo incremental también puede ser de naturaleza "impulsada por un plan" si los requisitos se conocen al principio del ciclo de vida. El desarrollo
de la funcionalidad se realiza de forma incremental para permitir la inserción de la última tecnología o posibles cambios en las necesidades o requisitos.
El desarrollo incremental también impone restricciones. El ejemplo que se muestra en la Figura 3 usa los incrementos para desarrollar subsistemas (o
componentes) de alto riesgo temprano, pero el sistema no puede funcionar hasta que se completen todos los incrementos.
Figura 3. Desarrollo incremental con entrega única (Forsberg, Mooz, Cotterman 2005). Reimpreso con permiso de John Wiley & Sons Inc.
Todos los demás derechos están reservados por el propietario de los derechos de autor.
Aconseje que esta figura y sección se trasladen a la sección de Estudio de caso del SEBoK. La figura 4 muestra la era de la investigación aplicada para
el desarrollo del transbordador espacial Orbiter e ilustra varios niveles de desarrollo simultáneo, estudios comerciales y, en última instancia, implementación.
Figura 4. Evolución de los componentes y subsistemas del orbitador (incluidos los mosaicos del transbordador espacial) durante la creación de un gran proyecto de "paso
único" (Forsberg 1995). Reimpreso con permiso de Kevin Forsberg. Todos los demás derechos están reservados por el copyright
dueño.
Aconseje que esta información a continuación se mueva a la Parte 6, a menos que sea redundante o esté desactualizada.
Modelos de proceso de desarrollo de software iterativo
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 agrega material (código) a la
creciente base de software; la base de código ampliada se prueba, se vuelve a trabajar según sea necesario y se demuestra que satisface los requisitos de la línea
de base.
Los modelos de proceso para el desarrollo de software admiten el desarrollo iterativo en ciclos de varias longitudes. La Tabla 1 enumera tres modelos iterativos de
desarrollo de software que se presentan con más detalle a continuación, así como los aspectos del desarrollo de software que enfatizan esos modelos.
Tabla 1. Énfasis principales de tres modelos iterativos de desarrollo de software.
modelo iterativo Énfasis
Construcción incremental Ciclos iterativos de implementaciónverificaciónvalidacionesdemostración
Espiral Análisis iterativo basado en riesgos de enfoques alternativos y evaluación de resultados
Ágil Evolución iterativa de requisitos y código.
Tenga en cuenta que la siguiente información se centra específicamente en la utilización de diferentes modelos de ciclo de vida para
sistemas de software. Para comprender mejor las interacciones entre la ingeniería de software (SwE) y la ingeniería de sistemas (SE),
consulte Ingeniería de sistemas e Ingeniería de software KA en la Parte 6.
Descripción general de los modelos de proceso de desarrollo iterativo
Desarrollar y modificar software involucra procesos creativos que están sujetos a muchas fuerzas externas y cambiantes. La larga experiencia
ha demostrado que es imposible “hacerlo bien” la primera vez, y que los procesos de desarrollo iterativo son preferibles a los modelos de
proceso de desarrollo lineal y secuencial, como el conocido modelo Waterfall.
En el desarrollo iterativo, cada ciclo de la iteración subsume el software de la iteración anterior y agrega nuevas capacidades al producto en
evolución para crear una versión ampliada del software. Los procesos de desarrollo iterativo proporcionan las siguientes ventajas:
• Integración, verificación y validación continuas del producto en evolución; • Demostraciones
frecuentes de progreso; • Detección temprana de defectos; • Alerta temprana de problemas de
proceso; • Incorporación sistemática del inevitable retrabajo que ocurre en el desarrollo de
software; y • Entrega anticipada de capacidades de subconjunto (si se desea).
El desarrollo iterativo adopta muchas formas en SwE, incluidas las siguientes:
• Un proceso de construcción incremental, que se utiliza para producir construcciones periódicas (generalmente semanales) de productos en aumento.
capacidades;
• Desarrollo ágil, que se utiliza para involucrar de cerca a un cliente prototípico en un proceso iterativo que puede
repetir a diario; y
• El modelo espiral, que se utiliza para afrontar y mitigar los factores de riesgo encontrados en el desarrollo de las sucesivas
versiones de un producto.
El modelo de construcción incremental
El modelo de construcción incremental es un modelo de construcción, prueba y demostración de ciclos iterativos en los que se enfatizan las
demostraciones frecuentes de progreso, verificación y validación del trabajo hasta la fecha. El modelo se basa en requisitos estables y una
especificación de arquitectura de software. Cada compilación agrega nuevas capacidades al producto en crecimiento incremental.
El proceso finaliza cuando la versión final es verificada, validada, demostrada y aceptada por el cliente.
La Tabla 2 enumera algunos criterios de partición para el desarrollo incremental en unidades de construcción incrementales de (típicamente)
una semana calendario cada una. Los incrementos y la cantidad de desarrolladores disponibles para trabajar en el proyecto determinan la
cantidad de funciones que se pueden incluir en cada compilación incremental. Esto, a su vez, determina el programa general.
Tabla 2. Algunos criterios de partición para compilaciones incrementales (Fairley 2009). Reimpreso con
permiso de IEEE Computer Society y John Wiley & Sons Inc. Todos los demás derechos están reservados
tipo de sistema Criterios de partición
Paquete de aplicación Prioridad de características
Sistemas críticos para la seguridad Las características de seguridad son lo primero; otros siguen priorizados
Sistemas de uso intensivo Interfaz de usuario primero; otros siguen priorizados
Software del sistema Núcleo primero; siguen las utilidades priorizadas
La Figura 5 ilustra los detalles de los ciclos de construcciónverificaciónvalidacióndemostración en el proceso de construcción incremental. Cada
compilación incluye diseño detallado, codificación, integración, revisión y pruebas realizadas por los desarrolladores. En los casos en que el código se va
a reutilizar sin modificaciones, parte o la totalidad de una construcción incremental puede consistir en la revisión, integración y prueba del código base
aumentado con el código reutilizado. Es importante tener en cuenta que el desarrollo de un incremento puede resultar en la reelaboración de componentes
anteriores desarrollados para la integración para corregir defectos.
Figura 5. Ciclos incrementales de construcciónverificaciónvalidacióndemostración (Fairley 2009). Reimpreso con permiso de IEEE Computer Society y John Wiley & Sons Inc.
Todos los demás derechos están reservados por el propietario de los derechos de autor.
La verificación, validación y demostración incrementales, como se ilustra en la Figura 5, superan dos de los principales problemas de un enfoque en
cascada al:
• exponer los problemas con anticipación para que puedan corregirse a medida que ocurren;
e • incorporar cambios menores en el alcance de los requisitos que ocurren como resultado de demostraciones incrementales en
construcciones posteriores.
La Figura 5 también ilustra que es posible superponer construcciones sucesivas del producto. Puede ser posible, por ejemplo, iniciar un diseño detallado
de la próxima versión mientras se valida la versión actual.
Tres factores determinan el grado de superposición que se puede lograr:
1. Disponibilidad de personal; 2.
Progreso adecuado en la versión anterior; y 3. El riesgo de
reelaboración significativa en la siguiente compilación superpuesta debido a cambios en la compilación anterior en curso.
El proceso de compilación incremental generalmente funciona bien con equipos pequeños, pero se puede ampliar para proyectos más grandes.
Una ventaja importante de un proceso de compilación incremental es que las características creadas primero se verifican, validan y demuestran con
mayor frecuencia porque las compilaciones posteriores incorporan las características de las iteraciones anteriores. Al construir el software para controlar
un reactor nuclear, por ejemplo, el software de apagado de emergencia podría construirse primero, ya que luego se verificaría y validaría junto con las
características de cada construcción sucesiva.
En resumen, el modelo de construcción incremental, como todos los modelos iterativos, brinda las ventajas de la integración y validación continuas del
producto en evolución, demostraciones frecuentes de progreso, advertencia temprana de problemas, entrega temprana de capacidades de subconjunto e
incorporación sistemática del inevitable retrabajo que ocurre en el desarrollo de software.
El papel de la creación de prototipos en el desarrollo de software
En SwE, un prototipo es una maqueta de la funcionalidad deseada de alguna parte del sistema. Esto contrasta con los sistemas físicos, donde un prototipo
suele ser la primera versión completamente funcional de un sistema (Fairley 2009, 74).
En el pasado, la incorporación de prototipos de software en los sistemas de producción ha creado muchos problemas. La creación de prototipos es una
técnica útil que debe emplearse según corresponda; sin embargo, la creación de prototipos no es un modelo de proceso para el desarrollo de software. Al
construir un prototipo de software, el conocimiento obtenido a través del desarrollo del prototipo es beneficioso para el programa; sin embargo, el código
prototipo no se puede usar en la versión entregable del sistema.
En muchos casos, es más eficiente y más efectivo construir el código de producción desde cero utilizando el conocimiento obtenido mediante la creación
de prototipos que rediseñar el código existente.
Sostenimiento del ciclo de vida del software
El software, como todos los sistemas, requiere esfuerzos de mantenimiento para mejorar las capacidades, adaptarse a nuevos entornos y corregir
defectos. La distinción principal para el software es que los esfuerzos de mantenimiento cambian el software; a diferencia de las entidades físicas, los
componentes de software no tienen que ser reemplazados debido al desgaste físico. Cambiar el software requiere una nueva verificación y revalidación,
lo que puede implicar una extensa prueba de regresión para determinar que el cambio tiene el efecto deseado y no ha alterado otros aspectos de la
funcionalidad o el comportamiento.
Retiro de Software
El software útil rara vez se retira; sin embargo, el software que es útil a menudo experimenta muchas actualizaciones durante su vida útil. Una versión
posterior puede tener poca semejanza con el lanzamiento inicial. En algunos casos, el software que se ejecutaba en un entorno operativo anterior se
ejecuta en emuladores de hardware que proporcionan una máquina virtual en un hardware más nuevo. En otros casos, una mejora importante puede
reemplazar y cambiar el nombre de una versión anterior del software, pero la versión mejorada proporciona todas las capacidades del software anterior
de manera compatible. A veces, sin embargo, es posible que una versión más reciente del software no proporcione compatibilidad con la versión anterior,
lo que requiere otros cambios en un
sistema.
Principalmente Procesos Evolutivos y Concurrentes: El Incremental
Modelo espiral de compromiso
Descripción general del modelo de espiral de compromiso incremental
En la Figura 6 se muestra una vista del Modelo Espiral de Compromiso Incremental (ICSM).
Figura 6. El Modelo Espiral de Compromiso Incremental (ICSM) (Pew y Mavor 2007). Reimpreso con permiso de la Academia Nacional de Ciencias,
cortesía de National Academies Press, Washington, DC Todos los demás derechos están reservados por el propietario de los derechos de autor.
En el ICSM, cada espiral aborda los requisitos y las soluciones al mismo tiempo, en lugar de secuencialmente, así como los productos y procesos, el
hardware, el software, los factores humanos y los análisis de casos comerciales de configuraciones alternativas de productos o inversiones en líneas de
productos. Las partes interesadas consideran los riesgos y los planes de mitigación de riesgos y deciden un curso de acción. Si los riesgos son aceptables
y están cubiertos por planes de mitigación de riesgos, el proyecto pasa a la siguiente espiral.
Las espirales de desarrollo después de la primera revisión del compromiso de desarrollo siguen el enfoque de desarrollo incremental de tres equipos para
lograr tanto la agilidad como la seguridad que se muestra y analiza en la Figura 2,
"Manejo de cambios rápidos simultáneos evolutivos y alta seguridad" de los controladores de procesos del ciclo de vida del sistema y
Elecciones.
Otras vistas del modelo de espiral de compromiso incremental
La figura 7 presenta una vista actualizada del proceso del ciclo de vida del ICSM recomendado en el estudio Integración del sistema humano en el proceso
de desarrollo del sistema del Consejo Nacional de Investigación (Pew y Mavor 2007). En el estudio, se denominó Modelo de Compromiso Incremental
(ICM). El ICSM se basa en las fortalezas de los modelos de proceso actuales, como los conceptos de validación y verificación temprana en el modelo Vee,
conceptos de concurrencia en el modelo de ingeniería concurrente, conceptos más livianos en los modelos ágiles y esbeltos, conceptos basados en el
riesgo en el modelo en espiral , las fases y los puntos de anclaje en el proceso unificado racional (RUP) (Kruchten 1999; Boehm 1996), y las extensiones
recientes del modelo en espiral para abordar la adquisición de capacidades de sistemas de sistemas (SoS) (Boehm y Lane 2007).
Figura 7. Vista por fases del proceso del modelo espiral de compromiso incremental genérico (Pew y Mavor 2007). Reimpreso con permiso
de la Academia Nacional de Ciencias, cortesía de National Academies Press, Washington, DC Todos los demás derechos están reservados
La fila superior de actividades en la Figura 7 indica que varios aspectos del sistema se están diseñando simultáneamente a un nivel creciente de
comprensión, definición y desarrollo. Los más significativos de estos aspectos se muestran en la Figura 8, una extensión de una vista similar de "diagrama
de joroba" de actividades de software diseñadas simultáneamente desarrolladas como parte de RUP (Kruchten 1999).
Figura 8. Categorías de actividad del ICSM y nivel de esfuerzo (Pew y Mavor 2007).
Reimpreso con permiso de la Academia Nacional de Ciencias, cortesía de National Academies Press,
Washington, DC Todos los demás derechos están reservados por el propietario de los derechos de autor.
Al igual que con la versión de RUP, la magnitud y la forma de los niveles de esfuerzo dependerán del riesgo y es probable que varíen de un proyecto a
otro. La Figura 8 indica que se produce una gran cantidad de actividad simultánea dentro y entre las diversas fases del ICSM, todas las cuales deben
"sincronizarse y estabilizarse", una frase de mejores prácticas tomada de Microsoft Secrets (Cusumano y Selby 1996) para mantener el proyecto bajo
control.
Los procesos de revisión y el uso de expertos independientes se basan en los procedimientos altamente exitosos de la Junta de revisión de arquitectura
de AT&T descritos en “Revisiones de arquitectura: práctica y experiencia” (Maranzano et al. 2005). La Figura 9 muestra el contenido de la descripción de
la evidencia de factibilidad. Mostrar la viabilidad de los elementos desarrollados simultáneamente ayuda a sincronizar y estabilizar las actividades
simultáneas.
Figura 9. Contenido de descripción de evidencia de factibilidad (Pew y Mavor 2007). Reimpreso con permiso de la
Academia Nacional de Ciencias, cortesía de National Academies Press, Washington, DC Todos los demás derechos
La revisión del compromiso de operaciones (OCR) es diferente en el sentido de que aborda los riesgos operativos, a menudo más altos, de implementar
un sistema inadecuado. En general, las partes interesadas experimentarán un aumento de dos a diez veces en el nivel de compromiso mientras pasan
por la secuencia de hitos de revisión de certificación de ingeniería (ECR) a revisión de certificación de diseño (DCR), pero el aumento al pasar de DCR a
OCR puede ser mucho más alto. Estos niveles de compromiso se basan en perfiles de costos típicos en las distintas etapas del ciclo de vida de la
adquisición.
Principios subyacentes del ICSM
ICSM tiene cuatro principios subyacentes que deben seguirse:
1. Definición y evolución del sistema basado en el valor de las partes
interesadas; 2. Compromiso y responsabilidad incrementales; 3. Definición y
desarrollo de sistemas y software concurrentes; y 4. Toma de decisiones basada en
evidencia y riesgo.
Experiencia modelo hasta la fecha
El estudio de Integración de sistemas humanos del Consejo Nacional de Investigación (2008) encontró que los procesos y principios del ICSM se
corresponden bien con las mejores prácticas comerciales, como se describe en el Estudio de caso de bomba de infusión médica de próxima generación
en la Parte 7. Se encuentran más ejemplos en Integración de sistemas humanos en el Proceso de Desarrollo de Sistemas: Una Nueva Mirada (Pew y
Mavor 2007, cap. 5), Gestión de Proyectos de Software (Royce 1998, Apéndice D), y la serie anual de "Los Cinco Proyectos de Software de Calidad
Principales", publicado en CrossTalk (2002 2005).
Aconseje que esta información a continuación se elimine o se mueva a la Parte 6 porque parte de ella será redundante para el nuevo artículo
Ingeniería de Sistemas Ágiles y la parte Lean si son redundantes al artículo de Ingeniería Lean. Estos movimientos impulsarán las actualizaciones/
limpiezas necesarias para las referencias.
Procesos ágiles y esbeltos
De acuerdo con el Manual de ingeniería de sistemas de INCOSE 3.2.2, “Los métodos de ejecución de proyectos se pueden describir en un continuo
desde 'adaptativo' hasta 'predictivo'. Los métodos ágiles existen en el lado 'adaptativo' de este continuo, lo que no es lo mismo que decir que los métodos
ágiles son 'no planificados' o 'indisciplinados'” (INCOSE 2011, 179). Los métodos de desarrollo ágiles se pueden utilizar para admitir modelos de ciclo de
vida iterativos, lo que permite flexibilidad sobre un proceso lineal que se alinea mejor con el ciclo de vida planificado para un sistema. Principalmente
enfatizan el desarrollo y uso del conocimiento interpersonal tácito en comparación con el conocimiento documentado explícito, como se evidencia en las
cuatro propuestas de valor en el "Manifiesto Ágil":
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de esto
trabajo que hemos llegado a valorar
• Individuos e interacciones sobre procesos y herramientas; • Software de
trabajo sobre documentación completa; • Colaboración con el cliente en la
negociación de contratos; y • Responder al cambio sobre seguir un plan.
Es decir, mientras hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda. (Alianza Ágil
2001)
Los procesos Lean a menudo se asocian con métodos ágiles, aunque son más escalables y aplicables a sistemas de alta seguridad. A continuación, se
presentan algunos métodos ágiles específicos y se analiza la evolución y el contenido de los métodos lean. Consulte "Referencias principales",
"Referencias adicionales" y el artículo Ingeniería ajustada para obtener más detalles sobre procesos ágiles y ajustados específicos.
Melé
La Figura 10 muestra un ejemplo de Scrum como un flujo de proceso ágil. Al igual que con la mayoría de los otros métodos ágiles, Scrum utiliza el proceso
secuencial evolutivo que se muestra en la Tabla 1 (arriba) y se describe en la sección Requisitos fijos y Procesos de desarrollo evolutivo en los que las
capacidades de los sistemas se desarrollan en períodos cortos, generalmente alrededor de 30 días.
Luego, el proyecto vuelve a priorizar su acumulación de funciones deseadas y determina cuántas funciones puede desarrollar el equipo (generalmente 10
personas o menos) en los próximos 30 días.
La Figura 10 también muestra que una vez que se han ampliado las características a desarrollar para el Scrum actual (generalmente en forma de historias
informales) y asignado a los miembros del equipo, el equipo establece un ritmo diario de inicio con una breve reunión en la que cada equipo miembro
presenta un resumen de aproximadamente un minuto que describe el progreso desde la última reunión de Scrum, los posibles obstáculos y los planes
para el próximo día.
Figura 10. Ejemplo de flujo de proceso ágil: Scrum (Boehm y Turner 2004). Reimpreso con permiso de Ken Schwaber. Todos los otros derechos están reservados
Métodos ágiles diseñados
Durante la última década, varias organizaciones han podido ampliar los métodos ágiles mediante el uso de dos capas de equipos Scrum de diez personas.
Esto implica, entre otras cosas, hacer que la reunión diaria de cada equipo Scrum sea seguida por una reunión diaria de los líderes del equipo Scrum para
analizar las inversiones iniciales en la evolución de la arquitectura del sistema (Boehm et al. 2010). La Figura 11 muestra un ejemplo del enfoque
Architected Agile.
Figura 11. Ejemplo de proceso de arquitectura ágil (Boehm 2009). Reimpreso con permiso de Barry Boehm en nombre de USCCSSE. Todos los otros derechos están
reservados por el propietario de los derechos de autor.
Prácticas y principios ágiles
Como se ve con Scrum y los métodos ágiles diseñados, los principios "generalmente compartidos" no necesariamente se "siguen de manera uniforme".
Sin embargo, existen algunas prácticas y principios generales compartidos por la mayoría de los métodos ágiles:
• El equipo del proyecto entiende, respeta, trabaja y se comporta dentro de un proceso de SE definido; • El proyecto se
ejecuta lo más rápido posible con el mínimo tiempo de inactividad o desvío del personal durante el proyecto y la
se gestiona la ruta crítica; •
Todos los jugadores clave están colocados física o electrónicamente y los "cuadernos" se consideran propiedad del equipo.
disponible para todos;
• La gestión de referencia y el control de cambios se logran mediante acuerdos orales formales basados en “hacer una
promesa—cumplir una promesa” disciplina. Los participantes se responsabilizan mutuamente;
• La exploración de oportunidades y la reducción de riesgos se logran mediante la consulta de expertos y la verificación rápida del modelo.
junto con una estrecha colaboración con el cliente;
• El desarrollo de software se realiza en un entorno de desarrollo rápido, mientras que el hardware se desarrolla en un
taller de modelos multidisciplinar; y • Una
cultura de confrontación constructiva impregna la organización del proyecto. El equipo se hace cargo del éxito;
nunca es “responsabilidad de otra persona”.
Los principios de desarrollo ágil (adaptados para SE) son los siguientes (adaptado de Principios detrás del Manifiesto Ágil (Beedle et al. 2009)):
1. Primero, satisfacer al cliente a través de la entrega temprana y continua de software valioso (y otro sistema
elementos).
2. Dar la bienvenida a los requisitos cambiantes, incluso al final del desarrollo; Los procesos ágiles aprovechan el cambio para el cliente.
ventaja competitiva.
3. Entregar software funcional (y otros elementos del sistema) con frecuencia, desde un par de semanas hasta un par de meses,
con una preferencia por la escala de tiempo más corta.
4. El personal comercial y los desarrolladores deben trabajar juntos diariamente durante todo el proyecto.
5. Construir proyectos en torno a personas motivadas; darles el entorno, apoyar sus necesidades y confiar en ellos para
Termina el trabajo.
6. El método más eficiente y efectivo para transmitir información es la conversación cara a cara.
7. El software funcional (y otros elementos del sistema) es la principal medida de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible; los patrocinadores, desarrolladores y usuarios deben poder mantener
un ritmo constante indefinidamente.
9. La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
Un equipo debe reflexionar sobre cómo volverse más efectivo a intervalos regulares y luego sintonizar y ajustar su comportamiento en consecuencia. Esta
autorreflexión es un aspecto crítico para los proyectos que implementan procesos ágiles.
Ingeniería y Desarrollo de Sistemas Esbeltos
Orígenes
A medida que la fabricación de productos de consumo, como los automóviles, se diversificó más, los enfoques tradicionales de producción en masa
previamente planificada tuvieron problemas crecientes con la calidad y la adaptabilidad. Los sistemas de manufactura esbelta como el Sistema de
producción de Toyota (TPS) (Ohno 1988) eran mucho más adecuados para adaptarse a la diversidad, mejorar la calidad y respaldar la manufactura justo
a tiempo que podía adaptarse rápidamente a los patrones de demanda cambiantes sin tener que llevar grandes cantidades. , inventarios caros.
Gran parte de esta transformación fue estimulada por el trabajo de W. Edwards Deming, cuyo enfoque de Gestión de calidad total (TQM) transfirió la
responsabilidad de la calidad y la productividad de los planificadores e inspectores a los trabajadores de producción que estaban más cerca de los
procesos reales (Deming 1982). El enfoque de Deming involucró a todos en la organización de fabricación en la búsqueda de la mejora continua del
proceso, o "Kaizen".
Algunas de las técnicas TQM, como el control estadístico de procesos y la repetibilidad, eran más adecuadas para los procesos de fabricación repetitivos
que para el trabajo del conocimiento, como la ingeniería de sistemas (SE) y la ingeniería de software (SwE).
Otros, como la eliminación temprana de errores, la eliminación de desperdicios, la estabilización del flujo de trabajo y Kaizen, eran igualmente aplicables
al trabajo del conocimiento. Dirigido por Watts Humphrey, TQM se convirtió en el foco del Modelo de Madurez de la Capacidad del Software (Humphrey
1987; Paulk et al. 1994) y el CMMIntegrated o CMMI, que amplió su alcance para incluir la ingeniería de sistemas (Chrissis et al. 2003). Un cambio
significativo fue la redefinición del Nivel de Madurez 2 de "Repetible" a "Administrado".
El Instituto de Tecnología de Massachusetts (MIT) realizó estudios del TPS, que produjeron un enfoque similar que se denominó "Sistema de producción
ajustada" (Krafcik 1988; Womack et al. 1990). El desarrollo posterior del "pensamiento lean" y el trabajo relacionado en el MIT llevó a la Iniciativa
Aeroespacial Lean patrocinada por la Fuerza Aérea (ahora llamada Iniciativa de Avance Lean), que aplicó el pensamiento lean a SE (Murman 2003,
WomackJones 2003).
Al mismo tiempo, se utilizaron ideas lean para fortalecer los aspectos de escalabilidad y confiabilidad de los métodos ágiles para software (Poppendieck
2003; LarmanVodde 2009). El enfoque orientado al flujo de Kanban se ha aplicado con éxito al desarrollo de software (Anderson 2010).
Principios
Cada uno de estos esfuerzos ha desarrollado un conjunto similar pero diferente de principios Lean. Para la ingeniería de sistemas, la mejor fuente actual es
Lean for Systems Engineering, el producto de varios años de trabajo del grupo de trabajo INCOSE Lean SE (Oppenheim 2011). Está organizado en seis
principios, cada uno de los cuales se elabora en un conjunto de patrones de facilitadores y subhabilitadores lean para satisfacer el principio:
1. Valor. Guiar el proyecto determinando las propuestas de valor de los clientes y otras partes interesadas clave.
Manténgalos involucrados y gestione los cambios en sus propuestas de valor.
2. Mapear el flujo de valor (planificar el programa). Esto incluye una especificación exhaustiva de los requisitos, la exploración simultánea de espacios
comerciales entre las propuestas de valor, la evaluación COTS y la evaluación de la madurez de la tecnología, lo que da como resultado un plan de
proyecto completo y un conjunto de requisitos.
3. Flujo. Centrarse en las actividades de la ruta crítica del proyecto para evitar costosos paros laborales, incluida la coordinación
con proveedores externos.
4. Tire. Extraiga las próximas tareas a realizar en función de las necesidades y dependencias priorizadas. Si una necesidad de la tarea no puede ser
encontrado, rechazarlo como desecho.
5. Perfección. Aplicar la mejora continua de procesos para acercarse a la perfección. Elimine los defectos antes de tiempo para que el sistema funcione
correctamente la primera #vez, en lugar de corregirlos durante la inspección y la prueba. Encuentre y corrija las causas raíz en lugar de
síntomas.
6. Respeto a las Personas. Fluir hacia abajo la responsabilidad, la autoridad y la rendición de cuentas a todo el personal. Nutrir un aprendizaje
ambiente. Tratar a las personas como los activos más valiosos de la organización. (Oppenheim 2011)
Estos principios Lean SE son muy similares a los cuatro principios subyacentes del modelo espiral de compromiso incremental.
• Principio 1: Definición y evolución del sistema basado en el valor de las partes interesadas, aborda los principios Lean SE de
valor, mapeo de flujo de valor y respeto por las personas (los desarrolladores son partes interesadas críticas para el éxito en el ICSM).
• Principio 2: Compromiso y responsabilidad incrementales, aborda en parte el principio de atracción y también
aborda el respeto por las personas (que son responsables de sus compromisos). • Principio 3:
Definición y desarrollo simultáneos de sistemas y software, aborda en parte tanto el flujo de valor
mapeo y flujo.
• Principio 4: Toma de decisiones basada en evidencia y riesgo, usa evidencia de factibilidad como su medida de
éxito. En general, los principios del ICSM son algo ligeros en cuanto a la mejora continua del proceso, y los principios lean SE son algo insensibles a
la aparición de requisitos al defender un plan de proyecto preespecificado completo y un conjunto de requisitos.
Consulte Ingeniería ajustada para obtener más información.
Referencias
Trabajos citados
Alianza ágil. 2001. “Manifiesto para el desarrollo ágil de software”. http://agilemanifesto.org/.
Anderson, D. 2010. Kanban, Sequim, WA: Blue Hole Press.
Boehm, B. 1996. "Anclaje del proceso de software". Software IEEE 13(4): 7382.
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". Diafonía. 20(10) (octubre de 2007): 49.
Boehm, B., J. Lane, S. Koolmanjwong y R. Turner. 2010. “Soluciones ágiles diseñadas para sistemas dependientes de software”, en Dingsoyr, T., T. Dyba. y
N. Moe (eds.), Desarrollo de software ágil: investigación actual y direcciones futuras. Nueva York, NY, Estados Unidos: Springer.
Castellano, DR 2004. “Top Five Quality Software Projects”. Diafonía. 17(7) (julio de 2004): 419. Disponible en: http://www.crosstalkonline.org/
storage/issuearchives/2004/200407/2004070Issue.pdf .
Chrissis, M., M. Konrad y S. Shrum. 2003. CMMI: Pautas para la integración de procesos y la mejora de productos.
Nueva York, NY, EE. UU., Addison Wesley.
Deming, WE 1982. Fuera de la crisis. Cambridge, MA, EE. UU.: MIT.
Fairley, R. 2009. Gestión y liderazgo de proyectos de software. Nueva York, NY, EE. UU.: John Wiley & Sons.
Forsberg, K. 1995. "Si pudiera hacer eso, entonces podría..." Ingeniería de sistemas en un entorno de investigación y desarrollo. Actas del
Quinto Simposio Internacional del Consejo Internacional de Ingeniería de Sistemas (INCOSE). 2226 de julio de 1995. St. Louis, MO, EE.
UU.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos, 3.ª ed. Nueva York, NY, EE. UU.: John Wiley & Sons.
Humphrey, W., 1987. "Caracterización del proceso de software: un marco de madurez". Pittsburgh, PA, EE. UU.: Instituto de Ingeniería de
Software CMU. CMU/SEI87TR11.
Krafcik, J. 1988. "Triunfo del sistema de producción ajustada". Revisión de la gestión de Sloan. 30(1): 41–52.
larman , C. y B. Vodde. 2009. Escalando el desarrollo Lean y Agile. Nueva York, NY, EE. UU.: Addison Wesley.
Maranzano, JF, SA Rozsypal, GH Zimmerman, GW Warnken, PE Wirth, DM Weiss. 2005. "Revisiones de arquitectura: práctica y
experiencia". Software IEEE . 22(2): 3443.
Murman, E. 2003. Ingeniería de sistemas Lean I, II, notas de clase, curso MIT 16.885J, otoño. Cambridge, MA, EE. UU.:
CON.
Oppenheim, B. 2011. Lean para Ingeniería de Sistemas. Hoboken, Nueva Jersey: Wiley.
Paulk, M., C. Weber, B. Curtis y M. Chrissis. 1994. El modelo de madurez de capacidad: pautas para mejorar el proceso de software.
Reading, MA, EE. UU.: Addison Wesley.
Poppendieck, M. y T. Poppendieck. 2003. Desarrollo de software Lean: un kit de herramientas ágil para gerentes de desarrollo de software.
Nueva York, NY, EE. UU.: Addison Wesley.
Stauder, T. "Los cinco premios principales del programa del Departamento de Defensa". Diafonía. 18(9) (septiembre de 2005): 413.
Womack, J., D. Jones y D Roos. 1990. La máquina que cambió el mundo: la historia de la producción ajustada.
Nueva York, NY, EE. UU.: Rawson Associates.
Womack, J. y D. Jones. 2003. Pensamiento Lean. Nueva York, NY, EE. UU.: The Free Press.
Consultado en 2010. Disponible en: www.agilemanifesto.org/principles.html.
Fairley, R. 2009. Gestión y liderazgo de proyectos de software. Nueva York, NY, EE. UU.: J. Wiley & Sons.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos, 3ra ed. Nueva York, NY, Estados Unidos: J.
Wiley & Sons.
INCOSE. 2012. Manual de ingeniería de sistemas: una guía para los procesos y actividades del ciclo de vida del sistema. Versión 3.2.2.
INCOSETP200300203.2.2.
Lawson, H. 2010. Un viaje a través del panorama de los sistemas. Kings College, Reino Unido: Publicaciones universitarias.
Royce, WE 1998. Gestión de proyectos de software: un marco unificado. Nueva York, NY, EE. UU.: Addison Wesley.
Anderson, D. 2010. Kanban. Sequim, WA, EE. UU.: Blue Hole Press.
Baldwin, C. y K. Clark. 2000. Reglas de diseño: el poder de la modularidad. Cambridge, MA, EE. UU.: MIT Press.
Beck, K. 1999. Explicación de la programación extrema. Nueva York, NY, EE. UU.: Addison Wesley.
Beedle, M., et al. 2009. "El Manifiesto Ágil: Principios detrás del Manifiesto Ágil" en El Manifiesto Ágil [base de datos en línea]. Consultado
en 2010. Disponible en: www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus y P. Gruenbacher (eds.). 2005. Ingeniería de Software Basada en Valor.
Nueva York, NY, Estados Unidos: Springer.
Boehm, B. 1988. "Un modelo espiral de desarrollo de software". Computadora IEEE . 21(5): 6172.
Boehm, B. 2006. "Algunas tendencias e implicaciones futuras para los procesos de ingeniería de sistemas y software". Sistemas
Ingeniería. 9(1): 119.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah y R. Madachy. 1998. "Uso del modelo espiral WinWin: un estudio de caso". Computadora
IEEE . 31(7): 3344.
Boehm, B., J. Lane, S. Koolmanojwong y R. Turner. 2013 (en prensa). Adoptando el Modelo Espiral: Creando Sistemas Exitosos con el
Modelo Espiral de Compromiso Incremental. Nueva York, NY, EE. UU.: Addison Wesley.
Castellano, DR 2004. “Top Five Quality Software Projects”. Diafonía. 17(7) (julio de 2004): 419. Disponible en: http://www.crosstalkonline.org/
storage/issuearchives/2004/200407/2004070Issue.pdf .
Checkland, P. 1981. Pensamiento sistémico, práctica de sistemas. Nueva York, NY, EE. UU.: Wiley.
Crosson, S. y B. Boehm. 2009. "Ajuste de los puntos de anclaje del ciclo de vida del software: lecciones aprendidas en un contexto de
sistema de sistemas". Actas de la Conferencia de Tecnología de Sistemas y Software, 2023 de abril de 2009, Salt Lake City, UT, EE. UU.
Dingsoyr, T., T. Dyba. y N. Moe (eds.). 2010. "Desarrollo de software ágil: investigación actual y direcciones futuras". Capítulo en B. Boehm,
J. Lane, S. Koolmanjwong y R. Turner, Architected Agile Solutions for SoftwareReliant Systems, Nueva York, NY, EE. UU.: Springer.
Dorner, D. 1996. La lógica del fracaso. Nueva York, NY, EE. UU.: Libros básicos.
Faisandier, A. 2012. Arquitectura y Diseño de Sistemas. Belberaud, Francia: Sinergy'Com.
Forsberg, K. 1995. "'Si pudiera hacer eso, entonces podría...' Ingeniería de sistemas en un entorno de investigación y desarrollo". Actas
del Quinto Consejo Internacional Anual de Ingeniería de Sistemas (INCOSE)
Simposio Internacional. 2226 de julio de 1995. St. Louis, MO, EE. UU.
Forsberg, K. 2010. "Los proyectos no comienzan con requisitos". Actas de la Conferencia de Sistemas IEEE. 58 de abril de 2010. San
Diego, CA, EE. UU.
Gilb, T. 2005. Ingeniería competitiva. Maryland Heights, MO, EE. UU.: Elsevier Butterworth Heinemann.
Goldratt, E. 1984. La meta. Great Barrington, MA, EE. UU.: North River Press.
Hitchins, D. 2007. Ingeniería de sistemas: una metodología de sistemas del siglo XXI. Nueva York, NY, EE. UU.: Wiley.
Holanda, J. 1998. Emergencia. Nueva York, NY, EE. UU.: Perseus Books.
ISO/CEI. 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
247481:2010.
ISO/CEI/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. ISO/CEI/IEEE
15288:2015.
ISO/CEI. 2003. Ingeniería de sistemas : una 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).
Landis, TR 2010. Familia Lockheed Blackbird (A12, YF12, D21/M21 y SR71). North Branch, MN, EE. UU.: Prensa especializada.
Madachy, R. 2008. Dinámica de procesos de software. Nueva York, NY, EE. UU.: Wiley.
Maranzano, J., et al. 2005. "Revisiones de arquitectura: práctica y experiencia". Software IEEE . 22(2): 3443.
Consejo Nacional de Investigación de las Academias Nacionales (EE.UU.). 2008. PreHito A e ingeniería de sistemas de fase temprana.
Osterweil, L. 1987. "Los procesos de software también son software". Actas de la SEFM 2011: 9th International Conference on Software
Engineering. Monterrey, CA, Estados Unidos.
Poppendeick, M. y T. Poppendeick. 2003. Desarrollo de software Lean: un kit de herramientas ágil. Nueva York, NY, EE. UU.: Addison
Wesley.
Rechtin, E. 1991. Arquitectura de sistemas: creación y construcción de sistemas complejos. Upper Saddle River, Nueva York, EE. UU.:
Prentice Hall.
Rechtin, E. y M. Maier. 1997. El arte de la arquitectura de sistemas. Boca Ratón, FL, EE. UU.: CRC Press.
Schwaber, K. y M. Beedle. 2002. Desarrollo Ágil de Software con Scrum. Upper Saddle River, Nueva York, EE. UU.:
Prentice Hall.
Stauder, T. 2005. “Los cinco premios principales del programa del Departamento de Defensa”. Diafonía. 18(9) (septiembre de 2005): 413.
Warfield, J. 1976. Sistemas sociales: planificación, política y complejidad. Nueva York, NY, EE. UU.: Wiley.
Womack, J. y D. Jones. 1996. Pensamiento Lean. Nueva York, NY, EE. UU.: Simon and Schuster.
Modelos de proceso del ciclo de vida del sistema: sistemas ágiles
Ingeniería
Autora principal: Phyllis Marbach
Para un sistema, un ciclo de vida generalmente comienza en la fase de definición del concepto, avanza a través de etapas hasta la finalización de este
sistema, como se define en la etapa de definición del concepto. Un modelo del ciclo de vida puede ser una representación física, de datos o gráfica de
ese ciclo de vida. El proceso describe los pasos para lograr cada etapa del ciclo de vida, incluidas las entradas y salidas de esta etapa. Los sistemas
complejos y cada vez más conectados de la actualidad enfrentan una rápida obsolescencia bajo el estrés del cambio tecnológico, el cambio ambiental y
las necesidades de las misiones en rápida evolución. Para que estos sistemas sigan siendo robustos frente a la disrupción, deben diseñarse para
adaptarse ágilmente. Para satisfacer estas necesidades, se debe evaluar el sistema para aplicar el proceso que mejor sirva al sistema, subsistema o
componente del sistema de interés (SOI).
Es importante determinar el mejor ciclo de vida a utilizar para el SOI al principio de la fase de definición del concepto. En un programa que va a operar
ágilmente, especialmente si será un modelo híbrido con ágil y otros modelos de ciclo de vida, es importante definirlos y armonizarlos en puntos clave de
integración basados en el hardware u otra madurez de elementos de largo plazo. Un estudio de caso informativo donde se identificaron los puntos clave
de integración a lo largo de múltiples ciclos de vida en uso por varios componentes importantes del Observatorio de Radioastronomía de Sudáfrica
(SARAO) proporciona un excelente ejemplo de un proceso de adaptación de metodología (Kusel 2020).
En el proceso Agile SE, el ingeniero de sistemas trabaja de manera iterativa e incremental, modelando, analizando, desarrollando y comercializando
opciones continuamente para enfocar la definición de la solución del sistema. Un ejemplo de este trabajo será analizar y mantener no solo los requisitos,
sino también el modelo arquitectónico de los requisitos de nivel superior y la vinculación de esos requisitos de nivel superior con los requisitos de nivel
inferior analizados. Además de los requisitos y las representaciones de la arquitectura, el mantenimiento y la verificación de las interfaces que se definen
y siguen a medida que avanza el desarrollo son algunas de las tareas de los ingenieros de sistemas. Estas responsabilidades de los ingenieros de
sistemas son las mismas independientemente del ciclo de vida, aunque la secuencia y la organización pueden ser diferentes. El liderazgo del programa,
la ingeniería de sistemas y todos los miembros del equipo trabajan en una cultura que representa una mentalidad ágil. Agile Mindset es una combinación
de creencias y acciones de valores ágiles que incluyen enfocarse en brindar capacidades de trabajo a menudo, confiar en los trabajadores del conocimiento
para encontrar la mejor solución, mejorar el producto y el proceso a través de demostraciones y retrospecciones periódicas, planificar a menudo para
implementar las lecciones aprendidas.
Principios para el desarrollo ágil
Los principios para el desarrollo ágil (Marbach 2015) proporcionan una base para la relación de trabajo entre equipos multifuncionales que incluyen
ingenieros de sistemas y software que trabajan en proyectos de clientes que incluyen tanto el desarrollo de hardware como el desarrollo de software.
Estos principios, en la Tabla 1, son una versión modificada que se originó a partir del Manifiesto Ágil (Beck 2001) y se expandieron para aplicarlos a la
ingeniería de sistemas. La adopción de estos principios permitirá a los equipos de equipos producir capacidades de alto valor de forma incremental.
Modelos de proceso del ciclo de vida del sistema: ingeniería de sistemas ágiles 323
Principios para el desarrollo ágil (Marbach 2015) Principios tradicionales de SEBook SE
Primero, satisfacer al cliente a través de la entrega temprana y continua de capacidades valiosas. 1. La aplicación de SE es específica para las necesidades de las partes interesadas, el espacio
de la solución, la(s) solución(es) del sistema resultante y el contexto a lo largo del ciclo de vida
del sistema.
8. SE aborda las necesidades de las partes interesadas, teniendo en cuenta el
presupuesto, el cronograma y las necesidades técnicas, junto con otras expectativas y
limitaciones.
2. Planificar para la evolución de los requisitos y conservar tanta flexibilidad como sea 7. Las necesidades de las partes interesadas pueden cambiar y deben tenerse en cuenta durante el
valiosa a lo largo del desarrollo; Los procesos ágiles aprovechan el cambio para el cliente, ciclo de vida del sistema.
especialmente cuando el cambio conduce a una ventaja competitiva.
9. Las decisiones de SE se toman bajo incertidumbre teniendo en cuenta el riesgo.
3. Entregar capacidades de trabajo con frecuencia, desde un par de semanas hasta un par 5. El sistema físico real es el modelo perfecto del sistema.
de meses, con preferencia a la escala de tiempo más corta.
2. SE tiene una visión holística del sistema que incluye los elementos del sistema y
las interacciones entre ellos, los sistemas habilitadores y el entorno del sistema.
4. El personal comercial, los clientes o sus defensores e implementadores deben trabajar juntos 3. La SE influye y es influenciada por recursos internos y externos, y factores políticos,
diariamente durante todo el proyecto. económicos, sociales, tecnológicos, ambientales y legales. 13. SE integra las disciplinas
de ingeniería de una manera efectiva
manera.
14. SE es responsable de gestionar las interacciones disciplinarias dentro de la
organización.
5. Construir proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que 6. Un enfoque de SE es una comprensión progresivamente más profunda de las
necesitan, y confíe en ellos para hacer el trabajo. interacciones, sensibilidades y comportamientos del sistema, las necesidades de las
partes interesadas y su entorno operativo.
6. El método más eficiente y efectivo para transmitir información es la conversación personal. 13. SE integra las disciplinas de ingeniería de manera efectiva.
7. Las capacidades de trabajo son la medida principal del progreso. 5. El sistema físico real es el modelo perfecto del sistema.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, 8. SE aborda las necesidades de las partes interesadas, teniendo en cuenta el
desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente. presupuesto, el cronograma y las necesidades técnicas, junto con otras expectativas y
limitaciones.
9. Las decisiones de SE se toman bajo incertidumbre teniendo en cuenta el riesgo.
9. La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad. 10. La calidad de la decisión depende del conocimiento del sistema, los sistemas
habilitadores y los sistemas interoperativos presentes en el proceso de toma de
decisiones.
10. La simplicidad “el arte de maximizar la cantidad de trabajo no realizado” es esencial, 4. Tanto la política como la ley deben entenderse correctamente para no
especialmente dentro del equipo de implementación. Un proyecto de desarrollo restringir demasiado o limitar la implementación del sistema.
verdaderamente ágil no obliga al equipo de implementación a cumplir requisitos artificiales
de informes y procesos.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados, 10. La calidad de la decisión depende del conocimiento del sistema, los sistemas
basados en un conjunto mínimo de principios rectores. habilitadores y los sistemas interoperativos presentes en el proceso de toma de
decisiones.
12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego sintoniza 4. Tanto la política como la ley deben entenderse correctamente para no
y ajusta su comportamiento en consecuencia. restringir demasiado o limitar la implementación del sistema.
Los Principios para el desarrollo ágil enfatizan centrarse en las capacidades de trabajo y mantener el trabajo en progreso pequeño. La Tabla 1
asigna los Principios para el desarrollo ágil a los Principios SE tradicionales elaborados en otras partes del SEBoK. Los Principios para el
Desarrollo Ágil son complementarios a los Principios SE tradicionales y en algunos casos muy similares. Haga clic aquí para ver el conjunto
completo de los Principios de Ingeniería de Sistemas SEBoK.
Agile Systems Engineering Life Cycle Model for Mixed Discipline Engineering (Dove 2019) describe los principios que facilitan la agilidad operativa
en acción: Sense, Respond and Evolve (SRE). Un gran programa para toda la vida.
ciclo se beneficiará de la aplicación de estos principios. Además, Scaled Agile Framework® (SAFe®) describe los principios que facilitan la
agilidad del desarrollo en programas grandes con equipos de equipos, incluida la ingeniería de sistemas. Los Principios de Agilidad Operacional y
los Principios LeanAgile de SAFe se mapean en la Tabla 2 para mostrar la coherencia entre ellos. Es valioso comenzar con una mentalidad ágil
y aplicar un conjunto de principios.
Principios de agilidad operativa (Dove, et al) Scaled Agile Framework (SAFe) Principios LeanAgile
Detección: Conciencia externa (estado de alerta proactivo) Adoptar una visión económica Aplicar el pensamiento sistémico
Detección: conciencia interna (estado de alerta proactivo) Visualice y limite WIP, reduzca el tamaño de los lotes y administre la longitud de la cola
Detección: creación de sentido (análisis de riesgo, análisis del espacio comercial) Aplicar el pensamiento sistémico
Responder: Toma de decisiones (oportuna, informada) Descentralizar la toma de decisiones Aplicar cadencia, sincronizar con la planificación entre dominios
Organizar en torno al valor
Suponer variabilidad; conservar la opción
Responder: Realización de acciones (invocar/configurar la actividad del Desbloquear la motivación intrínseca de los trabajadores del conocimiento Base los hitos en la
proceso para abordar la situación) evaluación objetiva del sistema de trabajo
Responder: Evaluación de acciones (verificación y validación) Aplicar cadencia, sincronizar con la planificación entre dominios Visualizar y limitar el trabajo en curso, reducir el tamaño de los
lotes y administrar la longitud de la cola
Base los hitos en la evaluación objetiva del sistema de trabajo.
Evolución: Experimentación (variaciones en el proceso ConOps) Base los hitos en la evaluación objetiva del sistema de trabajo
Evolucionando: Evaluación (juicio interno y externo) Base los hitos en la evaluación objetiva del sistema de trabajo Construya gradualmente con ciclos de
aprendizaje rápidos e integrados
Evolución: memoria (cultura en evolución, capacidades de respuesta y Suponer variabilidad; Opción de conservación Base los hitos en la evaluación objetiva del sistema de
procesos ConOps) trabajo
[1]
Tabla 2. Comparación (o mapeo) de Principios para equipos interdisciplinarios. Los principios SAFe LeanAgile son material con derechos de
autor de Scaled Agile, Inc.
Utilizando la mentalidad ágil alineada con los valores ágiles, los principios de desarrollo ágil y los principios LeanAgile de SAFe se pueden aplicar
a las etapas del ciclo de vida de Agile SE.
Un Modelo Genérico de Ciclo de Vida muestra una etapa de Definición, una Etapa de Realización y una Etapa de Retiro. Dentro de cada etapa
hay más etapas. Cada SOI tiene un modelo de ciclo de vida correspondiente que se compone de etapas que se completan con procesos. Los
procesos dentro de cada etapa pueden ser Vee, Iterative o Agile dependiendo de la evaluación del SOI realizada durante la etapa de Definición.
Varios modelos de procesos han sido presentados en la literatura y pueden ser llamados Proceso, Modelo o Marco de Ingeniería de Sistemas
Ágiles.
Hay seis etapas del ciclo de vida del sistema que se "encuentran comúnmente" según ISO/IES/IEEE 247481 Ingeniería de sistemas y software
Gestión del ciclo de vida Parte 1: Guía para la gestión del ciclo de vida (ISO/IES/IEEE 2018).
Dove describe una "actividad de proceso y etapa del ciclo de vida asíncrona y concurrente" que agrega una séptima etapa del ciclo de vida,
Conciencia situacional (Dove 2019). Esta representación, Figura 1, se desarrolló como parte de cuatro estudios de casos de organizaciones que
usaban prácticas ágiles de manera efectiva en el desarrollo de sus sistemas. Usando este Modelo de ciclo de vida de ingeniería de sistemas
ágiles (ASELCM), el camino puede comenzar en la etapa de "Concepto", pasar a la fase de Conciencia situacional, luego pasar a la fase de
Desarrollo, volver a la fase de Conciencia situacional y así sucesivamente alrededor del círculo. Esta fase de conocimiento de la situación permite
una demostración, revisión y mejora continua antes de volver a centrar la atención en la siguiente fase adecuada, como volver al concepto o al
desarrollo.
El modelo de ciclo de vida representado en la Figura 1 se puede representar visualmente utilizando la Jerarquía de clases de patrón S* que se
muestra en la Figura 2. En esta jerarquía, el nivel superior muestra un paradigma de relación de entidad, "el contenido conceptual mínimo
necesario para modelar cualquier sistema con fines de ingeniería". o la ciencia.” (Schindel 2016). A medida que uno avanza hacia representaciones
de modelos más específicas, el patrón ASELCM hereda el contenido de los patrones principales.
El “Patrón general de ASELCM” que se muestra aproximadamente en la mitad de la Figura 2 se amplía en la Figura 3. Al desarrollar un sistema de interés (SOI),
uno debe considerar no solo el SOI que podemos considerar como el sistema objetivo, el Sistema 1 en la Figura 3 , pero también considere el proceso que produce
el sistema objetivo, el Sistema 2 en la Figura 3. Además de los sistemas 1 y 2, hay un tercer sistema que se muestra como el Sistema de Innovación. Este Sistema
3 es la metavisión de lo que influye en el diseño, desarrollo y operación del sistema de destino, el marco conductual integrado de los Sistemas 1 y 2.
Al modelar el sistema objetivo, se deben considerar los otros sistemas de influencia 2 y 3.
Otros modelos de ingeniería de sistemas, el tradicional (o cascada), el Vee, incremental y espiral se describen en
esos artículos de SEBook.
Marcos
Los pasos del proceso de ingeniería de sistemas ágiles que se realizan en cada una de las etapas a menudo incluyen:
1. Defina el elemento de mayor prioridad y/o mayor riesgo para trabajar primero, manteniendo abiertas las opciones de diseño, hasta el último
momento responsable. Esto produce una lista de elementos de trabajo con el elemento de trabajo más alto en la parte superior. Esta lista priorizada de
elementos de trabajo se denomina acumulación del programa.
2. Durante las iteraciones de desarrollo, los ingenieros analizan el requisito, diseñan las soluciones para cumplir con esos
requisitos, desarrollar sus productos, realizar pruebas de ese producto y demostrar ese producto. Para los productos de ingeniería de sistemas, estos registros
se conservan mejor en herramientas como una herramienta de gestión de requisitos, una herramienta de ingeniería de sistemas basada en modelos y un
repositorio controlado por configuración, por nombrar algunas. La iteración de desarrollo es un período corto de tiempo, generalmente de dos semanas a cuatro
semanas de duración.
3. Para productos grandes en desarrollo donde varios equipos integran sus elementos de trabajo para mostrar una
producto demostrable, es posible que se necesiten varias iteraciones para llegar a ese punto. Este período de múltiples iteraciones a menudo se
denomina incremento y, con frecuencia, dura unos tres meses.
4. Antes de iniciar un incremento, todos los equipos que trabajan para producir productos demostrables, deben reunirse para planificar su trabajo, identificar
dependencias entre los equipos y establecer compromisos para cumplir con el plan. Esta planificación recibe diferentes nombres según el marco utilizado
por el programa. Algunos lo llaman planificación de sala grande, otros lo llaman planificación de incremento de programa.
5. Al final del conjunto de iteraciones, el producto demostrable puede ser "lanzado" a las partes interesadas. Entonces todo
los miembros del programa se reúnen para planificar el próximo incremento de trabajo.
En la Figura 4 se muestra una representación visual de los equipos que trabajan con esta cadencia descrita (Rosser et al. 2014).
[2]
Este marco de ingeniería de sistemas ágiles (SE) (Rosser 2014) se alinea con la representación de Scaled Agile Framework (SAFe) del programa de trabajo
de los equipos y los trabajos pendientes del equipo mediante el desarrollo iterativo. SAFe es un marco que implementa los principios del desarrollo iterativo.
Representa cómo un sistema grande puede tener múltiples procesos de ciclo de vida que se siguen en paralelo a lo largo del tiempo. Los puntos de decisión clave
deben estar alineados entre los múltiples procesos del ciclo de vida. Hay muchos enfoques ágiles que un programa podría usar tal cual o combinados para
adaptarse a lo que funciona mejor para un dominio determinado. AgileAlliance (2017, 100) ilustra muchos de los "enfoques ágiles en función de su profundidad de
orientación y la amplitud de sus ciclos de vida".
Para un sistema complejo con requisitos cambiantes, la evaluación puede resultar en la decisión de utilizar un enfoque incremental e iterativo para el desarrollo.
Independientemente del modelo o marco que se seleccione, un programa comienza con una visión, un presupuesto y, por lo general, un período de ejecución.
Luego, las partes interesadas del programa identifican la capacidad de mayor valor para desarrollar primero. La lista de capacidades se prioriza para que el
desarrollo a largo plazo sea visible.
Sin embargo, este orden de prioridad puede cambiar a medida que avanza el trabajo. Lo que se conoce sobre el producto previsto puede tener requisitos y
representaciones de arquitectura bien definidos y lo que es conceptual tendrá esos requisitos y diseños desarrollados gradualmente a medida que pasa el tiempo.
Este método incremental de desarrollo está habilitado por el uso de una arquitectura de sistema abierto, herramientas de ingeniería de sistemas basados en
modelos (MBSE), diseño basado en conjuntos, pensamiento de diseño, integración continua, desarrollo continuo, patrones de arquitectura, arquitectura de
microservicios e ingeniería Lean.
Referencias
Trabajos citados
Agile Alliance®, Instituto de Gestión de Proyectos (PMI). 2017. "Anexo A3 Descripción general de los marcos Agile y Lean", en Agile Practice
Guide, Newtown Square, Pensilvania: Project Management Institute, Inc. p. 100.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Greening, J., Highsmith, J., Jeffries, R., Kern, J., Marick, B.,
Martin, R., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D. 2001. Principios detrás del manifiesto ágil. Consultado el 12 de septiembre de
2020. Disponible: Agilemanifesto.org/principles.html
Dove, R., Schindel, W. 2019. "Modelo de ciclo de vida de ingeniería de sistemas ágiles para ingeniería de disciplina mixta".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 20 al 25 de julio de 2019, Orlando,
FL, EE. UU.
Kusel, T. 2020. "Una metodología genérica de adaptación de procesos de ingeniería de sistemas, basada en lecciones de MeerKAT".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), julio
2022, 2020.
Marbach, P., Rosser, L., Osvalds, G., Lempia, D. 2015. "Principios para el desarrollo ágil". Actas del Simposio Internacional de la Conferencia
Internacional sobre Ingeniería de Sistemas (INCOSE), del 13 al 16 de julio de 2015, Seattle,
Washington, Estados Unidos.
Rosser, L., Marbach, P., Osvalds, G., Lempia, D. 2014. "Ingeniería de Sistemas para Programas Intensivos de Software usando Agile". Actas del
Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 30 de junio al 3 de julio de 2014, Las Vegas,
NV, EE. UU.
Principios LeanAgile de Scaled Agile Framework (SAFe®). Consultado el 12 de septiembre de 2020. Disponible: https://www.
scaledagileframework.com/safeleanagileprinciples/
Schindel, W., Dove, R. 2016. "Introducción al patrón MBSE del ciclo de vida de ingeniería de sistemas ágiles".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 18 al 21 de julio de 2016, Edimburgo,
Escocia, Reino Unido.
Agile Alliance®, Instituto de Gestión de Proyectos (PMI). 2017. "Anexo A3 Descripción general de los marcos Agile y Lean", en Agile Practice
Guide, Newtown Square, Pensilvania: Project Management Institute, Inc. p. 100.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Greening, J., Highsmith, J., Jeffries, R., Kern, J., Marick, B.,
Martin, R., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D. 2001. Principios detrás del manifiesto ágil. Consultado el 12 de septiembre de
2020. Disponible: Agilemanifesto.org/principles.html
Dove, R., Schindel, W. 2019. "Modelo de ciclo de vida de ingeniería de sistemas ágiles para ingeniería de disciplina mixta".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 20 al 25 de julio de 2019, Orlando,
FL, EE. UU.
Kusel, T. 2020. "Una metodología genérica de adaptación de procesos de ingeniería de sistemas, basada en lecciones de MeerKAT".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), julio
2022, 2020.
Marbach, P., Rosser, L., Osvalds, G., Lempia, D. 2015. "Principios para el desarrollo ágil". Actas del Simposio Internacional de la Conferencia
Internacional sobre Ingeniería de Sistemas (INCOSE), del 13 al 16 de julio de 2015, Seattle,
Washington, Estados Unidos.
Rosser, L., Marbach, P., Osvalds, G., Lempia, D. 2014. "Ingeniería de Sistemas para Programas Intensivos de Software usando Agile". Actas del
Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 30 de junio al 3 de julio de 2014, Las Vegas,
NV, EE. UU.
Principios LeanAgile de Scaled Agile Framework (SAFe®). Consultado el 12 de septiembre de 2020. Disponible: https://www.
scaledagileframework.com/safeleanagileprinciples/
Schindel, W., Dove, R. 2016. "Introducción al patrón MBSE del ciclo de vida de ingeniería de sistemas ágiles".
Actas del Simposio Internacional de la Conferencia Internacional sobre Ingeniería de Sistemas (INCOSE), del 18 al 21 de julio de 2016, Edimburgo,
Escocia, Reino Unido.
Ward., D. 2014. FIRE Cómo los métodos rápidos, económicos, moderados y elegantes encienden la innovación, Nueva York, NY: Harper Collins
Publishers.
Referencias
[1] https://www.scaledagileframework.com/safeleanagileprinciples/
[2] https://www.scaledagileframework.com/
Integración de procesos
Autores principales: Kevin Forsberg, Bud Lawson
Al realizar actividades de ingeniería de sistemas, es importante considerar la relación mutua entre los procesos y el sistema deseado. El tipo de
sistema (consulte Tipos de sistemas) que se produce afectará los procesos necesarios, como se indica en las opciones y los impulsores del
proceso del ciclo de vida del sistema. Esto puede causar la adaptación de procesos definidos como se describe en la aplicación de estándares de
ingeniería de sistemas.
Integración de procesos 328
Modelos de procesos y productos
La Figura 1 de los modelos de ciclo de vida introdujo la perspectiva de ver los productos de trabajo de la etapa proporcionados por la ejecución
del proceso como versiones de un sistema de interés (SoI) en varias etapas de la vida. Los cambios fundamentales que tienen lugar durante el
ciclo de vida de cualquier sistema creado por el hombre incluyen la definición, la producción y la utilización. Al construir sobre estos, es útil
considerar la estructura de un modelo genérico de etapas del ciclo de vida del proceso y del producto, como se muestra en la Figura 1 a
continuación.
Figura 1. Estructura de etapas genéricas (T) del ciclo de vida del sistema (Lawson 2010). Reimpreso con permiso de Harold "Bud"
Lawson. Todos los otros derechos están reservados por el propietario de los derechos de autor.
El modelo (T) indica que una etapa de definición precede a una etapa de producción donde se ha logrado la implementación (adquisición,
aprovisionamiento o desarrollo) de dos o más elementos del sistema. Los elementos del sistema se integran de acuerdo con relaciones definidas
en el SoI. Por lo tanto, se retratan tanto los aspectos del proceso como los del producto.
Los procesos de implementación e integración se siguen para proporcionar los resultados de la etapa primaria, es decir, en instancias de
productos o servicios del sistema ensamblado. Sin embargo, como se señala en los modelos de ciclo de vida, la definición del SoI cuando se
proporciona en una etapa de desarrollo también puede ser el resultado de las primeras versiones del sistema. Por ejemplo, un prototipo, que
puede verse como una forma de producción o etapa de preproducción. Después de la etapa de producción hay una etapa de utilización. Otras
etapas relevantes pueden incluir apoyo y jubilación. Tenga en cuenta que este modelo también muestra la importante distinción entre definición
versus implementación e integración.
De acuerdo con ISO/IEC/IEEE 15288 (2015), esta estructura es genérica para cualquier tipo de SoI hecho por el hombre para someterse a la
gestión del ciclo de vida. La etapa de producción se convierte así en el punto focal del modelo (T) en el que los elementos del sistema se
implementan e integran en instancias de productos o servicios del sistema en función de las definiciones. Para los sistemas físicos definidos, este
es el punto en el que se fabrican y ensamblan las instancias del producto (individualmente o en masa).
Para los sistemas no físicos, los procesos de implementación e integración se utilizan en la preparación del servicio (establecimiento) antes de
que se ejemplifiquen para proporcionar un servicio. Para los sistemas de software, este es el punto en el que se producen compilaciones que
combinan elementos de software en versiones, lanzamientos o alguna otra forma de producto de software administrado.
Usando la descomposición recursiva, la implementación de cada elemento del sistema puede involucrar la invocación del estándar nuevamente
en el siguiente nivel más bajo, tratando así el elemento del sistema como un SoI por derecho propio. Un nuevo ciclo de vida
Luego, la estructura se utiliza para los SoI de nivel inferior.
Esto se ilustra en el modelo Dual Vee (Figuras 2a y 2b). El modelo Dual Vee es un modelo de desarrollo de sistemas tridimensionales que integra
productos y procesos en la creación de arquitecturas de sistemas y componentes. Enfatiza
• gestión simultánea de oportunidades y riesgos; • validación
en proceso del usuario; • planificación de integración,
verificación y validación; y • resolución de problemas de verificación.
Cuando termina la descomposición de acuerdo con la necesidad práctica y el análisis de riesgobeneficio, los elementos del sistema se
implementan (adquieren, aprovisionan o desarrollan) de acuerdo con el tipo de elemento involucrado.
Figura 2a. El modelo Dual Vee (2a) (Forsberg, Mooz, Cotterman 2005). Reimpreso con permiso de John Wiley & Sons Inc. Todos los demás derechos
Figura 2b. El modelo Dual Vee (2b) (Forsberg, Mooz, Cotterman 2005). Reimpreso con permiso de John Wiley & Sons Inc. Todos los demás derechos
Un aspecto práctico que puede afectar el aspecto del proceso y del producto es la decisión de utilizar elementos listos para usar en forma
comercial lista para usar (COTS). En este caso, no es necesaria una mayor descomposición del elemento. El uso de elementos COTS (y su
vecino creado internamente o elemento de no desarrollo (NDI)) se ha generalizado y han demostrado su valor. Sin embargo, los desarrolladores
deben asegurarse de que el producto COTS sea apropiado para
su entorno.
Una falla conocida que ocurre con poca frecuencia en el uso normal del producto en su entorno previsto puede ser benigna y tratarse fácilmente.
En una situación nueva, podría tener consecuencias adversas dramáticas, como las que ocurrieron en el USS Yorktown Cruiser en 1998 (Wired
News Contributors 1998). El cliente ordenó que se usara Windows NT como sistema operativo principal para el barco. Una falla de división por
cero provocó que el sistema operativo fallara y el barco quedó muerto en el agua. Tuvo que ser remolcado de regreso a puerto en tres ocasiones.
Los modelos espirales diseñan simultáneamente no solo modelos de procesos y productos, sino también modelos de propiedad y éxito.
La Figura 3 muestra cómo estos modelos proporcionan controles y equilibrios, tanto en las revisiones de hitos como en las elecciones de modelos
individuales. Los métodos y herramientas que respaldan esta ingeniería concurrente se proporcionan en "Cuando los modelos chocan: lecciones
del análisis del sistema de software" (Boehm y Port 1999), "Evitar el conflicto entre modelos de software y la telaraña".
(Boehm, Port y AlSaid 2000) y “Detección de conflictos de modelos durante el desarrollo de sistemas de software” (AlSaid 2003).
Figura 3. Soporte del modelo espiral para modelos de procesos, modelos de productos, modelos de éxito, modelos de propiedades (Boehm y Port 1999). Reimpreso con permiso de
© Copyright IEEE – Todos los derechos reservados. Todos los otros derechos están reservados por el propietario de los derechos de autor.
Para los sistemas de software, la entrada en las etapas de producción es el punto en el que se crean compilaciones que combinan elementos de
software (módulos de código) en versiones, lanzamientos o alguna otra forma de producto de software administrado. Por lo tanto, la principal
diferencia entre los sistemas en general y los sistemas de software es la ligera variante del modelo genérico que se presenta en la Figura 4.
Figura 4. Modelo T para el sistema de software (Lawson 2010). Reimpreso con permiso de Harold "Bud" Lawson. Todos los otros derechos están reservados
Orden de Ejecución Etapa
La ejecución secuencial de las etapas del ciclo de vida es la más sencilla. Tal como se presenta en Modelos de proceso del ciclo de vida del
sistema : Vee y Modelos de proceso del ciclo de vida del sistema: iterativo, las variantes del modelo Vee y el modelo en espiral proporcionan
modelos no secuenciales cuando las consideraciones prácticas requieren una ejecución no lineal de las etapas del ciclo de vida.
Sobre la base de estos dos modelos, es importante tener en cuenta que varios tipos de sistemas complejos requieren que se revisen las etapas
del modelo del ciclo de vida a medida que se obtiene información (conocimiento), así como cuando cambian los requisitos de las partes
interesadas. Las iteraciones pueden implicar cambios necesarios en los procesos y en el sistema del producto o servicio. Por lo tanto, dentro del
contexto del modelo de etapas (T), se pueden describir convenientemente varias ordenaciones de ejecución de etapas, que reflejan formas de
ordenación de etapas no secuenciales, como se muestra en la Figura 5.
Figura 5. Iteración a través de las etapas del ciclo de vida (Lawson 2010). Reimpreso con permiso de Harold "Bud" Lawson. Todos los otros derechos
Cada patrón de ejecución de etapa implica la iteración de las etapas anteriores, quizás con requisitos alterados para los procesos o el sistema.
Las líneas gruesas en la Figura 5 indican la demarcación de los puntos finales revisados. Tres son formas iterativas, de las que se pueden extraer
varias variantes:
1. El desarrollo iterativo se implementa con bastante frecuencia para evaluar los requisitos de las partes interesadas, analizar el
requerimientos y desarrollar un diseño arquitectónico viable. Por lo tanto, es típico que la etapa de concepto pueda revisarse durante la
etapa de desarrollo. Para los sistemas en los que los productos se basan en estructuras físicas (electrónica, mecánica, química, etc.), la
iteración una vez iniciada la producción puede implicar costes significativos y retrasos en la programación. Por lo tanto, es importante hacerlo
"bien" antes de pasar a producción. Por lo tanto, las primeras etapas se utilizan para generar confianza (verificar y validar) que la solución
funciona correctamente y satisfará las necesidades de las partes interesadas. Naturalmente, tal enfoque también podría usarse para software
y sistemas de actividad humana; sin embargo, debido a su naturaleza suave, puede ser útil ir más allá experimentando y evaluando varias
configuraciones del sistema.
2. El desarrollo iterativo y la implementación implican producir (definir, implementar e integrar)
varias versiones del sistema, evaluando qué tan bien cumplen con los requisitos de las partes interesadas, quizás en el contexto de requisitos
cambiantes, y luego revisando el concepto y/o las etapas de desarrollo. Tales iteraciones son típicas dentro del desarrollo de sistemas de
software, donde el costo de producción no es tan significativo como para los sistemas físicos definidos. Una variante de este enfoque es el
modelo en espiral, donde iteraciones sucesivas completan más detalles (Boehm y May 1998). El uso de este enfoque requiere una cuidadosa
atención a los problemas relacionados con la gestión de la línea de base y la configuración. En este enfoque, se debe realizar una verificación
(prueba) significativa en los sistemas de software para generar confianza en que el sistema entregado cumplirá con los requisitos de las
partes interesadas.
3. La adquisición incremental o progresiva implica la entrega de sistemas en forma de productos y/o servicios a los consumidores. Este enfoque
es apropiado cuando se anticipan cambios estructurales y de capacidad (funciones) de manera controlada después del despliegue. El uso de
este enfoque puede deberse a que no se conocen todos los requisitos al principio, lo que lleva a una adquisición/implementación progresiva,
o a una decisión de manejar la complejidad del sistema y su utilización en incrementos, es decir, adquisición incremental. Estos enfoques son
vitales para los sistemas complejos en los que el software es un elemento importante del sistema. Cada incremento implica revisar las etapas
de definición y producción. La utilización de estos enfoques debe basarse en relaciones bien definidas y acordadas entre las empresas
proveedoras y adquirentes. De hecho, la iteración asociada con cada instancia de producto y/o servicio resultante bien puede verse como un
proyecto conjunto, con roles de actor proporcionados por ambas empresas.
En todos los enfoques, es aconsejable utilizar técnicas de modelado y simulación y herramientas relacionadas para ayudar a comprender el
efecto de los cambios realizados en los sistemas complejos que se gestionan durante el ciclo de vida. Estas técnicas generalmente se implementan
en las primeras etapas; sin embargo, se pueden utilizar para comprender mejor los posibles problemas y oportunidades asociados con las últimas
etapas de utilización y mantenimiento (por ejemplo, para comprender los aspectos logísticos y de asistencia técnica necesarios).
Asignación y cumplimiento de requisitos Integración de proceso y producto
Modelos
Independientemente del orden en que se ejecuten las etapas del ciclo de vida, los requisitos de las partes interesadas para el sistema, incluidos
los requisitos modificados en cada iteración, deben asignarse a las actividades apropiadas de los procesos utilizados en los proyectos para varias
etapas, así como a las propiedades de los elementos de el sistema de productos o el sistema de servicios y sus relaciones definidas. Esta
distribución se ilustró en la cuarta variante del modelo T de Lawson, tal como se presenta en Modelos de proceso del ciclo de vida del sistema:
Iterativo y Modelos de proceso del ciclo de vida del sistema: Vee.
Idealmente, el equipo de gestión de proyectos debería implementar procesos probados que integrarán los modelos de procesos técnicos con los
modelos de productos de gestión de proyectos para gestionar cualquiera de los procesos discutidos anteriormente, incluido el desarrollo
incremental y evolutivo. Los procesos que se muestran son el flujo de gestión de proyectos, comenzando con el comienzo de la fase de desarrollo
(Forsberg, Mooz y Cotterman 2005, 201).
Figura 6a. Proceso de planificación de nuevos productos: primeros pasos (Forsberg, Mooz y Cotterman 2005). Reimpreso con permiso de John Wiley & Sons
Inc. Todos los demás derechos están reservados por el propietario de los derechos de autor.
Figura 6b. Proceso de planificación de nuevos productos para resolver el problema (Forsberg, Mooz y Cotterman 2005). Reimpreso con permiso de
John Wiley & Sons Inc. Todos los demás derechos están reservados por el propietario de los derechos de autor.
Figura 6c. Proceso de planificación de nuevos productos: compromiso (Forsberg, Mooz y Cotterman 2005). Reimpreso con permiso de John
Wiley & Sons Inc. Todos los demás derechos están reservados por el propietario de los derechos de autor.
Referencias
Trabajos citados
Boehm, B. y W. May. 1988. "Un modelo en espiral de desarrollo y mejora de software". Computadora IEEE 21 (5): 6172.
Boehm, B. y D. Puerto. 1999. "Cuando los modelos chocan: lecciones del análisis de sistemas de software". Profesional de TI 1(1): 4956.
Boehm, B., J. Lane, S. Koolmanojwong y R. Turner (próximamente). Adoptando el Modelo Espiral: Creando Sistemas Exitosos con el Modelo
Espiral de Compromiso Incremental. Nueva York, NY, EE. UU.: Addison Wesley.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos. 3ra ed. Nueva York, NY, Estados Unidos: J.
Wiley & Sons.
ISO/CEI/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.ISO/IEC/IEEE
15288:2015
Colaboradores de noticias por cable. 2011. “Sunk by Windows NT”, Wired News, última modificación el 24 de julio de 1998. Acceso el 11 de
septiembre de 2011. Disponible en http://www.wired.com/science/discoveries/news/1998/07/13987.
Boehm, B. y W. May. 1988. "Un modelo en espiral de desarrollo y mejora de software". Computadora IEEE . 21(5): 6172.
Forsberg, K., H. Mooz y H. Cotterman. 2005. Visualización de la gestión de proyectos, 3ra ed. Nueva York, NY, EE. UU.: John Wiley & Sons.
AlSaid, M. 2003. "Detección de conflictos de modelos durante el desarrollo de sistemas de software". Tesis doctoral Departamento de Ciencias
de la Computación, Universidad del Sur de California, diciembre de 2003.
Boehm, B., J. Lane, S. Koolmanojwong y R. Turner. (próximo). Adoptando el Modelo Espiral: Creando Sistemas Exitosos con el Modelo Espiral
de Compromiso Incremental. Nueva York, NY, EE. UU.: Addison Wesley.
Boehm, B. y D. Puerto. 1999. "Escapar del pozo de alquitrán del software: conflictos de modelos y cómo evitarlos". Notas de ingeniería de software
de ACM. (enero de 1999): pág. 3648.
Boehm, B. y D. Puerto. 1999. "Cuando los modelos chocan: lecciones del análisis de sistemas de software". Profesional de TI. 1(1): 4956.
Boehm, B., D. Port y M. AlSaid. 2000. "Evitar el software ModelClash Spiderweb". Computadora IEEE .
33(11): 120122.
Lawson, H. y M. Persson. 2010. "Representación de aspectos de los modelos de ciclo de vida del sistema". Actas de la Conferencia Europea de
Ingeniería de Sistemas (EuSEC). 2326 de mayo de 2010. Estocolmo, Suecia.
Ingeniería esbelta 338
Ingeniería esbelta
La ingeniería de sistemas lean (LSE) es la aplicación del pensamiento lean (Womack 2003) a la ingeniería de sistemas (SE) y los aspectos relacionados de
la gestión empresarial y de proyectos. LSE es un enfoque aplicable durante todo el ciclo de vida del sistema. El objetivo de LSE es ofrecer el mejor valor de
ciclo de vida para sistemas técnicamente complejos con un desperdicio mínimo. La ingeniería Lean es relevante para todos los procesos técnicos
tradicionales de SE (ver definición de concepto, definición de sistema, realización del sistema, implementación y uso del sistema, etc.). La ingeniería Lean
también interactúa y utiliza muchas de las disciplinas de ingeniería especializadas discutidas en la Parte 6.
Ingeniería de sistemas esbeltos
SE es una práctica sólida y establecida, pero no siempre se entrega de manera efectiva. La mayoría de los programas están cargados con algún tipo de
desperdicio, como: coordinación deficiente, requisitos inestables, problemas de calidad, demoras, reelaboración o frustración de la administración. Estudios
recientes de la Oficina de Responsabilidad del Gobierno de EE. UU. (GAO), la Asociación Nacional de Aeronáutica y del Espacio (NASA) y el Instituto de
Tecnología de Massachusetts (MIT) sobre programas gubernamentales documentan importantes sobrecostos presupuestarios y programados y una
cantidad significativa de desperdicio en programas gubernamentales, algunos alcanzando el setenta por ciento. de tiempo cargado. Este desperdicio
representa una reserva de productividad en los programas y grandes oportunidades para mejorar la eficiencia de los programas.
LSE es la aplicación del pensamiento lean a la ingeniería de sistemas y aspectos relacionados de la gestión empresarial y de proyectos. SE se centra en la
disciplina que permite el desarrollo de sistemas técnicos complejos. El pensamiento Lean es un paradigma holístico que se enfoca en brindar el máximo
valor al cliente y minimizar las prácticas derrochadoras.
Se ha aplicado con éxito en la fabricación, los depósitos de aviones, la administración, la gestión de la cadena de suministro, la asistencia sanitaria y el
desarrollo de productos, que incluye la ingeniería. LSE es el área de sinergia entre el pensamiento lean y SE, cuyo objetivo es ofrecer el mejor valor de ciclo
de vida para sistemas técnicamente complejos con un desperdicio mínimo. LSE no significa menos SE. Significa más y mejor SE con mayor responsabilidad,
autoridad y rendición de cuentas (RAA), lo que lleva a un mejor flujo de trabajo sin desperdicios con una mayor garantía de la misión. Bajo la filosofía de la
LSE, el aseguramiento de la misión no es negociable y debe incluirse cualquier tarea que sea legítimamente necesaria para el éxito; sin embargo, debe
estar bien planificado y ejecutado con un desperdicio mínimo.
Principios esbeltos
Oppenheim (2011) describe los seis principios lean para el desarrollo de productos (PD) de la siguiente manera:
1. Captar el valor definido por el cliente. No se puede enfatizar demasiado la importancia de capturar el valor de la tarea o del programa (requisitos,
CONOPS, etc.) con precisión, claridad y exhaustividad antes de que los gastos de recursos aumenten para evitar reelaboraciones innecesarias.
2. Mapear el flujo de valor (planificar el programa) y eliminar el desperdicio. Asignar todas las tareas vinculadas de extremo a extremo,
nodos de control/decisión, y los flujos de información de interconexión necesarios para obtener valor para el cliente. Durante el proceso de mapeo,
elimine todas las actividades que no agregan valor y permita que las actividades restantes fluyan (sin volver a trabajar, retroceder o detenerse). El
término flujo de información se refiere a los paquetes de información (conocimiento) creados por diferentes tareas y que fluyen hacia otras tareas para
agregar valor posteriormente, tales como: diseño, análisis, prueba, revisión, decisión o integración. Cada tarea agrega valor si aumenta el nivel de
información útil y reduce el riesgo en el contexto de entregar valor al cliente.
3. Haga fluir el trabajo a través de pasos y procesos de valor agregado planificados y optimizados, sin paradas ni tiempo de inactividad, reelaboración
no planificada o reflujo. Para optimizar el flujo, se debe planificar la máxima concurrencia de tareas, hasta casi la capacidad de una empresa. Las
iteraciones de ingeniería legítimas se necesitan con frecuencia en PD, pero tienden a consumir mucho tiempo y son costosas si se extienden a través
de disciplinas. Lean PD fomenta la metodología eficiente de falla temprana: falla a menudo a través de técnicas rápidas de arquitectura y descubrimiento
durante el diseño inicial
etapas. Lean flow también hace todo lo posible por utilizar técnicas que eviten iteraciones prolongadas, como la carga anticipada del diseño,
la exploración del espacio comercial, los diseños de escenarios, los diseños modulares, el conocimiento heredado y los grandes márgenes. Cuando
las iteraciones interfuncionales detalladas son realmente necesarias, el flujo ajustado optimiza los bucles de iteración para obtener un valor general.
4. Deje que los clientes obtengan valor. En PD, el principio de extracción tiene dos significados importantes: (1) la inclusión de cualquier tarea en un
programa debe estar justificada por una necesidad específica de un cliente interno o externo y coordinada con ellos, y (2) la tarea debe completarse
cuando el cliente necesita la salida. La finalización excesivamente temprana conduce a la "obsolescencia de la vida útil", incluida la posible pérdida de
la memoria humana o los requisitos modificados, y la finalización tardía conduce a retrasos en el cronograma. Esta es la razón por la que cada
propietario o ingeniero de tareas debe estar en estrecha comunicación con sus clientes internos para comprender completamente sus necesidades y
expectativas y coordinar su trabajo.
5. Perseguir la perfección de todos los procesos. La competencia global requiere mejoras continuas de los procesos y
productos Sin embargo, ninguna organización puede darse el lujo de gastar recursos mejorando todo todo el tiempo. Los ingenieros de sistemas deben
hacer una distinción entre procesos y salidas de procesos. Perfeccionar y refinar el resultado del trabajo en una tarea dada debe estar delimitado por la
propuesta de valor general (éxito del sistema o misión, presupuesto del programa y cronograma) que define cuándo un resultado es "suficientemente
bueno". Por el contrario, la ingeniería y otros procesos deben mejorarse continuamente por razones competitivas.
6. Respeto a las personas. Una empresa lean es una organización que reconoce que su gente es lo más importante
recurso. En una empresa Lean, las personas no tienen miedo de identificar problemas e imperfecciones de manera honesta y abierta en tiempo real,
generar ideas sobre las causas fundamentales y las acciones correctivas sin temor, o planificar soluciones efectivas en conjunto por consenso para
evitar que un problema vuelva a ocurrir.
Habilitadores Lean para sistemas
En 2009, el Grupo de Trabajo Lean SE (LSE WG) del Consejo Internacional de Ingeniería de Sistemas (INCOSE) lanzó un producto en línea titulado Lean
Enablers for Systems Engineering (LEfSE). Es una colección de prácticas y recomendaciones formuladas como "hacer" y "no hacer" de SE, basadas en el
pensamiento lean. Las prácticas cubren un amplio espectro de SE y otras prácticas de gestión empresarial relevantes, con un enfoque general en mejorar
el valor del programa y la satisfacción de las partes interesadas y reducir el desperdicio, las demoras, los sobrecostos y las frustraciones. LEfSE se agrupan
bajo los seis principios lean descritos anteriormente. Las LEfSE no pretenden convertirse en una práctica obligatoria, pero deben usarse como una lista de
verificación de buenas prácticas. LEfSE no reemplaza al SE tradicional; en cambio, lo modifican con un pensamiento esbelto.
LEfSE fue desarrollado por catorce profesionales experimentados de INCOSE, algunos líderes reconocidos en Lean y SE de la industria, la academia y los
gobiernos (como los EE. UU., el Reino Unido e Israel), con la cooperación del LSE WG internacional de 160 miembros. Recopilaron las mejores prácticas
de muchas empresas, agregaron el conocimiento tácito colectivo, la sabiduría y la experiencia de los miembros del LSE WG e insertaron las mejores
prácticas de la investigación y la literatura lean. El producto ha sido evaluado mediante encuestas y comparaciones con las recomendaciones programáticas
recientes de la GAO y la NASA.
Oppenheim (2011) incluye una explicación completa de los habilitadores, así como la historia de LSE, el proceso de desarrollo de LEfSE, ejemplos
industriales y otro material. Oppenheim, Murman y Secor (2011) proporcionan un artículo académico sobre LEfSE. Oppenheim también publicó un breve
resumen en 2009.
Referencias
Trabajos citados
Grupo de Trabajo de Ingeniería de Sistemas Lean. 2009. "Habilitadores Lean para Ingeniería de Sistemas". Consultado el 13 de enero
2016 a las http:/ / www. ingeniería de sistemas esbeltos. org/ wpcontent/ uploads/ 2012/ 07/
LeanEnablersforSEVersion1_03.pdf.
Grupo de Trabajo de Ingeniería de Sistemas Lean. 2009. "Guía de referencia rápida Habilitadores Lean para ingeniería de sistemas".
Consultado el 13 de enero de 2016 en http://www. ingeniería de sistemas esbeltos. org/ wpcontent/ uploads/ 2012/ 07/ LEfSEQuick
ReferenceGuide8pages.pdf.
Oppenheim, BW 2009. "Process Replication: Lean Enablers for Systems Engineering". CrossTalk, la revista de ingeniería de software de
defensa. julio/agosto de 2009.
Oppenheim, BW 2011. Lean para Ingeniería de Sistemas, con Lean Enablers para Ingeniería de Sistemas. Hoboken, Nueva Jersey, Estados
Unidos: Wiley.
Oppenheim, BW, EM Murman y D. Secor. 2011. "Habilitadores Lean para Ingeniería de Sistemas". Diario de Sistemas
Ingeniería. 1(14).
Womack, JP 2003. Pensamiento Lean. Columbus, OH, EE. UU.: Prensa libre.
Grupo de Trabajo de Ingeniería de Sistemas Lean. 2009. "Habilitadores Lean para Ingeniería de Sistemas". Consultado el 13 de enero de
2016 en http:/ / www. ingeniería de sistemas esbeltos. org/ wpcontent/ uploads/ 2012/ 07/ LeanEnablersforSEVersion1_03.pdf.
Oppenheim, B., E. Murman y D. Sekor. 2010. "Habilitadores Lean para Ingeniería de Sistemas". Ingeniería de Sistemas.
14(1). Consultado el 13 de enero de 2016. Disponible en http://www.leansystemsengineering. org/wpcontent/ uploads/ 2012/07/LEfSE
JSEcompressed.pdf.
Instituto Lean Enterprise. 2009. "Principios de Lean". Consultado el 1 de marzo de 2012 en http://www.lean.org/WhatsLean/Principles.cfm .

Expo Spanish

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Expo Spanish

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Preespecificado Productos manufacturados simples: Eficiente, fácil de verificar Dificultades con cambios rápidos, requisitos

Un solo paso Tuercas, pernos, sensores simples emergentes (sensores complejos, sistemas intensivos

Preespecificado Plataforma de vehículos más mejoras de Capacidad inicial temprana, escalabilidad cuando es Requerimientos emergentes o cambios rápidos,

Evolutivo Pequeño: ágil Adaptabilidad al cambio, sistemas Arreglos más fáciles primero, tardíos, costosos, brechas

Secuencial intensivos en humanos más pequeños de tiempo de ingeniería de sistemas, lentos para sistemas

Evolutivo Desarrollo estable, tecnología madura Actualizaciones de tecnología madura Requerimientos emergentes o cambios rápidos,

Evolutivo Desarrollo rápido y emergente, sistemas Requerimientos emergentes o cambios rápidos, Exceso en sistemas pequeños o altamente estables

Modelo ¿Requisitos estables y ¿Está bien esperar a que se necesito esperar necesito esperar

preespecificables? desarrolle el sistema completo? prioridades del próximo incremento? habilitadores de siguiente incremento*?

También podría gustarte

Expo Spanish

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Expo Spanish

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Pre­especificado Productos manufacturados simples: Eficiente, fácil de verificar Dificultades con cambios rápidos, requisitos

Un solo paso Tuercas, pernos, sensores simples emergentes (sensores complejos, sistemas intensivos

Pre­especificado Plataforma de vehículos más mejoras de Capacidad inicial temprana, escalabilidad cuando es Requerimientos emergentes o cambios rápidos,

Evolutivo Pequeño: ágil Adaptabilidad al cambio, sistemas Arreglos más fáciles primero, tardíos, costosos, brechas

Secuencial intensivos en humanos más pequeños de tiempo de ingeniería de sistemas, lentos para sistemas

Evolutivo Desarrollo estable, tecnología madura Actualizaciones de tecnología madura Requerimientos emergentes o cambios rápidos,

Evolutivo Desarrollo rápido y emergente, sistemas Requerimientos emergentes o cambios rápidos, Exceso en sistemas pequeños o altamente estables

Modelo ¿Requisitos estables y ¿Está bien esperar a que se necesito esperar necesito esperar

preespecificables? desarrolle el sistema completo? prioridades del próximo incremento? habilitadores de siguiente incremento*?

También podría gustarte

Preespecificado Productos manufacturados simples: Eficiente, fácil de verificar Dificultades con cambios rápidos, requisitos

Preespecificado Plataforma de vehículos más mejoras de Capacidad inicial temprana, escalabilidad cuando es Requerimientos emergentes o cambios rápidos,