Machine Translated by Google

90

Área de Conocimiento: Fundamentos de Sistemas

Fundamentos de Sistemas
Autor principal: Rick Adcock, autores colaboradores: Janet Singer, Duane Hybertson

Esta área de conocimiento (KA) proporciona una guía para algunos de los conocimientos más importantes sobre un sistema, que forma
parte del pensamiento sistémico y actúa como base para los mundos relacionados de la ciencia integrada de sistemas y los enfoques
sistémicos para la práctica.

Esto es parte del conocimiento de sistemas más amplio, que puede ayudar a proporcionar un lenguaje común y una base intelectual y
hacer que los conceptos, principios, patrones y herramientas prácticos de los sistemas sean accesibles para la ingeniería de sistemas
(SE) como se analiza en la Parte 2: Fundamentos de la ingeniería de sistemas.

Temas
Cada parte del SEBoK se divide en KA, que son agrupaciones de información con un tema relacionado. Los KA, a su vez, se dividen en
temas. Este KA contiene los siguientes temas:

• Introducción a los fundamentos del sistema •

Tipos de sistemas • Complejidad • Emergencia
• Fundamentos para la ingeniería de sistemas
del futuro
Machine Translated by Google

Fundamentos de Sistemas 91

Introducción
La palabra sistema se usa en muchas áreas de la actividad humana y en muchos niveles. Pero, ¿qué quieren decir los investigadores y

profesionales de sistemas cuando usan la palabra sistema? ¿Hay alguna parte de ese significado común a todas las aplicaciones?

El siguiente diagrama resume las formas en que se explora esta pregunta en este KA.

Figura 1. Fundamentos del sistema y sistemas de ingeniería. (Original SEBoK)

Se exploran los conceptos de sistema abierto y sistema cerrado. Los sistemas abiertos, descritos por un conjunto de elementos y relaciones,

se utilizan para describir muchos fenómenos del mundo real. Los sistemas cerrados no tienen interacciones con su entorno. En este KA se

describen dos aspectos particulares de los sistemas, la complejidad y la emergencia. Entre ellos, estos dos conceptos representan muchos

de los desafíos que impulsan la necesidad de un pensamiento sistémico y una apreciación de la ciencia de sistemas en SE.

Se presentan algunas clasificaciones de sistemas, caracterizadas por tipo de elemento o por propósito.

Un sistema de ingeniería se define dentro del SEBoK como una combinación que abarca tecnología y personas en el contexto de entornos

naturales, sociales, comerciales, públicos o políticos, creado, utilizado y sostenido para un propósito identificado. La aplicación del enfoque

de sistemas aplicado a los sistemas de ingeniería requiere la capacidad de ubicar problemas u oportunidades en el sistema más amplio que

los contiene, crear o cambiar un sistema de interés de ingeniería específico y comprender y manejar las consecuencias de estos cambios en

sistemas más amplios apropiados.

El concepto de un contexto de sistema permite que todos los elementos del sistema y las relaciones necesarias para soportar esto sean
identificado.

Las discusiones sobre los contextos de los sistemas de ingeniería incluyen la idea general de grupos de sistemas para ayudar a lidiar con

situaciones en las que los elementos de un sistema de ingeniería son sistemas de ingeniería independientes. Para ayudar a proporcionar un

enfoque para las discusiones sobre cómo SE se aplica a los problemas del mundo real, se presentan cuatro contextos de sistemas de ingeniería.
introducido en el KA:
Machine Translated by Google

Fundamentos de Sistemas 92

1. contexto del sistema de

productos 2. contexto del sistema

de servicios 3. contexto del sistema

empresarial 4. contexto del sistema de sistemas (sos)

Los detalles de cómo SE se aplica a cada uno de estos contextos se describen en la Parte 4: Aplicaciones de Ingeniería de Sistemas.

Referencias

Trabajos citados
Ninguna.

Referencias primarias
Bertalanffy, L., von. 1968. Teoría general de sistemas: fundamentos, desarrollo, aplicaciones, rev. edición Nueva York, NY, Estados Unidos: Braziller.

Magee, CL, OL de Weck. 2004. "Clasificación de sistemas complejos". Actas del 14º Simposio Internacional Anual del Consejo Internacional sobre

Ingeniería de Sistemas, Toulouse, Francia, 20-24 de junio de 2004.

Rebovich, G. y BE White (eds.). 2011. Ingeniería de Sistemas Empresariales: Avances en la Teoría y la Práctica.

Boca Ratón, FL, EE. UU.: CRC Press.

Sheard, SA y A. Mostashari. 2009. “Principios de sistemas complejos para ingeniería de sistemas”. Ingeniería de Sistemas, vol. 12, núm. 4. págs.

295-311.

Tien, JM y D. Berg. 2003. "Un caso para la ingeniería de sistemas de servicio". Revista de Ciencias de Sistemas e Ingeniería de Sistemas, vol. 12, núm.

1, págs. 13-38.

Referencias adicionales
Ninguna.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021

Machine Translated by Google

Introducción a los fundamentos del sistema 93

Introducción a los fundamentos del sistema

Autor principal: Rick Adcock, autores colaboradores: Brian Wells, Scott Jackson, Janet Singer, Duane Hybertson

Este artículo forma parte del área de conocimiento de Fundamentos de Sistemas (KA). Proporciona varias perspectivas sobre los sistemas,
incluidas las definiciones, el alcance y el contexto.

Este artículo proporciona una guía de algunos de los conceptos básicos de sistemas desarrollados por la ciencia de sistemas y analiza
cómo estos se relacionan con las definiciones que se encuentran en la literatura de ingeniería de sistemas (SE). El concepto de un sistema
de ingeniería se introduce como el contexto del sistema de importancia crítica para SE.

Visión general

En System Fundamentals KA definiremos algunos términos e ideas que son fundamentales para la comprensión y práctica de la Ingeniería
de Sistemas (SE). En particular, se exploran varias vistas del sistema; estos son
se resumen a continuación y se describen con más detalle con enlaces a referencias relevantes en el resto de este artículo.

• Una definición simple de Sistema es cualquier conjunto de partes relacionadas para las cuales hay suficiente coherencia entre
las partes para que sea útil verlas como un todo. Si consideramos situaciones más complejas en las que las partes de un sistema
también pueden verse como sistemas, podemos identificar conceptos de sistemas comunes útiles para ayudar a nuestra comprensión.
Esto permite la creación de teorías de sistemas, modelos y enfoques útiles para cualquier persona que intente comprender, crear o
utilizar colecciones de cosas relacionadas, independientemente de lo que esté hecho el sistema o el dominio de la aplicación que lo
considere.
• Muchas de estas ideas de sistemas comunes se relacionan con redes complejas o jerarquías de elementos de sistemas relacionados.
Un contexto de sistema es un conjunto de interrelaciones de sistemas asociados con un sistema de interés (SoI) particular
dentro de un entorno del mundo real. Una o más vistas de un contexto nos permiten centrarnos en el SoI pero sin perder de vista
sus relaciones e influencias más amplias y holísticas. El contexto se puede utilizar para muchos tipos de sistemas, pero es
particularmente útil para determinar el alcance de los problemas y permitir la creación de soluciones que combinen personas y
tecnología y operen en el mundo natural. Estos se denominan contextos de sistemas sociotécnicos. • La Ingeniería de Sistemas es una
de las disciplinas interesadas en los sistemas sociotécnicos a lo largo de toda su vida. Esto incluye de dónde provienen los problemas y
cómo se definen, cómo identificamos y seleccionamos las soluciones candidatas, cómo equilibrar la tecnología y los elementos
humanos en el contexto más amplio de la solución, cómo administrar los sistemas organizacionales complejos necesarios para
desarrollar nuevas soluciones y cómo se desarrollaron las soluciones. son utilizados, mantenidos y eliminados. Para respaldar esto,
definimos un sistema de ingeniería como un sistema sociotécnico que es el foco de un ciclo de vida de ingeniería de sistemas.

• Si bien la SE se enfoca en la entrega de un sistema de ingeniería de interés, una SE debe considerar la totalidad
Contexto del sistema diseñado para que se pueda alcanzar la comprensión necesaria y se puedan tomar las decisiones
correctas de ingeniería de sistemas a lo largo de cada ciclo de vida.
Machine Translated by Google

Introducción a los fundamentos del sistema 94

Una vista general de los sistemas

La idea de un sistema completo se puede encontrar tanto en la filosofía occidental como en la oriental. Muchos filósofos han considerado las

nociones de holismo, el concepto de que las ideas, las personas o las cosas deben ser consideradas en relación con las cosas que las rodean

