Principios de Sistemas Complejos para la Ingeniería de Sistemas

7/22/2019 Principios de Sistemas Complejos para la Ingeniería de Sistemas

http://slidepdf.com/reader/full/principios-de-sistemas-complejos-para-la-ingenieria-de-sistemas 1/21

Principios de Sistemas Complejos para la Ingeniería de SistemasSarah A. Sheard1 y Ali MontashariStevens Institute of Technology, Castle Point on the Hudson, Hoboken, NJ 07030

ABSTRACT

Este paper muestra como tres sistemas, de tipos bien conocidos para la Ingeniería de Sistemas pueden serentendidos como sistemas complejos. Esto es importante porque la investigación en la ciencia de sistemascomplejos es vibrante y provee entendimiento crítico, pero si la ingeniería de sistemas no entiende losaspectos complejos de los sistemas con que ellos trabajan a diario ellos no serán capaces de usar losresultados de estas investigaciones. A la fecha, la ingeniería de sistemas ha estado explotando solo el lado“orden” del espectro orden -caos. Ahora es tiempo de entender y empezar a utilizar los principios delespectro que están desde la mitad hasta el lado del caos. Tres ejemplos de sistemas complejos sonINCOSE, los procesos de ingeniería de sistemas (tales como el proceso estándar de una compañía), y elcontrol de tráfico aéreo. INCOSE representa a la mayoría de grupos sociales u organizaciones de

voluntarios. La mayoría de ingenieros de sistemas no nota que los procesos de ingeniería de sistemas enuna compañía son una red que puede ser estudiada con los métodos de los sistemas complejos. El controlde tráfico aéreo puede ser más cercano a la definición de sistema para muchos de los ingenieros desistemas. Este paper provee principios de sistemas complejos basados en una gran variedad de fuentes ymuestra la aplicación de sistemas complejos a uno de los ejemplos.

Palabras clave: ingeniería de sistemas complejos, complejidad, caos, principios, sistema de sistemas, roles.

1. INTRODUCCIÓN

La Ingeniería de sistemas (IS) ha evolucionado sin mucho conocimiento previo teórico o formal de su práctica;en lugar de eso ha dependido de los principios o heurística desarrollados experimentalmente [Defoe, 1993;Rechtin, 1991, Stevens et al., 1998]. La ingeniería de sistemas desarrolló el logro de un balance entre subsistemas ydistintas disciplinas. Manteniéndonos en el tema, para los investigadores de ingeniería de sistemas espotencialmente valioso investigar qué hay en los sistemas a parte de sus componentes, en otras palabras, qué da aun sistema su valor añadido sobre la suma de las partes [Rouse 2007]. Uno podría imaginar una ciencia derelaciones subyacente a la ingeniería de sistemas.

Afortunadamente, la investigación en el mundo de sistemas complejos (algunas veces llamado teoría de lacomplejidad) está empezando a crear una base teórica formal para la ingeniería de sistemas que está parcialmentelista para ser usada, ambos explican la práctica actual y ayudan a modelar los sistemas existentes de modo que sepuedan hacer exploraciones predictivas. Si modelos matemáticos pueden predecir, por ejemplo, las característicasde desempeño holístico, entonces los parámetros del sistema pueden ser variados para mejorar vía modelamientocualidades particulares, más que intentar numerosas respuestas posibles erróneas en el desarrollo de hardware y

software. La pronta determinación de parámetros clave puede ayudar a mantener los programas de la ingenieríade sistemas encaminados y evitar “descarrilamientos” debido a sorpresas tardías y el subsecuente efecto encadena que estos programas pueden experimentar.

Muchos científicos de sistemas complejos están haciendo grandes hallazgos año a año, lo cual desde el puntode vista de los ingenieros de sistemas significa que sus recomendaciones están cambiando constantemente. Porello es prematuro especificar con seguridad “mejores prácticas” (y podría ser siempre incorrecto intentar usar“mejores prácticas” en este campo; ver Kurtz y Snowden [2003]), es valioso mantenerse al día con la literatura y

1 E-mail: [email protected]



Los sistemas complejos exhiben comportamiento emergente en un macro-nivel que emerge de acciones einteracciones de los agentes individuales. La estructura y comportamiento de un sistema complejo no esfácil deducir o inferir solamente a partir de la estructura o comportamiento de sus partes componentes.Más bien las interacciones entre las partes importan dramáticamente, y pueden dominar la estructura ycomportamiento del sistema complejo.

o El comportamiento puede ser no determinístico, i.e., exhibir comportamiento impredecible,

incluyendo comportamiento caótico bajo ciertas condiciones.o Generalmente el comportamiento involucra dinámica no lineal, algunas veces caos, y rara vez

algún equilibrio en el largo plazo.o A menudo los agentes están organizados en grupos o jerarquías, en cuyo caso la estructura

influencia la evolución del sistema (ver Figura 1). Sin embargo el sistema complejo en la mayoríade casos no funciona bajo un mando central.

o Tales estructuras tienden a resaltar un número de diferentes escalas, cualquiera de las cualespuede 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 energía (recursos crudos) y retroalimentación entre elementos. En el tiempoellos manifiestan el incremento de especialización y capacidades.

o Sus elementos cambian en respuesta a “presiones” impuestas por sus elementos vecinos.

Figura 1. Características de los sistemas complejos

En este paper nosotros usamos estas características para analizar si tres ejemplos de sistemas complejosque son bastante conocidos para los ingenieros de sistemas son en realidad sistemas complejos, pues si ellos loson entonces los principios de sistemas complejos podrían ser capaces de proveer nuevas conocimientos en eldesarrollo y operación de los ejemplos.



3. DEFINICIONES APLICADAS A LOS TRES EJEMPLOS DE SISTEMAS COMPLEJOS

Tabla 1. Ejemplos de Sistemas Complejos

INCOSE Procesos de IS Sistema Aéreo Nacional (SAN)1. Interacción

autónoma ente laspartes (agentes)

Miembros, compañías de la Junta Concejal

Corporativa (JCC), capítulos

Actividades, artefactos de la IS Aerolíneas, aviones, aeropuertos, controladores de

tráfico aéreo, bases de datos, pasajeros, ayudas denavegación, pilotos. Seguridad de transporte,torres, etc.

- Límites difusos Quiénes están incluidos en JCC? Cuestionesde propiedad intelectual cuando losmiembros contribuyen a los productos deINCOSE. Esfuerzos conjuntos trans-organizacionales; miembros que participanen múltiples sociedades

Interfaces con gestión deprogramas y con el softwareson particularmente difusos.Además proceso de lacompañía vs los de losclientes, muchos más

Reglas para entregar y compartir data de pasajerosentre diferentes países; relaciones entreaerolíneas, e.g. ¿puede SAN requerir a lasaerolíneas colocar equipos tales comotranscriptores de data en los aviones de modo queel control de tráfico aéreo sea más confiable?

2. Auto-organización Los miembros forman grupos de interesesy capítulos, además también grupos deamigos

Las actividades de los procesosesperan hasta que otraactividad libere recursos pararealizarlos

Las aerolíneas prefieren hubs para mantenimientoy economía operacional; las fuerzas de lacompetencia tarifan por una estructura similar, losembotellamientos de tráfico aéreo emergen deciertas condiciones climáticas

