Principios de Sistemas Complejos para la Ingeniera de Sistemas

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.

2. DEFINICIN DE SISTEMAS COMPLEJOS

Los sistemas complejos son un campo de estudio plagado de vocabulario sobrecargado. A palabras como empresa y arquitectura se les da nuevo significado, entendimiento y evolucin tecnolgica, y cada nuevo significado desarrolla a su vez otros siguientes. Desafortunadamente es raro que los problemas de terminologa sean proactivamente tratados mediante una examinacin sistmica de usos y significados. Como ejemplo, mostramos el uso del trmino sistema complejo. Algunos ingenieros de sistemas piensan que todos los sistemas con que ellos trabajan son sistemas complejos (si ellos no lo fueran no sera necesario que los trate la ingeniera de sistemas) Este paper est usando un significado muy especfico usado por los cientficos que hacen investigacin en el rea de teora de complejidad y sus descendientes:
Sistemas complejos son sistemas que no tienen un mando centralizado y cuya especificacin de diseo no se conoce, sino que en lugar de ello involucran muchos diferentes interesados creando sistemas que son funcionales para otros propsitos y slo se juntan en sistemas complejos debido a que los agentes individuales del sistema ven tal cooperacin como beneficiosa para ellos.

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.

3. DEFINICIONES APLICADAS A LOS TRES EJEMPLOS DE SISTEMAS COMPLEJOS

Tabla 1. Ejemplos de Sistemas Complejos
INCOSE Miembros, compaas de la Junta Concejal Corporativa (JCC), captulos Sistema Areo Nacional (SAN) Aerolneas, aviones, aeropuertos, controladores de trfico areo, bases de datos, pasajeros, ayudas de navegacin, pilotos. Seguridad de transporte, torres, etc. Quines estn incluidos en JCC? Cuestiones Interfaces con gestin de Reglas para entregar y compartir data de pasajeros de propiedad intelectual cuando los programas y con el software entre diferentes pases; relaciones entre miembros contribuyen a los productos de son particularmente difusos. aerolneas, e.g. puede SAN requerir a las INCOSE. Esfuerzos conjuntos transAdems proceso de la aerolneas colocar equipos tales como organizacionales; miembros que participan compaa vs los de los transcriptores de data en los aviones de modo que en mltiples sociedades clientes, muchos ms el control de trfico areo sea ms confiable? Los miembros forman grupos de intereses Las actividades de los procesos Las aerolneas prefieren hubs para mantenimiento y captulos, adems tambin grupos de esperan hasta que otra y economa operacional; las fuerzas de la amigos actividad libere recursos para competencia tarifan por una estructura similar, los realizarlos embotellamientos de trfico areo emergen de ciertas condiciones climticas Los miembros pagar tasas y pecios Los procesos cambian Combustible de los aviones, demanda pblica de mediante fondos personales o de eliminando actividades de bajo transporte, fondos de accionistas de aerolneas, compaas. Los miembros traen energa a valor fondos del gobierno, oferta de pilotos entrenados INCOSE por ello. por los militares, pilotos retirados Como cualquier institucin social la Cmo las actividades estn Los patrones de los vuelos de los jet (rutas areas, estructura no est atada a los cuerpos dispuestas en un proceso no reglas visuales de instrumentos areos, hubs, humanos. est relacionado con la retrasos por clima) no pueden ser determinados de estructura de las actividades la estructura de las aeronaves o an de los aeropuertos. Nmero de asistentes a las conferencias Pequeos errores en los Reduccin del tiempo de vuelo entre ciudades (o vara significativamente ao tras ao por primeros pasos pueden precio de ticket) un pequeo monto (por debajo razones no lineales relacionadas a los destruir el progreso del del de los competidores) puede incrementar precios de las conferencias. programa, sobre todo cuando bastante el nmero de pasajeros de una aerolnea. se descubren tarde. Organizacin de simples voluntarios; los IS Redes de interaccin con otras Aerolneas pueden salir del negocio, se compran no intentan encajar en cajas tareas cambiantes; ningn unas a otras, o caen en bancarrota. Las aerolneas predeterminadas, la tecnologa y los grupo entiende todas las compiten en rutas de vuelos. El precio del petrleo competidores evolucionan (e.g., sistemas actividades o racionalidades es esencialmente incontrolable. Los pasajeros intensivos en software, Sistemas de potenciales responden diferente a varios esquemas Sistemas) de precios de tickets. Data de entrada y salida de diferentes formatos de sistemas de posicionamiento global y conectado a hardware. Toman nuevas medidas de seguridad de cara a los peligros terroristas. Construyen nuevos aeropuertos con ambientes seguros. Las aeronaves se compran de fabricantes competentes de aeronaves. Evolucin rpida para mantenerse a salvo de terrorista. Eligen aeronaves ms grandes para rutas populares. Ofrece nuevos privilegios para pasajeros frecuentes; trabajos especializados para personal de aerolneas, tickets electrnicos, requerimientos de data para pasajeros Los aeropuertos hub de aerolneas pueden construir nuevos terminales o incluso pistas. Las aerolneas ajustan sus precios para estar de acorde al de las otras. Los pasajeros ajustan planes de viaje o procedimientos de ticket (e.g., los tickets unodespus-de-otro toman ventaja de los ahorros en precio para ciertas rutas) Procesos de IS Actividades, artefactos de la IS