para ser plenamente comprendidas (M'Pherson 1974).

Una definición influyente de la ciencia de sistemas de un sistema proviene de la teoría general de sistemas (GST):

Un Sistema es un conjunto de elementos en interacción. (Bertalanffy 1968)

Las partes de un sistema pueden ser organizaciones conceptuales de ideas en forma simbólica u objetos reales. GST considera que los sistemas

abstractos contienen solo elementos conceptuales y los sistemas concretos que contienen al menos dos elementos que son objetos reales,

por ejemplo, personas, información, software y artefactos físicos, etc.

Se pueden encontrar ideas similares de totalidad en la literatura de ingeniería de sistemas. Por ejemplo:

Creemos que la esencia de un sistema es la 'unión', la unión de varias partes y las relaciones que forman para producir un nuevo

todo... (Boardman y Sauser 2008).

Las interacciones cohesivas entre un conjunto de partes sugieren un límite del sistema y definen lo que significa pertenecer al sistema. Para

sistemas cerrados, todos los aspectos del sistema existen dentro de este límite. Esta idea es útil para sistemas abstractos y para algunas

descripciones de sistemas teóricos.

El límite de un sistema abierto define elementos y relaciones que pueden considerarse parte del sistema y describe cómo estos elementos

interactúan a través del límite con elementos relacionados en el entorno. Las relaciones entre los elementos de un sistema abierto pueden

entenderse como una combinación de la estructura y el comportamiento de los sistemas. La estructura de un sistema describe un conjunto de

elementos del sistema y las relaciones permitidas entre ellos.

El comportamiento del sistema se refiere a los efectos o resultados producidos cuando una instancia del sistema interactúa con su entorno. Una

configuración permitida de las relaciones entre los elementos se denomina estado del sistema. Un sistema estable es aquel que vuelve a su

estado original, oa otro estado estable, después de una perturbación en el medio ambiente.

Las entidades de totalidades del sistema a menudo muestran emergencia, comportamiento que tiene sentido solo cuando se atribuye a la

totalidad, no a sus partes (Checkland 1999).

La identificación de un sistema y su límite es, en última instancia, la elección del observador. Esto puede ser a través de la observación y

clasificación de conjuntos de elementos como sistemas, a través de una conceptualización abstracta de uno o más límites y relaciones posibles

en una situación dada, o una combinación de este pensamiento concreto y conceptual. Esto subraya el hecho de que cualquier identificación

particular de un sistema es una construcción humana utilizada para ayudar a comprender mejor un conjunto de cosas y compartir esa comprensión

con otros si es necesario.

Muchas cosas naturales, sociales y hechas por el hombre se pueden entender mejor si se las ve como sistemas abiertos. Una de las razones por

las que encontramos útil la idea de los sistemas es que es posible identificar conceptos compartidos que se aplican a muchas vistas del sistema.

Estos conceptos recurrentes o isomorfias pueden brindar información útil sobre muchas situaciones, independientemente de los tipos de

elementos que componen un sistema en particular. Las ideas de estructura, comportamiento, emergencia y estado son ejemplos de tales

conceptos. La identificación de estas ideas de sistemas compartidas es la base para el pensamiento sistémico y su uso en el desarrollo de teorías

y enfoques en una amplia gama de campos de estudio, la base para las ciencias de sistemas.

La ingeniería de sistemas (SE) y otras disciplinas relacionadas utilizan conceptos, patrones y modelos de sistemas en la creación de resultados

o cosas útiles. El concepto de una red de sistemas abiertos creada, sostenida y utilizada para lograr un propósito dentro de uno o más entornos

es un modelo poderoso que se puede usar para comprender muchas situaciones complejas del mundo real y proporcionar una base para la

resolución efectiva de problemas dentro de ellas.

Machine Translated by Google

Introducción a los fundamentos del sistema 95

Contexto del sistema

Bertalanffy (1968) dividió los sistemas abiertos en nueve tipos del mundo real que van desde estructuras estáticas y mecanismos de control
hasta sistemas socioculturales. Otros sistemas de clasificación similares se discuten en el artículo Tipos de
Sistemas.

La siguiente es una clasificación simple de los elementos del sistema que encontramos en el corazón de muchos de estos
clasificaciones:

• Elementos, objetos o conceptos de sistemas naturales que existen fuera de cualquier control humano práctico. Ejemplos: el
sistema de números reales, el sistema solar, sistemas de circulación de la atmósfera planetaria.
• Elementos del sistema social, ya sean tipos humanos abstractos o construcciones sociales, o individuos o grupos sociales concretos. •
Elementos del Sistema Tecnológico, artefactos o construcciones hechos por el hombre; incluyendo hardware físico, software y
información.

Si bien las distinciones anteriores se pueden hacer como una clasificación abstracta general, en realidad no existen límites estrictos entre
estos tipos de sistemas: por ejemplo, los sistemas naturales son operados, desarrollados y, a menudo, contienen sistemas sociales, que
dependen de sistemas técnicos. para realizar plenamente su propósito. Los sistemas que contienen elementos técnicos y humanos o
naturales a menudo se denominan sistemas sociotécnicos. El comportamiento de tales sistemas está determinado tanto por la naturaleza
de los elementos técnicos como por su capacidad para integrarse o lidiar con la variabilidad de los sistemas naturales y sociales que los
rodean.

Muchas de las ideas originales en las que se basan GST y otras ramas del estudio de sistemas provienen del estudio de sistemas en las
ciencias naturales y sociales. Muchos sistemas naturales y sociales se forman inicialmente como estructuras simples a través de la cohesión
inherente entre un conjunto de elementos. Una vez formados, tenderán a permanecer en esta estructura, así como a combinarse y
evolucionar hacia estados estables más complejos para explotar esta cohesión con el fin de sostenerse frente a amenazas o presiones
ambientales. Dichos sistemas complejos pueden exhibir una especialización de elementos, con elementos que asumen roles que contribuyen
al propósito del sistema, pero pierden parte o la totalidad de su identidad separada fuera del sistema. Dichos roles pueden incluir la gestión
de recursos, defensa, autorregulación o resolución de problemas y control. Los sistemas naturales y sociales pueden entenderse a través
de la comprensión de esta totalidad, cohesión y especialización. También pueden ser guiados hacia el desarrollo de comportamientos que
no solo mejoran su supervivencia básica, sino que también cumplen otros objetivos de beneficio para ellos o los sistemas que los rodean.
En The Architecture of Complexity, Simon (1962) ha demostrado que los sistemas naturales o sociales que evolucionan a través de una
serie de "formas intermedias jerárquicas" estables serán más exitosos y resistentes al cambio ambiental.

Por lo tanto, a menudo es cierto que el entorno en el que se asienta un sistema en particular y los elementos de ese sistema pueden
considerarse como sistemas abiertos. Puede ser útil considerar colecciones de elementos relacionados como un sistema y como parte de
uno o más sistemas. Por ejemplo, Koestler definió un “holón” o elemento del sistema como algo que existe simultáneamente como un todo
y como una parte (Koestler 1967). En algún momento, la naturaleza de las relaciones entre los elementos dentro y fuera de los límites de
una jerarquía de sistemas puede conducir a estructuras complejas y comportamientos emergentes que son difíciles de comprender o
predecir. Tal complejidad a menudo se puede abordar mejor no solo buscando más detalles, sino también considerando las relaciones más
amplias del sistema abierto.
Machine Translated by Google

Introducción a los fundamentos del sistema 96

Figura 1: Descripción general del Contexto del Sistema (SEBoK Original)

Un contexto de sistema describe todos los elementos externos que interactúan a través de los límites de un sistema de interés particular (SoI) y una

visión suficiente de los elementos dentro de sus límites, para permitir que el SoI se entienda mejor como parte de un sistema más amplio. Para

comprender completamente el contexto, también debemos identificar el entorno en el que se encuentran el SoI y el sistema más amplio y los

sistemas del entorno que los influyen.

Muchos sistemas creados por el hombre están diseñados como redes y jerarquías de elementos de sistemas relacionados para lograr

comportamientos deseables y los tipos de resiliencia que se observan en los sistemas naturales. Si bien dichos sistemas pueden crearse

deliberadamente para aprovechar las propiedades del sistema, como el holismo y la estabilidad, también deben considerar los desafíos del sistema,

como la complejidad y la emergencia. Considerar diferentes puntos de vista de un SoI y su contexto a lo largo de su vida puede ayudar a habilitar

esta comprensión. Considerar los sistemas en contexto nos permite centrarnos en un SoI mientras mantenemos la necesaria perspectiva de

sistemas holísticos más amplia. Esta es una de las bases del Enfoque de Sistemas descrito en SEBoK parte 2, que forma la base de la ingeniería

de sistemas.

Ingeniería de Sistemas y Sistemas

Algunas de las ideas de sistemas discutidas anteriormente forman parte del cuerpo de conocimiento de la ingeniería de sistemas. La literatura, los

estándares y las guías de ingeniería de sistemas a menudo se refieren a "el sistema" para caracterizar un sistema sociotécnico con un propósito

definido como el enfoque de SE, p.

• “Un sistema es un objeto que entrega valor” (Dori 2002). • “Un

sistema es una matriz de componentes diseñados para lograr un objetivo particular de acuerdo con el plan” (Johnson,

Kast y Rosenzweig 1963).

• “Un sistema se define como un conjunto de conceptos y/o elementos utilizados para satisfacer una necesidad o requerimiento” (Miles 1973).

El Manual del Consejo Internacional de Ingeniería de Sistemas (INCOSE 2015) generaliza esta idea, definiendo sistema como “una combinación

de elementos que interactúan para lograr un objetivo definido. Estos incluyen hardware, software,
Machine Translated by Google

Introducción a los fundamentos del sistema 97

firmware, personas, información, técnicas, instalaciones, servicios y otros elementos de soporte". Si bien estas definiciones cubren los sistemas

sociotécnicos creados por SE, también es necesario considerar las situaciones de problemas naturales o sociales en las que se asientan estos sistemas,

el los sistemas sociales que los desarrollaron, sustentaron y utilizaron, y las empresas comerciales o públicas en las que todos estos se asientan como

sistemas (Martin 2004).

Por lo tanto, aunque muchos autores de SE hablan de sistemas e ideas de sistemas, a menudo se basan en una visión del mundo particular relacionada

con los artefactos de ingeniería. También sería útil tener una visión más amplia del contexto en el que se ubican estos artefactos y considerar las relaciones

a lo largo de la vida como parte de ese contexto. Para ayudar a promover esto, el SEBoK intentará ser más preciso con el uso de la palabra sistema y

distinguir entre los principios generales de los sistemas y los sistemas sociotécnicos específicos creados por SE.

El término sistema sociotécnico es utilizado por muchos en la comunidad de sistemas y puede tener significados distintos a los relevantes para SE. Por lo

tanto, definiremos un sistema de ingeniería como un sistema sociotécnico que forma el enfoque principal o sistema de interés (SoI) para una aplicación de

SE. Un ciclo de vida SE considerará un contexto de sistema de ingeniería, desde la formulación inicial del problema hasta la eliminación final segura del

uso (INCOSE 2015). A continuación se puede encontrar una discusión más detallada del contexto del sistema de ingeniería y cómo se relaciona con los

fundamentos de la práctica de la ingeniería de sistemas.

Introducción a los sistemas de ingeniería

Un sistema de ingeniería define un contexto que contiene tecnología y elementos sociales o naturales, desarrollado para un propósito definido por un ciclo

de vida de ingeniería.

Contextos del sistema de ingeniería:

• son creados, usados y sostenidos para lograr un propósito, meta o misión que es de interés para una empresa, equipo o
un individuo.

• requieren un compromiso de recursos para el desarrollo y apoyo. • son impulsados por

partes interesadas con múltiples puntos de vista sobre el uso o la creación del sistema, o con algún otro interés en

el sistema, sus propiedades o existencia. •

contener hardware, software, personas, servicios o una combinación de estos. • existen dentro de un ambiente

que impacta las características, el uso, el sostenimiento y la creación del sistema.

Los sistemas de ingeniería típicamente:

• se definen por su propósito, meta o misión. • tener un ciclo de

vida y una dinámica de evolución.

•
puede incluir operadores humanos (que interactúan con los sistemas a través de procesos), así como otros componentes sociales y naturales

que deben tenerse en cuenta en el diseño y desarrollo del sistema. • son parte de una jerarquía de sistema de interés.

Los sistemas abiertos son una forma útil de entender muchas situaciones complejas. Las disciplinas de ingeniería tradicionales se han vuelto muy buenas

en la construcción de modelos detallados y prácticas de diseño para lidiar con la complejidad de colecciones de elementos estrechamente integradas

dentro de un dominio tecnológico. Es posible modelar la integración aparentemente aleatoria de muchos elementos similares utilizando enfoques

estadísticos. La ingeniería de sistemas hace uso de estos dos aspectos de la complejidad del sistema, como se explica en el artículo Complejidad.

SE también considera la complejidad de un número relativamente pequeño de elementos tomados de una variedad de disciplinas de diseño junto con

personas que no siempre pueden tener experiencia o capacitación detallada en su uso. Dichos sistemas de ingeniería pueden implementarse en entornos

inciertos o cambiantes y usarse para ayudar a las personas a lograr una serie de resultados vagamente definidos. Los cambios relativamente pequeños en

el funcionamiento interno de los elementos de estos sistemas de ingeniería, o en cómo se combinan esos elementos, pueden conducir a la aparición de

resultados complejos o inesperados. Puede ser difícil predecir y diseñar todos estos resultados durante la creación de un sistema de ingeniería, o responder

a ellos durante su uso. Se necesitan enfoques iterativos del ciclo de vida que exploren la complejidad y la emergencia a lo largo de una serie de ciclos de

desarrollo y uso para abordar este aspecto de la complejidad. Las formas en que la ingeniería de sistemas trata
Machine Translated by Google

Introducción a los fundamentos del sistema 98

con estos aspectos de complejidad en la definición de ciclo de vida y procesos de ciclo de vida aplicados a una ingeniería
el contexto del sistema se explora completamente en la Parte 3

Definiciones de ciclo de vida

Además de ser un tipo de sistema, un sistema de ingeniería también es el foco de un ciclo de vida y, por lo tanto, parte de un
transacción comercial. Históricamente,

Los economistas dividen toda la actividad económica en dos grandes categorías, bienes y servicios.
Las industrias productoras de bienes son la agricultura, la minería, la manufactura y la construcción; cada uno de ellos
crea algún tipo de objeto tangible. Las industrias de servicios incluyen todo lo demás: banca,
comunicaciones, comercio al por mayor y al por menor, todos los servicios profesionales como ingeniería, informática
desarrollo de software y medicina, actividad económica sin fines de lucro, todos los servicios al consumidor y todos
servicios gubernamentales, incluida la defensa y la administración de justicia.... (Enciclopedia Británica 2011).

El siguiente diagrama define algunos términos relacionados con el ciclo de vida de un sistema de ingeniería y el desarrollo de bienes.
(productos y servicios.

Figura 2: Terminología del ciclo de vida (modificado de Capability Engineering: an Analysis of Perspectives) (modificado de (Henshaw et al, 2011), utilizado
con permiso))

En la figura anterior, la capacidad necesaria para permitir que una empresa logre sus objetivos se proporciona mediante el uso
sincronizado de los servicios. Esos servicios son proporcionados por un sistema de servicio, que es creado, sostenido y desplegado
por una o más organizaciones. Un sistema de servicio está compuesto por personas, tecnología, información y acceso a servicios
relacionados y otros recursos necesarios. Algunos de estos recursos son proporcionados por servicios habilitadores y los elementos
tecnológicos pueden desarrollarse y suministrarse como sistemas de productos. Un sistema empresarial describe una colección de
capacidades relacionadas y servicios asociados que juntos permiten el logro del propósito general de una empresa como entidad
gubernamental, comercial o social. La medición y revisión de los objetivos de la empresa pueden definir las necesidades de cambio
Machine Translated by Google

Introducción a los fundamentos del sistema 99

que requieren que una organización adquiera o modifique e integre los elementos necesarios para evolucionar sus sistemas de servicio.

La terminología general anterior se describe brevemente en las definiciones del glosario asociado y se amplía en las definiciones relacionadas.

artículos de la Parte 4: Aplicaciones de la Ingeniería de Sistemas.

Contexto del sistema diseñado

Los sistemas de ingeniería se desarrollan como combinaciones de productos y servicios dentro de un ciclo de vida. La figura de abajo

da una visión general del contexto completo para cualquier aplicación potencial de un ciclo de vida SE.

Figura 3: Contexto del sistema de ingeniería general (SEBoK original)

Desde este punto de vista, un sistema de servicio relacionado directamente con una necesidad de capacidad establece el límite general. Esta necesidad establece la

situación problemática u oportunidad que encapsula el punto de partida de cualquier ciclo de vida. Dentro de este sistema de servicio

son los servicios relacionados, los productos y las personas (o agentes de software inteligente) necesarios para brindar una solución completa a ese

necesitar. El medio ambiente incluye a cualquier persona, organización, regla o condición que influya o restrinja el

sistema de servicio o las cosas dentro de él. El SoI para un ciclo de vida SE particular puede definirse en cualquier nivel de este

contexto general. Si bien el enfoque del contexto variará para cada ciclo de vida, es importante que alguna versión de este

Se considera el contexto general para todos los ciclos de vida de SE, para ayudar a mantener una visión holística del problema y la solución. Esto es

discutido en Tipos de sistemas.

Un contexto de sistema diseñado describe el contexto de un SoI para que se pueda alcanzar la comprensión necesaria y se puedan tomar las decisiones correctas

de ingeniería de sistemas a lo largo de la vida de ese SoI. Esto requerirá una serie de puntos de vista diferentes del contexto a lo largo de un ciclo de vida de SE,

tanto para identificar toda influencia externa en el SoI como para guiar y restringir la ingeniería de sistemas de los elementos del SoI. Un contexto completo de

sistemas de ingeniería incluirá la situación del problema a partir de la cual se identifica la necesidad de un SoI, una o más soluciones sociotécnicas, las organizaciones

necesarias para crear y mantener nuevas soluciones y el entorno operativo dentro del cual esas soluciones deben integrarse, usarse y eventualmente eliminado. Los

tipos de vistas que se pueden usar para representar un contexto SoI sobre su
Machine Translated by Google

Introducción a los fundamentos del sistema 100

La vida y cómo esos puntos de vista se pueden combinar en modelos se analiza en Representación de sistemas con modelos KA en la Parte
2. Las actividades que usan esos modelos se describen conceptualmente en el Enfoque de sistemas aplicado a los sistemas de ingeniería
KA en la parte 2 y se relacionan con SE más formal. procesos del ciclo de vida en la Parte 3.

Referencias

Trabajos citados

Bertalanffy, L. von. 1968. Teoría general de sistemas: fundamentos, desarrollo, aplicaciones, rev. edición Nueva York:
brasileño.

Boardman, J. y B. Sauser. 2008. Pensamiento sistémico: Cómo hacer frente a los problemas del siglo XXI. Boca Ratón, Florida, EE. UU.:

Taylor & Francis.

Checkland, P. 1999. Pensamiento sistémico, práctica de sistemas. Nueva York, NY, EE. UU.: Wiley and Sons, Inc.

Dori, D. 2002. Metodología Objeto-Proceso – Un Paradigma de Sistemas Holísticos. Nueva York, NY, Estados Unidos: Springer.

Henshaw, M., D. Kemp, P. Lister, A. Daw, A. Harding, A. Farncombe y M. Touchin. 2011. "Ingeniería de capacidades: un análisis de
perspectivas". Presentado en el 21° Simposio Internacional del Consejo Internacional de Ingeniería de Sistemas (INCOSE), Denver, CO, EE.
UU., del 20 al 23 de junio de 2011.

Hitchins, D. 2009. “¿Cuáles son los principios generales aplicables a los sistemas?” Insight de INCOSE , vol. 12, núm. 4, págs. 59-63.

INCOSE. 2015. Manual de ingeniería de sistemas: una guía para los procesos y actividades del ciclo de vida del sistema, versión 4.0. San

Diego, CA, EE. UU.: Consejo Internacional de Ingeniería de Sistemas (INCOSE), INCOSE-TP-2003-002-03.2.2.

Johnson, RA, FW Kast y JE Rosenzweig. 1963. La Teoría y Gestión de Sistemas. Nueva York, NY, EE. UU.: McGraw-Hill Book Company.

Koestler, A. 1990. The Ghost in the Machine, edición reimpresa de 1990. Sturgis, Michigan, Estados Unidos: Penguin Group.

Martin, J, 2004. "Los siete samuráis de la ingeniería de sistemas: Tratando con la complejidad de 7 sistemas interrelacionados".
Actas del 14º Simposio Internacional Anual del Consejo Internacional sobre Ingeniería de Sistemas, 20-24 de junio de 2004, Toulouse,
Francia, 20-24 de junio de 2004.

Millas, RF (ed). 1973. Conceptos de sistema. Nueva York, NY, EE. UU.: Wiley and Sons, Inc.

M'Pherson, PK 1974. "Una perspectiva sobre la ciencia de sistemas y la filosofía de sistemas". Futuros. vol. 6, núm. 3, págs.
219-39.

Simon, HA 1962. "La arquitectura de la complejidad". Actas de la Sociedad Filosófica Americana. vol. 106, núm. 6 (12 de diciembre de 1962),
págs. 467-482.

Referencias primarias
Bertalanffy, L., von. 1968. Teoría general de sistemas: fundamentos, desarrollo, aplicaciones, rev. edición Nueva York, NY, Estados Unidos:
Braziller.

INCOSE. 2015. Manual de ingeniería de sistemas: una guía para los procesos y actividades del ciclo de vida del sistema, versión 4.0. San

Diego, CA, EE. UU.: Consejo Internacional de Ingeniería de Sistemas (INCOSE), INCOSE-TP-2003-002-03.2.2.

Referencias adicionales

Hybertson, Duane. 2009. Ciencia de ingeniería de sistemas orientada a modelos: un marco unificador para sistemas tradicionales y
complejos. Boca Ratón, FL, EE. UU.: CRC Press.

Hubka, Vladimir y WE Eder. 1988. Teoría de los sistemas técnicos: una teoría del concepto total para el diseño de ingeniería. Berlín: Springer-

Verlag.
Machine Translated by Google

Introducción a los fundamentos del sistema 101

Laszlo, E., ed. 1972. La relevancia de la teoría general de sistemas: artículos presentados a Ludwig von Bertalanffy en su septuagésimo

cumpleaños. Nueva York, NY, Estados Unidos: George Brazillier.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021

Tipos de Sistemas
Autor principal: Rick Adcock, autores colaboradores: Brian Wells, Scott Jackson

Este artículo forma parte del área de conocimiento de Fundamentos de Sistemas (KA). Proporciona varias perspectivas sobre clasificaciones de

sistemas y tipos de sistemas, ampliadas a partir de las definiciones presentadas en ¿Qué es un sistema?.

El mundo moderno tiene numerosos tipos de sistemas que influyen en la vida diaria. Algunos ejemplos incluyen sistemas de transporte; sistemas

solares; sistemas telefónicos; el Sistema Decimal Dewey; sistemas de armas; sistemas ecológicos; sistemas espaciales; etc. De hecho, parece

que casi no hay fin al uso de la palabra "sistema" en la sociedad actual.

Este artículo considera los diferentes sistemas de clasificación que algunos autores de ciencia de sistemas han propuesto en un intento por

extraer algunos principios generales de estas múltiples ocurrencias. Estos esquemas de clasificación analizan los tipos de elementos de los que

se compone el sistema o su razón de ser.

La idea de un sistema de ingeniería se amplía. En la ingeniería de sistemas se reconocen generalmente cuatro tipos específicos de contexto de

sistemas de ingeniería: sistema de productos, sistema de servicios, sistema empresarial y sistema de sistemas.

Clasificación del sistema

Una taxonomía es "una clasificación en categorías ordenadas" (Dictionary.com 2011). Las taxonomías son formas útiles de organizar un gran

número de elementos individuales para que sus similitudes y diferencias sean evidentes. No existe una taxonomía de sistemas estándar única,

aunque se han realizado varios intentos para producir una taxonomía de clasificación útil, p.

(Bertalanffy 1968) y (Miller 1986).

Kenneth Boulding (Boulding 1956), uno de los padres fundadores de la teoría general de sistemas, desarrolló una clasificación de sistemas que

ha sido el punto de partida de gran parte del trabajo posterior. Clasifica los sistemas en nueve

tipos:

1. Estructuras (Puentes)

2. El reloj funciona (Sistema solar)

3. Controles (Termostato)

4. Abierto (Células biológicas)

5. Organismos inferiores (Plantas)

6. Animales (Pájaros)

7. Hombre (Humanos)

8. Social (Familias)

9. Trascendental (Dios)

Estos enfoques también destacan algunos de los problemas posteriores con este tipo de clasificación. El boulding implica que las estructuras

físicas son cerradas y naturales mientras que las sociales están abiertas. Sin embargo, un puente solo puede entenderse considerando cómo

reacciona al tráfico que lo cruza, y debe mantenerse o repararse a lo largo del tiempo (Hitchins 2007).

Boulding también separa a los humanos de los animales, lo que no encajaría en el pensamiento más moderno.

Peter Checkland (Checkland 1999, 111) divide los sistemas en cinco clases: sistemas naturales, sistemas físicos diseñados, sistemas abstractos

diseñados, sistemas de actividad humana y sistemas trascendentales. Las dos primeras clases se explican por sí mismas.
Machine Translated by Google

Tipos de Sistemas 102

• Sistemas abstractos diseñados : estos sistemas no contienen ningún artefacto físico, pero están diseñados por humanos para

servir a algún propósito explicativo.

• Sistemas de actividad humana : estos sistemas son observables en el mundo de innumerables conjuntos de actividades humanas que

están ordenados más o menos conscientemente en totalidades como resultado de algún propósito o misión subyacente. En un extremo

hay un sistema que consiste en un ser humano empuñando un martillo. En el otro extremo se encuentra la política internacional

sistemas

• Sistemas trascendentales : estos son sistemas que van más allá de las cuatro clases de sistemas mencionadas anteriormente, y son

considerados como sistemas más allá del conocimiento.

Checkland se refiere a estos cinco sistemas como un "mapa de sistemas del universo". Se pueden encontrar otras categorizaciones similares de

tipos de sistemas en (Aslaksen 1996), (Blanchard 2005) y (Giachetti 2009).

Magee y de Weck (Magee y de Weck 2004) brindan una descripción completa de las fuentes sobre clasificación de sistemas, como (Maier y

Rechtin 2009), (Paul 1998) y (Wasson 2006). Cubren algunos métodos para clasificar los sistemas naturales, pero su principal énfasis y valor para

la práctica de la ingeniería de sistemas está en su método de clasificación para sistemas diseñados o hechos por el hombre. Examinan muchos

métodos posibles que incluyen: grado de complejidad, rama de la economía que produjo el sistema, ámbito de existencia (física o mental), límite,

origen, dependencia del tiempo, estados del sistema, participación humana/control del sistema, deseos humanos, propiedad y tipo funcional.

Concluyen proponiendo un método de clasificación funcional que clasifica los sistemas por su proceso (transformar, transportar, almacenar,

intercambiar o controlar) y por la entidad sobre la que operan (materia, energía, información y valor).

Tipos de sistemas de ingeniería

La siguiente figura es una vista general del contexto para cualquier aplicación potencial del ciclo de vida de un sistema diseñado.

Figura 1: Tipos generales de Sistema de Ingeniería de Interés (SoI) (SEBoK original)

Machine Translated by Google

Tipos de Sistemas 103

La Figura 1 muestra cuatro casos generales de sistema de interés (SoI) que podrían ser el foco de un ciclo de vida.

• Un sistema de producto SoI centrado en la tecnología incorporado dentro de uno o más productos integrados, • Un

sistema de producto SoI integrado de múltiples tecnologías que se usa directamente para ayudar a proporcionar un

servicio, • Un sistema de servicio habilitador SoI que soporta múltiples sistemas de servicio • Un sistema de servicio

SoI creado y sostenido para entregar directamente la capacidad.

Productos y sistemas de productos

La palabra producto se define como "una cosa producida por trabajo o esfuerzo; o cualquier cosa producida" (Oxford English Dictionary). En un

sentido comercial, un producto es cualquier cosa que una organización adquiere, posee y mantiene y utiliza una empresa (hardware, software,

información, personal, etc.).

Un sistema de productos es un sistema de ingeniería en el que el enfoque del ciclo de vida es desarrollar y entregar productos a un adquirente

para uso interno o externo para respaldar directamente la entrega de servicios que necesita ese adquirente.

Un contexto de ciclo de vida de sistemas de productos describirá un SoI centrado en la tecnología más los productos, personas y servicios

relacionados con los que se requiere que interactúe el SoI. Tenga en cuenta que las personas asociadas con un sistema de producto durante su

vida útil (por ejemplo, operadores, mantenedores, productores, etc.) se sientan fuera del SoI del producto, ya que no se entregan como parte del

producto. Sin embargo, para desarrollar un producto exitoso, es esencial comprender completamente sus interfaces e influencias humanas como

parte de su contexto. El contexto del producto también definirá los sistemas de servicio dentro de los cuales se implementará para ayudar a

proporcionar la capacidad necesaria a la empresa adquirente.

En el ciclo de vida de un producto, este contexto más amplio define las relaciones fijas y acordadas dentro de las cuales debe operar el SoI y las

influencias ambientales dentro de las cuales se debe entregar el ciclo de vida. Esto le da al desarrollador del producto la libertad de elegir

soluciones dentro de ese contexto y garantizar que estas opciones encajen y no interrumpan el contexto más amplio.

Es posible que el ciclo de vida de un producto deba recomendar cambios en los servicios habilitadores, como el reclutamiento y la capacitación

de personas u otras actualizaciones de infraestructura. Los mecanismos apropiados para la implementación de estos cambios deben ser parte

del acuerdo entre el adquirente y el proveedor y estar integrados en el ciclo de vida del producto. El ciclo de vida de un producto también puede

sugerir cambios en el contexto más amplio que mejorarían la propiedad o el uso del producto, pero esos cambios deben negociarse y acordarse

con los propietarios relevantes de los sistemas con los que se relacionan antes de que puedan agregarse a los resultados del ciclo de vida. .

Se puede encontrar una discusión más detallada de la teoría de sistemas asociada con los sistemas de productos en Historia de la ciencia de

sistemas y una expansión de la aplicación de la ingeniería de sistemas a los sistemas de servicio en Ingeniería de sistemas de productos KA en

la Parte 4.

Servicios y Sistemas de Servicio

Un servicio puede definirse simplemente como un acto de ayuda o asistencia, o como cualquier resultado requerido por uno o más usuarios que

puede definirse en términos de resultados y calidad del servicio sin detallar cómo se proporciona (por ejemplo, transporte, comunicaciones,

protección, tratamiento de datos, etc.). Los servicios son procesos, actuaciones o experiencias que una persona u organización realiza en

beneficio de otra, como la confección de un traje a la medida; cocinar una cena por encargo; conducir una limusina; montar una defensa legal;

arreglar un hueso roto; dar una clase; o ejecutar la infraestructura y las aplicaciones de tecnología de la información de una empresa. En todos

los casos, el servicio implica el despliegue de conocimientos y habilidades (competencias) que una persona u organización tiene en beneficio de

otra (Lusch y Vargo 2006), a menudo realizado como un trabajo único y personalizado. Para tener éxito, el servicio requiere aportes sustanciales

del cliente y de las partes interesadas relacionadas, lo que a menudo se denomina creación conjunta de valor (Sampson 2001). Por ejemplo,

¿cómo se puede personalizar un bistec a menos que el cliente le diga al mesero cómo quiere que se prepare el bistec?

Un sistema de servicio (glosario) es un sistema de ingeniería creado y sostenido por una organización que proporciona resultados para los

clientes dentro de una empresa. Un contexto de sistema de servicio contiene los mismos tipos de elementos de sistema que un producto
Machine Translated by Google

Tipos de Sistemas 104

contexto del sistema, pero permite una mayor libertad de lo que se puede crear o cambiar para entregar el servicio requerido.

El ciclo de vida de un sistema de servicio puede generar cambios en la forma en que se implementan y utilizan los productos existentes y otros servicios.

También puede identificar la necesidad de modificar productos existentes o crear nuevos productos, en cuyo caso puede iniciar un ciclo de vida del

producto relacionado. En la mayoría de los casos, el desarrollador del servicio no tendrá total libertad para cambiar todos los aspectos del contexto del

sistema del servicio sin alguna negociación con los propietarios de los elementos del sistema relacionados. En particular, las personas y la infraestructura

son parte del contexto del servicio y los cambios en la forma en que se utilizan los elementos del sistema para proporcionar los resultados deseados son

parte del alcance del ciclo de vida del servicio.

La descripción anterior del contexto del sistema de productos podría verse como un caso especial de un contexto de sistema de servicios en el que una

organización crea e integra un producto específico en un sistema de servicio fijo y lo utiliza una empresa directamente relacionada con la organización

para proporcionar una capacidad. .

En un contexto de sistema de servicio general, no es necesario entregar todos los productos de hardware o software al proveedor de servicios. En

algunos casos, algunos de los elementos de hardware, software o humanos pueden ser propiedad de un tercero que no es responsable del servicio

directamente pero proporciona resultados habilitadores para una serie de dichos servicios. En otros casos, todo el servicio puede ser proporcionado por

una organización completamente separada de la empresa que necesita el servicio. Tampoco es necesario definir e integrar las versiones exactas de los

productos o servicios habilitados antes de la prestación del servicio. Algunos elementos del sistema de servicio se pueden seleccionar e integrar más

cerca del punto de uso. Para permitir esta configuración tardía de un sistema de servicio, contendrá algún método de descubrimiento mediante el cual

se pueden encontrar los elementos disponibles apropiados y un elemento de gestión de servicio general para implementar y dirigir cada instancia del

sistema de servicio. El uso de un enfoque de sistema de servicio brinda mayor libertad a los adquirentes en la forma en que obtienen y respaldan todos

los equipos de capital, software, personas, etc. para obtener las capacidades necesarias para satisfacer

usuarios

Los servicios han sido parte del lenguaje de la ingeniería de sistemas (SE) durante muchos años, ya sea como una forma de describir el contexto de un

ciclo de vida centrado en el producto o para describir acuerdos comerciales para la 'tercerización' de la propiedad y operación del producto a otros. El

uso del término sistema de servicio en tiempos más recientes a menudo se asocia con sistemas configurables por software e intensivos en información,

es decir,

...características únicas que caracterizan los servicios , es decir, los servicios, especialmente los servicios emergentes, se basan en la

información, se centran en el cliente, se orientan electrónicamente y se centran en la productividad. (Tien y Berg 2003, 13)

Se puede encontrar una discusión más detallada de la teoría de sistemas asociada con los sistemas de servicio en History of Systems Science y una

expansión de la aplicación de la ingeniería de sistemas a los sistemas de servicio en Service Systems Engineering KA en la Parte 4.

Empresas y Sistemas Empresariales

Una empresa es una o más organizaciones o individuos que comparten una misión, metas y objetivos definidos para ofrecer un resultado, como un

producto o servicio.

Un sistema empresarial consta de una combinación intencionada (red) de recursos interdependientes (p. ej., personas, procesos, organizaciones,

tecnologías de apoyo y financiación) que interactúan entre sí (p. ej., para coordinar funciones, compartir información, asignar financiación, crear flujos de

trabajo, etc.). y tomar decisiones) y su(s) entorno(s), para lograr objetivos comerciales y operativos a través de una compleja red de interacciones