- Energía entrante y

saliente (ejemplos)

Los miembros pagar tasas y pecios

mediante fondos personales o decompañías. Los miembros traen energía aINCOSE por ello.

Los procesos cambian

eliminando actividades de bajovalor

Combustible de los aviones, demanda pública de

transporte, fondos de accionistas de aerolíneas,fondos del gobierno, oferta de pilotos entrenadospor los militares, pilotos retirados…

3. Exhibición decomportamientoemergente enmacro-nivel

Como cualquier institución social laestructura no está atada a los cuerposhumanos.

Cómo las actividades estándispuestas en un proceso noestá relacionado con laestructura de las actividades

Los patrones de los vuelos de los jet (rutas aéreas,reglas visuales de instrumentos aéreos, hubs,retrasos por clima) no pueden ser determinados dela estructura de las aeronaves o aún de losaeropuertos.

- No linealidad Número de asistentes a las conferenciasvaría significativamente año tras año porrazones no lineales relacionadas a losprecios de las conferencias.

Pequeños errores en losprimeros pasos puedendestruir el progreso delprograma, sobre todo cuandose descubren tarde.

Reducción del tiempo de vuelo entre ciudades (oprecio de ticket) un pequeño monto (por debajodel de los competidores) puede incrementarbastante el número de pasajeros de una aerolínea.

- No jerarquía nimando central

Organización de s imples voluntarios; los ISno intentan encajar en cajaspredeterminadas, la tecnología y loscompetidores evolucionan (e.g., sistemasintensivos en software, Sistemas deSistemas)

Redes de interacción con otrastareas cambiantes; ningúngrupo entiende todas lasactividades o racionalidades

Aerolíneas pueden salir del negocio, se compranunas a otras, o caen en bancarrota. Las aerolíneascompiten en rutas de vuelos. El precio del petróleoes esencialmente incontrolable. Los pasajerospotenciales responden diferente a varios esquemasde precios de tickets.

- Escalas varias Individuos y compañías; capítulos, regionesy países,; grupos de interés, comités ygrupos de trabajo

Políticas corporativas, juntasde procesos de ciclo de vida, através de procedimientosespecíficos.

Data de entrada y salida de diferentes formatos desistemas de posicionamiento global y conectado ahardware.

4. Adaptados a losalrededores(entornos)

Las reuniones de INCOSE compiten pormiembros con IEEE, AIAA, y otros grupos,por ejemplo para crear programas decertificación.

Los procesos de la IScompletan la falta donde otrosprocesos se quedan cortos; seadaptan a estándarescambiantes (CMMI).

Toman nuevas medidas de seguridad de cara a lospeligros terroristas. Construyen nuevosaeropuertos con ambientes seguros. Las aeronavesse compran de fabricantes competentes deaeronaves.

- Se vuelven máscomplejos con eltiempo; incrementan

su especialización

Grupos de trabajo múltiples yespecializados; estructuras de gobiernoque incluyen posiciones no imaginadas

hace 10 años; certificación y cursos depreparación para certificación.

Crean procesos especializadospara varios tipos de programas(grandes, pequeños, intensivos

en TI, militares, de precio fijo).

Evolución rápida para mantenerse a salvo deterrorista. Eligen aeronaves más grandes para rutaspopulares. Ofrece nuevos privilegios para pasajeros

frecuentes; trabajos especializados para personalde aerolíneas, tickets electrónicos, requerimientosde data para pasajeros

- Elementos cambianen respuesta apresiones de suselementos vecinos

Miembros pueden cambiar su grupo detrabajo dependiendo de quien más estéallí; los capítulos mejoran para ganarpremios a capítulos, los miembros escribenpapers usando papers anteriores comofuentes.

Las actividades más tardíasdeben ser más cortas si lasactividades iniciales fueronlargas. IS retrasan nuevospasos si los primeros pasos noson resueltos o se encuentrananomalías

Los aeropuertos hub de aerolíneas puedenconstruir nuevos terminales o incluso pistas. Lasaerolíneas ajustan sus precios para estar de acordeal de las otras. Los pasajeros ajustan planes de viajeo procedimientos de ticket (e.g., los tickets uno-después-de-otro toman ventaja de los ahorros enprecio para ciertas rutas)



3.1. Tres Ejemplos

Este paper observa en los siguientes tres ejemplos, todos cumplen con las definiciones antes mencionadas desistemas complejos, por esta razón todos deberían dejarse influir por las mejoras basadas en los principios paralos sistemas complejos de ingeniería manejados en secciones posteriores. Los ingenieros de sistemas debieronestar 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 interés para los ingenieros desistemas. Los tópicos fueron originalmente definidos por [Maier, 1998]; conferencias y papers relacionados consistemas de sistemas se han incrementado enormemente en los últimos pocos años. Las cuestiones de sistemas desistemas que difieren de las cuestiones de sistemas incluyen:

Integración de sistemas de componentes operacionalmente independientes que fueron construidos paraotros propósitos.

Rápida evolución tanto de necesidades de usuarios como de tecnologías de sistemas, lo cual impide

requerimientos estables. Múltiples y dispares interesados con necesidades en conflicto y falta de incentivos para participar en elsistema de sistemas.

Desarrollo distribuido y sus consecuentes problemas de comunicación. Dependencia sobre una infraestructura de computación integrada, que tiene una extremadamente alta e

incremental complejidad, por ello con amenazantes consecuencias imprevisibles.

En un contexto de ingeniería los sistemas de sistemas a menudo son, pero no siempre, sistemas complejos. LaFigura 2 muestra esta comparación. Los sistemas de sistemas usualmente surgen en un contexto de adquisición deprograma, y se distinguen por ser inmanejables usando el estándar de ingeniería de sistemas de arriba-abajo,mientras que los sistemas complejos surgen en un contexto científico o analítico y los describe su imposibilidad deser descompuestos.

La mayoría de sistemas de sistemas son además sistemas complejos (SCx) y viceversa; aquí los dos círculossuperiores se traslapan bastante. Un sistema tal como un Avión de Combate Conjunto que es desarrolladomediante un administrador de programa y un jefe de ingeniería por definición no es un sistema complejo (no hayagentes independientes) sin embargo está específicamente considerado como un sistema de sistemas en algunostrabajos del Departamento de Defensa. [Jefatura del Comando Conjunto, 2007], aunque no está de acuerdo con lamayoría de definiciones comúnmente aceptadas [DOD AT&L, 2006], la cual es mucho más como la definición deMaier. 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 período dedesarrollo específico [Ferris, 2006]. La mayoría de estos califican como sistemas complejos que consisten de ungran número de partículas elementales o son sistemas biológicos no relacionados a la ingeniería y podrían no serconsiderados sistemas de sistemas.

4. HALLAZGOS EN LA CIENCIA DE SISTEMAS COMPLEJOS

La Ciencia de Sistemas Complejos incluye una cantidad de áreas de investigación donde todas tienen que verde algún modo con la complejidad, sistemas complejos, o sistemas no lineales. Algunos ejemplos incluyen teoríade complejidad, teoría del caos, autómatas celulares, y dinámica no lineal. Tomándolo como un todo, estasciencias ofrecen los siguientes hallazgos, los cuales son potencialmente importantes para la ingeniería de sistemas[Sheard, 2006]:



