Arquitectura del Sistema

El objetivo de las actividades de arquitectura del sistema es definir una solución integral basada en
principios, conceptos y propiedades lógicamente relacionadas y consistentes entre sí. La arquitectura de
la solución tiene características, propiedades y características que satisfacen, en la medida de lo posible,
el problema u oportunidad expresada por un conjunto de requisitos del sistema (trazables a los
requisitos de misión / negocio y partes interesadas) y conceptos de ciclo de vida (por ejemplo, operativo,
de soporte) y son implementables a través de tecnologías (por ejemplo, mecánica, electrónica, hidráulica,
software, servicios, procedimientos, actividad humana).

La arquitectura del sistema es abstracta, orientada a la conceptualización, global y enfocada para

alcanzar la misión y los conceptos del ciclo de vida del sistema. También se enfoca en la estructura de
alto nivel en los sistemas y elementos del sistema. Aborda los principios arquitectónicos, conceptos,
propiedades y características del sistema de interés. También se puede aplicar a más de un sistema, en
algunos casos formando la estructura común, patrón y conjunto de requisitos para clases o familias de
sistemas similares o relacionados.

Conceptos y principios generales

Noción de estructura

El SEBoK considera la ingeniería de sistemas para cubrir todos los aspectos de la creación de un sistema,
incluida la arquitectura del sistema.

La mayoría de las interpretaciones de la arquitectura del sistema se basan en la noción bastante

intangible de la estructura (es decir, las relaciones entre los elementos). Algunos autores limitan los tipos
de estructura que se consideran arquitectónicos; por ejemplo, restringirse a la estructura funcional y
física. La práctica reciente ha ampliado la consideración para incluir las dimensiones conductuales,
temporales y de otra índole de la estructura.

ISO / IEC / IEEE 42010 Ingeniería de software y sistemas - Descripción de arquitectura (ISO 2011)
proporciona una descripción útil de la arquitectura teniendo en cuenta las inquietudes de los
interesados, los puntos de vista de la arquitectura, las vistas de arquitectura, los modelos de
arquitectura, las descripciones de arquitectura y la arquitectura a lo largo del ciclo de vida. Se puede
encontrar una discusión sobre las características de las arquitecturas de sistemas en (Maier y Rechtin
2009). Un intento de desarrollar y aplicar un enfoque sistemático para caracterizar los sistemas de
creencias de la arquitectura en la ingeniería de sistemas ha sido descrito por el grupo de trabajo de
arquitectura INCOSE UK (Wilkinson et al.2010, Wilkinson 2010).

Descripción de la arquitectura del sistema

Un marco de arquitectura contiene puntos de vista estandarizados, plantillas de vistas, metamodelos,

plantillas de modelos, etc. que facilitan el desarrollo de las vistas de una arquitectura de sistema
(consulte el Marco de arquitectura (glosario) para ver ejemplos). ISO / IEC / IEEE 42010 (ISO 2011)
especifica las características normativas de los marcos de arquitectura, puntos de vista y vistas, ya que
pertenecen a la descripción de la arquitectura. Un punto de vista aborda una preocupación particular de
las partes interesadas (o conjunto de preocupaciones estrechamente relacionadas). El punto de vista
especifica los tipos de modelo que se utilizarán en el desarrollo de la arquitectura del sistema para
abordar esa preocupación (o conjunto de preocupaciones), las formas en que se deben generar los
modelos y cómo los modelos se relacionan y utilizan para componer una vista.

Los modelos lógicos y físicos (o vistas) se utilizan a menudo para representar aspectos fundamentales de
la arquitectura del sistema. Otros puntos de vista y puntos de vista complementarios se usan
necesariamente para representar cómo la arquitectura del sistema aborda las preocupaciones de los
interesados, por ejemplo, modelos de costos, modelos de procesos, modelos de reglas, ontológicos
modelos, modelos de creencias, modelos de proyectos, modelos de capacidad, modelos de datos, etc.
Clasificación de principios y heurística

Los ingenieros y los arquitectos utilizan una mezcla de principios matemáticos y heurísticos (las
heurísticas son lecciones aprendidas a través de la experiencia, pero no están comprobadas
matemáticamente). Cuando un problema se identifica y define a través de los requisitos del sistema, los
principios y la heurística pueden o no ser capaces de abordarlo. Los principios y las heurísticas que se
utilizan en las vistas / modelos del sistema se pueden clasificar de acuerdo con los dominios en los que
se utilizan esas vistas / modelos del sistema, de la siguiente manera:

1. El dominio estático se relaciona con la estructura física u organización de los SoI desglosados
en sistemas y elementos del sistema. Se trata de sistemas de particiones, elementos del sistema
e interfaces físicas.

2. El dominio dinámico se relaciona con modelos de arquitectura lógica; en particular, a la

representación del comportamiento del sistema. Incluye una descripción de funciones (es decir,
transformaciones de flujos de entrada en flujos de salida) e interacciones entre funciones del
sistema y entre aquellas de los objetos o sistemas externos. Tiene en cuenta las reacciones a
eventos que inician o detienen la ejecución de funciones del sistema. También se ocupa de la
efectividad (es decir, las actuaciones, las condiciones de funcionamiento) del sistema.

3. El dominio temporal se relaciona con los niveles de invarianza temporal de la ejecución de las
funciones del sistema. Esto significa que cada función se ejecuta de acuerdo con características
cíclicas o sincrónicas. Incluye niveles decisionales que son características asincrónicas del
comportamiento de algunas funciones.

4. El dominio ambiental se refiere a habilitadores (producción, soporte logístico, etc.), pero

también a la capacidad de supervivencia del sistema en reacción a riesgos naturales o amenazas
ya la integridad del sistema en reacción a riesgos potenciales internos. Esto incluye, por
ejemplo, aspectos climáticos, mecánicos, electromagnéticos y biológicos.

Se puede encontrar una clasificación más detallada de la heurística en (Maier y Rechtin 2009).

Transición de los requisitos del sistema a los modelos de arquitectura lógica y física

El objetivo del enfoque es avanzar desde los requisitos del sistema (representando el problema desde el
punto de vista del proveedor / diseñador, tan independiente de la tecnología como sea posible) a través
de un modelo intermedio de arquitectura lógica, para asignar los elementos del modelo de arquitectura
lógica al sistema elementos de modelos candidatos de arquitectura física.

(Los requisitos del sistema y los modelos de arquitectura lógica comparten muchas características, ya
que ambos están organizados en líneas funcionales, independientemente de la implementación. Algunos
autores (Stevens et al 1998) llegan incluso a combinarlos, lo que simplifica el manejo de múltiples vistas
simultáneas. La adopción de este enfoque depende de las prácticas específicas de la organización de
desarrollo y de dónde se establecen los límites contractuales).

Las decisiones de diseño y las soluciones tecnológicas se seleccionan de acuerdo con criterios de
rendimiento y requisitos no funcionales, como condiciones operativas y restricciones del ciclo de vida
(por ejemplo, condiciones ambientales, restricciones de mantenimiento, restricciones de realización,
etc.), como se ilustra en la Figura 1. Creación de modelos intermedios, como los modelos de arquitectura
lógica, facilita la validación de las propiedades funcionales, de comportamiento y temporales del sistema
frente a los requisitos del sistema que no tienen un impacto tecnológico importante durante la vida del
sistema, las interfaces físicas o la capa tecnológica sin cuestionar completamente el funcionamiento
lógico del sistema.
 Modelo intermedio

Modelo de
Modelo de Modelo de arquitectura física
requisitos arquitectura
del sistema lógica

Relacionado con las

Independiente de las tecnologías
alternativas de solución Independiente de la
o de la tecnología tecnología Tenga en cuenta los
requisitos no funcionales

Iteraciones entre el desarrollo del modelo de arquitectura lógica y física

Como se explica en los requisitos del sistema, el enfoque exacto adoptado en la síntesis de soluciones
dependerá a menudo de si el sistema es una evolución de un producto o servicio ya entendido, o una
solución nueva y sin precedentes (consulte Sintetizar posibles soluciones).

Independientemente del enfoque, las actividades de arquitectura requieren pasar varias iteraciones
entre el desarrollo de modelos de arquitectura lógica y el desarrollo de modelos de arquitectura física,
hasta que los modelos de arquitectura lógica y física sean consistentes y proporcionen el nivel de detalle
necesario. Una de las primeras actividades de arquitectura es la creación de un modelo de arquitectura
lógica basado en escenarios nominales (de funciones). El modelo de arquitectura física se usa para
determinar los principales elementos del sistema que podrían realizar funciones del sistema y
organizarlos.

Las iteraciones subsiguientes del modelo de arquitectura lógica pueden tener en cuenta las asignaciones
de funciones a los elementos del sistema y las funciones derivadas de las elecciones de soluciones físicas.
También complementa el modelo de arquitectura lógica inicial al introducir otros escenarios, análisis de
fallas y requisitos operacionales no considerados anteriormente. Las funciones derivadas se asignan a
los elementos del sistema; a su vez, esto afecta los modelos de arquitectura física.