distribuidas a lo largo de la geografía y el tiempo (Rebovich y White 2011).

Tanto los sistemas de productos como los de servicios requieren un sistema empresarial para crearlos y una empresa para usar el sistema de productos

para brindar servicios, ya sea internamente a la empresa o externamente a una comunidad más amplia.

Los sistemas empresariales son únicos, en comparación con los sistemas de productos y servicios, en el sentido de que están en constante evolución;

rara vez tienen requisitos detallados de configuración controlada; por lo general, tienen el objetivo de proporcionar valor para los accionistas y satisfacción

del cliente, que cambian constantemente y son difíciles de verificar; y existen en un contexto (o entorno) mal definido y en constante cambio.
Machine Translated by Google

Tipos de Sistemas 105

Si bien un sistema empresarial no se puede describir usando el contexto general del sistema anterior, una empresa puede desear crear un

modelo de las capacidades y servicios que necesita para lograr su estrategia y objetivos. Tal modelo puede extenderse para describir una línea

de base de los contextos del sistema de servicios y del sistema de productos relacionados con sus capacidades actuales y con las capacidades

futuras propuestas. Estas se denominan arquitecturas empresariales o arquitecturas de referencia empresarial.

Se puede encontrar una discusión más detallada de la teoría de sistemas asociada con los sistemas de servicio en History of Systems Science