Emergencia: Emergencia está relacionada del todo sobre las partes, la interdependencia de las partes, yla especialización de las partes, si se estudia las partes por separado no funciona, la naturaleza de lossistemas complejos puede ser probada investigando como los cambios en una parte pueden afectar a lasotras además de al comportamiento del todo.

Formación de patrones: Simples modelos matemáticos capturan la formación de patrones tales comoactivación local /inhibición de largo plazo.

Estados múltiples (meta- ) estables: Pequeños desplazamientos (perturbaciones) llevan a recuperarse ygrandes desplazamientos pueden llevar a cambios radicales de propiedades. La dinámica no essimplemente de promedios.

Descripciones multiescala: son necesarias para entender los sistemas complejos pequeñas escalasinfluencias en grandes escalas de comportamiento.

Es difícil pero no imposible responder a la pregunta “ ¿Cuan complejo es?” Complejidad de comportamiento (respuesta): Para describir el comportamiento de un sistema

intentamos describir la función de respuesta: acciones como función del entorno. Sin embargo, a pesar deque se hacen asunciones para simplificar, esto requiere mucha información, la que creceexponencialmente con la complejidad del entorno.

Contraste: Los sistemas complejos a menudo exhiben características contrastantes, como simplicidad ycomplejidad, 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 primeracolumna de la tabla 2, las otras tres columnas muestran como nuestros ejemplos de sistemas evolucionan deacuerdo a este ciclo.

El primer paso del ciclo es abstraer un modelo a partir del mundo real. Esto involucra un balance entregranular y grueso. El segundo paso es identificar regularidades o patrones en la información abstraída, a menudoes difícil diferenciar lo que es aleatorio de lo que es informativo o patrones. El tercer paso es organizar esasregularidades en un esquema. Esto esencialmente comprime la información en algo más simple, cuántacompresión es aceptable depende de un análisis juicioso. El cuarto paso consiste en la identificación de algunasvariaciones de esta descripción, en el análisis de sistemas complejos existentes, esto puede significar elagrupamiento de las variaciones que se notaron. En la creación de sistemas complejos esto puede significar hacerintencionalmente que los elementos varíen. El uso de los esquemas es un medio subjetivo para la validación delmundo real. Finalmente las presiones del mundo real causan la selección de los esquemas que tienen más sentidoen la mayoría de casos.



Es útil notar que para explicar este ciclo el Doctor Gell-Mann [1994b] estaba concentrado en sistemasbiológicos más que en los sistemas “ingeneriados” por el hombre, entonces la aplicabilidad del ciclo a sistemascomplejos hechos por el hombre es sugestivo de una verdad general.

Tabla 2. Ciclo de Sistemas Adaptativos Complejos Aplicado a Ejemplos

Ejemplo:Ciclo SAC .

INCOSE Procesos de IS Sistema Aéreo Nacional (SAN)

I. Granularidad gruesade información delsistema real

Entender la ingeniería de sistemascomo práctica, y abstraer paracrear principios y consejo

Entender qué está siendo hecho enproyectos

Extrae necesidades de múltiples clientesATC

II. Identificación deregularidadespercibidas

Identificar patrones repetidos en eltrabajo de la IS

Notar actividades similares hechaspor ingenieros de sistemas parasistemas de ingeniería

Identifica requerimientos para lasiguiente generación de sistemas ATC

III. Compresión en unesquema

Crear principios y guías ,posiblemente como estándares

Documentar actividades y ordenarversiones abstraídas en procesostípicos

Escribe documentos operacionales yrequerimientos

IV. Variación deesquemas

Buscar revisión y guía de múltipleslugares

Programas hacen a medidaprocesos estandarizados

Usa múltiples sistemas al menos viejos ynuevos

V. Uso de los esquemas Comunicar guía y estándares a losmiembros

Programas usan procesos a medida Pone nuevos sistemas en acción en lugarde los viejos sistemas

VI. Consecuencias en elmundo real ejerciendopresión de selecciónque afecta lacompetición entreesquemas

Compañías miembros JCC eligencuales actividades incluir en suproceso de ingeniería de sistemasy eligen cuales estándares usan yapoyan.

Programas se hacen mejor o peordependiendo en parte en cuánto ycuan bien es hecha la IS, estovuelve a los grupos de proceso deIS y los éxitos son capturados.

Solo se siguen los nuevos sistemas si loscontroladores los manejan y sonmejores, o al menos no obsoletos nipeores.

5. ORDEN, CAOS E INGENIERÍA DE SISTEMAS

5.1. Ingeniería de Sistemas OrdenadosLa ingeniería de sistemas tradicional (designa ISO, por Ingeniería de Sistemas Ordenados) se enfoca sobre ellado “orden” del espectro orden -al-caos mostrado en la Figura 3. Las curvas de campana son ubicuas, la mecánicanewtoniana se usa predominantemente, y las ecuaciones no lineales son linealizadas, los administradorespresumen de saber lo que necesita ser hecho, y la meta es incrementar la predictibilidad y el orden. A pesar de queel hecho de que la ciencia del caos han sido ambos conocidos y popularizados por tres décadas, essorprendentemente cuan poco de la teoría se ha convertido instantáneamente en práctica para la ingeniería desistemas. El plan para la ingeniería de sistemas complejos (SCx) es reconocer tanto el lado del orden como el delcaos y hacer uso de los patrones descubiertos en la investigación para ser capaz de usar los principios aplicablescuando se necesitan.

5.2. Ingeniería de Sistemas Complejos

Esta sección se busca qué principios aplica a la ingeniería de sistemas complejos. Primero, es importante notar quela ingeniería de sistemas ordenados, los cuales tradicionalmente buscan como resolver un problema específicocreando una solución de diseño y luego construyéndola, tiene muchos traslapes con la ingeniería de sistemascomplejos, los cuales buscan primeramente identificar los sistemas complejos que ya existen y sus tendenciasevolucionarias y luego las tendencias que las afecten de modo que el sistema evolucione para producir másresultados deseados. La Figura 4, adaptado de [Hyberston, 2006] muestra tres tipos de principios que se aplican aIngeniería de Sistemas Ordenados (ISO, llamados ingeniería de sistemas en la fuente) e ingeniería de sistemascomplejos (SCx, llamados ISC en la fuente).



En el bloque inferior de la Figura 4 (3. Común a todos ) caen los principios básicos que pueden ser usadosen el desarrollo de sistemas complejos. En el bloque del medio ( 2. Diferentes en grado ) están los principios de ISOque deben ser extendidos para ser usados por los sistemas complejos. La guía SoSE DOS mencionada arriba [DoDAT&L, 2006] se enfoca en este bloque, en este su ámbito es la adaptación de guía de ingeniería de sistemasgenerales para grandes programas únicos que desarrollan sistemas de sistemas. Otra buena guía para tal prácticaes un modelo de costeo para sistemas de sistemas llamado COSOSIMO, ver [Boehm, 2006].