Las iteraciones adicionales se centran en producir vistas lógicas y físicas completas y consistentes de la
solución.

Durante el diseño del sistema, las elecciones tecnológicas pueden conducir potencialmente a nuevas
funciones, nuevos flujos de entrada / salida y control, y nuevas interfaces físicas. Estos nuevos elementos
pueden conducir a la creación de nuevos requisitos del sistema, llamados requisitos derivados.

Noción de interfaz

La noción de interfaz es una de las más importantes a considerar cuando se define la arquitectura de un
sistema. El aspecto fundamental de una interfaz es funcional y se define como entradas y salidas de
funciones. Como las funciones son realizadas por elementos físicos (elementos del sistema), las entradas
/ salidas de funciones también son llevadas por elementos físicos; estos se llaman interfaces físicas.
Consecuentemente, tanto los aspectos funcionales como físicos se consideran en la noción de interfaz. Un
análisis detallado de una interfaz muestra la función "enviar" ubicada en un elemento del sistema, la
función "recibir" ubicada en la otra, y la función "llevar" como realizada por la interfaz física que soporta
el flujo de entrada / salida (ver figura 2).
 Flujo de E/S

Función Función Función de

¨Enviar¨ ¨Llevar¨ ¨Recepción¨

Elemento del sistema 1 Elemento del sistema 2

Interfaz física

En el contexto de intercambios complejos entre elementos del sistema, particularmente en sistemas de

software intensivo, se considera que un protocolo es una interfaz física que permite el intercambio de
datos. Sin embargo, los flujos de entrada / salida pueden incluir muchos otros intercambios además de
los datos, como la energía.

Propiedades emergentes

La arquitectura general de un sistema puede tener propiedades de diseño o efectos operacionales que
surgen de la disposición e interacción entre los elementos del sistema, pero que pueden no ser
propiedades de ningún elemento individual o estar destinados al sistema como un todo.

Los elementos de un sistema diseñado interactúan entre sí y pueden crear fenómenos deseables o
indeseables, como inhibición, interferencia, resonancia o el refuerzo de cualquier propiedad. La
definición del sistema incluye un análisis de las interacciones entre los elementos del sistema para evitar
propiedades indeseables y reforzar las deseables.

Una propiedad que emerge de un sistema puede tener varios orígenes, desde un elemento de sistema
único hasta las interacciones entre varios elementos (Thome, B. 1993). El término propiedades
emergentes es utilizado por algunos autores para identificar cualquier propiedad que surja de un
sistema, mientras que otros pueden referirse a esto como sinergia y reserva de propiedades emergentes
para explicar propiedades o propiedades inesperadas no consideradas completamente durante el
desarrollo del sistema, pero surgidas durante la operación. El concepto del sistema de emergencia se
analiza en SEBoK Parte 2 (ver Emergencia).
Categorías amplias de propiedades Descripción y ejemplos

Propiedad local La propiedad se encuentra en un solo elemento del sistema, p. la capacidad de

un contenedor es la capacidad del sistema.

Propiedad del Sistema Acumulativo La propiedad se encuentra en varios elementos del sistema y se obtiene
mediante la suma simple de propiedades elementales, p. Ej. el peso del sistema
resulta de la suma de los pesos de sus elementos del sistema.

Propiedad emergente modificada por
arquitectura y / o interacciones.
La propiedad existe en varios elementos del sistema y se modifica por sus
interacciones, p. la confiabilidad / seguridad de un sistema resulta de la
confiabilidad / seguridad de cada elemento del sistema y la forma en que están
organizados. Los pasos arquitectónicos son a menudo críticos para cumplir con
los requisitos del sistema.

Propiedad emergente creada por La propiedad no existe en los elementos del sistema y los resultados solo de sus
interacciones interacciones, p. Ej. interfaces electromecánicas, electromagnetismo, electricidad
estática, etc.