y una expansión de la aplicación de la ingeniería de sistemas a los sistemas de servicio en Enterprise Systems Engineering KA en la Parte 4.

La noción de empresas y sistemas empresariales también impregna la Parte 5 Habilitación de Ingeniería de Sistemas.

Sistemas de Sistemas
Un producto, servicio o contexto empresarial se puede definir como una jerarquía de elementos del sistema, con la definición adicional de qué

elementos son parte de una solución SoI, que forman el contexto del problema relacionado y que influyen en cualquier ciclo de vida asociado

con ese contexto.

Los conceptos adicionales de Sistemas de Sistemas (SoS) o Federaciones de Sistemas (FoS) se utilizan para algunos contextos. En términos

de la descripción general de la Figura 1 anterior, esto se aplicaría a cualquier contexto de ciclo de vida en el que los elementos dentro del SoI

tengan relaciones de ciclo de vida independientes. Este concepto podría aplicarse a cualquiera de los contextos de ciclo de vida anteriores,

aunque es de particular relevancia para los contextos de servicios y empresas.

Es importante comprender que el término SoS es una adición al concepto general de jerarquía del sistema que se aplica a todos los sistemas.

Maier examinó el significado de Sistema de Sistemas en detalle y utilizó un enfoque de caracterización que enfatiza la naturaleza independiente

de los elementos del sistema (Maier 1998, 268). Maier describe tanto la independencia en cómo opera un elemento del sistema (p. ej., un

elemento en el SoI también tiene su propia misión separada o es parte de otro SoI) como en cómo se desarrolla o sostiene un elemento (p. ej.,

un elemento se pone a disposición, se modifica o se configura por una organización diferente a la responsable del resto del SoI).

Hay ventajas en poder compartir elementos en varios sistemas de ingeniería y en poder crear rápidamente soluciones a los problemas

mediante la combinación de sistemas de ingeniería existentes. A medida que la tecnología para permitir la integración de sistemas

independientes se vuelve más común, este enfoque de SoS se convierte en un aspecto común de muchos ciclos de vida de SE.

Siempre que los elementos del sistema en un contexto de sistema de ingeniería tengan algún grado de independencia del ciclo de vida del

SoI, esto agrega una complejidad adicional; específicamente, restringiendo cómo se puede cambiar o controlar el sistema de ingeniería

resultante. Esta dimensión de complejidad afecta los aspectos de gestión y control del enfoque de sistemas.

Se puede encontrar una discusión más detallada de las diferentes taxonomías de agrupación de sistemas desarrolladas por la ciencia de

sistemas en la Parte 4 Aplicaciones de Ingeniería de Sistemas y una expansión de las formas en que tratamos con la complejidad de SoS se

puede encontrar en los Sistemas de Sistemas KA en la Parte 4.

Aplicación de contextos de sistemas de ingeniería

De las discusiones anteriores sobre los contextos de productos y servicios, debe quedar claro que requieren una comprensión de sistemas

similares para tener éxito y que la diferencia entre ellos es más sobre el alcance de las opciones del ciclo de vida y la autoridad para hacer

cambios que sobre qué tipos de sistemas. están.

Estos contextos se presentan aquí como generalizaciones del enfoque de ingeniería de sistemas. Todos los proyectos reales pueden tener

dimensiones de sistema de producto y servicio. En esta visión general de los sistemas de ingeniería, siempre hay un sistema empresarial

directamente interesado en el contexto del sistema de servicio y que posee y opera directamente cualquier sistema de producto y habilita los

servicios u obtiene acceso a ellos según sea necesario. Este sistema empresarial puede estar involucrado explícitamente en el inicio y la

gestión del ciclo de vida de un sistema de ingeniería o puede estar implícito en la propiedad compartida de una situación problemática.

Cualquier contexto de sistema diseñado puede tener aspectos de la independencia de SoS discutidos anteriormente. Esto puede ser parte del

contexto en el sistema o entorno más amplio o puede estar relacionado con la elección de elementos dentro
Machine Translated by Google

Tipos de Sistemas 106

el SoI.

Un ciclo de vida real de SE generalmente combina diferentes aspectos de estos contextos generales en un contexto único de problema y solución

y relaciones comerciales asociadas de adquirente y proveedor. Estos deben ser identificados por ese ciclo de vida como parte de sus actividades

de SE. En la parte 2 se brindan más detalles de estos diferentes contextos del ciclo de vida y en la parte 4 se amplían sus aplicaciones a la práctica

de SE.

Ring (1998) da un buen ejemplo de una descripción general de lo anterior, quien define el contexto general como el Sistema de Supresión de

Problemas, describe un ciclo mediante el cual una empresa explorará sus necesidades actuales, las utiliza para identificar una o más necesidades

de vida. intervenciones de ciclo y organizaciones relevantes, luego conducir y entregar esos ciclos de vida e integrar sus resultados en el PSS; la

empresa puede entonces revisar los resultados en el entorno y comenzar el ciclo nuevamente.

Este enfoque general de sistemas se describe en la parte 2 y se utiliza como enfoque para identificar áreas de conocimiento fundamental.

Las prácticas actuales de SE descritas en el resto del SEBoK hacen referencia a estos fundamentos según corresponda.

Referencias

Trabajos citados

Aslaksen, EW 1996. La naturaleza cambiante de la ingeniería. Nueva York, NY, EE. UU.: McGraw-Hill.

Bertalanffy, L. von. 1968. Teoría General de Sistemas. Nueva York, NY, Estados Unidos: Brazillier.

Blanchard, BS y WJ Fabrycky. 2005. Ingeniería y Análisis de Sistemas, 4ª ed. Serie Internacional Prentice-Hall en Ingeniería Industrial y de

Sistemas. Englewood Cliffs, Nueva Jersey, EE. UU.: Prentice-Hall.

Boulding, K. 1956. “Teoría general de sistemas: El esqueleto de la ciencia” Management Science, vol. 2, núm. 3, abril, págs. 197-208, 1956;

reimpreso en General Systems, Yearbook of the Society for General Systems Research, vol. 1, 1956.

Checkland, PB 1999. Pensamiento de sistemas, práctica de sistemas. Chichester, Reino Unido: John Wiley & Sons Ltd.

Dictionary.com, sv "Taxonomía". Consultado el 3 de diciembre de 2014. Disponible en: http://diccionario. referencia. com/navegar/taxonomía.

Enciclopedia Britannica, sv "Industria de servicios". Consultado el 3 de diciembre de 2014. Disponible en: http://www.britannica. com/EBchecked/

