Professional Documents
Culture Documents
Sarah A. Sheard y Ali Montashari Stevens Institute of Technology, Castle Point on the Hudson, Hoboken, NJ 07030
1
ABSTRACT
Este paper muestra como tres sistemas, de tipos bien conocidos para la Ingeniera de Sistemas pueden ser entendidos como sistemas complejos. Esto es importante porque la investigacin en la ciencia de sistemas complejos es vibrante y provee entendimiento crtico, pero si la ingeniera de sistemas no entiende los aspectos complejos de los sistemas con que ellos trabajan a diario ellos no sern capaces de usar los resultados de estas investigaciones. A la fecha, la ingeniera de sistemas ha estado explotando solo el lado orden del espectro orden-caos. Ahora es tiempo de entender y empezar a utilizar los principios del espectro que estn desde la mitad hasta el lado del caos. Tres ejemplos de sistemas complejos son INCOSE, los procesos de ingeniera de sistemas (tales como el proceso estndar de una compaa), y el control de trfico areo. INCOSE representa a la mayora de grupos sociales u organizaciones de voluntarios. La mayora de ingenieros de sistemas no nota que los procesos de ingeniera de sistemas en una compaa son una red que puede ser estudiada con los mtodos de los sistemas complejos. El control de trfico areo puede ser ms cercano a la definicin de sistema para muchos de los ingenieros de sistemas. Este paper provee principios de sistemas complejos basados en una gran variedad de fuentes y muestra la aplicacin de sistemas complejos a uno de los ejemplos. Palabras clave: ingeniera de sistemas complejos, complejidad, caos, principios, sistema de sistemas, roles.
1. INTRODUCCIN
La Ingeniera de sistemas (IS) ha evolucionado sin mucho conocimiento previo terico o formal de su prctica; en lugar de eso ha dependido de los principios o heurstica desarrollados experimentalmente [Defoe, 1993; Rechtin, 1991, Stevens et al., 1998]. La ingeniera de sistemas desarroll el logro de un balance entre subsistemas y distintas disciplinas. Mantenindonos en el tema, para los investigadores de ingeniera de sistemas es potencialmente valioso investigar qu hay en los sistemas a parte de sus componentes, en otras palabras, qu da a un sistema su valor aadido sobre la suma de las partes [Rouse 2007]. Uno podra imaginar una ciencia de relaciones subyacente a la ingeniera de sistemas. Afortunadamente, la investigacin en el mundo de sistemas complejos (algunas veces llamado teora de la complejidad) est empezando a crear una base terica formal para la ingeniera de sistemas que est parcialmente lista para ser usada, ambos explican la prctica actual y ayudan a modelar los sistemas existentes de modo que se puedan hacer exploraciones predictivas. Si modelos matemticos pueden predecir, por ejemplo, las caractersticas de desempeo holstico, entonces los parmetros del sistema pueden ser variados para mejorar va modelamiento cualidades particulares, ms que intentar numerosas respuestas posibles errneas en el desarrollo de hardware y software. La pronta determinacin de parmetros clave puede ayudar a mantener los programas de la ingeniera de sistemas encaminados y evitar descarrilamientos debido a sorpresas tardas y el subsecuente efecto en cadena que estos programas pueden experimentar. Muchos cientficos de sistemas complejos estn haciendo grandes hallazgos ao a ao, lo cual desde el punto de vista de los ingenieros de sistemas significa que sus recomendaciones estn cambiando constantemente. Por ello es prematuro especificar con seguridad mejores prcticas (y podra ser siempre incorrecto intentar usar mejores prcticas en este campo; ver Kurtz y Snowden [2003]), es valioso mantenerse al da con la literatura y
1
E-mail: sheard@3Milsys.com
obtener los conocimientos regularmente. Este paper es un intento de coleccionar y presentar principios de Sistemas Complejos, seleccionados por su aplicabilidad al desarrollo y uso en sistemas basados en ingeniera hechos por el hombre, i.e., ingeniera de sistemas. Un reciente libro: Sistemas de Ingeniera Compleja [Braha, Minai, y Bar-Yam 2006] sirve como una amplia introduccin al campo de los sistemas complejos para los ingenieros de sistemas. Aunque tan completo (y nico) como es, este libro, el cual es fuertemente terico, no tiene suficiente principios prcticos para la ingeniera de sistemas. Es posible deducir principios de sistemas complejos e ingeniera de sistemas complejos (ISCx) a partir de la gran cantidad de papers dentro de ello, pero la mayora de papers son presentados de modo que no muchos ingenieros de sistemas se tomarn el tiempo de decodificarlos. Este paper intenta mostrar ejemplos de sistemas que son sistemas complejos, y que condensan un buen nmero de principios en un resumen adecuado para una amplia distribucin por INCOSE. La esperanza es que despus de la revisin y re-trabajo organizacional, este pueda crecer y convertirse en una documentacin til en el cuerpo de conocimiento de la ingeniera de sistemas.
Un razonable y pequeo conocimiento previo en teora de sistemas complejos para ingenieros de sistemas se puede encontrar en Sheard [2005]. Una versin un ligeramente ms grande se puede encontrar en Sheard [2007]. Otro material que adems puede ser til es el del Grupo Facilitador de Ciencia de Sistemas de INCOSE (ahora llamado Grupo de Trabajo de Sistemas Complejos) tal como el de Sheard [2006]. Es importante definir sistema complejo si la informacin acerca de ellos ser usada para mejorar la prctica de la ingeniera de sistemas. Las siguientes definiciones detalladas integran ingredientes de definiciones del Consejo Internacional para la Ingeniera de Sistemas (INCOSE) [Sheard, 2006; Haskins, 2006], Universidad de Michigan [Umich, 2006], Clemson University [Maier y Fadel, 2006], MITRE Corporation [Norman y Kuras, 2006], y el New England Complex Systems Institute [Bar-Yam, 2006, 2003b]. Definicin de Sistemas Complejo Un sistema complejo tiene muchos componentes autnomos, i.e., los bloques constitutivos bsicos son agentes individuales del sistema. o Los elementos son heterogneos (difieren en caractersticas importantes), i.e., tienen variedad. o La frontera del sistema a menudo es difcil de sealar. Los sistemas complejos son auto-organizados (muestran un decremento de entropa debido a la utilizacin de energa del ambiente)
Los sistemas complejos exhiben comportamiento emergente en un macro-nivel que emerge de acciones e interacciones de los agentes individuales. La estructura y comportamiento de un sistema complejo no es fcil deducir o inferir solamente a partir de la estructura o comportamiento de sus partes componentes. Ms bien las interacciones entre las partes importan dramticamente, y pueden dominar la estructura y comportamiento del sistema complejo. o El comportamiento puede ser no determinstico, i.e., exhibir comportamiento impredecible, incluyendo comportamiento catico bajo ciertas condiciones. o Generalmente el comportamiento involucra dinmica no lineal, algunas veces caos, y rara vez algn equilibrio en el largo plazo. o A menudo los agentes estn organizados en grupos o jerarquas, en cuyo caso la estructura influencia la evolucin del sistema (ver Figura 1). Sin embargo el sistema complejo en la mayora de casos no funciona bajo un mando central. o Tales estructuras tienden a resaltar un nmero de diferentes escalas, cualquiera de las cuales puede afectar el comportamiento del sistema complejo. Los sistemas complejos se adaptan a su entorno mientras evolucionan. o En particular, en la medida que evolucionan incrementan su propia complejidad, dando un constante influjo de energa (recursos crudos) y retroalimentacin entre elementos. En el tiempo ellos manifiestan el incremento de especializacin y capacidades. o Sus elementos cambian en respuesta a presiones impuestas por sus elementos vecinos.
Figura 1. Caractersticas de los sistemas complejos En este paper nosotros usamos estas caractersticas para analizar si tres ejemplos de sistemas complejos que son bastante conocidos para los ingenieros de sistemas son en realidad sistemas complejos, pues si ellos lo son entonces los principios de sistemas complejos podran ser capaces de proveer nuevas conocimientos en el desarrollo y operacin de los ejemplos.
2. Auto-organizacin
- Escalas varias
Individuos y compaas; captulos, regiones Polticas corporativas, juntas y pases,; grupos de inters, comits y de procesos de ciclo de vida, a grupos de trabajo travs de procedimientos especficos. 4. Adaptados a los Las reuniones de INCOSE compiten por Los procesos de la IS alrededores miembros con IEEE, AIAA, y otros grupos, completan la falta donde otros (entornos) por ejemplo para crear programas de procesos se quedan cortos; se certificacin. adaptan a estndares cambiantes (CMMI). - Se vuelven ms Grupos de trabajo mltiples y Crean procesos especializados complejos con el especializados; estructuras de gobierno para varios tipos de programas tiempo; incrementan que incluyen posiciones no imaginadas (grandes, pequeos, intensivos su especializacin hace 10 aos; certificacin y cursos de en TI, militares, de precio fijo). preparacin para certificacin. - Elementos cambian en respuesta a presiones de sus elementos vecinos Miembros pueden cambiar su grupo de trabajo dependiendo de quien ms est all; los captulos mejoran para ganar premios a captulos, los miembros escriben papers usando papers anteriores como fuentes. Las actividades ms tardas deben ser ms cortas si las actividades iniciales fueron largas. IS retrasan nuevos pasos si los primeros pasos no son resueltos o se encuentran anomalas
En un contexto de ingeniera los sistemas de sistemas a menudo son, pero no siempre, sistemas complejos. La Figura 2 muestra esta comparacin. Los sistemas de sistemas usualmente surgen en un contexto de adquisicin de programa, y se distinguen por ser inmanejables usando el estndar de ingeniera de sistemas de arriba-abajo, mientras que los sistemas complejos surgen en un contexto cientfico o analtico y los describe su imposibilidad de ser descompuestos. La mayora de sistemas de sistemas son adems sistemas complejos (SCx) y viceversa; aqu los dos crculos superiores se traslapan bastante. Un sistema tal como un Avin de Combate Conjunto que es desarrollado mediante un administrador de programa y un jefe de ingeniera por definicin no es un sistema complejo (no hay agentes independientes) sin embargo est especficamente considerado como un sistema de sistemas en algunos trabajos del Departamento de Defensa. [Jefatura del Comando Conjunto, 2007], aunque no est de acuerdo con la mayora de definiciones comnmente aceptadas [DOD AT&L, 2006], la cual es mucho ms como la definicin de Maier. En contraste a los sistemas de desarrollo long-lead top-down, los sistemas de sistemas ad hoc se llevan juntos hasta el ltimo minuto por personal operativo y no tendr jefe integrador de sistema ni un perodo de desarrollo especfico [Ferris, 2006]. La mayora de estos califican como sistemas complejos que consisten de un gran nmero de partculas elementales o son sistemas biolgicos no relacionados a la ingeniera y podran no ser considerados sistemas de sistemas.
Emergencia: Emergencia est relacionada del todo sobre las partes, la interdependencia de las partes, y la especializacin de las partes, si se estudia las partes por separado no funciona, la naturaleza de los sistemas complejos puede ser probada investigando como los cambios en una parte pueden afectar a las otras adems de al comportamiento del todo. Formacin de patrones: Simples modelos matemticos capturan la formacin de patrones tales como activacin local /inhibicin de largo plazo. Estados mltiples (meta-) estables: Pequeos desplazamientos (perturbaciones) llevan a recuperarse y grandes desplazamientos pueden llevar a cambios radicales de propiedades. La dinmica no es simplemente de promedios. Descripciones multiescala: son necesarias para entender los sistemas complejos pequeas escalas influencias en grandes escalas de comportamiento. Es difcil pero no imposible responder a la pregunta Cuan complejo es? Complejidad de comportamiento (respuesta): Para describir el comportamiento de un sistema intentamos describir la funcin de respuesta: acciones como funcin del entorno. Sin embargo, a pesar de que se hacen asunciones para simplificar, esto requiere mucha informacin, la que crece exponencialmente con la complejidad del entorno. Contraste: Los sistemas complejos a menudo exhiben caractersticas contrastantes, como simplicidad y complejidad, orden y desorden, comportamiento aleatorio y predecible, patrones repetitivos y cambios. No podemos predecir hacia donde evolucionar un sistema complejo.
El ciclo de los sistemas adaptativos complejos creados por Gell-Mann [1994a], se muestra en la primera columna de la tabla 2, las otras tres columnas muestran como nuestros ejemplos de sistemas evolucionan de acuerdo a este ciclo. El primer paso del ciclo es abstraer un modelo a partir del mundo real. Esto involucra un balance entre granular y grueso. El segundo paso es identificar regularidades o patrones en la informacin abstrada, a menudo es difcil diferenciar lo que es aleatorio de lo que es informativo o patrones. El tercer paso es organizar esas regularidades en un esquema. Esto esencialmente comprime la informacin en algo ms simple, cunta compresin es aceptable depende de un anlisis juicioso. El cuarto paso consiste en la identificacin de algunas variaciones de esta descripcin, en el anlisis de sistemas complejos existentes, esto puede significar el agrupamiento de las variaciones que se notaron. En la creacin de sistemas complejos esto puede significar hacer intencionalmente que los elementos varen. El uso de los esquemas es un medio subjetivo para la validacin del mundo real. Finalmente las presiones del mundo real causan la seleccin de los esquemas que tienen ms sentido en la mayora de casos.
Es til notar que para explicar este ciclo el Doctor Gell-Mann [1994b] estaba concentrado en sistemas biolgicos ms que en los sistemas ingeneriados por el hombre, entonces la aplicabilidad del ciclo a sistemas complejos hechos por el hombre es sugestivo de una verdad general.
Tabla 2. Ciclo de Sistemas Adaptativos Complejos Aplicado a Ejemplos Ejemplo: INCOSE Ciclo SAC . I. Granularidad gruesa Entender la ingeniera de sistemas de informacin del como prctica, y abstraer para sistema real crear principios y consejo II. Identificacin de regularidades percibidas III. Compresin en un esquema IV. Variacin de esquemas Procesos de IS Sistema Areo Nacional (SAN)
Entender qu est siendo hecho en Extrae necesidades de mltiples clientes proyectos ATC
Identificar patrones repetidos en el Notar actividades similares hechas trabajo de la IS por ingenieros de sistemas para sistemas de ingeniera Crear principios y guas , posiblemente como estndares Buscar revisin y gua de mltiples lugares Documentar actividades y ordenar versiones abstradas en procesos tpicos Programas hacen a medida procesos estandarizados
Escribe documentos operacionales y requerimientos Usa mltiples sistemas al menos viejos y nuevos
V. Uso de los esquemas Comunicar gua y estndares a los miembros VI. Consecuencias en el mundo real ejerciendo presin de seleccin que afecta la competicin entre esquemas Compaas miembros JCC eligen cuales actividades incluir en su proceso de ingeniera de sistemas y eligen cuales estndares usan y apoyan.
Programas usan procesos a medida Pone nuevos sistemas en accin en lugar de los viejos sistemas Programas se hacen mejor o peor dependiendo en parte en cunto y cuan bien es hecha la IS, esto vuelve a los grupos de proceso de IS y los xitos son capturados. Solo se siguen los nuevos sistemas si los controladores los manejan y son mejores, o al menos no obsoletos ni peores.
En el bloque inferior de la Figura 4 (3. Comn a todos) caen los principios bsicos que pueden ser usados en el desarrollo de sistemas complejos. En el bloque del medio (2. Diferentes en grado) estn los principios de ISO que deben ser extendidos para ser usados por los sistemas complejos. La gua SoSE DOS mencionada arriba [DoD AT&L, 2006] se enfoca en este bloque, en este su mbito es la adaptacin de gua de ingeniera de sistemas generales para grandes programas nicos que desarrollan sistemas de sistemas. Otra buena gua para tal prctica es un modelo de costeo para sistemas de sistemas llamado COSOSIMO, ver [Boehm, 2006]. El bloque superior (1. Diferente en tipo) gua a esos principios que no son comunes entre ISO y ISC, para los sistemas descritos en este paper, se puede argumentar que el bloque 1a (el bloque de la izquierda) es el conjunto nulo, i.e., todos los principios de ingeniera de sistemas ordenados aplican de algn modo a estos sistemas complejos, debido a que los sistemas complejos incluyen sistemas ms pequeos, sin embargo, el bloque 1b (el bloque de la derecha) no es el conjunto nulo. Hay principios de ingeniera de sistemas complejos que son en esencia diferentes de los de ISO.
Esto parece contra intuitivo para quienes ven a la ingeniera de sistemas como una teora de todo, sin embargo, la existencia del bloque 1b deben ser consideradas buenas noticias. La industria est sufriendo actualmente de fallas muy consistentes de programas creados para desarrollar grande sistemas, sistemas de sistemas, o sistemas complejos. Los principios en el bloque 1b presentan esperanza: esperanza de que hay ms
cosas que podemos aprender e institucionalizar de modo que podamos acercarnos a estos grandes sistemas de modo diferente y ahora empezar a tener xito, sin este bloque nosotros estaramos restringidos a hacer ms de lo mismo, quizs con ms control y ms disciplina, an no hay indicativos que tal acercamiento fuera exitoso, con este bloque por lo menos podemos buscar principios adicionales y ver que ms hay para combinar con lo que ya estamos haciendo.
6.1. Principios de Sistemas tipo arquitectnico (DS o Rol del Diseador de Sistema)
Pensar en la evolucin del sistema ms que en el diseo del sistema (sobre una hoja de papel en blanco). Los sistemas complejos no son creados por improvisacin, ms bien ellos vienen de otros sistemas complejos con pequeos ajustes. INCOSE ha notado que los requerimientos iniciales probablemente sean ambiguos, y la ingeniera de sistemas de sistemas nunca est terminada. [Haskins, 2006] Usar elementos probados, su sistema podra aprovecharse de la evolucin que ya ocurri en contextos similares o incluso diferentes, que dejan una cosecha de componentes ganadores disponibles. Conjunto de metas que establezcan los espacios de resultados deseables. Un conjunto de metas bien definidos sirven como un atractor (similar a los atractores extraos de la teora del caos) que mantienen los espacios de estado cerca del rea deseada. Pequeos ajustes a grandes sistemas llevan a la evolucin del sistema al espacio de resultados deseado, White [2005] y Norman y Kuras [2006] amonestaron la identificacin de espacios de resultados, no especificaron resultados, y establecieron recompensas (y penalidades)- incentivos por las decisiones que causaron que el sistema complejo entre al espacio de resultados objetivo.
Ejemplo de proceso de IS: Procesos no son desarrollados una vez sino que evolucionan con el tiempo, capturar los procesos como son es un mejor modo para empezar que escribir lo que piensas que el proceso debe hacer, debido a que estos procesos como son han evolucionado.
Buscar acciones locales que puedan tener consecuencias globales [Minai, Braha, y Bar-Yam, 2006]. Determinaron y explotaron interacciones locales que llevaban hacia comportamiento global deseado a travs de auto-organizacin. Cules son los ratios primarios del sistema que el gobierno federal puede ajustar el mercado de capitales de sus sistema? Puedes establecer las reglas de negocio que fomenten el tipo correcto de comportamiento emergente?
Ejemplo de proceso de IS: Qu acciones de reporte individual, interacciones o an lnea de parada pueden llevar a la mejora del sistema?
Mantener mltiples posibilidades viables. Los sistemas complejos prosperan fomentando la variedad entre los elementos y dejando a los elementos competir para ver cul es el que ms se ajusta. Una gestin de tendencia hacia la eficacia (teniendo slo uno de cada uno en todo, el ms costo-eficiente) funciona contra esto y de hecho configura el programa para fallas catastrficas [Norman y Kuras, 2006]. En lugar de eso hay que permitir explcitamente la variacin; la explosin combinatoria se refiere al hecho de que an con una pequea cantidad de tems se pueden crear varios patrones mediante la combinacin de varios subconjuntos de tems variando los vnculos entre ellos y enfocando rpidamente a lo funcionalmente infinito [Minai, Braha, y Bar-Yam, 2006]. Use este hecho para recombinar diferentes cantidades de componentes para mantener variedad en todo momento. Imponer explcitamente variedad en el sistema (lo opuesto a estandarizacin y eficiencia). [Minai, Braha, y Bar-Yam, 2006] Aceptan la unicidad inherente de los sistemas individuales: La conformidad no es siempre una virtud, y la novedad no es del todo un vicio. Como siempre, las opciones de trade-off en el comienzo mantienen ms de una opcin viable, sin embargo, con una bsqueda continuada y desarrollo por ejemplo. El proceso de desarrollo de Toyota est siempre innovndose pero preserva el modo en que la funcin se actualmente se realiza en caso que la innovacin no madure en un punto predeterminado en el ciclo de vida de desarrollo del producto [Keneddy, 2003]. Las opciones se prueban contra escenarios reales tanto como sea posible antes de elegir el mejor; la literatura de hecho sugiere que la eleccin no puede ser hecha por anlisis o prueba sino ejecutando mltiples opciones en las operaciones reales. Fomentar tanto la redundancia como la degeneracin en todos los niveles de las jerarquas que aparezcan [Minai, Braha, y Bar-Yam, 2006], redundancia significa tener mltiples componentes idnticos que pueden sustituirse mutuamente si fuera necesario, la degeneracin significa tener mltiples componentes
distintos que pueden ayudarse unos a otros, debido a que los componentes no son idnticos esta variacin le da robustez ya que los componentes no fallaran del mismo modo.
Ejemplo de proceso de IS: Mantener los procesos de mltiples organizaciones en competencia, no intentar eliminar todos sino un conjunto de procesos, la eficiencia se obtiene de modo concreto.
Arquitectura en capas que aslen de los otros a elementos con distintos ratios de cambio. Establecer una capa de cosas que cambien muy lentamente, una capa diferente de cosas que cambien muy rpidamente, y una o ms capas en medio [Norman y Kuras, 2006]; conectar estas capas con puntos de baja variedad, tales como protocolos estandarizados, esto permite que tems de cambio rpido cambien rpidamente sin afectar las cosas que fueron creadas bastante tiempo atrs y estarn all por mucho tiempo.
Ejemplo de proceso de IS: Las polticas organizacionales raramente cambian, adems un ejecutivo debe firmarlas. Los procesos cambian con mayor frecuencia, y requieren menos firmas que lo autoricen. Cosas como plantillas son las que ms difieren y necesitan el ms bajo nivel de autorizacin.
Use rboles de decisin para determinar donde funcionan mejor los cuatro enfoques de diseo [Anderson, 2006]: Simulacin de abajo hacia arriba (diseo bottom-up) Ingeniera de arriba hacia abajo (diseo top-down) Analoga e imitacin (arquetpico, prototpico, e inspiracional) Evolucin interactiva (evolucin slo con ajustes especficos de evaluacin humana) Anderson ofrece un rbol de decisiones en la Figura 6 para elegir entre estos cuatro enfoques [Anderson, 2006].
Ejemplo de proceso de IS: Con procesos sabes que estn buscando como eficiencia, y casi siempre hay sistemas anlogos, entonces podras querer: emular sistemas conocidos, haciendo unos pocos cambios o modificnd olo tanto como sea necesario, posiblemente usando computacin evolucionaria o sistemas paramtricos.
1.
Es posible definir matemticamente una funcin matemtica objetivo/de ajuste? (en otras palabras, sabes lo que ests buscando? S: Ir a la pregunta 3 No: Ir a la pregunta 2 Se puede notar en tiempo real el comportamiento a nivel de sistema? S: La evolucin interactiva es una posibilidad fuerte. No: O una lenta y probablemente frustrante proceso de manejo manual de parmetros o est involucrada una bsqueda sistemtica a travs de espacios de estado, o una tcnica tal como bsqueda abiertafinal. Hay un sistema anlogo conocido? S: Emule el sistema conocido, haga pequeos cambios o modifquelos cuanto sea necesario, posiblemente usando computacin evolucionaria para parametrizar el sistema. No: Ir a la pregunta 4 El sistema requiere o involucra mltiples niveles de jerarqua, o es de fcil influencia para su introduccin? (Podemos trozarlo?) S: Pueden ser posibles algunos elementos de ingeniera top-down, probablemente en conjuncin con modelamiento bottom-up. No: Modelamiento bottom-up, adoptando alguno de los principios generales expuestos en la literatura que pueden funcionar.
Figura 6. Enfoque de diseo por rbol de decisin
2.
3.
4.
Considere la creacin de enjambres para realizar algunas tareas. Ejemplo: mltiples agentes independientes para ISR (Inteligencia, Supervivencia, Reconocimiento), entendiendo el enjambre multiagente y simulndolo.
Ejemplo de proceso de IS: Podra querer simular muchos ingenieros ejecutando diferentes cambios de ingeniera pedidos (CIPs) durante el proceso en el mismo momento.
Permitir utilizacin de mdulos sin etiqueta [Minai, Braha, y Bar-Yam, 2006], permite a los componentes ser usados en usos que no fueron previstos cuando fueron creados. Este es el modo primario como evolucionan los sistemas de sistemas, y los sistemas de componentes pueden evolucionar ms rpidamente de este modo que diseando nuevos componentes por inspiracin. Los mdulos que son capaces de ser usados sin etiqueta tienen que probar su utilidad de algn modo o no se les debera considerar para reutilizarlos, esto muestra que al menos se ha alcanzado un nivel mnimo de calidad Renunciar al ltimo bit de optimizacin (satisfaciente) y congelar lo ms temprano posible las especificaciones de componentes de segunda prioridad [Mihm y Loch, 2006] En proyectos complejos las ms grandes amenazas para completarlos (sin mencionar el logro del desempeo necesario) es la gran cantidad de bucles de re-trabajo causados cuando los cambios en un componente vuelven atrs y requieren cambios en otros componentes, lo cual causa efectos terceros; prevenir estas fuertes conexiones permite a un proyecto estar ms libremente emparejado; un modo de lograr esto es determinar explcitamente cules componentes son segunda prioridad, nombrarlos, su desempeo tiene efectos slo de segundo orden sobre el desempeo del sistema. Los componentes de segunda prioridad no deben ser optimizados, en lugar de eso sus especificaciones deben ser congeladas pues ellas servirn como puntos de certeza en una mezcla turbulenta en un proyecto cambiante. Satisfaciente es usado como una combinacin de satisfacer y suficiente para recomendar remover ciclos circulares, pero no intentando satisfacer requerimientos en cualquier modo ptimo, sino ms bien quitar los desperdicios cuando el desempeo sea suficiente. De modo similar, seleccionar componentes para que el sistema optimice un pedazo ms que el sistema completo crea una pequea cantidad de vnculos interdependientes, como piezas de un pedazo generalmente no afectarn o se comunicarn con piezas de otro pedazo, esto tiene el mismo efecto que reducir el acoplamiento ligado que es la base del re-trabajo y bucles circulares.
Ejemplo de proceso de IS: No optimice procesos completamente, siempre habr ineficiencias, algunas cosas sern chequeadas tanto al fin de un paso como al comienzo de otro, tal redundancia permitir que las interfaces entre los procesos vayan suavemente.
Ejemplo de proceso de IS: Tanto los procesos como los programas son fractales, hay pocos procesos grandes y un gran nmero de ellos son pequeos, ellos son auto-similares si se mira las partes grandes y las versiones ms pequeas, considerando tanto el crecimiento de los procesos (y la probabilidad de que nuevos procesos se conecten a los procesos ms altamente conectados) y la competencia y adaptacin de los proceso individuales, la resistencia organizacional a las mejoras puede ser pensada como una homeostasis biolgica.
Modelar cuando es necesario. Simule el comportamiento multiagente para determinar el mejor conjunto de reglas para tu sistema complejo, pequeos cambios en las polticas o en las reglas que siguen elementos puede alterar drsticamente el comportamiento de un sistema complejo. Pequeos cambios vuelven bandadas de palomas en formaciones V, o convierten muchedumbres en coreografas. No sobre-simplifique El mismo principio de variedad requerida (mencionado arriba) aplica tambin a los modelos: modelos simples no pueden capturar la esencia de las situaciones complejas. Desarrollar una ayuda con ms modelos complejos usando herramientas validadas si la complejidad no puede ser manejada por un cerebro humano. Modelar para evaluar las consecuencias globales de acciones locales. Simular los efectos de varias reglas sobre los nodos y sobre la red de modo que puedas elegir las reglas y nodos (elementos) apropiados.
Ejemplo de proceso de IS: Podra querer simular muchos ingenieros ejecutando distintos pedidos de cambio de ingeniera (PCI) al mismo tiempo a lo largo del proceso.
Analizar redes de sistemas, que incluyen cualquier red hecha por el hombre (e.g., redes de procesos de IS) usando herramientas de anlisis de redes para averiguar cmo hacer pequeos cambios que den gran ventaja [Braha y Bar-Yam, 2006; Valnerde, 2006; Heylighen, 2006]. Probablemente todos los diagramas de procesos incluyan herramientas de gestin de proyectos como diagramas PERT sean analizables mediante anlisis de redes. Algunos de los anlisis incluyen pendientes de leyes de potencias asociadas con grados de entrada y grados de salida, los efectos de vnculos rotos en la red, y el tiempo que le toma a la red volver a su estado estable o estado de convergencia (todas las actividades completadas), dada la probabilidad aleatoria de interrupcin de una actividad a causa de una interrupcin en una actividad con la cual esta est vinculada. Las conclusiones publicadas en la literatura abierta son menos importantes (ms obvias) que lo que parecen estar garantizadas por la profundidad del anlisis; dos ejemplos de que recursos deben ser consumidos de modo preferente en nodos (e.g, tareas de procesos) que tienen un alto grado de salida, alto nmero de vnculos salientes, i.e., montones de otras tareas esperando por sus output [Braha y Bar-Yam 2006] y ese margen y ausencia reduce el nmero de vnculos, permitiendo desacoplar tareas y por lo tanto una ms alta probabilidad de convergencia. Mientras la mayora de gerentes de proyecto supondran estos resultados generales los cuales podran o no aplicar en sus proyectos particulares. El punto es que tales herramientas existen y podran ser aplicados en particular a sus proyectos donde podran tener mayor impacto.
Ejemplo de proceso de IS: Las redes de proceso puede ser simulada para predecir la convergencia en el tiempo.
Pero en ninguna parte hay una buena descripcin del cual los roles deberan o podran apropiarse o hacer sus conceptos operacionales y entendimiento del espacio del problema. Esto sugiere que el entendimiento de la interface entre el sistema y el entorno no fue tan bien desarrollado a comienzos de los 90 como el da de hoy. Este entendimiento es crtico para sistemas complejos; por ello los siguientes conceptos acerca del entendimiento del espacio del problema son especialmente resaltados, ajustados al DR debido a que es la parte ms temprana del ciclo de vida, aunque no es un match perfecto. Asumir que un sistema es complejo hasta probar lo contrario. Los sistemas que se ajustan son casi siempre complejos. Buscar aspectos del espacio del problema que pueden ser explicados por complejidad: 1. Fractales 2. Borde del caos 3. Leyes de Potencia 4. Redes libres de escala Use lo que se conoce acerca de ellos para dirigir tu atencin a los riesgos, por ejemplo:
Ejemplo de proceso de IS: Puede intentar hacer procesos tanto flexibles como estables, en la medida que estuvieran cerca al borde del caos.
Use el Profiler Enterprise de la IS [Stevens, 2006] para evaluar la dificultad de sus problemas . Esto resaltar aquellos importantes retos que puede encontrar en cuatro cuadrantes de implementacin (Sistema, Estrategia, Implementacin, y contexto de interesados) y ocho variables (Resultado Deseado, Comportamiento de Sistema, Entorno de la Misin, mbito de esfuerzo, Escala de Esfuerzo, Entorno de Adquisicin, Involucramiento de Interesados, y Relaciones de Interesados.) Cada una de estas puede ser considerada como de dominio de programa Tradicional, de dominio Transicional, o Frontera del Desorden, y cada uno de ellos sugiere cierta gestin de comportamientos.
Ejemplo de proceso de IS: Por ejemplo, los procesos para equipos multiempresa podran tener menos involucrados cohesivos, y un contexto de implementacin dificultoso, pero podra tener una misin y un mbito fuertemente estables.
Adems configurar buenas fronteras de modo que las personas que necesitan hacer cambios importantes no sean agobiadas por barreras burocrticas a cualquier cambio. Aqu Norman y Kuras [2006] discuten ms que la tpica informacin en el proyecto, la clave es reconocer que los sistemas complejos son significativamente diferentes que los sistemas predecesores, entonces la innovacin es ms crtica para el xito tecnolgico que lo que ha sido en el pasado. Desafortunadamente, una caracterstica de la innovacin es que esta tiende a enredarse con procesos estndares trillados. El punto de este principio es reconocer esto y establecer fronteras claras dentro de los cuales a los grupos de personas se les permite an innovar procesos sin interferencia del lobby: no podeos hacerlo de ese modo debido a que nunca lo hemos hecho as antes.
Ejemplo de proceso de IS: Convocar regularmente un Consejo de Cambio de Procesos para asegurarse que aquellos afectados sean contactados sobre potenciales cambios.
Establecer el tipo correcto de comunicacin. La Coordinacin debera ser sobre una escala lo suficientemente grande como para realizar las tareas, pero no tan grande que dae la independencia de demasiados elementos en escalas ms pequeas [Bar-Yam, 2006]. Usualmente es necesario tener una coordinacin jerrquica [Mihm y Loch, 2006]. Puesto que la auto-organizacin crea espontneamente jerarquas en la mayor parte de casos, esto usualmente no es un problema, aunque all podra haber una expectativa especfica de que las jerarquas sean sobre coordinacin as como sobre recursos (dinero) o autoridad.
Ejemplo de proceso de IS: Los procesos necesitan encontrar un delicado balance entre ser restrictivos y no ser de suficiente ayuda (muy vagos).
Conectar con la gente y los grupos tanto como sea posible [Norman y Kuras, 2006]. Saber qu fortalezas tiene la gente como ellos pueden contribuir. Esta informacin se puede obtener solamente conociendo a la gente, aunque las bases de datos, si se les mantiene adecuadamente, pueden ayudar en algo. Buscar la atencin de aquellos quienes pueden ayudarles. Hacer una prctica presentarse a gente tanto como sea posible. Nunca se sabe cundo las conexiones resultarn ser importantes. Es espacialmente valioso conectarse con gente de diversas disciplinas, dominios, y lmites de la compaa. Vnculos dbiles [Granovetter, 1980] a menudo resultan ser ms valiosos que vnculos fuertes (la gente que ya conoces bien) debido a que los vnculos dbiles traen a muchas personas antes no accesibles. Preparar reuniones de intercambio tcnico (RITs) y otros modos de juntar a personas quienes pueden tener informacin acerca del problema, pero hacer ms: adems establecer tantas conexiones uno a uno como sea posible.
Ejemplo de proceso de IS: Configurar interfaces de trabajo en grupos que atraviesan los lmites del equipo.
Construir organizaciones capaces [INCOSE, 2006]. Como se mencion antes es inevitable una interaccin compleja entre administracin y tcnico. Las organizaciones deben estar fuertemente acopladas, as como ni las decisiones tcnicas ni las de gestin deben hacerse sin conocimiento del otro conjunto de preocupaciones [Haskins, 2006]. La ley de variedad requerida de Ashby acerca de los sistemas de control implica que intentan responder a retos complejos necesariamente sern complejas. Adems la complejidad evolucionar para ser ms grande que su incremento de capacidades [Heylighen, 2006]. Un indicador de esta complejidad es la especializacin de funciones de los agentes individuales: las organizaciones se vuelven ms complejas desarrollando ms y ms especializaciones. A pesar de que una multitud de especialidades que no se hablan unas a otras crea complicaciones que pueden no ser necesarias, hay un aspecto de irreductible complejidad en la especializacin, sin embargo es importante evitar aislamientos completos.
Ejemplo de proceso de IS: Nuevas capacidades necesitarn nuevos procesos. Nuevos procesos implican una especializacin ms grande. Algunas personas desarrollarn pericia en cada proceso, y cada proceso ser asociado con unas pocas personas que lo puedan hacer muy bien. A estas personas se les pedir realizar estos procesos mltiples veces, aadiendo experiencia a su pericia.
Juzgue los resultados reales [White, 2005; Norman y Kuras, 2006]. Juzgar implica la aplicacin de un juicio humano a los resultados, pero la evolucin se juzga tambin, por lo menos, en retrospectiva (los que sobrevivieron son juzgados ms ajustadamente, si esto fue real o en efecto sobrevivieron debido a una casualidad genrica). Juicio basado en el logro de resultados cerca o dentro del espacio de resultados deseado establecido durante la arquitectura del sistema. Mantener vigilancia constante respecto a problemas crnicos. xito evitando catstrofes a menudo lleva a problemas crnicos [Tenner, 1996]. La vigilancia constante puede consumir recursos rpidamente. Necesidad por ms recursos para empujar nuevos problemas lleva a un camino al azar dentro de un rgimen inseguro, el cual a menudo lleva a accidentes [Sheard,2008; Woods y Cook, 2006] Los algoritmos para medir valor deben imponer presin selectiva sobre los agentes. Reducir tanto como sea posible el incentivo a jugar con el sistema: sesgar las mediciones en una direccin favorable. Esto interfiere con tu capacidad para entender el sistema, e incrementa las dificultades que tendrs llevndolo a una evolucin en una direccin deseada.
Ejemplo de proceso de IS: Por ejemplo, seguir el nmero de renuncias y el nmero de cambios. Zero es probablemente un modo en que las noticias estn siendo acalladas. No recompense la cancelacin de problemas.
Haga explcitas las reglas de negocio de interaccin [White, 2005; Norman y Kuras, 2006]. Las reglas de negocio son la base de las reglas que las personas y las organizaciones usan para tomar decisiones relacionadas con otras personas y organizaciones. Los problemas surgen cuando un grupo piensa que las reglas de negocio de los otros son las mismas que las suyas, cuando de hecho son diferentes. Hacer las reglas explcitas ayuda por un lado a reducir aquello que es indiscutible [Argyris, 1990] y por el otro en un sentido ms all, a mantener la comunicacin vital. Cambiar un poco las reglas tanto como sea necesario para mantener al sistema evolucionando en la direccin deseada. Las reglas que siguen agentes individuales es lo que esencialmente determina los patrones en los sistemas complejos. Pequeos cambios en reglas aplicadas y simuladas en aves resultan engrandes cambios en el comportamiento de bandada. El gobierno federal de EEUU hace pequeos ajustes a la bolsa de valores para prevenir grandes fluctuaciones y cadas. El desarrollo de sistemas muy probablemente experimenta tales efectos sobre los cambios en las reglas, pero no se estn haciendo grandes estudios a la fecha.
Ejemplo de proceso de IS: Las reglas de negocio explican en detalle cundo los procesos son seguidos y con qu grado de coordinacin. Quines deben participar en una revisin por pares? Hay situaciones en las que no hay qurum, si es as, qu se debe hacer entonces? Cundo los abandonos son aceptables?
Encuentre a los expertos adecuados, particularmente aquellos quienes son entendidos acerca de los sistemas complejos [Sheard, 2005].
Ejemplo de proceso de IS: Idealmente los ingenieros de proceso entendern la complejidad.
Enfocarse en los procesos de ingeniera y en los recursos para (e.g., proveer fondos y tecnologa que los soporte) tareas de desarrollo central de productos [Braha y Bar-Yam, 2006].
Ejemplo de proceso de IS: Cules procesos que hace cada quien dependen de informacin? El dinero gastado hacindolos eficaces y eficientes ser devuelto muchas veces de nuevo.
Entender que los diagramas de Pareto se derivan de las leyes de potencia. Considere resolver tanto los problemas ms grandes (los ms raros) as como los problemas ms comunes (los ms pequeos) primero, luego selectivamente maneje otros.
Ejemplo de proceso de IS: Por ejemplo los pedidos de cambio de procesos ms grandes y ms comunes deberan ser manejados primero. Adems, las compaas a menudo escriben procesos para sus programas ms grandes, pero olvidan hacer una versin previamente ajustada para los programas pequeos (y ms numerosos).
Siga los pasos para reducir las catstrofes Vigilancia constante [Tenner, 1996] de problemas crnicos, con priorizacin y monitoreo continuo y una gestin no furiosa [Drner, 1989]. Observar oscilaciones y luego perodos como un indicador de que el sistema est transicionando hacia el caos. Cuando esto es detectado tmese tiempo para examinar las fuerzas y luego haga cambios importantes. Modele y simule probables efectos de varias opciones. No haga cambios sin saber los efectos que esos cambios pueden tener. Pequeos cambios pueden llevar a un sistema al caos. Permita (u haga uso de) la evolucin y la adaptacin para evolucionar hacia un sistema cerrado que funcione. Intente alejarse de situaciones completamente nuevas y no probadas, especialmente sin un plan de recuperacin. Mantenga mltiples opciones abiertas, e.g., La filosofa de desarrollo de Toyota [Kennedy, 2003].
Trace una situacin compleja con el instrumento Cynefin, para identificar patrones de problemas y soluciones [Kurtz y Snowden, 2003]
Ejemplo de proceso de IS: La definicin de procesos toma tems conocibles y los hace conocidos. Esto puede no aplicar a situaciones complejas, y no aplicar a situaciones caticas. Saber qu tipo de situaciones que surgen no pueden ser predichas y aplicar estrategias complejas y caticas preferentemente en su lugar.
Base sus decisiones en datos: Los buenos tomadores de decisiones (en situaciones complejas) [Drner, 1989]: Tomaron en cuenta mltiples cosas cuando tomaron decisiones Fueron menos distrados (enfocados en sus metas) Hicieron ms preguntas del tipo por qu ms que tomar los eventos y evaluarlos considerndolos inconexos. Reflexionaron crticamente sobre su propio comportamiento e intentaron mejorar su toma de decisiones.
Ejemplo de proceso de IS: ver Sheard [2001] para encontrar acciones de mejora para gestin senior.
7. CONCLUSIONES
Debiera quedar claro a partir de los ejemplos que la prctica de la ingeniera de sistemas tiene muchas de las caractersticas de los sistemas complejos. En consecuencia la IS evolucionar y el objetivo de teorizar y mejorar procesos debe ser guiar la evolucin a un estado de alta capacidad, lo cual significa ms variedad de la cual elegir y por ello ms complejidad. Para hacer uso de uno de los ltimos principios: Transicionar de hacer Ingeniera de Sistemas a hacer Ingeniera de Sistemas Complejos [Bar-Yam, 2006]: a) Construir continuamente sobre lo que ya existe [es un sistema complejo despus de todo, este debe evolucionar]. La evolucin desde el principio es lenta, empieza desde una cosa que t ya tienes. b) Enfcate en crear un entorno y en los procesos ms que enfocarte exclusivamente en los productos. c) Los componentes individuales deben ser modificables in situ. d) Los sistemas operacionales incluyen mltiples versiones de componentes funcionales. e) Utilice mltiples procesos de desarrollo en paralelo. f) Evale experimentalmente in situ. g) Incremente gradualmente la utilizacin de componentes ms efectivos. En la construccin sobre las prcticas de la ingeniera de sistemas que ya existen, los ingenieros de sistemas deben volverse ms conscientes de los sistemas complejos que hay en la prctica de la IS (a). INCOSE puede contribuir modificndolas para transformarlas en los entornos donde los ingenieros de sistemas aprenden a usar las ideas de los sistemas complejos, y mostrando inters deliberado en el mundo de investigacin de sistemas complejos (b). Sera ideal si los procesos de modificacin de las prcticas de la IS son capturadas por INCOSE (por ejemplo Haskins [2006], e INCOSE [2006], fueron fciles de actualizar (tal como una wiki) y frecuentemente empleados (c). d esencialmente significa que deben estar disponibles mltiples versiones de buenas prcticas de IS, y con ello competir contra las otras durante el curso normal de la prctica de la ingeniera de sistemas. Un modo de promulgar esto es construir un conjunto de prcticas de sistemas complejos, a lo largo de las lneas de [DOD AT&L, 2006] pero manejando los sistemas complejos como en mbito, haciendo que los ingenieros de sistemas se familiaricen con ella, y luego ver si ellos resultan ganadores en el uso actual de escenarios comparados con las prcticas actuales de la ingeniera de sistemas: Se ajustan ellos ms que las prcticas ajenas a los sistemas complejos? Esta ltima pregunta es f; e es realmente dado, ya que tenemos siendo realizadas muchas instancias independientes de ingeniera de sistemas. Esas instancias que son las ms tiles posteriormente sern realizadas ms frecuentemente, dando como resultado un incremento en la capacidad de los sistemas de la IS (g). De este modo sern capaces de mejorar de la efectividad de la IS en modos que antes no se pudieron imaginar.
REFERENCIAS
C. Anderson, Creation of desirable complexity: Strategies for designing self -organized systems, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. C. Argyris, Overcoming organizational defenses. Facilitating organizational learning, Allyn and Bacon, Boston, 1990. Y. Bar-Yam, Complex systems and sports: Complex systems insights to building effective teams, http://necsi.org/projects/yaneer/SportsBarYam.pdf, 2003a. Y. Bar-Yam, When systems engineering failstoward complex systems engineering. International conference on systems, man & cybernetics, vol 2, IEEE Press, Piscataway, NJ, 2003b, pp. 2021 2028. Y. Bar-Yam, Engineering complex systems: Multiscale analysis and evolutionary engineering, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. B. Boehm, SoS vs. systems engineering: Activity differences and cost drivers, System of Systems Engineering Panel, INCOSE Symp, 2006. D. Braha and Y. Bar-Yam, The structure and dynamics of complex product design, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. D. Braha, A.A. Minai, and Y. Bar-Yam (Editors), Complex engineered systems: Science meets technology, Springer, Cambridge, MA, 2006. Chairman, Joint Chiefs of Staff, Joint Capabilities Integration and Development System (JCIDS), Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01F, Glossary, Definition of SoS, Washington, DC, May 1, 2007, p. 58. M. Clemens, Characteristics of complex systems, www.idiagram.com (October, 2008). J.C. Defoe, An identification of pragmatic principles-final report, Version 0, National Council on System Engineering, Seattle, WA, 1993. D. Drner, The logic of failure: Why things go wrong and what we can do to make them right, Holt, New York, 1989. DOD AT&L, System of systems engineering guide: Considerations for systems engineering in a systems of systems environment, Draft, Director, Systems and Software En-gineering, Deputy Undersecretary of Defense (Acquisition and Technology), Office of the Undersecretary of Defense (Acquisition, Technology, and Logistics), Washington, DC, October 17, 2006. T.L.J. Ferris, Systems of systems engineering requires new methods if you are talking about new kinds of systems of systems, Systems of Systems panel discussion, INCOSE Symp, 2006. M. Gell-Mann, Complex adaptive systems, Complexity, metaphors, models, and reality, G. Cowan, D. Pines, and D. Melzner (Editors), SFI Studies in the Sciences of Complexity, New York: Addison-Wesley, 1994a. (Cited in Maier and Fadel [2006: 134].) M. Gell-Mann, The quark and the jaguar, Freeman, New York, 1994b.
M. Granovetter, The strength of weak ties, Amer J Sociol 78(6) (1980), 13601380. C. Haskins (Editor), Systems engineering handbook: A guide for system life cycle processes and activities, INCOSE, Seattle, WA, 2006. F. Heylighen, The growth of complexity, at http:// pespmc1.vub.ac.be/COMPGROW.html, 2006. D. Hybertson, What concepts of systems science support systems engineering? INCOSE SSEG Meeting, July 2006. INCOSE, Guide to the systems engineering body of knowledge, http://www.incose.org/practice/guidetosebodyofknow.aspx, 2006. M.N. Kennedy, Product development in the lean enterprise: Why Toyotas system is four times more productive and how you can implement it, Oaklea, Richmond, VA, 2003. M. Klein, H. Sayama, P. Faratin, and Y. Bar-Yam, The dynamics of collaborative design: Insights from complex systems and negotiation research, Complex engineered systems: Science meets technology, D. Braha, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. C.F. Kurtz and D. J. Snowden, The new dynamics of strategy: Sense-making in a complex and complicated world, IBM Syst J 42(3) (2003), 462483, http://www.research.ibm.com/journal/sj/423/kurtz.pdf. J.R.A. Maier and G.M. Fadel, Understanding the complexity of design, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. M.W. Maier, Architecting principles for systems-of-systems, Syst Eng 1(4) (1998), 267284. J. Mihm and C.H. Loch, Spiraling out of control: problem-solving dynamics in complex distributed engineering projects, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar -Yam (Editors), Springer, Cambridge, MA, 2006. A.A. Minai, D. Braha, and Y. Bar-Yam, Complex engineered systems: A new paradigm, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, andY. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. D.O. Norman and M.L. Kuras, Engineering complex systems, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. D.O. Norman, Private communication, January 2008. L.D. Pohlmann, Is systems engineering for systems of systems really any different? Yes! qualitatively & quantitatively, Systems of Systems panel discussion, INCOSE Symp, 2006. E. Rechtin, Systems architecting: Creating & building complex systems, Prentice Hall, Englewood Cliffs, NJ, 1991. E. Rechtin and M.W. Maier, The art of systems architecting, CRC Press, New York, 1997. W.B. Rouse, Complex engineered, organizational, and natural systems, Syst Eng 10(3) (2007), 260 271. S.A. Sheard, Twelve systems engineering roles, Proc Sixth Annu Int Symp INCOSE, Boston, July 1996.
S.A. Sheard, What is senior management commitment? Proc Eleventh Annu Int Symp INCOSE. Melbourne, Australia, July 2001. S. Sheard, Practical applications of complexity theory for systems engineers, Proc Fifteenth Annu Int Symp INCOSE, 2005. S. Sheard, Definition of the sciences of complex systems, INSIGHT 9(1) (October 2006), 25. S. Sheard, Complex adaptive systems in systems engineering and management, Handbook of systems engineering and management, 2nd edition, Wiley, New York, 2007, Chap. 35, submitted. S.A. Sheard, A framework for system resilience discussions, Proc Eighteenth Annu Int Symp INCOSE, June 2008, to appear. R. Stevens, Engineering enterprise systems: Challenges and prospects, DAS XIII, 2006. R. Stevens, P. Brook, K. Jackson, and S. Arnold, Systems engineering: Coping with complexity, Prentice Hall, London, 1998. E. Tenner, Why things bite back: technology and the revenge of unintended consequences. Knopf, New York, 1996. University of Michigan, About the science of complexity, http://www.cscs.umich.edu/about/complexity.html, Ann Arbor, 2006. S. Valnerde and R.V. Sole, On the nature of design, Complex engineered systems: Science meets technology, D. Braha, Dan, A.A. Minai, and Y. Bar-Yam (Editors), Springer, Cambridge, MA, 2006. B.E. White, Engineering enterprises using complex systems engineering, First Annu Systems of Systems Eng Conf, Johnstown, PA, June 2005. D.D. Woods and R.I. Cook, Incidentsmarkers of resilience or brittleness? Resilience engineering: Concepts and precepts, E. Hollnagel, D.D. Woods, and N.G. Leveson (Editors), Ashgate, Aldershot, UK, Chap. 6.