Propiedad emergente controlada Propiedad controlada o inhibida antes de salir del sistema - por ejemplo:
desequilibrio eliminado por la adición de una carga; vibración amortiguada por
un amortiguador.
El diseño de la arquitectura física incluirá la identificación de posibles sinergias y propiedades
emergentes y la inclusión de funciones derivadas, componentes, arreglos y / o restricciones ambientales
en los modelos de arquitecturas lógicas o físicas para evitarlos, mitigarlos o restringirlos dentro de
límites aceptables. Los requisitos derivados correspondientes se deben agregar a la línea de base de
requisitos del sistema cuando impactan el sistema de interés (SoI). Esto se puede lograr a través del
conocimiento y la experiencia del ingeniero de sistemas o mediante la aplicación de patrones del
sistema. Sin embargo, generalmente no es posible predecir, evitar o controlar todas las propiedades
emergentes durante el desarrollo de la arquitectura. El tratamiento completo de las consecuencias de la
emergencia solo se puede realizar a través de la iteración entre la definición del sistema, la realización
del sistema y la implementación y uso del sistema (Hitchins, 2008)

La noción de emergencia se aplica durante la arquitectura y el diseño para resaltar las funciones
derivadas necesarias; Además, la emergencia interna a menudo está vinculada a la noción de
complejidad. Este es el caso de los sistemas adaptativos complejos (CAS), en los que los elementos
individuales actúan independientemente, pero se comportan conjuntamente de acuerdo con las
limitaciones y objetivos comunes (Flood y Carson 1993). Los ejemplos de CAS incluyen: la red
macroeconómica global dentro de un país o grupo de países, mercado bursátil, red compleja de
compañías tenedoras transfronterizas, negocios manufactureros, organizaciones geopolíticas, etc.
(Holland, J. 1999 y 2006).

Reutilización de elementos del sistema

Los ingenieros de sistemas utilizan con frecuencia los elementos del sistema existentes. Esta restricción
de reutilización tiene que identificarse como un requisito del sistema y tenerse en cuenta
cuidadosamente durante la arquitectura y el diseño. Se pueden distinguir tres casos generales que
involucran la reutilización de elementos del sistema, como se muestra en la Tabla 2.
Caso de reutilización Acciones y Comentarios

Caso 1: los requisitos del elemento del sistema • La arquitectura del sistema a definir tendrá que adaptarse a los límites,
están actualizados y se volverá a utilizar sin interfaces, funciones, efectividad y comportamiento del elemento del
necesidad de modificaciones. sistema reutilizado.
• Si el elemento del sistema no está adaptado, es probable que aumenten los
costos, la complejidad y los riesgos.

Caso 2: los requisitos del elemento del sistema
están actualizados y se reutilizarán con posibles
modificaciones.
• La arquitectura del sistema que se debe definir es lo suficientemente
flexible para acomodar los límites, las interfaces, las funciones, la efectividad
y el comportamiento del elemento del sistema reutilizado.
• El diseño del elemento del sistema reutilizado, incluidos sus informes de
prueba y otra documentación, será evaluado y potencialmente rediseñado.

Caso 3: los requisitos no están actualizados o no
existen.
• Es necesario realizar una ingeniería inversa del elemento del sistema para
identificar sus límites, interfaces, funciones, actuaciones y comportamiento.
• Esta es una actividad difícil, ya que la documentación existente para el
elemento del sistema reutilizado probablemente no esté disponible o sea
insuficiente.
• La ingeniería inversa es costosa en términos de tiempo y dinero, y conlleva
un mayor riesgo.

Existe una idea común de que la reutilización es gratuita; Sin embargo, si no se aborda correctamente, la
reutilización puede introducir riesgos que pueden ser significativos para el proyecto (costos, plazos,
complejidad).

Enfoque basado en procesos

Propósito

El propósito del proceso de Arquitectura del sistema es generar alternativas de arquitectura del sistema,
seleccionar una o más alternativas que enmarquen las preocupaciones de los interesados y cumplir los
requisitos del sistema, y expresar esto en un conjunto de vistas coherentes. (ISO 2015). Cabe señalar que
las actividades de arquitectura a continuación se superponen tanto con la definición del sistema como
con las actividades de definición del concepto. En particular, los aspectos clave del contexto operativo y
comercial, y por lo tanto ciertas necesidades de las partes interesadas, influyen fuertemente en el
enfoque adoptado para el desarrollo y la descripción de la arquitectura. Además, las actividades de
arquitectura impulsarán la selección de, y se adaptarán dentro de, cualquier enfoque a la síntesis de la
solución que se haya seleccionado.

Actividades del proceso

Las principales actividades y tareas realizadas durante este proceso incluyen lo siguiente:

1. Inicialice la definición de la arquitectura del sistema

• Comprenda el entorno / contexto de uso para el cual se necesita un sistema a fin de establecer una idea
de las inquietudes de los interesados. Para ello, analice la información relevante del mercado, la
industria, las partes interesadas, la empresa, los negocios, las operaciones, la misión, la legislación y de
otro tipo que ayude a comprender las perspectivas que podrían guiar la definición de vistas y modelos de
la arquitectura del sistema.