topic/535980/service-industry.

DeRosa, JK 2005. “Ingeniería de sistemas empresariales”. Asociación de la Fuerza Aérea, Día de la Industria, Día 1, 4 de agosto de 2005,
Danvers, MA, Estados Unidos.

Giachetti, RE 2009. Diseño de Sistemas Empresariales: Teoría, Arquitecturas y Métodos. Boca Ratón, Florida, EE. UU.:
Prensa CRC.

Hitchins, D. 2007. Ingeniería de sistemas: una metodología de sistemas del siglo XXI. Hoboken, Nueva Jersey, Estados Unidos: Wiley.

Lusch, RF y SL Vargo (Eds.). 2006. La lógica de marketing de servicio dominante: diálogo, debate y direcciones. Armonk, Nueva York, EE. UU.:

ME Sharpe Inc.

Magee, CL y OL de Weck. 2004. "Clasificación de sistemas complejos". Actas del 14º Simposio Internacional Anual del Consejo Internacional de

Ingeniería de Sistemas, Toulouse, Francia, 20-24 de junio de 2004.

Maier, MW 1998. "Principios de arquitectura para sistemas de sistemas". Ingeniería de Sistemas, vol. 1, no. 4, págs. 267-84.

Maier, M. y E. Rechtin. 2009. El arte de la arquitectura de sistemas, 3.ª ed. Boca Ratón, FL, EE. UU.: CRC Press.

Miller JG 1986. "¿Puede la teoría de sistemas generar hipótesis comprobables?: De Talcott Parsons a la teoría de los sistemas vivos" Systems

Research, vol. 3, págs. 73-84.

Paul, AS 1998. "Sistemas de clasificación". Actas del 8º Simposio Internacional Anual del Consejo Internacional sobre Ingeniería de Sistemas,

Vancouver, BC, Canadá, 26-30 de julio de 1998.

Machine Translated by Google

Tipos de Sistemas 107

Rebovich, G. y BE White (eds.). 2011. Ingeniería de Sistemas Empresariales: Avances en la Teoría y la Práctica.
Boca Ratón, FL, EE. UU.: CRC Press.

Ring, J., 1998. "Un enfoque de búsqueda de valor para la ingeniería de sistemas". Actas de la Conferencia IEEE sobre Sistemas, Hombre y

Cibernética. pags. 2704-2708.

Sampson, SE 2001. Comprender las empresas de servicios. Nueva York, NY, Estados Unidos: John Wiley.

Tien, JM y D. Berg. 2003. "Un caso para la ingeniería de sistemas de servicio". Revista de Ciencias de Sistemas e Ingeniería de Sistemas, vol.

12, núm. 1, págs. 13-38.

Wasson, CS 2006. Análisis, diseño y desarrollo de sistemas. Hoboken, NJ, EE. UU.: John Wiley and Sons.

Referencias primarias
Checkland, PB 1999. Pensamiento de sistemas, práctica de sistemas. Chichester, Reino Unido: John Wiley & Sons.

Magee, CL, OL de Weck. 2004. "Clasificación de sistemas complejos". Actas del 14º Simposio Internacional Anual del Consejo Internacional

sobre Ingeniería de Sistemas, Toulouse, Francia, 20-24 de junio de 2004.

Rebovich, G. y BE White (eds.). 2011. Ingeniería de Sistemas Empresariales: Avances en la Teoría y la Práctica.
Boca Ratón, FL, EE. UU.: CRC Press.

Tien, JM y D. Berg. 2003. "Un caso para la ingeniería de sistemas de servicio". Revista de Ciencias de Sistemas e Ingeniería de Sistemas, vol.

12, núm. 1, págs. 13-38.

Referencias adicionales
Ninguna.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021

Machine Translated by Google

Complejidad 108

Complejidad
Autor principal: Rick Adcock, autores colaboradores: Hillary Sillitto, Sarah Sheard

Este artículo es parte del área de conocimiento de Fundamentos de Sistemas (KA). Brinda los antecedentes y una indicación del pensamiento

actual sobre la complejidad y cómo influye en la práctica de la ingeniería de sistemas (SE).

La complejidad es uno de los conceptos de sistema más importantes y difíciles de definir. ¿Está la complejidad de un sistema en el ojo del

espectador, o hay una complejidad inherente en cómo se organizan los sistemas? ¿Existe una única definición definitiva de complejidad y, de ser

así, cómo se puede evaluar y medir? Este tema discutirá cómo estas ideas se relacionan con las definiciones generales de un sistema dadas en

¿Qué es un sistema?, y en particular con los diferentes contextos de sistemas de ingeniería. Este artículo está estrechamente relacionado con el

tema emergente que le sigue.

Definición de la complejidad del sistema

La complejidad ha sido considerada por varios autores desde varias perspectivas; algunas de las discusiones sobre la complejidad relevantes para

los sistemas se describen en la sección final de este artículo. Sheard y Mostashari (Sheard y Mostashari 2011) sintetizan muchas de estas ideas

para categorizar la complejidad de la siguiente manera:

1. Complejidad estructural analiza los elementos y las relaciones del sistema. En particular, la complejidad estructural analiza cuántas formas

diferentes se pueden combinar los elementos del sistema. Por lo tanto, está relacionado con el potencial del sistema para adaptarse a las

necesidades externas.

2. Complejidad Dinámica considera la complejidad que se puede observar cuando los sistemas se utilizan para realizar

tareas particulares en un entorno. Hay un elemento de tiempo en la complejidad dinámica. Las formas en que los sistemas interactúan en

el corto plazo están directamente relacionadas con el comportamiento del sistema; los efectos a largo plazo del uso de sistemas en un

entorno están relacionados con la evolución del sistema.

3. La Complejidad Socio-Política considera el efecto de los individuos o grupos de personas sobre la complejidad. La complejidad relacionada

con las personas tiene dos aspectos. Uno está relacionado con la percepción de una situación como compleja o no compleja, debido a los

múltiples puntos de vista de las partes interesadas dentro de un contexto de sistema y los sesgos sociales o culturales que se suman a las

influencias más amplias en un contexto de sistema. El otro involucra el comportamiento "irracional" de un individuo o el comportamiento de

enjambre de muchas personas que se comportan individualmente de manera que tiene sentido; sin embargo, el comportamiento emergente

es impredecible y quizás contraproducente. Este último tipo se basa en las interacciones de las personas de acuerdo con sus diversas

interrelaciones y, a menudo, se representa gráficamente utilizando formalismos de dinámica de sistemas.

Por lo tanto, la complejidad es una medida de cuán difícil es comprender cómo se comportará un sistema o predecir las consecuencias de

cambiarlo. Ocurre cuando no existe una relación simple entre lo que hace un elemento individual y lo que hará el sistema como un todo, y cuando

el sistema incluye algún elemento de adaptación o resolución de problemas para lograr sus objetivos en diferentes situaciones. Puede verse

afectado por atributos objetivos de un sistema, como el número, tipos y diversidad de elementos y relaciones del sistema, o por las percepciones

subjetivas de los observadores del sistema debido a su experiencia, conocimiento, capacitación u otras consideraciones sociopolíticas.

Esta visión de los sistemas complejos proporciona una idea del tipo de sistema para el cual el pensamiento sistémico y el enfoque sistémico son

esenciales.

Complejidad y Sistemas de Ingeniería

Las diferentes perspectivas sobre la complejidad no son independientes cuando se consideran en un contexto de sistemas. La complejidad

estructural de un sistema de interés (SoI) puede estar relacionada con la complejidad dinámica cuando el SoI también funciona como parte de un

sistema más amplio en diferentes escenarios de problemas. Las personas están involucradas en la mayoría de los contextos del sistema, como

parte de la situación del problema, como elementos del sistema y parte del entorno operativo. Los sistemas de actividad humana que creamos para

identificar, diseñar, construir y respaldar un sistema de ingeniería y el entorno social y comercial más amplio.
Machine Translated by Google

Complejidad 109

También es probable que los sistemas en los que se asientan sean complejos y afecten la complejidad de los sistemas que producen y
usar.

Sheard y Mostashari (2011) muestran las formas en que diferentes puntos de vista de la complejidad se asignan a los contextos del sistema de

productos, del sistema de servicios y del sistema empresarial, así como a los sistemas asociados de desarrollo y mantenimiento y organizaciones

de proyectos. Los sistemas ordenados ocurren como componentes del sistema y son objeto de la ingeniería tradicional. Es importante comprender

los comportamientos de dichos sistemas cuando se utilizan en un sistema complejo. También podría ser necesario considerar sistemas naturales

o sociales verdaderamente aleatorios o caóticos como parte del contexto de un sistema de ingeniería. El enfoque principal de los enfoques de

sistemas es la complejidad organizada (ver más abajo). Este tipo de complejidad no se puede abordar con las técnicas de análisis tradicionales,

ni se puede eliminar por completo con la forma en que diseñamos o usamos las soluciones. Un enfoque de sistemas debe ser capaz de reconocer

y manejar tal complejidad a lo largo de la vida de los sistemas con los que
interactúa.

Sillitto (2014) considera el vínculo entre los tipos de complejidad del sistema y la arquitectura del sistema. La capacidad de comprender, gestionar

y responder a la complejidad tanto objetiva como subjetiva en la situación del problema, los sistemas que desarrollamos o los sistemas que

usamos para desarrollarlos y mantenerlos es un componente clave del Enfoque de Sistemas Aplicado a los Sistemas de Ingeniería y, por lo tanto,

a la práctica. de ingeniería de sistemas.

Orígenes y características de la complejidad

En esta sección se describen algunas de las ideas prevalecientes sobre la complejidad. Varios autores han utilizado diferentes lenguajes para

expresar estas ideas. Si bien se pueden ver una serie de hilos comunes, algunas de las ideas adoptan diferentes puntos de vista y pueden ser de

naturaleza contradictoria.

Una de las definiciones de complejidad más utilizadas es el grado de dificultad para predecir las propiedades de un sistema si se dan las

propiedades de las partes del sistema (generalmente atribuido a Weaver). Esto, a su vez, está relacionado con la cantidad de elementos y

conexiones entre ellos. Weaver (Weaver 1948) relaciona la complejidad con los tipos de elementos y cómo interactúan. Describe la simplicidad

como problemas con un número finito de variables e interacción, e identifica dos tipos de complejidad:

1. La Complejidad Desorganizada se encuentra en un sistema con muchos elementos iguales, desorganizados y débilmente acoplados,

que posee ciertas propiedades promedio, como la temperatura o la presión. Tal sistema puede describirse mediante técnicas de análisis

estadístico del "siglo XIX".

2. La Complejidad Organizada se puede encontrar en un sistema con muchos elementos fuertemente acoplados, organizados y diferentes

que poseen ciertas propiedades y fenómenos emergentes como los exhibidos por los sistemas económicos, políticos o sociales. Tal sistema

no puede ser bien descrito por las técnicas de análisis tradicionales.

Las ideas de Weaver sobre este nuevo tipo de problema complejo son algunas de las ideas fundamentales del pensamiento sistémico. (Véase

también Pensamiento sistémico.)

Autores posteriores, como Flood y Carson (1993) y Lawson (2010), amplían la complejidad organizada a sistemas que se han organizado en una

estructura destinada a ser comprendida y, por lo tanto, susceptible de ingeniería y gestión del ciclo de vida (Braha et al. 2006). También sugieren

que la complejidad desorganizada podría resultar de un sistema complejo heterogéneo que evoluciona sin un control arquitectónico explícito

durante su vida (crecimiento de la complejidad). Este es un uso diferente de los términos "organizado" y "desorganizado" al que usa Weaver. Se

debe tener cuidado al mezclar estas ideas

La complejidad no debe confundirse con "complicado". Muchos autores distinguen entre orden y
colecciones desordenadas de elementos.

Los sistemas ordenados tienen relaciones fijas entre elementos y no son adaptables. Page (2009) cita un reloj como ejemplo de algo que puede

considerarse un sistema ordenado. Tal sistema es complicado, con muchos elementos trabajando juntos. Sus componentes se basan en

tecnologías similares, con un claro mapeo entre forma y función. Si el entorno operativo cambia más allá de los límites prescritos, o si se quita un

componente clave, el reloj dejará de realizar su función.

Machine Translated by Google

Complejidad 110

En el uso común, el caos es un estado de desorden o imprevisibilidad caracterizado por elementos que no están interconectados y se comportan

aleatoriamente sin adaptación ni control. La Teoría del Caos (Kellert 1993) se aplica a ciertos sistemas dinámicos (por ejemplo, el clima) que,

aunque tienen estructura y relaciones, exhiben un comportamiento impredecible. Estos sistemas pueden incluir aspectos de aleatoriedad, pero

pueden describirse utilizando modelos deterministas a partir de los cuales se puede describir su comportamiento dado un conjunto de condiciones

iniciales. Sin embargo, su estructura es tal que (no medibles) pequeñas perturbaciones en las entradas o las condiciones ambientales pueden

resultar en cambios impredecibles en el comportamiento. Dichos sistemas se denominan determinísticamente caóticos o, simplemente, sistemas