El bloque superior (1. Diferente en tipo) guía a esos principios que no son comunes entre ISO y ISC, paralos sistemas descritos en este paper, se puede argumentar que el bloque 1a (el bloque de la izquierda) es elconjunto nulo, i.e., todos los principios de ingeniería de sistemas ordenados aplican de algún modo a estossistemas complejos, debido a que los sistemas complejos incluyen sistemas más pequeños, sin embargo, el bloque1b (el bloque de la derecha) no es el conjunto nulo. Hay principios de ingeniería de sistemas complejos que son enesencia diferentes de los de ISO.

Figura3. Espectro orden-caos

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

Esto parece contra intuitivo para quienes ven a la ingeniería de sistemas como una teoría de todo, sinembargo, la existencia del bloque 1b deben ser consideradas buenas noticias. La industria está sufriendoactualmente de fallas muy consistentes de programas creados para desarrollar grande sistemas, sistemas desistemas, o sistemas complejos. Los principios en el bloque 1b presentan esperanza: esperanza de que hay más



cosas que podemos aprender e institucionalizar de modo que podamos acercarnos a estos grandes sistemas demodo diferente y ahora empezar a tener éxito, sin este bloque nosotros estaríamos restringidos a hacer más de lomismo, quizás con más control y más disciplina, aún no hay indicativos que tal acercamiento fuera exitoso, coneste bloque por lo menos podemos buscar principios adicionales y ver que más hay para combinar con lo que yaestamos 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 más probablemente con algunos aspectos caóticos también. La Figura 5muestra dos maneras de caracterizar tales islas de orden. Los sistemas tecnológicamente pueden ser diseñados yconstruidos usando procesos estándares de la ingeniería de sistemas partiendo de una especificación técnica. Ellostienen fronteras definidas e interactúan con su entorno vía “interfaces externas” definidas, estos sistemas semuestran como “sistemas diseñados” en la Figura 5, note que entre estas islas de orden hay muchas interfacesusualmente no planeadas, debido a que los sistemas diseñados son creados en diferentes momentos pordiferentes grupos de personas, a menudo para propósitos distintos a sus usos eventuales; a estas interfaces se lesdenota como “interacciones desordenadas”; además note que los sistemas complejos evolucionan de un mododinámico como un todo, acomodando actualizaciones asíncronas de los varios sistemas diseñados.

El diagrama de la derecha está basado en Norman [2008], este muestra las mismas islas de orden comopuntos de interfaces de baja variedad entre capas de variedad (tales como montones de ISO: cualquier cosa quepuede ocurrir dentro de una capa aunque protocolos definidos entre los montones son los que ayudan a mantenerel sistema entero teniendo sentido).

Un ejemplo organizacional es que dentro de una oficina de programa complejo hay este grupo de gestión deconfiguración cuyo rol es restaurar el orden y mantener una línea de base previa difícil-de-cambiar que nadie máspuede cambiar, esto paradójicamente es la estabilidad que permite que ocurra el cambio.

Figura 5. Islas de orden

6. PRINCIPIOS POTENCIALES DE INGENIERÍA DE SISTEMAS

La siguiente es la opinión del autor sobre una cantidad de potenciales principios de ingeniería de sistemascomplejos que podrían añadirse a la práctica de ingeniería de sistemas ordenados que son enseñados y yaampliamente conocidos, agrupados por roles relacionados de ingeniería de sistemas [Sheard, 1996]. Las itálicasdespués de cada principio muestran una aplicación del principio en la mitad del ejemplo de arriba, el proceso de laingeniería de sistemas dentro de un compañía. Las referencias proveen más información de tales principios.Dentro de la siguiente década se debería aprender lo suficiente de complejidad e ingeniería de sistemas complejosque estos potenciales principios que puedan convertirse en decisivos, mejor forzados, y ampliamente aceptados



6.1. Principios de Sistemas tipo arquitectónico (DS o Rol del Diseñador de Sistema)Pensar en la evolución del sistema más que en el “diseño” del sistema (sobre una hoja de papel en blanco).

Los sistemas complejos no son creados por improvisación, más bien ellos vienen de otros sistemas complejos conpequeños ajustes. INCOSE ha notado que los requerimientos iniciales probablemente sean ambiguos, y laingeniería de sistemas de sistemas nunca esté terminada. [Haskins, 2006]

Usar elementos probados, su sistema podría aprovecharse de la evolución que ya ocurrió en contextossimilares 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 biendefinidos sirven como un atractor (similar a los atractores extraños de la teoría del caos) que mantienenlos espacios de estado cerca del área deseada.

Pequeños ajustes a grandes sistemas llevan a la evolución del sistema al espacio de resultados deseado,White [2005] y Norman y Kuras [2006] amonestaron la identificación de espacios de resultados, noespecificaron resultados, y establecieron recompensas (y penalidades)- incentivos por las decisiones quecausaron 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 losprocesos como son es un mejor modo para empezar que escribir lo que piensas que el proceso debe hacer, debido a queestos 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 través deauto-organización.

¿Cuáles son los “ratios primarios” del sistema que el “gobierno federal” puede ajustar el “mercado decapitales” 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 aún “línea de parada” pueden llevar a lamejora del sistema?

Mantener múltiples posibilidades viables. Los sistemas complejos prosperan fomentando la variedad entrelos elementos y dejando a los elementos competir para ver cuál es el que más se ajusta. Una gestión de tendenciahacia la eficacia (teniendo sólo uno de cada uno en todo, el más costo-eficiente) funciona contra esto y de hechoconfigura el programa para fallas catastróficas [Norman y Kuras, 2006]. En lugar de eso hay que permitirexplícitamente la variación; la “explosión combinatoria” se refiere al hecho de que aún con una pequeña cantidadde ítems se pueden crear varios patrones mediante la combinación de varios subconjuntos de ítems variando losvínculos entre ellos y enfocando rápidamente a lo funcionalmente infinito [Minai, Braha, y Bar-Yam, 2006]. Useeste hecho para recombinar diferentes cantidades de componentes para mantener variedad en todo momento.

Imponer explícitamente variedad en el sistema (lo opuesto a estandarización y eficiencia). [Minai, Braha, yBar-Yam, 2006] Aceptan la unicidad inherente de los sistemas individuales: La conformidad no es siempre unavirtud, y la novedad no es del todo un vicio.

Como siempre, las opciones de trade-off en el comienzo mantienen más de una opción viable, sinembargo, con una búsqueda continuada y desarrollo por ejemplo. El proceso de desarrollo de Toyota estásiempre innovándose pero preserva el modo en que la función se actualmente se realiza en caso que lainnovación 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; laliteratura de hecho sugiere que la elección no puede ser hecha por análisis o prueba sino ejecutandomúltiples opciones en las operaciones reales.

Fomentar tanto la redundancia como la degeneración en todos los niveles de las jerarquías que aparezcan[Minai, Braha, y Bar-Yam, 2006], redundancia significa tener múltiples componentes idénticos que puedensustituirse mutuamente si fuera necesario, la degeneración significa tener múltiples componentes



distintos que pueden ayudarse unos a otros, debido a que los componentes no son idénticos estavariación le da robustez ya que los componentes no fallaran del mismo modo.

Ejemplo de proceso de IS: Mantener los procesos de múltiples organizaciones en competencia, no intentar eliminar todossino un conjunto de procesos, la eficiencia se obtiene de modo concreto.