• Capture las inquietudes de las partes interesadas (es decir, expectativas o limitaciones) que abarcan las
etapas del ciclo de vida del sistema. Las preocupaciones a menudo se relacionan con características
críticas del sistema que se relacionan con las etapas; deben traducirse o incorporarse a los requisitos del
sistema.

• Etiquetar los requisitos del sistema que tratan con condiciones operativas (por ejemplo, seguridad,
seguridad, confiabilidad, factores humanos, interfaces, condiciones ambientales) y restricciones del ciclo
de vida (por ejemplo, mantenimiento, eliminación, implementación) que influirían en la definición de los
elementos de la arquitectura.

• Establecer una hoja de ruta y estrategia de arquitectura que incluya métodos, técnicas de modelado,
herramientas, necesidad de sistemas, productos o servicios habilitantes, requisitos del proceso (por
ejemplo, enfoque y métodos de medición), proceso de evaluación (por ejemplo, revisiones y criterios).

• Planificar la adquisición de productos o servicios (necesidad, requisitos, adquisiciones).

2. Definir los puntos de vista de arquitectura necesarios

• Con base en las preocupaciones identificadas de las partes interesadas, identifique los puntos de vista
de arquitectura relevantes y los marcos de arquitectura que pueden respaldar el desarrollo de modelos y
vistas.

3. Desarrollar modelos y vistas de arquitecturas candidatas

• Usar técnicas y herramientas de modelado relevantes, y junto con el proceso Necesidades y requisitos
de las partes interesadas y el proceso de Requisitos del sistema, determinar el contexto del sistema de
interés, que incluye el límite con los elementos del entorno externo. Esta tarea incluye la identificación
de relaciones, interfaces o conexiones, intercambios e interacciones del sistema de interés con elementos
externos. Esta tarea permite definir o comprender los escenarios operacionales esperados y / o los
comportamientos del sistema dentro de su contexto de uso.

• Definir entidades arquitectónicas (por ejemplo, funciones, flujos de entrada / salida, elementos del
sistema, interfaces físicas, características arquitectónicas, elementos de información / datos,
contenedores, nodos, enlaces, recursos de comunicación, etc.), que abordan los diferentes tipos de
requisitos del sistema ( por ejemplo, requisitos funcionales, requisitos de interfaz, requisitos
ambientales, condiciones operacionales - confiabilidad, factores humanos, etc., restricciones -
dimensiones físicas, producción, mantenimiento, eliminación).

• Relacionar entidades arquitectónicas con conceptos, propiedades, características, comportamientos,

funciones y / o restricciones que son relevantes para las decisiones de la arquitectura del sistema de
interés. Esto da lugar a características arquitectónicas (por ejemplo, generalidad, modularidad,
operabilidad, eficiencia, simplicidad).
• Seleccione, adapte o desarrolle modelos de las arquitecturas candidatas del sistema, como los modelos
lógicos y físicos (consulte Desarrollo del modelo de arquitectura lógica y Desarrollo del modelo de
arquitectura física). A veces no es necesario ni suficiente utilizar modelos lógicos y físicos. Los modelos
que se utilizarán son los que mejor responden a las preocupaciones clave de los interesados.

• A partir de los modelos de las arquitecturas candidatas, componga vistas que sean relevantes para las
preocupaciones de los interesados y los requisitos críticos o importantes.

• Definir requisitos del sistema derivados inducidos por instancias necesarias de entidades
arquitectónicas (por ejemplo, funciones, interfaces) y por disposiciones estructurales (por ejemplo,
restricciones, condiciones operativas). Use el proceso de definición de requisitos del sistema para
definirlos y formalizarlos.

• Verifique la consistencia de los modelos y vistas y resuelva cualquier problema identificado. ISO / IEC /
IEEE 42010, 2011 puede ser utilizado para esto.

• Verificar y validar los modelos por ejecución o simulación, si las técnicas y herramientas de modelado
lo permiten. Donde sea posible, use herramientas de diseño para verificar la viabilidad y validez; y / o
implementar maquetas parciales, o usar prototipos o simuladores de arquitecturas ejecutables.

4. Relacionar la arquitectura del sistema con el diseño del sistema