caóticos. Se pueden crear simulaciones de sistemas caóticos y, con aumentos en el poder de cómputo, son posibles predicciones razonables de

comportamiento al menos algunas veces.

En un espectro que va desde el orden hasta el desorden total, la complejidad se encuentra en algún lugar en el medio, con más flexibilidad y

cambio que un orden total y más estabilidad que un desorden total (Sheard y Mostashari 2009).

Los sistemas complejos pueden evolucionar "hasta el borde del caos", dando como resultado sistemas que pueden parecer deterministas pero que

exhiben un comportamiento contrario a la intuición en comparación con los sistemas más ordenados. Las estadísticas de eventos aleatorios en un

sistema complejo a menudo se caracterizan por una distribución de ley de potencia, la "firma de complejidad" (Sheard 2005).

La distribución de la ley de potencia se encuentra en una variedad muy amplia de fenómenos naturales y artificiales, y significa que la probabilidad

de un evento de gran impacto de baja probabilidad es mucho más alta de lo que sugeriría una distribución gaussiana.

Tal sistema puede reaccionar de forma no lineal para exhibir cambios de fase abruptos. Estos cambios de fase pueden ser reversibles o

irreversibles. Esto tiene un gran impacto en los sistemas de ingeniería en términos de ocurrencia, impacto y aceptación pública del riesgo y la falla.

La complejidad objetiva es un atributo de los sistemas complejos y es una medida de dónde se ubica un sistema en este espectro. Se define como

la medida en que los estados futuros del sistema no se pueden predecir con certeza y precisión, independientemente de nuestro conocimiento del

estado actual y la historia. La complejidad subjetiva es una medida de lo fácil que es para un observador comprender un sistema o predecir lo que

hará a continuación. Como tal, es función de la perspectiva y comprensión de cada individuo. Es importante estar preparado para mitigar la

complejidad subjetiva con una comunicación clara y coherente y una fuerte participación de las partes interesadas (Sillitto 2009).

La literatura ha evolucionado hacia una definición bastante consistente de las características de los elementos del sistema y las relaciones para la

complejidad de los sistemas objetivos. El siguiente resumen lo da Page (2009):

1. Independencia: Elementos del sistema autónomo que son capaces de tomar sus propias decisiones, influenciados por

información de otros elementos y los algoritmos de adaptabilidad que los elementos autónomos llevan consigo (Sheard y Mostashari 2009).

2. Interconexión: los elementos del sistema se conectan a través de una conexión física, datos compartidos o simplemente una imagen

conciencia de dónde están los otros elementos y qué están haciendo, como en el caso de la bandada de gansos o el escuadrón de

aviones.

3. Diversidad: Elementos del sistema que son tecnológica o funcionalmente diferentes de alguna manera. Por ejemplo,

los elementos pueden llevar diferentes algoritmos de adaptabilidad.

4. Adaptabilidad: Elementos del sistema que se organizan a sí mismos y que pueden hacer lo que quieren para apoyarse a sí mismos oa todo

el sistema en respuesta a su entorno (Sheard y Mostashari 2009). La adaptabilidad a menudo se logra mediante elementos humanos, pero

se puede lograr con software. Pollock y Hodgson (2004) describen cómo se puede hacer esto en una variedad de tipos de sistemas complejos,

incluidas las redes eléctricas y los sistemas empresariales.

Debido a la variabilidad del comportamiento humano como parte de un sistema y las percepciones de las personas fuera del sistema, la inclusión

de personas en un sistema es a menudo un factor de su complejidad. Las personas pueden ser vistas como sistemas de observación o como

elementos del sistema que contribuyen a los otros tipos de complejidad (Axelrod y Cohen 1999). El comportamiento racional o irracional de los

individuos en situaciones particulares es un factor vital con respecto a la complejidad (Kline 1995). Parte de esta complejidad se puede reducir a

través de la educación, la capacitación y la familiaridad con un sistema. Algunos son irreductibles y deben gestionarse como parte de un problema

o solución. Checkland (1999) argumenta que un grupo de partes interesadas tendrá sus propias visiones del mundo que los llevarán a formar

interpretaciones diferentes, pero igualmente válidas, del contexto de un sistema. Estas

Machine Translated by Google

Complejidad 111

las diferencias no pueden ser explicadas o analizadas, y deben ser entendidas y consideradas en la formulación de problemas y la creación
de soluciones potenciales.

Warfield (2006) desarrolló una poderosa metodología para abordar problemas complejos, particularmente en el campo socioeconómico,
basada en un grupo relevante de personas que desarrollan una comprensión del problema en forma de un conjunto de problemas que
interactúan, lo que él llamó la "problemática". ”. Luego, la complejidad se caracteriza a través de varias medidas, como el número de
problemas significativos, sus interacciones y el grado de consenso sobre la naturaleza de los problemas. Lo que queda claro es que cómo,
por qué, dónde y quién utiliza un sistema pueden contribuir a su complejidad percibida.

Sheard y Mostashari (2011) clasifican los atributos de la complejidad en causas y efectos. Los atributos que causan complejidad incluyen
ser no lineal; emergente; caótico; adaptado; estrechamente acoplado; auto-organizado; descentralizado; abierto; político (en oposición a
científico); y multiescala; además de tener muchas piezas. Los efectos de aquellos atributos que hacen que un sistema sea percibido
como complejo incluyen ser incierto; difícil de comprender; impredecible; incontrolable; inestable; irreparable; inmantenible y costoso; tener
causa y efecto poco claros; y tarda demasiado en construirse.

Referencias

Trabajos citados

Axelrod, R. y M. Cohen. 1999. Aprovechando la Complejidad: Implicaciones Organizacionales de una Frontera Científica. Nueva York, NY,
EE. UU.: Simon and Schuster.

Braha, D., A. Minai y Y. Bar-Yam (eds.). 2006. Sistemas de ingeniería complejos: la ciencia se encuentra con la tecnología. Nueva York,
NY, Estados Unidos: Springer.

Checkland, P. 1999. Pensamiento sistémico, práctica de sistemas. Nueva York, NY, EE. UU.: John Wiley & Sons.

Inundación, RL y ER Carson. 1993. Lidiando con la Complejidad: Una Introducción a la Teoría y Aplicación de la Ciencia de Sistemas, 2da
ed. Nueva York, NY, EE. UU.: Plenum Press.

Lawson, HW 2010. Un viaje a través del panorama de los sistemas. Kings College, Reino Unido: Publicaciones universitarias.

Kellert, S. 1993. In the Wake of Chaos: Unpredictable Order in Dynamical Systems, Chicago, IL, EE. UU.: University of Chicago Press.

Kline, S. 1995. Fundamentos del Pensamiento Multidisciplinario. Stanford, CA, EE. UU.: Stanford University Press.

Page, Scott E. 2009. Comprender la complejidad. Chantilly, VA, EE. UU.: The Teaching Company.

Pollock, JT y R. Hodgson. 2004. Información adaptativa. Hoboken, Nueva Jersey, Estados Unidos: John Wiley & Sons.

Senge, PM 1990. La Quinta Disciplina: El Arte y la Práctica de la Organización de Aprendizaje. Nueva York, NY, EE. UU.: Doubleday/
Currency.

Sheard, SA 2005. "Aplicaciones prácticas de la teoría de la complejidad para ingenieros de sistemas". Actas del Decimoquinto Consejo
Internacional Anual de Ingeniería de Sistemas, vol. 15, núm. 1.

Sheard, SA y A. Mostashari. 2009. “Principios de sistemas complejos para ingeniería de sistemas”. Ingeniería de Sistemas, vol. 12, núm.
4, págs. 295-311.

Sheard, SA. y A. Mostashari. 2011. "Tipos de complejidad: de la ciencia a la ingeniería de sistemas". Actas del 21º Simposio Internacional
Anual del Consejo Internacional de Ingeniería de Sistemas (INCOSE), Denver, Colorado, EE. UU., 20-23 de junio de 2011.

Sillitto, H. 2014. "Arquitectura de sistemas: conceptos, principios y práctica", Londres, Reino Unido: Publicaciones universitarias.

Warfield, JN 2006. Introducción a la ciencia de sistemas. Londres, Reino Unido: World Scientific Publishing.

Weaver, W. 1948. "Ciencia y complejidad". Ciencia americana, vol. 36, págs. 536-544.
Machine Translated by Google

Complejidad 112

Referencias primarias
Inundación, RL y ER Carson. 1993. Lidiando con la Complejidad: Una Introducción a la Teoría y Aplicación de la Ciencia de Sistemas, 2da ed. Nueva

York, NY, EE. UU.: Plenum Press.

Page, Scott E. 2009. Comprender la complejidad. Chantilly, VA, EE. UU.: The Teaching Company.

Sheard, SA y A. Mostashari. 2009. “Principios de sistemas complejos para ingeniería de sistemas”. Ingeniería de Sistemas, vol. 12, núm. 4, págs.

295-311.

Referencias adicionales
Ashby, WR 1956. Introducción a la cibernética. Londres, Reino Unido: Chapman and Hall.

Aslaksen, EW 2004. "Termodinámica de sistemas: un modelo que ilustra la complejidad que surge de la simplicidad".

Ingeniería de Sistemas, vol. 7, núm. 3. Hoboken, Nueva Jersey, EE. UU.: Wiley.

Aslaksen, EW 2009. Ingeniería de Sistemas Complejos: Fundamentos del Diseño en el Dominio Funcional. Boca Ratón,

FL, EE. UU.: CRC Press.

Aslaksen, EW 2011. "Elementos de una ontología de ingeniería de sistemas". Actas de SETE 2011, Canberra,
Australia.

Eisner, H. 2005. Gestión de sistemas complejos: pensar fuera de la caja. Hoboken, Nueva Jersey, Estados Unidos: John Wiley & Sons.

Jackson, S., D. Hitchins y H. Eisner. 2010. “¿Qué es el Enfoque de Sistemas?” Insight de INCOSE , vol. 13, núm. 1, abril, págs. 41-43, 2010.

INGLETE. 2011. "Estrategias de ingeniería de sistemas para la incertidumbre y la complejidad". Guía de ingeniería de sistemas.

Consultado el 9 de marzo de 2011. Disponible en: http:/ / www. inglete. org/work/systems_engineering/guide/enterprise_engineering/

comprehensive_viewpoint/sys_engineering_strategies_uncertainty_complexity.html.

Ryan, A. 2007. "La emergencia está acoplada al alcance, no al nivel, a la complejidad". Una versión condensada apareció en INCOSE Insight, vol.

11, núm. 1, enero, págs. 23-24, 2008.

Sillitto HG 2009. "Sobre los arquitectos de sistemas y la arquitectura de sistemas: algunas reflexiones sobre la explicación del arte y la ciencia de la

arquitectura de sistemas". Actas del 19º Consejo Internacional Anual de Ingeniería de Sistemas (INCOSE)

Simposio Internacional, Singapur, 20-23 de julio de 2009.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021

Machine Translated by Google

Aparición 113

Aparición
Autor principal: Rick Adcock, autores colaboradores: Scott Jackson, Dick Fairley, Janet Singer, Duane Hybertson

Este tema forma parte del área de conocimiento de Fundamentos de Sistemas (KA). Brinda los antecedentes de algunas de las formas en que

se ha descrito la emergencia, así como una indicación del pensamiento actual sobre qué es y cómo influye en la práctica de la ingeniería de

sistemas (SE). Discutirá cómo estas ideas se relacionan con las definiciones generales de sistemas dadas en ¿Qué es un sistema?; en

particular, cómo se relacionan con diferentes contextos de sistemas de ingeniería. Este tema está estrechamente relacionado con el tema de

la complejidad que lo precede.

La emergencia es una consecuencia de los conceptos fundamentales del sistema de holismo e interacción (Hitchins 2007, 27).

Los conjuntos del sistema tienen comportamientos y propiedades que surgen de la organización de sus elementos y sus relaciones, que solo

se hacen evidentes cuando el sistema se coloca en diferentes entornos.

Las preguntas que surgen de esta definición incluyen: ¿Qué tipos de sistemas exhiben diferentes tipos de emergencia y bajo qué condiciones?

¿Se puede predecir la emergencia y es beneficiosa o perjudicial para un sistema? ¿Cómo tratamos la emergencia en el desarrollo y uso de

sistemas de ingeniería? ¿Se puede planificar? ¿Cómo?

Hay muchos puntos de vista variados y ocasionalmente contradictorios sobre la emergencia. Este tema presenta los puntos de vista

predominantes y proporciona referencias para otros.

Descripción general de la emergencia

Tal como lo define Checkland, la emergencia es “el principio de que las entidades exhiben propiedades que son significativas solo cuando se

atribuyen al todo, no a sus partes”. (Checkland 1999, 314). El comportamiento del sistema emergente puede verse como una consecuencia de

las interacciones y relaciones entre los elementos del sistema en lugar del comportamiento de los elementos individuales. Emerge de una

combinación del comportamiento y las propiedades de los elementos del sistema y la estructura del sistema o las interacciones permitidas