Arquitectura en capas que aíslen de los otros a elementos con distintos ratios de cambio. Establecer unacapa de cosas que cambien muy lentamente, una capa diferente de cosas que cambien muy rápidamente, y una omás capas en medio [Norman y Kuras, 2006]; conectar estas capas con puntos de baja variedad, tales comoprotocolos estandarizados, esto permite que ítems de cambio rápido cambien rápidamente sin afectar las cosasque fueron creadas bastante tiempo atrás y estarán allí por mucho tiempo.

Ejemplo de proceso de IS: Las políticas organizacionales raramente cambian, además un ejecutivo debe firmarlas. Losprocesos cambian con mayor frecuencia, y requieren menos firmas que lo autoricen. Cosas como plantillas son las que másdifieren y necesitan el más bajo nivel de autorización.

Use árboles de decisión para determinar donde funcionan mejor los cuatro enfoques de diseño [Anderson,2006]:

Simulación de abajo hacia arriba (diseño bottom-up)

Ingeniería de arriba hacia abajo (diseño top-down) Analogía e imitación (arquetípico, prototípico, e inspiracional) Evolución interactiva (evolución sólo con ajustes específicos de evaluación 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 están buscando como eficiencia, y casi siempre hay sistemas análogos,entonces podrías querer: “emular sistemas conocidos, haciendo unos pocos cambios o modificánd olo tanto como seanecesario, posiblemente usando computación evolucionaria o sistemas paramétricos”.

Figura 6. Enfoque de diseño por árbol de decisión

1. ¿Es posible definir matemáticamente una función matemáticaobjetivo/de ajuste? (en otras palabras, ¿sabes lo que estás buscando?

Sí: Ir a la pregunta 3No: Ir a la pregunta 2

2. ¿Se puede notar en tiempo real el comportamiento a nivel de sistema?Sí : La evolución interactiva es una posibilidad fuerte.No: O una lenta y probablemente frustrante proceso de manejomanual de parámetros o está involucrada una búsqueda sistemática através de espacios de estado, o una técnica tal como búsqueda abierta-final.

3. ¿Hay un sistema análogo conocido?Sí:Emule el sistema conocido, haga pequeños cambios o modifíqueloscuanto sea necesario, posiblemente usando computaciónevolucionaria para parametrizar el sistema.

No: Ir a la pregunta 44. ¿El sistema requiere o involucra múltiples niveles de jerarquía, o es de

fácil influencia para su introducción? (¿Podemos trozarlo?)Sí: Pueden ser posibles algunos elementos de ingeniería top-down,probablemente en conjunción con modelamiento bottom-up.No: Modelamiento bottom-up, adoptando alguno de los principiosgenerales expuestos en la literatura que pueden funcionar.



Considere la creación de enjambres para realizar algunas tareas.Ejemplo: múltiples agentes independientes para ISR (Inteligencia, Supervivencia, Reconocimiento), entendiendo elenjambre multiagente y simulándolo.

Ejemplo de proceso de IS: Podría querer simular muchos ingenieros ejecutando diferentes cambios de ingeniería pedidos(CIPs) durante el proceso en el mismo momento.

Permitir utilización de módulos sin etiqueta [Minai, Braha, y Bar-Yam, 2006], permite a los componentes serusados en usos que no fueron previstos cuando fueron creados. Este es el modo primario como evolucionan lossistemas de sistemas, y los sistemas de componentes pueden evolucionar más rápidamente de este modo quediseñando nuevos componentes por inspiración. Los módulos que son capaces de ser usados sin etiqueta tienenque probar su utilidad de algún modo o no se les debería considerar para reutilizarlos, esto muestra que al menosse ha alcanzado un nivel mínimo de calidad

“Renunciar al último bit de optimización” (“satisfaciente” ) y congelar lo más temprano posible lasespecificaciones de componentes de segunda prioridad [Mihm y Loch, 2006] En proyectos complejos las másgrandes amenazas para completarlos (sin mencionar el logro del desempeño necesario) es la gran cantidad debucles de re-trabajo causados cuando los cambios en un componente vuelven atrás y requieren cambios en otroscomponentes, lo cual causa efectos terceros; prevenir estas fuertes conexiones permite a un proyecto estar más

libremente emparejado; un modo de lograr esto es determinar explícitamente cuáles componentes son segundaprioridad, nombrarlos, su desempeño tiene efectos sólo de segundo orden sobre el desempeño del sistema. Loscomponentes de segunda prioridad no deben ser optimizados, en lugar de eso sus especificaciones deben sercongeladas pues ellas servirán como puntos de certeza en una mezcla turbulenta en un proyecto cambiante.“Satisfaciente” es usado como una combinación de “satisfacer” y “suficiente” para recomendar remover cicloscirculares, pero no intentando satisfacer requerimientos en cualquier modo óptimo, sino más bien quitar losdesperdicios cuando el desempeño sea suficiente. De modo similar, seleccionar componentes para que el sistemaoptimice un pedazo más que el sistema completo crea una pequeña cantidad de vínculos interdependientes, comopiezas de un pedazo generalmente no afectarán o se comunicarán con piezas de otro pedazo, esto tiene el mismoefecto 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 seránchequeadas tanto al fin de un paso como al comienzo de otro, tal redundancia permitirá que las interfaces entre losprocesos vayan suavemente.

6.2. Principios de Análisis 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 permitirán al

analista ver el sistema no sólo desde el punto de vista estándar sino además desde las leyes de potencia,fractales, auto-organización, y perspectiva de redes.

Entender el crecimiento, evolución, y ajuste al ámbito. En sistemas socio-técnicos el entorno dentro delcual el sistema tecnológico debe ajustarse, a menudo es de mucho mayor complejidad que la del sistematecnológico. Este entorno cambia constantemente, ambos debido tanto a las influencias externas alsistema socio técnico pero además debido a las adaptaciones que loe elementos emprenden para

incrementar su ajuste al ámbito cambiante. Otros importantes conceptos incluyen la co-evolución deelementos, el hecho que en sistemas interesantes las fronteras no solo puedan sino que deban serabiertas, el impredecible gran número de catástrofes actuales, y los requisitos de variedad.

La ley de variedad requerida de Ashby, originalmente creada para describir sistemas de control,demuestra que la reducción de la complejidad de una solución va de la mano con el costo de la capacidad;una solución no puede controlar un ambiente de mayor complejidad que la suya; esto enseña a losingenieros a tratar con la complejidad de los sistemas más de lo que la ingeniería ha intentado hastaahora. [Heyleghen, 2006].



Ejemplo de proceso de IS: Tanto los procesos como los programas son fractales, hay pocos procesos grandes y un grannúmero de ellos son pequeños, ellos son auto-similares si se mira las partes grandes y las versiones más pequeñas,considerando tanto el crecimiento de los procesos (y la probabilidad de que nuevos procesos se conecten a los procesosmás altamente conectados) y la competencia y adaptación de los proceso individuales, la resistencia organizacional a lasmejoras puede ser pensada como una homeostasis biológica.

Modelar cuando es necesario. Simule el comportamiento multiagente para determinar el mejor conjunto de reglas para tu sistema

complejo, pequeños cambios en las políticas o en las reglas que siguen elementos puede alterardrásticamente el comportamiento de un sistema complejo. Pequeños cambios vuelven bandadas depalomas en formaciones V, o convierten muchedumbres en coreografías.

No sobre-simplifique El mismo principio de variedad requerida (mencionado arriba) aplica también a los modelos: modelos

simples no pueden capturar la esencia de las situaciones complejas. Desarrollar una ayuda con másmodelos complejos usando herramientas validadas si la complejidad no puede ser manejada por uncerebro humano.

Modelar para evaluar las consecuencias globales de acciones locales. Simular los efectos de varias reglassobre los nodos y sobre la red de modo que puedas elegir las reglas y nodos (elementos) apropiados.

Ejemplo de proceso de IS: Podría querer simular muchos ingenieros ejecutando distintos pedidos de cambio de ingeniería(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 análisis de redes para averiguar cómo hacer pequeños cambios que den gran ventaja[Braha y Bar-Yam, 2006; Valnerde, 2006; Heylighen, 2006]. Probablemente todos los diagramas de procesosincluyan herramientas de gestión de proyectos como diagramas PERT sean analizables mediante análisis de redes.Algunos de los análisis incluyen pendientes de leyes de potencias asociadas con grados de entrada y grados desalida, los efectos de vínculos rotos en la red, y el tiempo que le toma a la red volver a su estado estable o estadode convergencia (todas las actividades completadas), dada la probabilidad aleatoria de interrupción de unaactividad a causa de una interrupción en una actividad con la cual esta está vinculada. Las conclusiones publicadasen la literatura abierta son menos importantes (más obvias) que lo que parecen estar garantizadas por laprofundidad del análisis; 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 número de vínculos salientes, i.e., montones de otrastareas esperando por sus output [Braha y Bar-Yam 2006] y ese margen y ausencia reduce el número de vínculos,permitiendo desacoplar tareas y por lo tanto una más alta probabilidad de convergencia. Mientras la mayoría degerentes de proyecto supondrían estos resultados generales los cuales podrían o no aplicar en sus proyectosparticulares. El punto es que tales herramientas existen y podrían ser aplicados en particular a sus proyectosdonde podrían 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 Dueño de los Requerimientos)Descripciones enfocadas en procesos de ingeniería de sistemas suelen empezar con requerimientos [Sheard,

1996] incluidas como parte del rol del DR:Los administradores/dueños de requerimientos, asignadores y quienes escriben o mantienen de especificaciones, o

dueños/desarrolladores de arquitectura funcional / desarrolladores de sistemas y subsistemas de requerimientos de lasnecesidades del cliente.

Rol de Operaciones y Logística (OL):Adicionalmente para tomar responsabilidad primaria en las últimas fases de los programas. Se espera que los

ingenieros de OL realicen mantenimiento, operaciones, logística, y hacerse de preocupaciones sobre los requerimientos,diseño 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 descripción del cual los roles deberían o podrían apropiarse o hacer susconceptos operacionales y entendimiento del espacio del problema. Esto sugiere que el entendimiento de lainterface entre el sistema y el entorno no fue tan bien desarrollado a comienzos de los 90 como el día de hoy. Esteentendimiento es crítico para sistemas complejos; por ello los siguientes conceptos acerca del entendimiento delespacio del problema son especialmente resaltados, ajustados al DR debido a que es la parte más temprana delciclo 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. Fractales2. Borde del caos

3. Leyes de Potencia4. Redes libres de escala

Use lo que se conoce acerca de ellos para dirigir tu atención a los riesgos, por ejemplo:

Ejemplo de proceso de IS: Puede intentar hacer procesos tanto flexibles como estables, en la medida que estuvieran cercaal 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 implementación (Sistema, Estrategia,Implementación, y contexto de interesados) y ocho variables (Resultado Deseado, Comportamiento de Sistema,Entorno de la Misión, Ámbito de esfuerzo, Escala de Esfuerzo, Entorno de Adquisición, Involucramiento deInteresados, y Relaciones de Interesados.) Cada una de estas puede ser considerada como de dominio deprograma Tradicional, de dominio Transicional, o Frontera del Desorden, y cada uno de ellos sugiere cierta gestiónde comportamientos.

Ejemplo de proceso de IS: Por ejemplo, los procesos para equipos multiempresa podrían tener menos involucradoscohesivos, y un contexto de implementación dificultoso, pero podría tener una misión y un ámbito fuertemente estables.

6.4. Principio de Gestión de Configuración (Rol del Administrador de Información, AI)Durante el desarrollo de sistemas prepararse para y que tengan cabida el diseño de cambios esperado. Identificar listas de quiénes serán impactados y por qué cambios. Inmediatamente difundir preliminarmente la información a las personas quienes han suscrito a esos

cambios. La difusión inmediata reduce la necesidad de cronogramas para hacer necesarios ajustes acualesquiera tareas futuras [Mihm y Loch, 2006] y por ello ayuda a que la red converja en unaconfiguración estable. Los aspectos de subscripción ayudan a reducir la sobrecarga de información. A

cualquier persona se le puede pedir que se subscriba a lo que ellos piensan que podría afectarles, o, porotro lado, las subscripciones podrían establecerse en base a un análisis de conectividad de red (enviandoinformación a través de sus vínculos salientes). Claramente la información preliminar debe serconfirmada.

El pulso en el tiempo de las entidades (para actualizaciones) debe ser tan corto como sea posible [Normany Kuras, 2006]. Esto es en su mayoría más de lo anterior, pero además sugiere que las entidades mismasdeben tener los recursos para hacer los ajustes requeridos rápidamente, así esto permitirá la propagaciónde cosas ya hechas en el flujo de trabajo sin retrasos.



Además configurar buenas fronteras de modo que las personas que necesitan hacer cambios importantesno sean agobiadas por barreras burocráticas a cualquier cambio. Aquí Norman y Kuras [2006] discutenmás que la típica información en el proyecto, la clave es reconocer que los sistemas complejos sonsignificativamente diferentes que los sistemas predecesores, entonces la innovación es más crítica para eléxito tecnológico que lo que ha sido en el pasado. Desafortunadamente, una característica de lainnovación es que esta tiende a enredarse con procesos estándares trillados. El punto de este principio es

reconocer esto y establecer fronteras claras dentro de los cuales a los grupos de personas se les permiteaún innovar procesos sin interferencia del lobby: “no podeos hacerlo de ese modo debido a que nunca lohemos hecho así antes”.

Ejemplo de proceso de IS: Convocar regularmente un Consejo de Cambio de Procesos para asegurarse que aquellosafectados sean contactados sobre potenciales cambios.

6.5. Principios de Coordinación (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 propósito común, pero esto es aúnmucho más cierto para sistemas socio técnicos. Esto no sólo involucra desarrolladores (a menudo de diferentesorganizaciones) sino además usuarios y clientes. La mayoría de sistemas socio técnicos tienen una gran cantidadde interesados, afortunadamente ellos pueden ser categorizados y usualmente no necesitan ser incluidos:“Opositores a cualquier construcción, afectados de los negocios debido a la falta de acceso, desarrolladoresbuscando subcon tratos,” etc. Dos principios generales acerca de tratar con el lado “socio” son:

Aprender acerca de los equipos y principios de psicología organizacional. Si tú no eres del tipo persona-gente, alíate con aquellos que lo son.

Ejemplo de proceso de IS: Las misiones de los equipos tienden a funcionar como atractores para mantener a todostrabajando juntos.

Establecer el tipo correcto de comunicación. La Coordinación debería ser sobre una escala lo suficientementegrande como para realizar las tareas, pero no tan grande que dañe la independencia de demasiados elementos enescalas más pequeñas [Bar-Yam, 2006]. Usualmente es necesario tener una coordinación jerárquica [Mihm y Loch,2006]. Puesto que la auto-organización crea espontáneamente jerarquías en la mayor parte de casos, esto

usualmente no es un problema, aunque allí podría haber una expectativa específica de que las jerarquías seansobre coordinación 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 desuficiente 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 información se puede obtener

solamente conociendo a la gente, aunque las bases de datos, si se les mantiene adecuadamente, puedenayudar en algo.

Buscar la atención de aquellos quienes pueden ayudarles. Hacer una práctica presentarse a gente tantocomo sea posible. Nunca se sabe cuándo las conexiones resultarán ser importantes.

Es espacialmente valioso conectarse con gente de diversas disciplinas, dominios, y límites de la compañía.Vínculos débiles [Granovetter, 1980] a menudo resultan ser más valiosos que vínculos fuertes (la genteque ya conoces bien) debido a que los vínculos débiles traen a muchas personas antes no accesibles.

Preparar reuniones de intercambio técnico (RITs) y otros modos de juntar a personas quienes puedentener información acerca del problema, pero hacer más: además establecer tantas conexiones uno a unocomo sea posible.

Ejemplo de proceso de IS: Configurar interfaces de trabajo en grupos que atraviesan los límites del equipo.



6.6. Principios Relacionados con la Gestión (Rol de Gestión Técnica, GT)Los trabajos de gestión y el técnico están mucho más enredados en el trabajo en sistemas complejos que en la

mecanicista ingeniería estándar de muchos sistemas [Haskins, 2006]. Desafortunadamente el tipo de gestión debecambiar: El control jerárquico top-down ya no es más un buen modelo [Sheard, 2006; Norman y Kuras, 2006]

Gestionar explícitamente la gestión del entorno

White [2005] y Norman y Kuras [2006] apunta que si bien los administradores están familiarizados con lagestión de esfuerzos de desarrollo de sistemas, debe haber un nuevo énfasis sobre la gestión de cómo contribuir alentono de desarrollo. Se debe prestar atención explícita y consciente a su forma inicial, reconocer que el entornoevolucionará. Si el entorno es visto como un ecosistema, ¿Quiénes son los agentes?, ¿Son ellos lo suficientementeinteractivos y autónomos? ¿Qué recursos fluyen a través del sistema para recompensar las variedades exitosas?Entender la función de los incentivos e implementarlos adecuadamente, debido a que la interacción de los agenteses lo que crea nuevas formas de capacidad a través de evolución, colaboración nutritiva. Con frecuencia estoademás significa competencia, debido a que la colaboración y competencia se soportan la una a la otra cuando sonen 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 interacción compleja entre administración y técnico. Las

organizaciones deben estar fuertemente acopladas, así como ni las decisiones técnicas ni las de gestióndeben 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 aretos complejos necesariamente serán complejas. Además la complejidad evolucionará para ser másgrande que su incremento de capacidades [Heylighen, 2006]. Un indicador de esta complejidad es laespecialización de funciones de los agentes individuales: las organizaciones se vuelven más complejasdesarrollando más y más especializaciones.

A pesar de que una multitud de especialidades que no se hablan unas a otras crea complicaciones quepueden no ser necesarias, hay un aspecto de irreductible complejidad en la especialización, sin embargoes importante evitar aislamientos completos.

Ejemplo de proceso de IS: Nuevas capacidades necesitarán nuevos procesos. Nuevos procesos implican una especializaciónmás grande. Algunas personas desarrollarán pericia en cada proceso, y cada proceso será asociado con unas pocaspersonas que lo puedan hacer muy bien. A estas personas se les pedirá realizar estos procesos múltiples veces, añadiendoexperiencia a su pericia.

Juzgue los resultados reales [White, 2005; Norman y Kuras, 2006]. Juzgar implica la aplicación de un juiciohumano a los resultados, pero la evolución se juzga también, por lo menos, en retrospectiva (los que sobrevivieronson juzgados más ajustadamente, si esto fue real o en efecto sobrevivieron debido a una casualidad genérica).

Juicio basado en el logro de resultados cerca o dentro del espacio de resultados deseado establecidodurante la arquitectura del sistema.

Mantener vigilancia constante respecto a problemas crónicos. Éxito evitando catástrofes a menudo lleva aproblemas crónicos [Tenner, 1996]. La vigilancia constante puede consumir recursos rápidamente.Necesidad por más recursos para empujar nuevos problemas lleva a un camino al azar dentro de unrégimen inseguro, el cual a menudo lleva a accidentes [Sheard,2008; Woods y Cook, 2006]

Los algoritmos para medir valor deben imponer presión selectiva sobre los agentes. Reducir tanto como sea posible el incentivo a “jugar con el sistema”: sesgar las mediciones en una

dirección favorable. Esto interfiere con tu capacidad para entender el sistema, e incrementa lasdificultades que tendrás llevándolo a una evolución en una dirección deseada.



Ejemplo de proceso de IS: Por ejemplo, seguir el número de renuncias y el número de cambios. Zero es probablemente unmodo en que las noticias están siendo acalladas. No recompense la cancelación de problemas.

Haga explícitas las reglas de negocio de interacción [White, 2005; Norman y Kuras, 2006]. Las reglas denegocio son la base de las reglas que las personas y las organizaciones usan para tomar decisiones relacionadascon otras personas y organizaciones. Los problemas surgen cuando un grupo piensa que las reglas de negocio delos otros son las mismas que las suyas, cuando de hecho son diferentes. Hacer las reglas explícitas ayuda por unlado a reducir aquello que es indiscutible [Argyris, 1990] y por el otro en un sentido más allá, a mantener lacomunicación vital.

Cambiar un poco las reglas tanto como sea necesario para mantener al sistema evolucionando en ladirección deseada. Las reglas que siguen agentes individuales es lo que esencialmente determina lospatrones en los sistemas complejos. Pequeños cambios en reglas aplicadas y simuladas en aves resultanengrandes cambios en el comportamiento de bandada. El gobierno federal de EEUU hace pequeñosajustes a la bolsa de valores para prevenir grandes fluctuaciones y caídas. El desarrollo de sistemas muyprobablemente experimenta tales efectos sobre los cambios en las reglas, pero no se están haciendograndes estudios a la fecha.

Ejemplo de proceso de IS: Las reglas de negocio explican en detalle cuándo los procesos son seguidos y con qué grado decoordinación. ¿Quiénes deben participar en una revisión por pares? ¿Hay situaciones en las que no hay quórum, si es así,

qué se debe hacer entonces? ¿Cuándo los abandonos son aceptables?

Encuentre a los expertos adecuados , particularmente aquellos quienes son entendidos acerca de los sistemascomplejos [Sheard, 2005].

Ejemplo de proceso de IS: Idealmente los ingenieros de proceso entenderán la complejidad.

Enfocarse en los procesos de ingeniería y en los recursos para (e.g., proveer fondos y tecnología que lossoporte) tareas de desarrollo central de productos [Braha y Bar-Yam, 2006].

Ejemplo de proceso de IS: ¿Cuáles procesos que hace cada quien dependen de información? El dinero gastado haciéndoloseficaces y eficientes será devuelto muchas veces de nuevo.

Entender que los diagramas de Pareto se derivan de las leyes de potencia. Considere resolver tanto losproblemas más grandes (los más raros) así como los problemas más comunes (los más pequeños) primero, luegoselectivamente maneje otros.

Ejemplo de proceso de IS: Por ejemplo los pedidos de cambio de procesos más grandes y más comunes deberían sermanejados primero. Además, las compañías a menudo escriben procesos para sus programas más grandes, pero olvidanhacer una versión previamente ajustada para los programas pequeños (y más numerosos).

Siga los pasos para reducir las catástrofes Vigilancia constante [Tenner, 1996] de problemas crónicos, con priorización y monitoreo continuo y una

gestión no furiosa [Dörner, 1989]. Observar oscilaciones y luego períodos como un indicador de que el sistema está transicionando hacia el

caos. Cuando esto es detectado tómese 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 esoscambios pueden tener. Pequeños cambios pueden llevar a un sistema al caos.

Permita (u haga uso de) la evolución y la adaptación para evolucionar hacia un sistema “cerrado ” quefuncione. Intente alejarse de situaciones completamente nuevas y no probadas, especialmente sin unplan de recuperación.

Mantenga múltiples opciones abiertas, e.g., La filosofía de desarrollo de Toyota [Kennedy, 2003].



Trace una situación compleja con el instrumento Cynefin® , para identificar patrones de problemas ysoluciones [Kurtz y Snowden, 2003]

Ejemplo de proceso de IS: La definición de procesos toma ítems conocibles y los hace conocidos. Esto puede no aplicar asituaciones complejas, y no aplicar a situaciones caóticas. Saber qué tipo de situaciones que surgen no pueden serpredichas y aplicar estrategias complejas y caóticas preferentemente en su lugar.

Base sus decisiones en datos: Los buenos tomadores de decisiones (en situaciones complejas) [Dörner, 1989]: Tomaron en cuenta múltiples cosas cuando tomaron decisiones Fueron menos distraídos (enfocados en sus metas) Hicieron más preguntas del tipo “por qué ” más que tomar los eventos y evaluarlos considerándolos

inconexos. Reflexionaron críticamente 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 gestión senior.

7. CONCLUSIONES

Debiera quedar claro a partir de los ejemplos que la práctica de la ingeniería de sistemas tiene muchas de lascaracterísticas de los sistemas complejos. En consecuencia la IS evolucionará y el objetivo de teorizar ymejorar procesos debe ser guiar la evolución a un estado de alta capacidad, lo cual significa más variedad de lacual elegir y por ello más complejidad. Para hacer uso de uno de los últimos principios:

Transicionar de hacer Ingeniería de Sistemas a hacer Ingeniería de Sistemas Complejos [Bar-Yam, 2006]:

a) Construir continuamente sobre lo que ya existe [es un sistema complejo después de todo, este debeevolucionar].La evolución desde el principio es lenta, empieza desde una cosa que tú ya tienes.

b) Enfócate en crear un entorno y en los procesos más que enfocarte exclusivamente en los productos.c) Los componentes individuales deben ser modificables in situ. d) Los sistemas operacionales incluyen múltiples versiones de componentes funcionales.e) Utilice múltiples procesos de desarrollo en paralelo.f) Evalúe experimentalmente in situ. g) Incremente gradualmente la utilización de componentes más efectivos.