1. Interaccin autnoma ente las partes (agentes) - Lmites difusos

2. Auto-organizacin

- Energa entrante y saliente (ejemplos)

3. Exhibicin de comportamiento emergente en macro-nivel - No linealidad

- No jerarqua ni mando central

- 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

3.1. Tres Ejemplos

Este paper observa en los siguientes tres ejemplos, todos cumplen con las definiciones antes mencionadas de sistemas complejos, por esta razn todos deberan dejarse influir por las mejoras basadas en los principios para los sistemas complejos de ingeniera manejados en secciones posteriores. Los ingenieros de sistemas debieron estar familiarizados por esos tres ejemplos mostrados en la Tabla 1.

3.2. Sistemas de Sistemas

Se debiera notar que los sistemas de sistemas son actualmente de gran inters para los ingenieros de sistemas. Los tpicos fueron originalmente definidos por [Maier, 1998]; conferencias y papers relacionados con sistemas de sistemas se han incrementado enormemente en los ltimos pocos aos. Las cuestiones de sistemas de sistemas que difieren de las cuestiones de sistemas incluyen: Integracin de sistemas de componentes operacionalmente independientes que fueron construidos para otros propsitos. Rpida evolucin tanto de necesidades de usuarios como de tecnologas de sistemas, lo cual impide requerimientos estables. Mltiples y dispares interesados con necesidades en conflicto y falta de incentivos para participar en el sistema de sistemas. Desarrollo distribuido y sus consecuentes problemas de comunicacin. Dependencia sobre una infraestructura de computacin integrada, que tiene una extremadamente alta e incremental complejidad, por ello con amenazantes consecuencias imprevisibles.

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.

4. HALLAZGOS EN LA CIENCIA DE SISTEMAS COMPLEJOS

La Ciencia de Sistemas Complejos incluye una cantidad de reas de investigacin donde todas tienen que ver de algn modo con la complejidad, sistemas complejos, o sistemas no lineales. Algunos ejemplos incluyen teora de complejidad, teora del caos, autmatas celulares, y dinmica no lineal. Tomndolo como un todo, estas ciencias ofrecen los siguientes hallazgos, los cuales son potencialmente importantes para la ingeniera de sistemas [Sheard, 2006]:

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.

Figura 2. Sistema de sistemas comparado con sistemas complejos

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

Identifica requerimientos para la siguiente generacin de sistemas ATC

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.

5. ORDEN, CAOS E INGENIERA DE SISTEMAS 5.1. Ingeniera de Sistemas Ordenados

La ingeniera de sistemas tradicional (designa ISO, por Ingeniera de Sistemas Ordenados) se enfoca sobre el lado orden del espectro orden-al-caos mostrado en la Figura 3. Las curvas de campana son ubicuas, la mecnica newtoniana se usa predominantemente, y las ecuaciones no lineales son linealizadas, los administradores presumen de saber lo que necesita ser hecho, y la meta es incrementar la predictibilidad y el orden. A pesar de que el hecho de que la ciencia del caos han sido ambos conocidos y popularizados por tres dcadas, es sorprendentemente cuan poco de la teora se ha convertido instantneamente en prctica para la ingeniera de sistemas. El plan para la ingeniera de sistemas complejos (SCx) es reconocer tanto el lado del orden como el del caos y hacer uso de los patrones descubiertos en la investigacin para ser capaz de usar los principios aplicables cuando se necesitan.

5.2. Ingeniera de Sistemas Complejos

Esta seccin se busca qu principios aplica a la ingeniera de sistemas complejos. Primero, es importante notar que la ingeniera de sistemas ordenados, los cuales tradicionalmente buscan como resolver un problema especfico creando una solucin de diseo y luego construyndola, tiene muchos traslapes con la ingeniera de sistemas complejos, los cuales buscan primeramente identificar los sistemas complejos que ya existen y sus tendencias evolucionarias y luego las tendencias que las afecten de modo que el sistema evolucione para producir ms resultados deseados. La Figura 4, adaptado de [Hyberston, 2006] muestra tres tipos de principios que se aplican a Ingeniera de Sistemas Ordenados (ISO, llamados ingeniera de sistemas en la fuente) e ingeniera de sistemas complejos (SCx, llamados ISC en la fuente).

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.