entre los elementos, y puede ser desencadenada o influenciada por un estímulo del entorno del sistema.

La emergencia es común en la naturaleza. El amoníaco gaseoso es el resultado de la combinación química de dos gases inodoros, hidrógeno

y nitrógeno. Como partes individuales, las plumas, los picos, las alas y las gargantas no tienen la capacidad de vencer la gravedad; sin

embargo, cuando se conectan correctamente en un ave, crean el comportamiento emergente de vuelo. Lo que llamamos “autoconciencia”

resulta del efecto combinado de las neuronas interconectadas e interactuantes que forman el cerebro (Hitchins 2007, 7).

Hitchins también señala que los sistemas tecnológicos exhiben surgimiento. Podemos observar una serie de niveles de resultados que surgen

de la interacción entre elementos en un contexto de sistema de ingeniería. En un nivel simple, algunos resultados o atributos del sistema tienen

un mapeo bastante simple y bien definido para sus elementos; por ejemplo, el centro de gravedad o la velocidad máxima de un vehículo

resultan de una combinación de propiedades de elementos y cómo se combinan. Se pueden asociar otros comportamientos con estos

resultados simples, pero su valor surge de formas complejas y menos predecibles en todo el sistema. El rendimiento de una sola vuelta de un

vehículo en una pista está relacionado con el centro de gravedad y la velocidad; sin embargo, también se ve afectado por la habilidad del

conductor, las condiciones externas, los componentes, etc. Obtener el "mejor" rendimiento de un vehículo solo se puede lograr mediante una

combinación de buen diseño y retroalimentación de vueltas reales.

en condiciones de carrera.

También hay resultados que son menos tangibles y que sorprenden tanto a los desarrolladores como a los usuarios del sistema.

¿Cómo se traduce el tiempo de vuelta en un equipo de automovilismo ganador? ¿Por qué un automóvil deportivo es más deseable para

muchos que otros vehículos con prestaciones tan buenas o mejores?

La emergencia siempre se puede observar en el nivel más alto del sistema. Sin embargo, Hitchins (2007, 7) también señala que en la medida

en que los elementos de los sistemas en sí mismos pueden ser considerados como sistemas, también exhiben emergencia. Page (2009) se

refiere a la emergencia como una “propiedad de nivel macro”. Ryan (2007) sostiene que la emergencia está acoplada al alcance
Machine Translated by Google

Aparición 114

en lugar de niveles jerárquicos del sistema. En términos de Ryan, el alcance tiene que ver con las dimensiones espaciales (cómo se
relacionan entre sí los elementos del sistema) en lugar de niveles jerárquicos.

Abbott (2006) no está en desacuerdo con la definición general de emergencia discutida anteriormente. Sin embargo, no está de acuerdo
con la noción de que la emergencia opera fuera de los límites de la física clásica. Él dice que "tales entidades de alto nivel... siempre
pueden reducirse a fuerzas físicas primitivas".

Bedau y Humphreys (2008) y Francois (2004) brindan descripciones exhaustivas de los antecedentes filosóficos y científicos de la
emergencia.

Tipos de Emergencia
Existe una variedad de definiciones de tipos de emergencia. Véase Emmeche et al. (1997), Chroust (2003) y O'Connor y Wong (2006)
para detalles específicos de algunas de las variantes. Page (2009) describe tres tipos de emergencia: "simple", "débil" y "fuerte".

Según Page, la emergencia simple es generada por la combinación de las propiedades y relaciones de los elementos y ocurre en
sistemas no complejos u “ordenados” (ver Complejidad) (2009). Para lograr la propiedad emergente de “vuelo controlado” no podemos
considerar solo las alas, o el sistema de control, o el sistema de propulsión. Se deben considerar los tres, así como la forma en que
estos tres están interconectados, entre sí, así como con todas las demás partes de la aeronave. Page sugiere que la emergencia simple
es el único tipo de emergencia que se puede predecir. Esta visión de emergencia también se conoce como sinergia (Hitchins 2009).

Page describe la emergencia débil como la emergencia esperada que se desea (o al menos se permite) en la estructura del sistema
(2009). Sin embargo, dado que la emergencia débil es producto de un sistema complejo, el nivel real de emergencia no puede
predecirse simplemente a partir del conocimiento de las características de los componentes individuales del sistema.

El término emergencia fuerte se usa para describir una emergencia inesperada; es decir, la emergencia no se observa hasta que el
sistema se simula o prueba o, lo que es más alarmante, hasta que el sistema encuentra en funcionamiento una situación que no se
anticipó durante el diseño y desarrollo.

Una emergencia fuerte puede ser evidente en fallas o paradas. Por ejemplo, el apagón EE. UU.-Canadá de 2003 descrito por el Grupo
de Trabajo de Interrupciones del Sistema de Energía de EE. UU.-Canadá (Grupo de Trabajo de Energía de EE. UU.-Canadá 2004) fue
un caso de apagado en cascada que resultó del diseño del sistema. Si bien no hubo fallas en los equipos, el cierre fue sistémico. Como
señala Hitchins, este ejemplo muestra que las propiedades emergentes no siempre son beneficiosas (Hitchins 2007, 15).

Otros autores hacen una distinción diferente entre las ideas de emergencia fuerte o inesperada e impredecible.
aparición:

• En primer lugar, están las propiedades inesperadas que podrían haberse predicho pero no se consideraron en un sistema.
desarrollo: "Propiedades que son inesperadas para el observador debido a su conjunto de datos incompletos, con respecto al
fenómeno en cuestión" (Francois, C. 2004, 737). Según Jackson et al. (2010), el nivel deseado de emergencia generalmente se
logra mediante la iteración. Esto puede ocurrir como resultado de procesos evolutivos, en los que las propiedades y combinaciones
de los elementos se "seleccionan", dependiendo de qué tan bien contribuyan a la efectividad de un sistema contra las presiones
ambientales o por iteración de parámetros de diseño a través de simulación o ciclos de construcción/prueba. Desde este punto de
vista, los valores específicos de emergencia débil pueden refinarse y los ejemplos de emergencia fuerte pueden considerarse en
iteraciones posteriores siempre que sean susceptibles de análisis.

• En segundo lugar, existen propiedades inesperadas que no se pueden predecir a partir de las propiedades del sistema.
componentes: "Propiedades que son, en sí mismas, no derivables a priori del comportamiento de las partes del sistema" (Francois,
C. 2004, 737). Esta visión de la emergencia es familiar en las ciencias sociales o naturales, pero más controvertida en la
ingeniería. Deberíamos distinguir entre una imprevisibilidad teórica y una práctica (Chroust 2002). El pronóstico del tiempo es
teóricamente predecible, pero más allá de cierta precisión limitada, es prácticamente imposible debido a su naturaleza caótica. El
surgimiento de la conciencia en los seres humanos no puede deducirse de
Machine Translated by Google

Aparición 115

las propiedades fisiológicas del cerebro. Para muchos, este tipo de complejidad genuinamente impredecible tiene un valor limitado
para la ingeniería. (Consulte las Consideraciones prácticas a continuación).

Un tipo de sistema particularmente sujeto a una fuerte emergencia es el sistema de sistemas (sos). La razón de esto es que el SoS, por
definición, se compone de diferentes sistemas que fueron diseñados para operar de forma independiente. Cuando estos sistemas funcionan
juntos, es probable que la interacción entre las partes del sistema dé como resultado una emergencia inesperada. Es probable que esta
clase de sistemas presente una emergencia caótica o verdaderamente impredecible.

Propiedades emergentes
Las propiedades emergentes se pueden definir de la siguiente manera: “Se dice que una propiedad de un sistema complejo es
'emergente' [en el caso en que], aunque surge de las propiedades y relaciones que caracterizan a sus constituyentes más simples, no es
predecible ni reducible a estas características de nivel inferior” (Honderich 1995, 224).

Todos los sistemas pueden tener propiedades emergentes que pueden o no ser predecibles o susceptibles de modelado, como se discutió
anteriormente. Gran parte de la literatura sobre la complejidad incluye la emergencia como una característica definitoria de los sistemas
complejos. Por ejemplo, Boccara (2004) afirma que “La aparición de propiedades emergentes es la característica más distintiva de los
sistemas complejos”. En general, cuanto más ordenado es un sistema, más fácil es predecir sus propiedades emergentes. Cuanto más
complejo es un sistema, más difícil es predecir sus propiedades emergentes
se convierte en

Algunos practicantes usan el término “emergencia” solo cuando se refieren a “emergencia fuerte”. Estos practicantes se refieren a las otras
dos formas de comportamiento emergente como sinergia o “comportamiento a nivel del sistema” (Chroust 2002). Tomando este punto de
vista, reservaríamos el término "Propiedad Emergente" para propiedades inesperadas, que pueden ser modeladas o refinadas a través de
iteraciones del desarrollo de sistemas.

La aparición imprevista provoca sorpresas desagradables. Muchos creen que el trabajo principal del enfoque de sistemas es prevenir la
emergencia no deseada para minimizar el riesgo de resultados inesperados y potencialmente indeseables. Esta revisión de propiedades
emergentes a menudo se asocia específicamente con la identificación y prevención de fallas del sistema (Hitchins 2007).

Sin embargo, Good SE no solo se enfoca en evitar fallas en el sistema. También implica maximizar la oportunidad al comprender y explotar
la emergencia en los sistemas de ingeniería para crear las características requeridas del nivel del sistema a partir de las interacciones
sinérgicas entre los componentes, no solo de los componentes mismos (Sillitto 2010).

Un grupo importante de propiedades emergentes incluye propiedades como la agilidad y la resiliencia. Estas son propiedades críticas del
sistema que no son significativas excepto a nivel de todo el sistema.

Consideraciones prácticas

Como se mencionó anteriormente, una forma de administrar las propiedades emergentes es a través de la iteración. Los requisitos para
iterar el diseño de un sistema de ingeniería para lograr los resultados de emergencia deseados en un proceso de diseño son más extensos
que los necesarios para diseñar un sistema ordenado. La creación de un sistema de ingeniería capaz de tal iteración también puede
requerir una solución más configurable o modular. El resultado es que los sistemas complejos pueden ser más costosos y lentos de
desarrollar que los ordenados, y el costo y el tiempo de desarrollo son inherentemente menos predecibles.

Sillitto (2010) observa que “los dominios de diseño de ingeniería que explotan la emergencia tienen buenos modelos matemáticos del
dominio y controlan rigurosamente la variabilidad de los componentes y subsistemas, y del proceso, tanto en el diseño como en la
operación”. Las iteraciones discutidas anteriormente se pueden acelerar mediante el uso de simulación y modelado, de modo que no todas
las iteraciones deban involucrar la construcción de sistemas reales y operarlos en el entorno real.

Hybertson explora aún más la idea de los modelos de dominio en el contexto de modelos o patrones generales aprendidos a lo largo del
tiempo y capturados en un espacio modelo (Hybertson 2009). Hybertson afirma que saber qué aparición aparecerá a partir de un diseño
determinado, incluidos los efectos secundarios, requiere retrospectiva. Para un nuevo tipo de problema que no se ha resuelto, o un nuevo
tipo de sistema que no se ha construido, es prácticamente imposible predecir el comportamiento emergente de la solución o el sistema. Se
puede obtener algo de retrospectiva, o al menos una idea, modelando e iterando un
Machine Translated by Google

Aparición 116

diseño de sistemas; sin embargo, iterar el diseño dentro del desarrollo de un sistema produce solo una visión retrospectiva limitada y, a

menudo, no brinda una sensación completa de emergencia y efectos secundarios.

La verdadera retrospectiva y la comprensión provienen de la construcción de múltiples sistemas del mismo tipo y su implementación, luego se

observa su comportamiento emergente en funcionamiento y los efectos secundarios de colocarlos en sus entornos. Si esas observaciones se

realizan sistemáticamente, y la aparición y los efectos secundarios se destilan y capturan en relación con el diseño de los sistemas, incluidas

las variaciones en esos diseños, y se ponen a disposición de la comunidad, entonces estaremos en condiciones de predecir y explotar La

emergencia.

Se descubren dos factores en este tipo de entorno de prueba: qué funciona (es decir, qué comportamiento emergente y qué efectos secundarios

son deseables); y qué no funciona (es decir, qué comportamiento emergente y qué efectos secundarios son indeseables).

Lo que funciona afirma el diseño. Lo que no funciona requiere correcciones en el diseño. Esta es la razón por la que se deben construir e

implementar múltiples sistemas, especialmente los sistemas complejos, a lo largo del tiempo y en diferentes entornos, para aprender y

comprender las relaciones entre el diseño, el comportamiento emergente, los efectos secundarios y el entorno.

Estos dos tipos de aprendizaje capturado corresponden respectivamente a patrones y "antipatrones", o patrones de falla, los cuales se analizan

en un contexto más amplio en los temas Principios del pensamiento sistémico y Patrones del pensamiento sistémico.

El uso de iteraciones para refinar los valores de las propiedades emergentes, ya sea a lo largo de la vida de un solo sistema o mediante el