• Definir los elementos del sistema que reflejan las características arquitectónicas (cuando la
arquitectura pretende ser independiente del diseño, estos elementos del sistema pueden ser nocionales
hasta que el diseño evolucione). Para ello, particione, alinee y asigne las características arquitectónicas y
los requisitos del sistema a los elementos del sistema. Establecer principios rectores para el diseño y la
evolución del sistema. A veces, se crea una "arquitectura de referencia" utilizando estos elementos del
sistema teórico como un medio para transmitir la intención arquitectónica y para verificar la viabilidad
del diseño.

• Definir interfaces para aquellas que son necesarias para el nivel de detalle y comprensión de la
arquitectura. Esto incluye las interfaces internas entre los elementos del sistema y las interfaces externas
con otros sistemas.

• Determinar las propiedades de diseño aplicables a los elementos del sistema para satisfacer las
características arquitectónicas.

• Para cada elemento del sistema que compone el sistema, desarrolle los requisitos correspondientes a la
asignación, la alineación y la partición de las propiedades de diseño y los requisitos del sistema a los
elementos del sistema. Para ello, utilice el proceso de definición de requisitos y necesidades de las partes
interesadas y el proceso de definición de requisitos del sistema.

5. Evaluar candidatos de arquitectura y seleccionar uno

• Evaluar las arquitecturas candidatas utilizando los criterios de evaluación de la arquitectura. Esto se
hace a través de la aplicación de los procesos de análisis de sistema, medición y gestión de riesgos.

• Seleccione la (s) arquitectura (s) preferida (s). Esto se hace mediante la aplicación del proceso de
Gestión de decisiones.

6. Administrar la arquitectura seleccionada

• Establecer y mantener el fundamento para todas las selecciones entre alternativas y decisiones para la
arquitectura, los marcos de arquitectura, los puntos de vista, los tipos de modelos y los modelos de la
arquitectura.

• Administrar el mantenimiento y la evolución de la descripción de la arquitectura, incluidos los modelos

y las vistas. Esto incluye la concordancia, la integridad y los cambios debidos a cambios en el entorno o el
contexto, la tecnología, la implementación y las experiencias operativas. Las matrices de asignación y
trazabilidad se utilizan para analizar los impactos en la arquitectura. El presente proceso se realiza en
cualquier momento en que se produzcan evoluciones del sistema.
• Establecer un medio para la gobernanza de la arquitectura. La gobernanza incluye los roles,
responsabilidades, autoridades y otras funciones de control.

• Coordinar las revisiones de la arquitectura para lograr el acuerdo de las partes interesadas. Los
requisitos de las partes interesadas y los requisitos del sistema pueden servir como referencias.

Artefactos, métodos y técnicas de modelado

Este proceso puede crear varios artefactos, como documentos de descripción de la arquitectura del
sistema y documentos de justificación del sistema (matrices de trazabilidad y opciones arquitectónicas).

El contenido, el formato, el diseño y la propiedad de estos artefactos pueden variar según la persona que
los crea y los dominios en los que se utilizan. Los resultados de las actividades del proceso deben cubrir
la información identificada en la primera parte de este artículo.

Consideraciones prácticas
Trampas
Algunas de las trampas clave encontradas en la planificación y realización de la arquitectura del sistema
se proporcionan en la Tabla 3.
Trampa Descripción

Relevancia del Si la arquitectura se desarrolla sin la participación de las preocupaciones de las partes interesadas, o
problema no se puede entender y relacionar con sus problemas, podría perder las inversiones de la comunidad
de partes interesadas.

Reutilización de En algunos proyectos, para fines industriales, los productos o servicios existentes se imponen desde
elementos del sistema muy temprano como restricciones de arquitectura / diseño en los requisitos de las partes
interesadas o en los requisitos del sistema, sin prestar suficiente atención al nuevo contexto de uso
del sistema en el que también están incluidos. Es mejor trabajar en la dirección correcta desde el
principio. Primero defina el sistema, tome nota de otros requisitos y luego vea si hay elementos
adecuados de no desarrollo (NDI) disponibles. No imponga un elemento del sistema desde el
principio, lo que reduciría el espacio comercial. El proceso de reutilización correcto consiste en
definir elementos del sistema reutilizables en todos los contextos de uso.

Prácticas comprobadas
Algunas prácticas comprobadas recopiladas a partir de las referencias se proporcionan en la Tabla 4.
Práctica Descripción

Propiedades Controlar las propiedades emergentes de las interacciones entre los sistemas o los elementos del
emergentes sistema; obtener las propiedades sinérgicas requeridas y controlar o evitar los comportamientos
indeseables (vibración, ruido, inestabilidad, resonancia, etc.).

Referencias
Trabajos citados
Faisandier, A. 2012. Arquitectura y diseño de sistemas. Belberaud, Francia: Sinergy'Com.