Figura3. Espectro orden-caos

Figura 4. Principios de ISO vs Ingeniera de Sistemas Complejos (adaptado de Hybertson [2006]).

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.

5.3. Islas de Orden

En verdad, orden y caos son extremos, los sistemas complejos reales tienen aspectos de orden dentro de ellos mezclados con aspectos de complejidad y ms probablemente con algunos aspectos caticos tambin. La Figura 5 muestra dos maneras de caracterizar tales islas de orden. Los sistemas tecnolgicamente pueden ser diseados y construidos usando procesos estndares de la ingeniera de sistemas partiendo de una especificacin tcnica. Ellos tienen fronteras definidas e interactan con su entorno va interfaces externas definidas, estos sistemas se muestran como sistemas diseados en la Figura 5, note que entre estas islas de orden hay muchas interfaces usualmente no planeadas, debido a que los sistemas diseados son creados en diferentes momentos por diferentes grupos de personas, a menudo para propsitos distintos a sus usos eventuales; a estas interfaces se les denota como interacciones desordenadas; adems note que los sistemas complejos evolucionan de un modo dinmico como un todo, acomodando actualizaciones asncronas de los varios sistemas diseados. El diagrama de la derecha est basado en Norman [2008], este muestra las mismas islas de orden como puntos de interfaces de baja variedad entre capas de variedad (tales como montones de ISO: cualquier cosa que puede ocurrir dentro de una capa aunque protocolos definidos entre los montones son los que ayudan a mantener el sistema entero teniendo sentido). Un ejemplo organizacional es que dentro de una oficina de programa complejo hay este grupo de gestin de configuracin cuyo rol es restaurar el orden y mantener una lnea de base previa difcil-de-cambiar que nadie ms puede cambiar, esto paradjicamente es la estabilidad que permite que ocurra el cambio.

Figura 5. Islas de orden

6. PRINCIPIOS POTENCIALES DE INGENIERA DE SISTEMAS

La siguiente es la opinin del autor sobre una cantidad de potenciales principios de ingeniera de sistemas complejos que podran aadirse a la prctica de ingeniera de sistemas ordenados que son enseados y ya ampliamente conocidos, agrupados por roles relacionados de ingeniera de sistemas [Sheard, 1996]. Las itlicas despus de cada principio muestran una aplicacin del principio en la mitad del ejemplo de arriba, el proceso de la ingeniera de sistemas dentro de un compaa. Las referencias proveen ms informacin de tales principios. Dentro de la siguiente dcada se debera aprender lo suficiente de complejidad e ingeniera de sistemas complejos que estos potenciales principios que puedan convertirse en decisivos, mejor forzados, y ampliamente aceptados

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.

6.2. Principios de Anlisis de Sistemas (AS o Rol del Analista de Sistemas)

Establecer ricos modelos mentales para entender el espacio del problema Aprender tanto como puedas sobre la complejidad te ayudar. Las ideas de la complejidad permitirn al analista ver el sistema no slo desde el punto de vista estndar sino adems desde las leyes de potencia, fractales, auto-organizacin, y perspectiva de redes. Entender el crecimiento, evolucin, y ajuste al mbito. En sistemas socio-tcnicos el entorno dentro del cual el sistema tecnolgico debe ajustarse, a menudo es de mucho mayor complejidad que la del sistema tecnolgico. Este entorno cambia constantemente, ambos debido tanto a las influencias externas al sistema socio tcnico pero adems debido a las adaptaciones que loe elementos emprenden para incrementar su ajuste al mbito cambiante. Otros importantes conceptos incluyen la co-evolucin de elementos, el hecho que en sistemas interesantes las fronteras no solo puedan sino que deban ser abiertas, el impredecible gran nmero de catstrofes actuales, y los requisitos de variedad. La ley de variedad requerida de Ashby, originalmente creada para describir sistemas de control, demuestra que la reduccin de la complejidad de una solucin va de la mano con el costo de la capacidad; una solucin no puede controlar un ambiente de mayor complejidad que la suya; esto ensea a los ingenieros a tratar con la complejidad de los sistemas ms de lo que la ingeniera ha intentado hasta ahora. [Heyleghen, 2006].

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.

6.3. Principios de Relevancia-Espacio-Problema (DR, Rol de Dueo de los Requerimientos)

Descripciones enfocadas en procesos de ingeniera de sistemas suelen empezar con requerimientos [Sheard, 1996] incluidas como parte del rol del DR:
Los administradores/dueos de requerimientos, asignadores y quienes escriben o mantienen de especificaciones, o dueos/desarrolladores de arquitectura funcional / desarrolladores de sistemas y subsistemas de requerimientos de las necesidades del cliente.