desarrollo de patrones que encapsulen el conocimiento obtenido de múltiples desarrollos, se aplica más fácilmente a la discusión anterior sobre

la fuerte emergencia. En este sentido, aquellas propiedades que se pueden observar pero que no se pueden relacionar con las elecciones de

diseño no son relevantes para un enfoque de sistemas. Sin embargo, pueden tener valor cuando se trata de una combinación de problemas

de ingeniería y de gestión que ocurren en contextos de sistemas de sistemas (Sillitto 2010). (Consulte Enfoque de sistemas aplicado a sistemas

de ingeniería).

Referencias

Trabajos citados

Abbott, R. 2006. "Explicación de la emergencia: hacer que los epifenómenos hagan un trabajo real". Complejidad, vol. 12, núm. 1 (septiembre-

octubre), pp. 13-26.

Bedau, MA y P. Humphreys, P. (eds.). 2008. "Emergencia" en lecturas contemporáneas en filosofía y ciencia. Cambridge, MA, EE. UU.: The

MIT Press.

Boccara, N. 2004. Modelado de Sistemas Complejos. Nueva York, NY, EE. UU.: Springer-Verlag.

Checkland, P. 1999. Pensamiento sistémico, práctica de sistemas. Nueva York, NY, EE. UU.: John Wiley & Sons.

chroust. G. 2002. "Propiedades emergentes en sistemas de software". X Charlas Interdisciplinarias de Gestión de la Información; Hofer, C. y

Chroust, G. (eds.). Verlag Trauner Linz, págs. 277-289.

Chroust, G., C. Hofer, C. Hoyer (eds.). 2005. El concepto de emergencia en la ingeniería de sistemas". The 12th Fuschl Conversation, 18-23

de abril de 2004, Instituto de Ingeniería de Sistemas y Automatización, Universidad Johannes Kepler de Linz. págs. 49-60.

Emmeche, C., S. Koppe y F. Stjernfelt. 1997. "Explicando la emergencia: Hacia una ontología de niveles". Revista de Filosofía General de la

Ciencia, vol. 28, núm. 1, págs. 83-119. Consultado el 3 de diciembre de 2014. Disponible en: http://www. nbi.dk/~emmeche/coPubl/97e.EKS/

emerg.html.

Francois, C. 2004. Enciclopedia Internacional de Sistemas y Cibernética, 2ª edición, 2 volúmenes. Múnich, Alemania: KGSaur Verlag.

Hitchins, D. 2007. Ingeniería de sistemas: una metodología de sistemas del siglo XXI. Hoboken, Nueva Jersey, EE. UU.: John Wiley &
Hijos.

Honderich. T. 1995. The Oxford Companion to Philosophy. Nueva York, NY, EE. UU.: Oxford University Press.
Machine Translated by Google

Aparición 117

Hybertson, D. 2009. Ciencia de ingeniería de sistemas orientada a modelos: un marco unificador para sistemas tradicionales y complejos. Boca

Ratón, FL, EE. UU.: Auerbach/CRC Press.

Jackson, S., D. Hitchins y H. Eisner. 2010. "¿Qué es el Enfoque de Sistemas?" INCOSE Insight. 13(1) (abril

2010): 41-43.

O'Connor, T. y H. Wong. 2006. "Propiedades emergentes", en la Enciclopedia de Filosofía de Stanford. Consultado el 3 de diciembre de 2014:

disponible en: http://plato.stanford.edu/entries/properties-emergent/.

Page, SE 2009. Comprender la complejidad. Los Grandes Cursos. Chantilly, VA, EE. UU.: The Teaching Company.

Ryan, A. 2007. "La emergencia está relacionada con el alcance, no con el nivel". Complejidad, vol. 13, núm. 2, noviembre-diciembre.

Sillitto, HG 2010. "Principios de diseño para sistemas de ultra gran escala". Actas del 20º Simposio Internacional Anual del Consejo Internacional

de Ingeniería de Sistemas (INCOSE), julio de 2010, Chicago, IL, EE. UU., reimpreso en "The Singapore Engineer", abril de 2011.

Grupo de Trabajo de Interrupción del Sistema Eléctrico de EE. UU. y Canadá. 2004. Informe final sobre el apagón del 14 de agosto de 2003 en

los Estados Unidos y Canadá: causas y recomendaciones. Washington-Ottawa. Consultado el 3 de diciembre de 2014. Disponible: http:/gov/
/
blackout-2003-final-report-august-14-2003-blackout-united-states-and-canada-causes-and
energía. oe/ descargas/

Referencias primarias
Emmeche, C., S. Koppe y F. Stjernfelt. 1997. "Explicando la emergencia: Hacia una ontología de niveles". Revista de Filosofía General de la

Ciencia, vol. 28, núm. 1, págs. 83-119. Disponible: http://www.nbi.dk/~emmeche/coPubl/97e.EKS/emerg.html.

Hitchins, D. 2007. Ingeniería de sistemas: una metodología de sistemas del siglo XXI. Hoboken, Nueva Jersey, EE. UU.: John Wiley &
Hijos.

Page, SE 2009. Comprender la complejidad. Los Grandes Cursos. Chantilly, VA, EE. UU.: The Teaching Company.

Referencias adicionales

Sheard, SA y A. Mostashari. 2008. “Principios de sistemas complejos para ingeniería de sistemas”. Ingeniería de Sistemas, vol. 12, núm. 4, págs.

295-311.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021

Machine Translated by Google

Fundamentos para la Ingeniería de Sistemas del Futuro 118

Fundamentos para la Ingeniería de Sistemas del Futuro

Autor principal: Rick Adcock, autor colaborador: Duane Hybertson

Este artículo forma parte del área de conocimiento de Fundamentos de Sistemas (KA). Considera las tendencias futuras en SE y cómo estas

podrían influir en la evolución de los fundamentos futuros.

El SEBoK contiene una guía de conocimientos generalizados sobre la práctica de la SE. No juzga ese conocimiento. Sin embargo, puede ser útil

en algunos casos indicar qué partes del conocimiento están enraizadas en la práctica existente y cuáles apuntan hacia la evolución futura de la

SE.

Este artículo proporciona un bosquejo de cómo está cambiando SE y sugiere cómo estos cambios pueden afectar el futuro de la ingeniería de

sistemas, el SEBoK y los cimientos en la Parte 2.

INCOSE Visión
La declaración INCOSE Vision 2025 (INCOSE 2014) describe algunas direcciones futuras en:

Ampliación de dominios de aplicación SE

• La relevancia e influencia de SE irá más allá de los sistemas aeroespaciales y de defensa tradicionales y se extenderá a un ámbito más amplio.

ámbito de los sistemas de ingeniería, naturales y sociales

• SE se aplicará más ampliamente a las evaluaciones de los sistemas sociofísicos en apoyo de las decisiones políticas y otros
formas de remediación

Sistemas más inteligentes y autónomos

• Los sistemas del futuro deben volverse más inteligentes, autoorganizados, sostenibles, eficientes en recursos, robustos y más seguros •

La cantidad de vehículos autónomos y sistemas de transporte debe aumentar • Los sistemas se vuelven más "inteligentes" y dominan las

aplicaciones críticas para la seguridad humana

Fundamentos teóricos

• SE contará con el respaldo de una base teórica más amplia y métodos y herramientas sofisticados basados en modelos que permitirán una

mejor comprensión de los sistemas y decisiones cada vez más complejos frente a la incertidumbre • Desafío: se define y se enseña de

manera consistente un cuerpo central de fundamentos de ingeniería de sistemas a través de la academia y forma la base para la práctica de la

ingeniería de sistemas

En este artículo consideraremos cómo los fundamentos de SE podrían necesitar evolucionar para respaldar esta visión.

¿Cómo cambiará SE?

En Tipos de sistemas, describimos tres contextos generales en los que se puede aplicar un ciclo de vida de SE. En un contexto de sistema de

producto, las salidas de SE se enfocan en la entrega de sistemas tecnológicos. Si bien dichos sistemas están diseñados para ser utilizados por

personas y encajar en un contexto más amplio de resolución de problemas, este contexto se ha considerado en gran medida fijo y externo a SE.

El contexto del sistema de servicios permite a SE considerar todos los aspectos del sistema de solución como parte de su responsabilidad. Esto

se ve actualmente como un caso especial de la aplicación SE centrada en gran medida en soluciones intensivas de software. El contexto del

sistema empresarial ofrece el potencial para una aplicación directa de SE para abordar problemas sociotécnicos complejos, al respaldar la

planificación, el desarrollo y el uso de combinaciones de sistemas de servicios.

Mientras se hace esto, puede ser difícil conectarse a los ciclos de vida centrados en el producto de muchos proyectos de SE.

El papel del ingeniero de sistemas ya ha comenzado a cambiar un poco debido a las dos primeras tendencias futuras mencionadas anteriormente.

Los cambios en el alcance de la aplicación de SE y el mayor uso de soluciones autónomas y reconfigurables intensivas en software harán que el

contexto del sistema de servicio sea el enfoque principal de la mayoría de los ciclos de vida de SE. Para permitir esto, la mayoría de los sistemas

de productos deberán volverse más generales y configurables, lo que les permitirá usarse en una variedad de sistemas de servicios según sea

necesario. Estos ciclos de vida se inician y gestionan cada vez más como parte de una cartera empresarial
Machine Translated by Google

Fundamentos para la Ingeniería de Sistemas del Futuro 119

de ciclos de vida relacionados.

En esta evolución de SE, el ingeniero de sistemas no puede considerar tantos aspectos del contexto para solucionar, lo que hace que el problema y

las posibles opciones de solución sean más complejos y difíciles de anticipar. Esto también significa que el ingeniero de sistemas tiene mayor libertad

para considerar soluciones que combinan tecnologías nuevas y existentes y en las que se puede cambiar el rol de las personas y el software autónomo

para ayudar a lograr los resultados deseados. Para que dichos sistemas tengan éxito, deberán incluir la capacidad de cambiar, adaptarse y crecer

tanto en funcionamiento como durante varias iteraciones de su ciclo de vida. Este cambio lleva a SE a involucrarse directamente en la estrategia y

planificación de la empresa, como parte de un enfoque continuo e iterativo para abordar los tipos de problemas sociales identificados en la visión de

INCOSE.

Esta evolución tanto del rol como del alcance de SE también verá aumentar los aspectos del sistema de sistemas de todos los contextos del sistema.

Podemos esperar que el sistema de ingeniería de sistemas se convierta en parte de la ingeniería de sistemas de muchos, si no la mayoría, de los

ciclos de vida de SE.

Evolución de los Fundamentos

Estos cambios en curso en SE ponen más énfasis en el papel de los agentes autónomos en la ingeniería de sistemas, y la agencia será un área de

mayor énfasis en la ingeniería de sistemas y SEBoK del futuro. Hybertson (2019) explica con más detalle el mayor papel de los agentes y la agencia

en el futuro SE. Pasar de un modelo de control total a un modelo de responsabilidad compartida cambia la naturaleza de la ingeniería a algo más

parecido a la actualización colectiva, como propone Hybertson (2009 y 2019). Los sistemas representarán una combinación e interacción de tecnología

y factores sociales, y pueden variar desde productos técnicos hasta proveedores de servicios y entidades sociales. En muchos casos serán una

combinación sociotécnica o híbrida.

Las tendencias anteriores tienen un impacto en los fundamentos de la ES, incluidos los aspectos técnicos, los aspectos sociales y los aspectos éticos.

La inclusión de personas en los sistemas implica una expansión significativa de las ciencias fundamentales, para proporcionar principios, teorías,

modelos y patrones del ámbito humano, biológico, social y de agentes, así como del ámbito técnico y físico.

El énfasis en los agentes implica una conceptualización revisada del cambio del sistema, desde el modelo tradicional de arreglos y actualizaciones

mecánicos y controlados a un modelo de cambio más orgánico que implica crecimiento, autoaprendizaje, autoorganización y autoadaptación. Las

consideraciones éticas incluirán cómo asignar la responsabilidad de un sistema en un modelo de responsabilidad compartida. En (Hybertson 2009 y

2019) se presenta una discusión adicional sobre la base ampliada y una lista de disciplinas fundamentales para la futura SE.

Referencias

Trabajos citados

Hybertson, D. (2009). Ciencia de ingeniería de sistemas orientada a modelos: un marco unificador para sistemas tradicionales y complejos, Boca

Raton, FL, EE. UU.: Auerbach/CRC Press.

Hybertson, D. (2020 próximamente). Ciencias de la Ingeniería de Sistemas. Capítulo en GS Metcalf, H. Deguchi y K.

Kijima (editores en jefe). Manual de ciencia de sistemas. Tokio: Springer.

INCOSE (2014). "Un mundo en movimiento: visión de ingeniería de sistemas 2025". Consejo Internacional de Ingeniería de Sistemas.
Machine Translated by Google

Fundamentos para la Ingeniería de Sistemas del Futuro 120

Referencias primarias
Ninguna.

Referencias adicionales
Ninguna.

< Artículo anterior | Artículo principal | Artículo siguiente >

SEBoK v. 2.4, publicado el 19 de mayo de 2021