En la construcción sobre las prácticas de la ingeniería de sistemas que ya existen, los ingenieros de sistemasdeben volverse más conscientes de los sistemas complejos que hay en la práctica de la IS (a). INCOSE puedecontribuir modificándolas para transformarlas en los entornos donde los ingenieros de sistemas aprenden a usarlas ideas de los sistemas complejos, y mostrando interés deliberado en el mundo de investigación de sistemascomplejos (b). Sería ideal si los procesos de modificación de las prácticas de la IS son capturadas por INCOSE (porejemplo Haskins [2006], e INCOSE [2006], fueron fáciles de actualizar (tal como una wiki) y frecuentementeempleados (c). “d” esencialmente significa que deben estar disponibles múltiples versiones de buenas prácticas de

IS, y con ello competir contra las otras durante el curso normal de la práctica de la ingeniería de sistemas. Un modode promulgar esto es construir un conjunto de prácticas de sistemas complejos, a lo largo de las líneas de [DODAT&L, 2006] pero manejando los sistemas complejos como “en ámbito ”, haciendo que los ingenieros de sistemasse familiaricen con ella, y luego ver si ellos“resultan ganadores ” en el uso actual de escenarios comparados con lasprácticas actuales de la ingeniería de sistemas: ¿Se ajustan ellos más que las prácticas ajenas a los sistemascomplejos? Esta última pregunta es “f ”; “e” es realmente dado, ya que tenemos siendo realizadas muchasinstancias independientes de ingeniería de sistemas. Esas instancias que son las más útiles posteriormente seránrealizadas más frecuentemente, dando como resultado un incremento en la capacidad de los sistemas de la IS (g).De este modo serán 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,” Complexengineered 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 fails—toward complex systems engineering. International conference onsystems, man & cybernetics, vol 2, IEEE Press, Piscataway, NJ, 2003b, pp. 2021 –2028.

Y. Bar-Yam, “Engineering complex systems: Multiscale analysis and evolutionary engineering,” Complex engineeredsystems: 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 theJoint 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 SystemEngineering, Seattle, WA, 1993.

D. Dörner, 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 systemsenvironment, Draft, Director, Systems and Software En-gineering, Deputy Undersecretary of Defense (Acquisitionand 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 ofsystems, Systems of Systems panel discussion, INCOSE Symp, 2006.

M. Gell-Mann, “Complex adaptive systems,” Complexity, metaphors, models, and reality, G. Cowan, D. Pines, andD. Melzner (Editors), SFI Studies in the Sciences of Complexity, New York: Addison-Wesley, 1994a. (Cited in Maierand 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), 1360 –1380.

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/guidetose-bodyofknow.aspx, 2006.

M.N. Kennedy, Product development in the lean enterprise: Why Toyota’s system is four times more productiveand 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 complexsystems 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), 462 –483, 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: Sciencemeets 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), 267 –284.

J. Mihm and C.H. Loch, “Spiraling out of control: problem -solving dynamics in complex distributed engineeringprojects,” 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 engineeredsystems: 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 meetstechnology, 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 systemsengineering 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, toappear.

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, AnnArbor, 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, “Incidents—markers of resilience or brittleness?” Resilience engineering: Concepts and

precepts, E. Hollnagel, D.D. Woods, and N.G. Leveson (Editors), Ashgate, Aldershot, UK, Chap. 6.

Principios de Sistemas Complejos para la Ingeniería de Sistemas

Documents

Transcript of Principios de Sistemas Complejos para la Ingeniería de Sistemas