Rol de Operaciones y Logstica (OL):

Adicionalmente para tomar responsabilidad primaria en las ltimas fases de los programas. Se espera que los ingenieros de OL realicen mantenimiento, operaciones, logstica, y hacerse de preocupaciones sobre los requerimientos, diseo y desarrollo de fases.

Rol en la interface de Clientes (IC):

A los ingenieros de sistemas se les puede pedir que representen el punto de vista del cliente y ver que es respetado apropiadamente a los largo del programa.

En el rol del Analista de Sistemas (AS):

Modelador y simulador de sistemas/presupuestos.

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.

6.4. Principio de Gestin de Configuracin (Rol del Administrador de Informacin, AI)

Durante el desarrollo de sistemas prepararse para y que tengan cabida el diseo de cambios esperado. Identificar listas de quines sern impactados y por qu cambios. Inmediatamente difundir preliminarmente la informacin a las personas quienes han suscrito a esos cambios. La difusin inmediata reduce la necesidad de cronogramas para hacer necesarios ajustes a cualesquiera tareas futuras [Mihm y Loch, 2006] y por ello ayuda a que la red converja en una configuracin estable. Los aspectos de subscripcin ayudan a reducir la sobrecarga de informacin. A cualquier persona se le puede pedir que se subscriba a lo que ellos piensan que podra afectarles, o, por otro lado, las subscripciones podran establecerse en base a un anlisis de conectividad de red (enviando informacin a travs de sus vnculos salientes). Claramente la informacin preliminar debe ser confirmada. El pulso en el tiempo de las entidades (para actualizaciones) debe ser tan corto como sea posible [Norman y Kuras, 2006]. Esto es en su mayora ms de lo anterior, pero adems sugiere que las entidades mismas deben tener los recursos para hacer los ajustes requeridos rpidamente, as esto permitir la propagacin de cosas ya hechas en el flujo de trabajo sin retrasos.

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.

6.5. Principios de Coordinacin (Rol del Coordinador, CO)

Coordinar con las personas [Norman y Kuras, 2006]. Entender que poner un sistema a trabajar ha estado siempre intrincadamente conectado a poner gente a trabajar junta con un propsito comn, pero esto es an mucho ms cierto para sistemas socio tcnicos. Esto no slo involucra desarrolladores (a menudo de diferentes organizaciones) sino adems usuarios y clientes. La mayora de sistemas socio tcnicos tienen una gran cantidad de interesados, afortunadamente ellos pueden ser categorizados y usualmente no necesitan ser incluidos: Opositores a cualquier construccin, afectados de los negocios debido a la falta de acceso, desarrolladores buscando subcontratos, etc. Dos principios generales acerca de tratar con el lado socio son: Aprender acerca de los equipos y principios de psicologa organizacional. Si t no eres del tipo persona-gente, alate con aquellos que lo son.
Ejemplo de proceso de IS: Las misiones de los equipos tienden a funcionar como atractores para mantener a todos trabajando juntos.

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.

6.6. Principios Relacionados con la Gestin (Rol de Gestin Tcnica, GT)

Los trabajos de gestin y el tcnico estn mucho ms enredados en el trabajo en sistemas complejos que en la mecanicista ingeniera estndar de muchos sistemas [Haskins, 2006]. Desafortunadamente el tipo de gestin debe cambiar: El control jerrquico top-down ya no es ms un buen modelo [Sheard, 2006; Norman y Kuras, 2006] Gestionar explcitamente la gestin del entorno White [2005] y Norman y Kuras [2006] apunta que si bien los administradores estn familiarizados con la gestin de esfuerzos de desarrollo de sistemas, debe haber un nuevo nfasis sobre la gestin de cmo contribuir al entono de desarrollo. Se debe prestar atencin explcita y consciente a su forma inicial, reconocer que el entorno evolucionar. Si el entorno es visto como un ecosistema, Quines son los agentes?, Son ellos lo suficientemente interactivos y autnomos? Qu recursos fluyen a travs del sistema para recompensar las variedades exitosas? Entender la funcin de los incentivos e implementarlos adecuadamente, debido a que la interaccin de los agentes es lo que crea nuevas formas de capacidad a travs de evolucin, colaboracin nutritiva. Con frecuencia esto adems significa competencia, debido a que la colaboracin y competencia se soportan la una a la otra cuando son en diferentes escalas [Bar-Yam, 2003a]: Los incentivos usualmente son el la forma de acceso a recursos, algunos otros tipos de recompensa, algunas veces reglas o castigos. Usar incentivos fertiliza la tierra donde el sistema crecer. Norman y Kuras [2006] llaman a est o permitir tazones de arroz.
Ejemplo de proceso de IS: Manejar los grupos de procesos de modo similar que los proyectos.

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.