ISO / IEC / IEEE. 2015. Ingeniería de sistemas y software: procesos del ciclo de vida del sistema. Ginebra,
Suiza: Organización Internacional de Normalización / Comisiones Electrotécnicas Internacionales. ISO /
IEC / IEEE 15288: 2015.

ISO / IEC / IEEE. 2011. Ingeniería de sistemas y software - Descripción de la arquitectura. Ginebra, Suiza:
Organización Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional (IEC) /
Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), ISO / IEC / IEEE 42010.
Maier, M. y E. Rechtin. 2009. El arte de la arquitectura de sistemas. 3ª ed. Boca Raton, FL, EE. UU.: CRC
Press.

Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. "Sistemas de creencias en arquitectura de
sistemas: método y aplicaciones preliminares". Presentado en la 5ta. Conferencia internacional de la
Sociedad de SMC de IEEE sobre el sistema de ingeniería de sistemas (SoSE). 22-24 de junio de 2010.
Universidad de Loughborough, Reino Unido.

Flood, R.L. y E.R. Carson. 1993. Tratando 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

Holland, J.H. 1999. Surgimiento: del caos al orden. Lectura, misa: Perseus Books.

Hitchins, D. 2008. "Surgimiento, jerarquía, complejidad, arquitectura: ¿cómo encajan todas juntas? Una
guía para los buscadores después de la iluminación". Libro blanco autopublicado. Consultado el 4 de
septiembre de 2012. Disponible en: http://www.hitchins.net/EmergenceEtc.pdf.

Holland, J.H. 2006. "Estudiar sistemas adaptativos complejos". Revista de Ciencia de Sistemas y
Complejidad. 19 (1): 1-8. http://hdl.handle.net/2027.42/41486

Thome, B. 1993. Ingeniería de Sistemas, Principios y Práctica de Ingeniería de Sistemas Basados en

Computadora. Nueva York, NY, EE. UU.: Wiley.

Referencias principales
ANSI / IEEE. 2000. Práctica recomendada para la descripción arquitectónica de sistemas intensivos de
software. Nueva York, NY, EE. UU.: Instituto Estadounidense de Estándares Nacionales (ANSI) / Instituto
de Ingenieros Eléctricos y Electrónicos (IEEE), ANSI / IEEE 1471-2000.

INCOSE. 2015. 'Manual de ingeniería de sistemas: una guía para procesos y actividades del ciclo de vida
del sistema', versión 4.0. Hoboken, NJ, EE. UU.: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0

ISO / IEC / IEEE. 2015. Ingeniería de Sistemas y Software - Procesos del ciclo de vida del sistema.
Ginebra, Suiza: Organización Internacional de Estandarización (ISO) / Comisión Electrotécnica
Internacional (IEC) / Instituto de Ingenieros Eléctricos y Electrónicos. ISO / IEC / IEEE 15288: 2015.

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, Francia: Sinergy'Com.

Blanchard, B.S., y W.J. Fabrycky. 2005. Ingeniería de Sistemas y Análisis. 4ª ed. Serie internacional de
Prentice-Hall en ingeniería industrial y de sistemas. Englewood Cliffs, NJ, EE. UU.: Prentice-Hall.

ISO / IEC. 2007. Ingeniería de sistemas: aplicación y gestión del proceso de ingeniería de sistemas.
Ginebra, Suiza: Organización Internacional de Estándares (ISO) / Comisión Electrotécnica Internacional
(IEC), ISO / IEC 26702: 2007.

ISO / IEC / IEEE. 2011. Ingeniería de Sistemas y Software - Descripción de la Arquitectura. Ginebra,
Suiza: Organización Internacional de Normalización (ISO) / Comisión Electrotécnica Internacional (IEC)
/ Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), ISO / IEC / IEEE 42010.

Martin, J.N. 1997. Guía de ingeniería de sistemas: un proceso para desarrollar sistemas y productos, 1ª
ed. Boca Raton, FL, EE. UU.: CRC Press.

NASA. 2007. Manual de Ingeniería de Sistemas. Washington, D.C.: Administración Nacional de

Aeronáutica y del Espacio (NASA), NASA / SP-2007-6105.

Referencias adicionales
Checkland, P. B. 1999. Pensamiento de sistemas, práctica de sistemas. Chichester, Reino Unido: John
Wiley & Sons Ltd.
DIOS MIO. 2010. Especificación de OMG Systems Modeling Language, versión 1.2, julio de 2010. http: //
www.Diosmio.org/technology/ocuments/spec_catalog.htm.

Sillitto H, "Sistemas de arquitectura - Conceptos, principios y práctica", College Publications 2014

Wilkinson, M.K. 2010. "Z8: Arquitectura de sistemas", en la serie Z-guide. INCOSE UK, disponible en
INCOSE UK en:
http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications.

<Artículo anterior | Artículo principal | Siguiente artículo>

SEBoK v. 1.8 lanzado el 27 de marzo de 2017

Discusión SEBoK
Proporcione sus comentarios y comentarios sobre el SEBoK a continuación. Tendrá que iniciar sesión en
DISQUS utilizando una cuenta existente (por ejemplo, Yahoo, Google, Facebook, Twitter, etc.) o crear una
cuenta DISQUS. Simplemente escriba su comentario en el campo de texto a continuación y DISQUS lo
guiará a través de los pasos de inicio de sesión o registro. Los comentarios serán archivados y utilizados
para futuras actualizaciones de SEBoK. Si proporcionó un comentario que ya no aparece en la lista, ese
comentario se ha adjudicado. Puede ver la adjudicación de los comentarios enviados antes de SEBoK v. 1.0
en SEBoK Review and Adjudication. Los comentarios posteriores se abordan y los cambios se resumen en la
Carta del Editor y los Agradecimientos y el Historial de versiones.

Si desea proporcionar ediciones en este artículo, recomendar contenido nuevo o hacer

comentarios sobre el SEBoK en general, consulte el SEBoK Sandbox [1].

ENCODED_CONTENT
MTk1MTMPGRpdiBpZD0iZGlzcXVzX3RocmVhZCI+PC9kaXY+CjxzY3JpcHQgdHlwZT0idGV4dC9qY
XZhc2NyaXB0Ij4KICAgIC8qICogKiBDT05GSUdVUkFUSU9OIFZBUklBQkxFUzogRURJVCBCRUZPUk
UgUEFTVElORyBJTlRPIFlPVVIgV0VCUEFHRSAqICogKi8KICAgIHZhciBkaXNxdXNfc2hvcnRuYW1lID
0gJ3NlYm9rd2lraTEwJzsgLy8gcmVxdWlyZWQ6IHJlcGxhY2UgZXhhbXBsZSB3aXRoIHlvdXIgZm9yd
W0gc2hvcnRuYW1lCiAgICB2YXIgZGlzcXVzX2lkZW50aWZpZXIgPSAnU3lzdGVtIEFyY2hpdGVjdHV
yZSc7ICAgIHZhciBkaXNxdXNfdXJsID0gJ2h0dHA6Ly9zZWJva3dpa2kub3JnL3dpa2kvU3lzdGVtX0F
yY2hpdGVjdHVyZSc7CiAgICAvKiAqICogRE9OJ1QgRURJVCBCRUxPVyBUSElTIExJTkUgKiAqICovCiA
gICAoZnVuY3Rpb24oKSB7CiAgICAgICAgdmFyIGRzcSA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbn
QoJ3NjcmlwdCcpOyBkc3EudHlwZSA9ICd0ZXh0L2phdmFzY3JpcHQnOyBkc3EuYXN5bmMgPSB0c
nVlOwogICAgICAgIGRzcS5zcmMgPSAnaHR0cDovLycgKyBkaXNxdXNfc2hvcnRuYW1lICsgJy5kaXN
xdXMuY29tL2VtYmVkLmpzJzsKICAgICAgICAoZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hb
WUoJ2hlYWQnKVswXSB8fCBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgnYm9keScpW
zBdKS5hcHBlbmRDaGlsZChkc3EpOwogICAgfSkoKTsKPC9zY3JpcHQ+Cjxub3NjcmlwdD5QbGVhc2
UgZW5hYmxlIEphdmFTY3JpcHQgdG8gdmlldyB0aGUgPGEgaHJlZj0iaHR0cDovL2Rpc3F1cy5jb20v
P3JlZl9ub3NjcmlwdCI+Y29tbWVudHMgcG93ZXJlZCBieSBEaXNxdXMuPC9hPjwvbm9zY3JpcHQ+
CjxhIGhyZWY9Imh0dHA6Ly9kaXNxdXMuY29tIiBjbGFzcz0iZHNxLWJybGluayI+YmxvZyBjb21tZW
50cyBwb3dlcmVkIGJ5IDxzcGFuIGNsYXNzPSJsb2dvLWRpc3F1cyI+RGlzcXVzPC9zcGFuPjwvYT4=
END_ENCODED_CONTENT