Gestión de la Ingeniería

de Sistemas
SESIÓN 7: PROCESO DE DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA
EXPLICAR ALCANCE DE LA SESION 7

Proceso de definición de Arquitectura del Sistema

1. Introducción
2. Enfoque de SEBoK
3. Enfoque de INCOSE
4. Conclusiones y recomendaciones
Modelos de Ciclo de Vida de Sistemas

• A lo largo del curso veremos dos enfoques del Ciclo de Vida de Sistemas:
• Enfoque de SEBoK

• Enfoque de INCOSE (ISO15288):

Utilización/
Concepto Desarrollo Producción Retiro
Soporte
 Procesos de Ciclo de Vida de Sistemas

Etapa / Definición de Definición del Realización/Desarr Producción/Sopo Retiro

Área de Concepto Sistema ollo del Sistema rte/Utilización
Conocim
iento
Proceso • Análisis del • Definición de • Implementación • Operación Eliminación
Negocio o Requisitos del • Integración • Mantenimiento
misión Sistema • Verificación
• Necesidades • Arquitectura del • Transición
y requisitos de Sistema • Validación
los • Diseño del
stakeholders Sistema
• Análisis del
Sistema
Proceso de Definición de Arquitectura
1. Introducción

Procesos Ténicos
del Modelo
ISO 15288:2015
Proceso de Definición de Arquitectura
1. Introducción

¿Qué es la arquitectura de Sistemas?

 Como se establece en ISO / IEC / IEEE 42010: 2011, la arquitectura del sistema
se define como: “conceptos o propiedades fundamentales de un sistema en
su entorno incorporados en sus elementos, relaciones y en los principios de
su diseño y evolución ”.
 La arquitectura se puede representar de acuerdo con varios puntos de vista
y en varios niveles de abstracción o granularidad. Los puntos de vista
comúnmente utilizados son los siguientes:
 El punto de vista de la arquitectura operativa, que describe la organización del
sistema en términos de funciones de caja negra o casos de uso y escenarios
operativos asociados. Representa servicios, sub servicios e interacciones entre ellos
proporcionados en respuesta a las capacidades deseadas de las partes
interesadas en el entorno / contexto operativo.
 El punto de vista de la arquitectura lógica de un sistema se compone de un
conjunto de conceptos y principios técnicos relacionados que respaldan el
funcionamiento lógico del sistema. Incluye un punto de vista de arquitectura
funcional, un punto de vista de arquitectura de comportamiento, un punto de vista
de arquitectura temporal y una partición de funciones en componentes del sistema
(bloques de construcción) excluyendo la implementación o cuestiones
tecnológicas [completado de SeBoK [2] V1.4]
 Proceso de Definición de Arquitectura
1. Introducción
¿Qué es la arquitectura de Sistemas?
 El punto de vista de la arquitectura lógica:
 El punto de vista de la arquitectura funcional describe la organización interna del sistema en
términos de funciones de “caja blanca”, sus interfaces (entradas / salidas) y su descomposición
en subfunciones hasta un nivel en el que la transformación de funciones puede asignarse por
completo a un bloque de construcción. Generalmente, la descomposición muestra la
distribución de los flujos de datos / energía desde las entradas de la función principal hasta sus
salidas y entre las subfunciones.
 El punto de vista de la arquitectura de comportamiento describe el comportamiento de las
funciones del sistema en términos de flujos de datos / energía y flujos de control. Los flujos de
control describen lógicas de ejecución (secuencia, decisión, sincronización…) de funciones y
condiciones de activación / desactivación de funciones (eventos, fin de otra función…).
 El punto de vista de la arquitectura temporal describe la frecuencia de ejecución de funciones
y define los aspectos síncronos o asincrónicos de las funciones (creadas a partir de SeBoK).

 El punto de vista de la arquitectura física describe la disposición de los elementos físicos

(elementos del sistema e interfaces físicas), lo que proporciona la solución de diseño
del sistema de interés y está destinado a satisfacer los elementos de la arquitectura
lógica y los requisitos del sistema. Es implementable a través de tecnologías.
Estos puntos de vista están destinados a organizar y estructurar la especificación del sistema, no a
describir soluciones de disciplina de implementación, como la mecánica, el software o el hardware.
Proceso de Definición de Arquitectura
del Sistema
2. ENFOQUE DEL SEBOK
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Introducción
• El propósito de las actividades de Arquitectura del Sistema es definir
una solución integral basada en principios, conceptos y propiedades
lógicamente relacionados y consistentes entre sí.
• La arquitectura de la solución tiene 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 la misión
/ requisitos de negocio y de las partes interesadas) y conceptos del ciclo
de vida (por ejemplo, operativo, soporte). y que 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, está orientada a la
conceptualización, es global y está enfocada a lograr los conceptos de
misión y ciclo de vida del sistema.
• También se centra en la estructura de alto nivel en sistemas y elementos
del sistema.
• Aborda los principios, conceptos, propiedades y características
arquitectónicas del sistema de interés.
• También se puede aplicar a más de un sistema, en algunos casos
formando la estructura, patrón y conjunto de requisitos comunes para
clases o familias de sistemas similares o relacionados.
Proceso de definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Contenido
1 Principios y conceptos generales
1.1 Noción de estructura
1.2 Descripción de la arquitectura del sistema
1.3 Clasificación de principios y heurísticas
1.4 Transición de los requisitos del sistema a los modelos de arquitectura lógica y física
1,5 Iteraciones entre el desarrollo de modelos de arquitectura lógica y física
1,6 Noción de interfaz
1,7 Propiedades emergentes
1.8 Reutilización de elementos del sistema
2 Enfoque basado en procesos
2.1 Propósito
2.2 Actividades del proceso
2.2.1. Inicializar la definición de la arquitectura del sistema.
2.2.2. Definir los puntos de vista de la arquitectura necesarios
2.2.3. Desarrollar modelos y vistas de arquitecturas candidatas
2.2.4. Relacionar la arquitectura del sistema con el diseño del sistema.
2.2.5. Evaluar candidatos de arquitectura y seleccionar uno.
2.2.6. Gestionar la arquitectura seleccionada
2.3 Artefactos, métodos y técnicas de modelado
Proceso de definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.1 Noción de estructura

• La mayoría de las interpretaciones de la arquitectura del sistema se basan en

la noción bastante intangible de estructura: conjunto de elementos que
caracterizan un determinado ámbito de la realidad o sistema
• Algunos autores limitan los tipos de estructura considerados arquitectónicos;
por ejemplo, restringiéndose a la estructura funcional y física.
• La práctica reciente ha ampliado la consideración para incluir el
comportamiento , el tiempo y otras dimensiones de la estructura.
• ISO / IEC / IEEE 42010 Ingeniería de software y sistemas - Descripción de la
arquitectura (ISO 2011) proporciona una descripción útil de la arquitectura
considerando las preocupaciones de las partes interesadas, los puntos de
vista de la arquitectura , las vistas de la arquitectura , los modelos
de arquitectura, las descripciones de la arquitectura y la arquitectura a lo
largo del ciclo de vida.
Nota: Este documento lo pueden encontrar y bajar de la web aquí:
https://nanopdf.com/download/iso-iec-ieee-420102011e-systems-and-software-
engineering_pdf
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.2 Descripción de la arquitectura del sistema
• Un marco de arquitectura contiene puntos de vista estandarizados, plantillas de
vista, metamodelos, plantillas de modelos, etc. que facilitan el desarrollo de las
vistas de una arquitectura de sistema (consulte el marco de arquitectura para ver
ejemplos). ISO / IEC / IEEE 42010 (ISO 2011) especifica las características
normativas de los marcos de arquitectura, puntos de vista y vistas en lo que
respecta a la descripción de la arquitectura.

• Un punto de vista aborda una preocupación particular de un interesado ​(o un

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 inquietud (o conjunto de inquietudes), las formas
en que se deben generar los modelos y cómo se relacionan y se usan los
modelos para componer una vista.

• Los modelos (o vistas) lógicos y físicos se utilizan a menudo para representar

aspectos fundamentales de la arquitectura del sistema.
• Otros puntos de vista y vistas complementarios se utilizan necesariamente para
representar cómo la arquitectura del sistema aborda las preocupaciones de las
partes interesadas, por ejemplo, modelos de costos, modelos de procesos,
modelos de reglas, modelos ontológicos, modelos de creencias, modelos de
proyectos, modelos de capacidad, modelos de datos, etc.
 Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.3 Clasificación de principios y heurísticas

Los ingenieros y arquitectos utilizan una mezcla de principios matemáticos y heurísticos (lecciones aprendidas a
través de la experiencia, pero no probadas 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 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 del SoI desglosado en sistemas y
elementos del sistema . Se ocupa de los sistemas de particiones, los elementos del sistema y las interfaces
físicas.
2. El dominio dinámico se relaciona con los modelos de arquitectura lógica, particularmente con 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
las 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 eficacia (es decir, prestaciones, condiciones
operativas) del sistema.
3. El dominio temporal se relaciona con los niveles de invariancia temporal de la ejecución de funciones del
sistema. Esto significa que cada función se ejecuta de acuerdo con características cíclicas o síncronas.
Incluye niveles de decisión que son características asincrónicas del comportamiento de algunas funciones.
4. El dominio ambiental se relaciona con los facilitadores (producción, apoyo logístico, etc.), pero también con
la capacidad de supervivencia del sistema en reacción a peligros o amenazas naturales y con la integridad
del sistema en reacción a peligros potenciales internos. Esto incluye, por ejemplo, aspectos climáticos,
mecánicos, electromagnéticos y biológicos.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.4 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 (lo más independiente
posible de la tecnología) a través de un modelo intermedio de arquitectura lógica para
asignar los elementos del modelo de arquitectura lógica a los elementos del sistema de la
arquitectura fisca candidata.

• 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 a
fusionar los dos, lo que simplifica el manejo de múltiples aplicaciones 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 trazan los límites contractuales.

• Las decisiones de diseño y las soluciones tecnológicas se seleccionan de acuerdo con

los criterios de rendimiento y los requisitos no funcionales, como las condiciones operativas
y las 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
Figura 1. Uso de modelos de arquitectura lógica
intermedia durante la arquitectura y el diseño (Faisandier
frente a los requisitos del sistema que no tienen impactos tecnológicos importantes durante
2012). la vida del sistema, las interfaces físicas o la capa tecnológica sin cuestionar completamente
el funcionamiento lógico del sistema.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.5 Iteraciones entre el desarrollo de modelos de arquitectura lógica y
física

• 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 utiliza para determinar los elementos principales del sistema
que podrían realizar funciones del sistema y organizarlos.
• Las iteraciones posteriores del modelo de arquitectura lógica pueden tener en cuenta las
asignaciones de funciones a los elementos del sistema y las funciones derivadas que provienen de
las opciones de solución física. También complementa el modelo de arquitectura lógica inicial al
introducir otros escenarios, análisis de fallas y requisitos operativos que no se consideraron
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 coherentes
de la solución.
• Durante el diseño del sistema, las elecciones tecnológicas pueden conducir potencialmente a
nuevas funciones, nuevos flujos de control y entrada / salida, y nuevas interfaces físicas. Estos
nuevos elementos pueden dar lugar a la creación de nuevos requisitos del sistema, denominados
requisitos derivados.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.6 Noción de interfaz

• La noción de interfaz es una de las más importantes a considerar al

definir 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 realizadas por elementos físicos; estos se
denominan interfaces físicas.
• En consecuencia, tanto los aspectos funcionales como los 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 el otro y la
función “llevar” como lo realiza la interfaz física que soporta el flujo de
entrada / salida (ver Figura 2). Figura 2. Representación de interfaz completa (Faisandier
2012).
• En el contexto de intercambios complejos entre elementos del sistema,
particularmente en sistemas con uso intensivo de software, un protocolo
se ve como una interfaz física que transporta intercambios de datos. Sin
embargo, los flujos de entrada / salida pueden incluir muchos otros
intercambios además de datos, como energía.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.7 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 en su conjunto.
• 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 prevenir propiedades
indeseables y reforzar las deseables.
• Algunos autores utilizan el término propiedades emergentes para identificar
cualquier propiedad que surge de un sistema, mientras que otros pueden referirse
a esto como sinergia y reservar propiedad emergente para explicar propiedades
inesperadas o propiedades que no se consideraron completamente durante el
desarrollo del sistema, pero que han surgido durante la operación.
 Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.7 Propiedades emergentes

Tabla 1. Propiedades y propiedades emergentes. (SEBoK Original)

Amplias categorías de Descripción y ejemplos
propiedades
Propiedad local La propiedad está ubicada en un solo elemento del sistema, por ejemplo, la capacidad de un
contenedor es la capacidad del sistema.
Propiedad acumulativa del La propiedad se encuentra en varios elementos del sistema y se obtiene mediante la simple suma de
sistema propiedades elementales; por ejemplo, el peso del sistema resulta de la suma de los pesos de sus
elementos del sistema.

Propiedad emergente La propiedad existe en varios elementos del sistema y se modifica por sus interacciones; por ejemplo,
modificada por arquitectura y la confiabilidad / seguridad de un sistema resulta de la confiabilidad / seguridad de cada elemento
/ o interacciones. del sistema y la forma en que están organizados. Los pasos arquitectónicos suelen ser fundamentales
para cumplir con los requisitos del sistema.

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

Propiedad emergente Propiedad controlada o inhibida antes de salir del sistema, por ejemplo: desequilibrio eliminado
controlada mediante la adición de una carga; vibración amortiguada por un amortiguador.
 Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
1 Principios y conceptos generales
1.8 Reutilización de elementos del sistema

• Los ingenieros de sistemas utilizan con frecuencia los elementos del sistema existentes. Esta restricción de reutilización debe
identificarse como un requisito del sistema y debe 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.

Tabla 2. Casos de reutilización de elementos del sistema (Faisandier 2012)

Caso de reutilización Acciones y comentarios
Caso 1: Los requisitos del elemento del •La arquitectura del sistema a definir deberá adaptarse a los límites, interfaces, funciones, efectividad y
sistema están actualizados y se comportamiento del elemento del sistema reutilizado.
reutilizará sin necesidad de •Si el elemento del sistema no se adapta, es probable que aumenten los costos, la complejidad y los riesgos.
modificaciones.
Caso 2: Los requisitos del elemento del •La arquitectura del sistema que se va a definir es lo suficientemente flexible para adaptarse a los límites, las
sistema están actualizados y se interfaces, las funciones, la eficacia y el comportamiento del elemento del sistema reutilizado.
reutilizará con posibles modificaciones. •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 •Es necesario aplicar ingeniería inversa al elemento del sistema para identificar sus límites, interfaces, funciones,
actualizados o no existen. desempeños 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 cara 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 importantes para el proyecto (costos, plazos, complejidad).
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema

2 Enfoque basado en procesos

2.1 Objetivo

• 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 las partes interesadas y cumplan con los
requisitos del sistema, y ​expresar esto en un conjunto de puntos de vista
consistentes.
• Cabe señalar que las actividades de arquitectura a continuación se
superponen con las actividades de definición de sistemas y de definición de
conceptos.
• En particular, los aspectos clave del contexto operativo y de negocio 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 y encajarán
en cualquier enfoque de síntesis de soluciones que se haya seleccionado.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
2 Enfoque basado en procesos
2.2 Actividades del proceso

2.2.1. Inicializar la definición de la arquitectura del sistema.

• Desarrollar una comprensión del entorno / contexto de uso para el que se necesita un sistema a
fin de establecer una comprensión de las preocupaciones de las partes interesadas.
• Para hacer esto, analice información relevante de mercado, industria, partes interesadas,
empresa, negocio, operaciones, misión, legal y otra información que ayude a comprender las
perspectivas que podrían guiar la definición de las vistas y modelos de la arquitectura del
sistema.
• Capture las preocupaciones de las partes interesadas (es decir, expectativas o limitaciones)
que abarquen las etapas del ciclo de vida del sistema. Las preocupaciones a menudo están
relacionadas con características críticas del sistema que se relacionan con las etapas; deben
traducirse o incorporarse a los requisitos del sistema.
• Etiquete los requisitos del sistema que se ocupan de las condiciones operativas (p. Ej.,
Protección, seguridad, confiabilidad, factores humanos, interfaces, condiciones ambientales) y
restricciones del ciclo de vida (p. Ej., Mantenimiento, eliminación, despliegue) que influirían en
la definición de los elementos de la arquitectura.
• Establecer una hoja de ruta y una estrategia de arquitectura que debería incluir métodos,
técnicas de modelado, herramientas, necesidad de sistemas, productos o servicios habilitantes,
requisitos de proceso (por ejemplo, métodos y enfoques de medición), proceso de evaluación
(por ejemplo, revisiones y criterios).
• Planificar la adquisición de productos o servicios habilitadores (necesidades, requisitos,
compras).
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
2 Enfoque basado en procesos
2.2 Actividades del proceso

2.2.2 Definir los puntos de vista de la arquitectura necesarios

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

2.2.3 Desarrollar modelos y vistas de arquitecturas candidatas

• Utilizando técnicas y herramientas de modelado relevantes, y junto con el proceso de Necesidades y

requisitos de las partes interesadas y el proceso de Requisitos del sistema , determine el contexto del
sistema de interés, incluido 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 la definición o comprensión de los escenarios operativos esperados
y / o comportamientos del sistema dentro de su contexto de uso.
• Definir entidades arquitectónicas (p. Ej., 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 (p. Ej. ,
requisitos funcionales, requisitos de interfaz, requisitos ambientales, condiciones operativas [confiabilidad,
factores humanos, etc.], limitaciones [dimensiones físicas, producción, mantenimiento, eliminación]).
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema

2 Enfoque basado en procesos

2.2 Actividades del proceso

2.2.3 Desarrollar modelos y vistas de arquitecturas candidatas (cont)

• 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).
• Seleccionar, adaptar o desarrollar modelos de las arquitecturas candidatas del sistema, como modelos lógicos y físicos
(consulte Desarrollo de modelos de arquitectura lógica y Desarrollo de modelos 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 abordan las
preocupaciones clave de las partes interesadas.
• A partir de los modelos de las arquitecturas candidatas, elabore vistas que sean relevantes para las preocupaciones de
las partes interesadas y los requisitos críticos o importantes.
• Definir los 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).
Utilice el Proceso de Definición de la Arquitectura del Sistema para definirlos y formalizarlos.
• Compruebe la coherencia de los modelos y las vistas y resuelva los problemas identificados. Para esto se puede utilizar
ISO / IEC / IEEE 42010, 2011.
• Verificar y validar los modelos mediante ejecución o simulación, si las técnicas y herramientas de modelado lo permiten.
Cuando sea posible, use herramientas de diseño para verificar la viabilidad y validez, y / o implemente maquetas
parciales, o use prototipos o simuladores de arquitectura ejecutable.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema

2 Enfoque basado en procesos

2.2 Actividades del proceso

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

• Defina los elementos del sistema que reflejen las características arquitectónicas (cuando se pretende que la arquitectura
sea independiente del diseño, estos elementos del sistema pueden ser teóricos hasta que el diseño evolucione). Para
hacer esto, particione, alinee y asigne características arquitectónicas y requisitos del sistema a los elementos del
sistema. Establecer principios rectores para el diseño y 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
verificar la viabilidad del diseño.
• Definir interfaces para aquellas que sean 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,
alineación y división de las propiedades de diseño y los requisitos del sistema para 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 la
Arquitectura del Sistema .
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
2 Enfoque basado en procesos
2.2 Actividades del proceso

2.2.5 Evaluar candidatos de arquitectura y seleccionar uno

• Evalúe las arquitecturas candidatas utilizando los criterios de evaluación de la arquitectura. Esto se hace mediante la
aplicación de los procesos de Análisis , Medición y Gestión de Riesgos del Sistema .
• Seleccione las arquitecturas preferidas. Esto se hace mediante la aplicación del proceso de Gestión de decisiones .

2.2.6. Gestionar la arquitectura seleccionada

• Establecer y mantener el fundamento de todas las selecciones entre alternativas y decisiones para la arquitectura, los
marcos de la arquitectura, los puntos de vista, los tipos de modelos y los modelos de la arquitectura.
• Gestionar el mantenimiento y la evolución de la descripción de la arquitectura, incluidos los modelos y las vistas. Esto
incluye concordancia, completitud, cambios debidos a cambios ambientales o de contexto, y experiencias tecnológicas,
de implementación y 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 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.
Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema

2 Enfoque basado en procesos

2.3 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 de arquitectura).
• El contenido, formato, diseño y 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.
 Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
 Consideraciones prácticas
 Trampas:
 Algunos de los obstáculos clave encontrados en la planificación y ejecución de
la arquitectura del sistema se proporcionan en la Tabla 3.
Tabla 3. Dificultades con la definición de la arquitectura del sistema. (Original SEBoK)
Trampa Descripción
Relevancia del problema Si la arquitectura se desarrolla sin el aporte de las preocupaciones de las partes
interesadas o no puede entenderse y relacionarse con sus problemas, podría
perder las inversiones de la comunidad de partes interesadas.
Reutilización de Elementos del En algunos proyectos, con fines industriales, los productos o servicios existentes se
Sistema imponen muy pronto como restricciones de arquitectura/diseño en los requisitos de
los interesados o en los requisitos del sistema, sin prestar suficiente atención al nuevo
contexto de uso del sistema en el que también se incluyen. . Es mejor trabajar en la
dirección correcta desde el principio. Primero defina el sistema, tenga en cuenta
otros requisitos y luego vea si hay disponibles elementos no relacionados con el
desarrollo (NDI) adecuados. 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 cada contexto de uso.
 Proceso de Definición de la Arquitectura del Sistema
2. Enfoque SEBoK – Arquitectura del sistema
 Consideraciones prácticas
 Prácticas Comprobadas:
 Algunas prácticas probadas recopiladas de las referencias se proporcionan en
la Tabla 4.

Tabla 4. Prácticas comprobadas con Definición de Arquitectura del Sistema. (Original SEBoK)
Práctica Descripción
Propiedades emergentes Controlar las propiedades emergentes de las interacciones entre
los sistemas o los elementos del sistema; obtener las propiedades
sinérgicas requeridas y controlar o evitar los comportamientos no
deseados (vibraciones, ruido, inestabilidad, resonancia, etc.).
Proceso de Definición de Arquitectura
3. ENFOQUE DEL INCOSE
Proceso de definición de necesidades y requisitos de los interesados
3. Introducción

Procesos Ténicos
del Modelo
ISO 15288:2015
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Propósito (segun 15288) - Para:
– Generar alternativas de arquitectura del sistema, para seleccionar una o más
alternativas que enmarquen las preocupaciones de las partes interesadas y
cumplan con los requisitos del sistema, y ​para expresar esto en un conjunto de
puntos de vista consistentes.
– Descripción:
• Las actividades de arquitectura y diseño del sistema permiten la creación de una
solución global basada en principios, conceptos y propiedades lógicamente relacionados
y consistentes entre sí.
• La arquitectura y el diseño de la solución tienen propiedades y características que
satisfacen, en la medida de lo posible, el problema u oportunidad expresada por:
– Un conjunto de requisitos del sistema (rastreables a la misión / negocios y
requisitos de las partes interesadas), y conceptos del ciclo de vida (por ejemplo,
operativo, soporte)
– Implementable a través de tecnologías (por ejemplo, mecánica, electrónica,
hidráulica, software, servicios, procedimientos).
• La arquitectura del sistema es más abstracta, orientada a la conceptualización,
global, enfocada:
– a lograr la misión y el concepto operativo del sistema
– enfocada en la estructura de alto nivel en los sistemas y elementos del sistema
– Aborda los principios, conceptos, propiedades y características arquitectónicas del
SOI
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• El proceso de definición de arquitectura (AD) agrega y se ocupa de los conocimientos
incrementales obtenidos sobre los requisitos especificados y las propiedades y comportamientos
emergentes del sistema y los elementos del sistema, mientras se gestiona la idoneidad, viabilidad
y asequibilidad.
• Para obtener información sobre los usos de la definición de arquitectura, consulte ISO / IEC /
IEEE 42010.
• El Proceso AD se utiliza para crear y establecer arquitecturas alternativas a través de varias
vistas y modelos, para:
• Evaluar las propiedades de estas alternativas (respaldadas por el proceso de análisis del
sistema)
• Seleccionar los elementos tecnológicos o técnicos apropiados del sistema que componen el
sistema:
• Según 15288, una arquitectura eficaz:
• Es tan independiente del diseño como sea posible para permitir la máxima flexibilidad
en el espacio comercial del diseño.
• Destaca y respalda las compensaciones para el proceso de DD y posiblemente otros
procesos como la gestión de la cartera, la planificación de proyectos, la definición de
requisitos del sistema, la verificación, etc.
• El proceso AD es iterativo y requiere la participación de ingenieros de sistemas o arquitectos
apoyados por diseñadores y especialistas relevantes en el dominio de sistemas.
• Se espera la iteración entre el proceso AD y otros a medida que se disponga de más información
y se realice el análisis.
• El proceso AD también se sigue aplicando de forma recursiva para definir los requisitos de cada
elemento del sistema.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Términos clave utilizados en esta sección:
– Arquitectura - (sistema) conceptos o propiedades fundamentales de un
sistema en su entorno incorporados en sus:
• elementos,
• relaciones, y en el
• principios de su diseño y evolución.
– Descripción de la arquitectura: producto de trabajo utilizado para expresar una
arquitectura.
– Marco de arquitectura: convenciones, principios y prácticas para la descripción de
arquitecturas establecidas dentro de un dominio específico de aplicación y / o
comunidad de partes interesadas.
– Vista de arquitectura: producto de trabajo que expresa la arquitectura de un
sistema desde la perspectiva de preocupaciones específicas del sistema.
– Punto de vista de la arquitectura - producto de trabajo que establece las
convenciones para la :
• construcción,
• interpretación, y
• uso de
• vistas de arquitectura para enmarcar preocupaciones específicas del sistema.
– Preocupación: interés (del sistema) en un sistema relevante para uno o más de sus interesados.
– Entidades arquitectónicas – Elementos de arquitectura que sirven para la descripción del
sistema, por ejemplo, funciones, flujos de funciones, flujos de entrada / salida, elementos del
sistema, interfaces, características arquitectónicas, elementos de información / datos,
contenedores, nodos, enlaces, recursos de comunicación, elementos de flujo de recursos,
elementos físicos, etc.)
Diagrama IPO del Proceso de Definición de Arquitectura
Controles

Entrada Actividades Salida

• Conceptos de ciclo de • Estrategia de definición
vida • Prepárese para la de arquitectura
• Definición de la función definición de • Descripción de la
del sistema arquitectura arquitectura del sistema
• Requisitos del sistema • Desarrollar puntos de • Justificación de la
• Identificación de la vista de la arquitectura arquitectura del sistema
interfaz funcional del • Desarrollar modelos y • Árbol de
sistema vistas de arquitecturas documentación
• Trazabilidad de los candidatas. • Definición de interfaz
requisitos del sistema • Relacionar la preliminar
• RVTM actualizado arquitectura con el • Necesidades
• Trazabilidad del diseño diseño preliminares de TPM
• Identificación de • Evaluar candidatos de • Datos preliminares de
actualización de arquitectura TPM
definición de interfaz • Gestionar la arquitectura • Trazabilidad de la
• Restricciones del ciclo seleccionada arquitectura
de vida • Registro de definición de
arquitectura
Facilitadores
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Entradas:
– Conceptos de ciclo de vida: articulación y refinamiento de los diversos conceptos de ciclo de
vida de acuerdo con las necesidades comerciales en forma de documentos de concepto de
Entrada
ciclo de vida en los que se basa, evalúa y selecciona el sistema de interés.
• La arquitectura se basa en estos conceptos y son esenciales para proporcionar un • Conceptos de ciclo de
contexto para la interpretación adecuada de los requisitos del sistema. vida
• Los conceptos típicos incluyen : • Definición de la función
– Concepto de adquisición del sistema
– Concepto de implementación • Requisitos del sistema
– Concepto operativo (OpsCon) • Identificación de la
– Concepto de soporte interfaz funcional del
– Concepto de retiro. sistema
– Definición de la función del sistema: definición de los límites funcionales del • Trazabilidad de los
sistema y las funciones que debe realizar el sistema. requisitos del sistema
– Requisitos del sistema: qué debe hacer el sistema, qué tan bien y bajo qué • RVTM actualizado
condiciones, según sea necesario para cumplir con las limitaciones del • Trazabilidad del diseño
proyecto y del diseño. • Identificación de
– Incluye tipos de requisitos tales como funcional, rendimiento, interfaz, actualización de
comportamiento (p Ej., Estados y modos, respuestas de estímulo, manejo de definición de interfaz
fallas y fallas),
• Restricciones del ciclo
– Condiciones operativas (p. Ej., Seguridad, confiabilidad, factores humanos,
de vida
condiciones ambientales),
– transporte, almacenamiento, restricciones, realización, integración, verificación,
validación, producción, mantenimiento, restricciones de eliminación y regulación.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Entradas (cont)
– Requisitos del sistema cont)
• Los requisitos del sistema se pueden capturar en un documento llamado Especificación Entrada
de requisitos del sistema (SyRS) o simplemente Especificación del sistema.
• Conceptos de ciclo de
• Esto incluye los requisitos en cualquier nivel de la jerarquía del sistema..
vida
– Identificación de la interfaz funcional del sistema: identificación y • Definición de la función
documentación de las interfaces funcionales con sistemas externos a los del sistema
límites y los requisitos de intercambio de información correspondientes. • Requisitos del sistema
– Trazabilidad de los requisitos del sistema: trazabilidad bidireccional de los • Identificación de la
requisitos del sistema interfaz funcional del
– RVTM actualizado: una lista actualizada de requisitos, sus atributos de sistema
verificación y sus rastros • Trazabilidad de los
– Trazabilidad del diseño: trazabilidad bidireccional de las características de la requisitos del sistema
arquitectura • RVTM actualizado
– Identificación de actualización de definición de interfaz: identificación de • Trazabilidad del diseño
actualizaciones de interfaz requisitos y definiciones, en su caso. • Identificación de
actualización de
– Restricciones del ciclo de vida: restricciones de todos los procesos del ciclo
definición de interfaz
de vida aplicables, incluidas las restricciones de implementación, integración,
• Restricciones del ciclo
verificación, transición, validación, operación, mantenimiento y eliminación..
de vida
 Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Actividades
– Prepárese para la definición de la arquitectura
– Identificar y analizar información relevante de mercado, industria, partes interesadas,
organizacional, comercial, operaciones, misión, legal y de otro tipo que ayudará a Actividades
comprender las perspectivas que guiarán el desarrollo de las vistas y modelos de
arquitectura..
– Esta información está destinada a ayudar a desarrollar una comprensión del entorno • Prepárese para la
para el que se necesita la solución a fin de establecer una mejor comprensión de las definición de
preocupaciones de las partes interesadas. arquitectura
– Analice los requisitos del sistema y etiquete requisitos no funcionales, que influirán • Desarrollar puntos de
fuertemente en definición de los elementos de la solución. vista de la arquitectura
– Captar las preocupaciones de las partes interesadas relacionadas con la arquitectura • Desarrollar modelos y
– Establecer el enfoque para definir la arquitectura. vistas de arquitecturas
– Asegúrese de que los elementos o servicios habilitadores estén disponibles. candidatas.
• Relacionar la
arquitectura con el
diseño
• Evaluar candidatos de
arquitectura
• Gestionar la arquitectura
seleccionada
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Actividades (cont)
– Desarrollar puntos de vista de la arquitectura.
• Con base en las preocupaciones identificadas de las partes interesadas, establezca o Actividades
identifique los puntos de vista de la arquitectura asociados, los tipos de modelos de apoyo
que facilitan el análisis y la comprensión del punto de vista y los marcos de arquitectura
relevantes para apoyar el desarrollo de los modelos y las vistas.. • Prepárese para la
– Desarrollar modelos y vistas de arquitecturas candidatas. definición de
• Utilizando técnicas y herramientas de modelado relevantes, y junto con el proceso de arquitectura
Necesidades y requisitos de las partes interesadas y el proceso de Requisitos del sistema, • Desarrollar puntos de
determine el contexto del sistema de interés, incluido el límite con los elementos del vista de la arquitectura
entorno externo. Esta tarea incluye la identificación de relaciones, interfaces o conexiones, • Desarrollar modelos y
intercambios e interacciones del sistema de interés con elementos externos. Esta tarea vistas de arquitecturas
permite la definición o comprensión de los escenarios operativos esperados y / o candidatas.
comportamientos del sistema dentro de su contexto de uso. • Relacionar la
• Definir entidades arquitectónicas (p. Ej., Funciones, flujos de entrada / salida, elementos arquitectura con el
del sistema, interfaces físicas, características arquitectónicas, elementos de información / diseño
datos, contenedores, nodos, enlaces, recursos de comunicación, etc.), que abordan los • Evaluar candidatos de
diferentes tipos de requisitos del sistema (p. Ej. , requisitos funcionales, requisitos de
arquitectura
interfaz, requisitos ambientales, condiciones operativas [confiabilidad, factores humanos,
• Gestionar la arquitectura
etc.], limitaciones [dimensiones físicas, producción, mantenimiento, eliminación]).
seleccionada
• 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).
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Activities (cont)
– Desarrollar modelos y vistas de arquitecturas candidatas.(cont)
Actividades
• Seleccione, adapte o desarrolle modelos de las arquitecturas candidatas del
sistema, como modelos lógicos y físicos (consulte Desarrollo de modelos de
arquitectura lógica y Desarrollo de modelos de arquitectura física ). A veces no es
necesario ni suficiente utilizar modelos lógicos y físicos. Los modelos que se utilizarán • Prepárese para la
son los que mejor abordan las preocupaciones clave de las partes interesadas. definición de
• A partir de los modelos de las arquitecturas candidatas, elabore vistas que sean arquitectura
relevantes para las preocupaciones de las partes interesadas y los requisitos críticos • Desarrollar puntos de
o importantes. vista de la arquitectura
• Definir los requisitos del sistema derivados inducidos por instancias necesarias de • Desarrollar modelos y
entidades arquitectónicas (por ejemplo, funciones, interfaces) y por disposiciones vistas de arquitecturas
estructurales (por ejemplo, restricciones, condiciones operativas). Utilice el proceso de candidatas.
definición de requisitos del sistema para definirlos y formalizarlos.
• Relacionar la
• Compruebe la coherencia de los modelos y las vistas y resuelva los problemas
identificados. Para esto se puede utilizar ISO / IEC / IEEE 42010, 2011. arquitectura con el
• Verificar y validar los modelos mediante ejecución o simulación, si las técnicas y diseño
herramientas de modelado lo permiten. Cuando sea posible, use herramientas de • Evaluar candidatos de
diseño para verificar la viabilidad y validez, y / o implemente maquetas parciales, o arquitectura
use prototipos o simuladores de arquitectura ejecutable. • Gestionar la arquitectura
seleccionada
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Activities (cont)
– Relacionar la arquitectura con el diseño.
Actividades
• Determinar los elementos del sistema que reflejan las entidades
arquitectónicas..
– Dado que la arquitectura está destinada a ser independiente del diseño, • Prepárese para la
estos elementos del sistema pueden ser teóricos hasta que el diseño definición de
evolucione. arquitectura
– Para hacer esto, particione, alinee y asigne entidades arquitectónicas y • Desarrollar puntos de
requisitos del sistema a los elementos del sistema. vista de la arquitectura
– Establecer principios rectores para el diseño y evolución del sistema. • Desarrollar modelos y
– A veces, se crea una "arquitectura de referencia" utilizando estos vistas de arquitecturas
elementos del sistema teórico como un medio para transmitir la intención
candidatas.
arquitectónica y verificar la viabilidad del diseño..
• Relacionar la
• Establecer matrices de asignación entre entidades arquitectónicas
arquitectura con el
utilizando sus relaciones.
diseño
• Realizar la definición de interfaz para las interfaces que son
necesarias para el nivel de detalle y comprensión de la arquitectura.
• Evaluar candidatos de
arquitectura
– La definición incluye las interfaces internas entre los elementos del
sistema y las interfaces externas con otros sistemas.. • Gestionar la arquitectura
seleccionada
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Actividades (cont)
– Relacionar la arquitectura con el diseño(cont) Actividades
• Determine las características de diseño que se relacionan con los elementos del
sistema y sus entidades arquitectónicas, por ejemplo, mediante el mapeo
• Prepárese para la
• Determinar la necesidad de requisitos del sistema derivados inducidos por las definición de
entidades arquitectónicas añadidas necesarias (por ejemplo, funciones, interfaces)
arquitectura
y por disposiciones estructurales (por ejemplo, restricciones, condiciones
operativas). • Desarrollar puntos de
vista de la arquitectura
• Utilice el Proceso de Definición de la Arquitectura del Sistema para formalizarlos.
• Desarrollar modelos y
• Para cada elemento del sistema que compone el sistema principal, desarrolle los
vistas de arquitecturas
requisitos correspondientes a la asignación, alineación y partición de las entidades
arquitectónicas y los requisitos del sistema para los elementos del sistema.. candidatas.
– Para ello, invoque el proceso de definición de necesidades y requisitos de las • Relacionar la
partes interesadas y el Proceso de Definición de la Arquitectura del Sistema .. arquitectura con el
diseño
– Evaluar candidatos de arquitectura.
• Evaluar candidatos de
• Utilizando los criterios de evaluación de la arquitectura, evalúe las
arquitectura
arquitecturas candidatas aplicando los procesos de análisis, medición
• Gestionar la arquitectura
y gestión de riesgos del sistema.
seleccionada
• Seleccione las arquitecturas preferidas. Esto se hace aplicando el
proceso de gestión de decisiones.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Actividades (cont)
– Gestionar la arquitectura seleccionada.
• Capturar y mantener el fundamento de todas las selecciones entre alternativas y Actividades
decisiones para la arquitectura, los marcos de la arquitectura, los puntos de vista,
los tipos de modelos y los modelos de la arquitectura.
• Gestionar el mantenimiento y la evolución de la arquitectura, incluidas las • Prepárese para la
entidades arquitectónicas, sus características (por ejemplo, entidades técnicas, definición de
legales, económicas, organizativas y operativas), modelos y vistas. arquitectura
– Esto incluye la concordancia, la integridad y los cambios debidos a cambios en el • Desarrollar puntos de
entorno o el contexto, experiencias tecnológicas, de implementación y operativas.
– Las matrices de asignación y trazabilidad se utilizan para analizar los impactos en la vista de la arquitectura
arquitectura. • Desarrollar modelos y
– El presente proceso se realiza en cualquier momento en que se produzcan
evoluciones del sistema.. vistas de arquitecturas
• Establecer un medio para la gobernanza de la arquitectura.. candidatas.
– La gobernanza incluye los roles, responsabilidades, autoridades y otras funciones de • Relacionar la
control. arquitectura con el
• Coordinar la revisión de la arquitectura para lograr los acuerdos de las partes diseño
interesadas. • Evaluar candidatos de
– Los requisitos de las partes interesadas y los requisitos del sistema pueden servir arquitectura
como referencias. • Gestionar la arquitectura
seleccionada
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Salidas
– Estrategia de definición de arquitectura: enfoques, programas, recursos y
consideraciones específicas necesarias para definir la arquitectura del sistema Salida
seleccionado que satisfaga los requisitos.
• Estrategia de definición
– Descripción de la arquitectura del sistema: descripción de la arquitectura del
sistema seleccionada, normalmente presentada en un conjunto de vistas de arquitectura
arquitectónicas (por ejemplo, vistas desde marcos de arquitectura), modelos (por • Descripción de la
ejemplo, modelos lógicos y físicos, aunque hay otros tipos de modelos que pueden arquitectura del sistema
ser útiles). y características arquitectónicas (por ejemplo, dimensiones físicas, • Justificación de la
resistencia ambiental, eficiencia de ejecución, operabilidad, confiabilidad,
arquitectura del sistema
mantenibilidad, modularidad, robustez, protección, comprensibilidad, etc.) (42010).
Los elementos del sistema de importancia arquitectónica se identifican y definen • Árbol de
hasta cierto punto en este artefacto. (Es posible que sea necesario agregar otros documentación
elementos del sistema durante el proceso de definición del diseño a medida que • Definición de interfaz
se desarrolla el diseño). preliminar
– Fundamento de la arquitectura del sistema: fundamento para la selección de la • Necesidades
arquitectura, la selección de elementos tecnológicos / técnicos del sistema y la preliminares de TPM
asignación entre los requisitos del sistema y las entidades arquitectónicas (por
ejemplo, funciones, flujos de entrada / salida, elementos del sistema, interfaces • Datos preliminares de
físicas, características arquitectónicas, elementos de información / datos, TPM
contenedores, nodos, enlaces, recursos de comunicación). • Trazabilidad de la
– Árbol de documentación: define la representación jerárquica del conjunto de arquitectura
productos de definición de sistema para el sistema en desarrollo. Basado en la • Registro de definición de
arquitectura del sistema en evolución. arquitectura
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Salidas (cont)
– Definición preliminar de la interfaz: los aspectos preliminares lógicos y físicos Salida
de las interfaces internas (entre los elementos del sistema que componen el
sistema) y las interfaces externas (entre los elementos del sistema del sistema • Estrategia de definición
y los elementos externos al sistema de interés). de arquitectura
• Descripción de la
– Necesidades preliminares del TPM: identificación preliminar del TPM, que
arquitectura del sistema
mide los atributos de un elemento del sistema para determinar qué tan bien un
• Justificación de la
sistema o elemento del sistema satisface o se espera que satisfaga un requisito
arquitectura del sistema
o objetivo técnico.
• Árbol de
– Datos preliminares de TPM: datos preliminares proporcionados para las documentación
necesidades de medición identificadas. • Definición de interfaz
– Trazabilidad de la arquitectura: trazabilidad bidireccional de las preliminar
características de la arquitectura. • Necesidades
– Registro de definición de arquitectura: forma permanente y legible de datos, preliminares de TPM
información o Conocimientos relacionados con la definición de arquitectura.. • Datos preliminares de
TPM
• Trazabilidad de la
arquitectura
• Registro de definición de
arquitectura
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Elaboración
– Representación de arquitectura.
• La noción de sistema es abstracta, pero es un medio práctico para crear, diseñar
o rediseñar productos, servicios o empresas.
– Un sistema es una solución que podría abordar / responder a un problema o una
oportunidad; puede haber varias soluciones para abordar el mismo problema u
oportunidad.
– La solución puede ser más o menos compleja y la noción de sistema es útil para
diseñar soluciones complejas.
– Una solución compleja no se puede aprehender con una sola vista o modelo
debido a la cantidad de características o propiedades.
– Estos últimos se agrupan reflejando tipologías de datos, y cada tipo de dato /
característica está estructurado.
– El conjunto de diferentes tipos y "estructuras" interrelacionadas puede entenderse
como la arquitectura del sistema.
– La mayoría de las interpretaciones de la arquitectura del sistema se basan en la
noción bastante intangible de estructura..
• Por lo tanto, la arquitectura del sistema se representa formalmente con conjuntos
de entidades arquitectónicas como funciones, flujos de funciones, interfaces,
elementos de flujo de recursos, elementos de información / datos, elementos
físicos, contenedores, nodos, enlaces, recursos de comunicación, etc..
– Estas entidades arquitectónicas pueden poseer características arquitectónicas tales
como dimensiones, resiliencia ambiental, disponibilidad, robustez, capacidad de
aprendizaje, eficiencia de ejecución, efectividad de la misión, etc.
– Las entidades no son independientes sino que están interrelacionadas por medio de
relaciones.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Elaboration (cont)
– Descripción de la arquitectura del sistema.
• 42010 especifica las características normativas de los marcos de arquitectura, puntos de vista y vistas en lo que
respecta a la descripción de la arquitectura..
– Los puntos de vista y las vistas a veces se especifican en marcos de arquitectura como Zachman (1987), DoDAF
(2010), MoDAF (n.d.) y The Open Group Architecture Framework (TOGAF), etc.
– Las vistas generalmente se generan a partir de modelos.
– Muchas prácticas de SE utilizan modelos (o vistas) lógicos y físicos para modelar la arquitectura del sistema..
• El proceso AD incluye también el posible uso de otros puntos de vista y vistas para
• representar cómo la arquitectura del sistema aborda las preocupaciones de las partes interesadas, por ejemplo :
– Modelos de costos, modelos de procesos, modelos de reglas, modelos ontológicos, modelos de creencias, modelos de
proyectos, modelos de capacidad, modelos de datos, etc.
– Maier y Rechtin (2009) proporcionan otra visión del proceso de desarrollo de la arquitectura del sistema.
– Consulte el Capítulo 9 para obtener un tratamiento más detallado de los modelos..
• Un punto de vista está destinado a abordar una inquietud particular de las partes interesadas (o un conjunto de
inquietudes estrechamente relacionadas).
– El punto de vista especificará los tipos de modelos que se utilizarán en el desarrollo de una vista arquitectónica que
describa cómo
– la arquitectura aborda esa inquietud (o conjunto de inquietudes).
– El punto de vista también especifica las formas en que se deben generar los modelos y cómo se utilizan los modelos para
componer la vista..
• Un marco de arquitectura contiene puntos de vista estandarizados, plantillas de vistas, metamodelos, plantillas
de modelos, etc. que facilitan el desarrollo de las vistas contenidas en una descripción de arquitectura.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Elaboración (cont)
– Propiedades emergentes.
• Emergencia: el principio de que las entidades completas exhiben propiedades, que
son significativas solo cuando se atribuyen al todo, no a sus partes..
Todo modelo de un sistema de actividad humana exhibe propiedades como una entidad
completa que se derivan de las actividades que lo componen y su estructura, pero no puede
reducirse a ellas (Checkland, 1998).
• Los elementos del sistema interactúan entre sí y pueden crear fenómenos deseables o
indeseables llamados "propiedades emergentes", como inhibición, interferencia,
resonancia o refuerzo de cualquier propiedad.
• La definición de la arquitectura del sistema incluye un análisis de las interacciones entre
los elementos del sistema para prevenir propiedades indeseables y reforzar las
deseables.
• La noción de propiedad emergente se utiliza durante la arquitectura y el diseño para
resaltar las funciones derivadas necesarias y las limitaciones físicas o ambientales
internas.
• Los requisitos derivados correspondientes deben agregarse a la línea de base de los
requisitos del sistema cuando afectan el SOI.
– Arquitectura en líneas de productos.
• La arquitectura juega un papel muy importante en una línea de productos..
– La arquitectura en una línea de productos abarca varias variantes de diseño,
proporcionando una base cohesiva para los diseños de la línea de productos al garantizar la
compatibilidad e interoperabilidad en toda la línea de productos.
 Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Elaboracion (cont)
– Noción de interfaz.
• Uno de los elementos más importantes a considerar al definir la arquitectura de un
sistema.
– El término "inter face" proviene de las palabras latinas "inter" y "facere" y significa "hacer
algo entre cosas.”
• 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, las entradas / salidas de las
funciones también son transportadas por elementos físicos, llamados interfaces físicas..
– En consecuencia, tanto los aspectos funcionales como los físicos se consideran en la noción de
interfaz.
• Ejemplos de elementos del sistema e interfaces físicas:
Elemento Sistema de producto Sistema de servicio Sistema empresarial
Elemento de Sistema Piezas de hardware (mecánica, Procesos, bases de datos, Corporativo, dirección,
electrónica, eléctrica, plástica, procedimientos, etc. división, departamento,
química, etc.) proyecto, equipo técnico,
líder, etc.
Roles de operador
Roles de operador Componentes de TI
Piezas de software
Aplicaciones de software

Interface Física Partes de hardware, protocolos, Protocolos, documentos, etc. Protocolos, procedimientos,
procedimientos, etc. documentos,
212etc.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Elaboración (cont)
– Noción de interfaz(cont)
• Una representación de una interfaz en la Figura 4.7
muestra :
– La función "enviar", ubicada en un elemento del sistema;
– La función “recibir”, ubicada en el otro; y
– La interfaz física que admite el flujo de entrada / salida.
• En el contexto de intercambios complejos entre
elementos del sistema en sistemas de tecnología de la
información (TI), un protocolo se considera una interfaz
física que transporta intercambios de datos..
4.4 Architecture Definition Process (cont)
• Elaboración (cont)
– Matriz de acoplamiento (también llamada diagrama N2)
• Un método básico para definir los agregados y el orden de
integración (Grady, 1994).
– Se utiliza durante la definición de la arquitectura, con el objetivo de
mantener las interfaces lo más simples posible (ver Fig. 4.8).
– La simplicidad de las interfaces puede ser una característica distintiva y
un criterio de selección entre candidatos arquitectónicos alternativos.
– También es útil para optimizar la definición agregada y la verificación de
interfaces

Figure 4.8 (a ) Disposición inicial de agregados; (b) arreglo final después de la reorganización. Reproducido
con permiso de Alain Faisandier. Todos los demás derechos reservados. No se puede copiar, escanear o
duplicar, total o parcialmente, excepto para el uso permitido por la licencia en un sitio web protegido con
contraseña para uso instructivo.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema

• Elaboración (cont)
– Asignación y partición de entidades lógicas a entidades físicas.
• La definición de un modelo estructural físico de la arquitectura de un sistema consiste en :
– Identificar los elementos del sistema capaces de realizar las funciones de los modelos lógicos.
– Identificar las interfaces físicas capaces de transportar flujos de entrada / salida y controlar los flujos, y
– Teniendo en cuenta las características arquitectónicas que caracterizan el sistema en el que se incluyen.
• El término asignación no significa simplemente asignar entidades lógicas a elementos del sistema
existentes.
– Medios de partición y asignación para separar, reunir o descomponer entidades lógicas en particiones
– y luego hacer la correspondencia entre estas particiones y los elementos potenciales del sistema.
• Los elementos del sistema existen (reutilizables, reutilizados o adquiribles) o pueden desarrollarse
e implementarse técnicamente.
• Los requisitos no funcionales y / o las características arquitectónicas se utilizan como criterios para
analizar, evaluar y seleccionar los elementos del sistema y las particiones lógicas candidatos..
– Ejemplos de criterios de evaluación incluyen transformaciones similares dentro de la misma tecnología, nivel
similar de eficiencia, intercambio del mismo tipo de flujos de entrada / salida (información, energía, materiales),
controles centralizados o distribuidos, ejecución con un nivel de frecuencia cercano, condiciones de
confiabilidad, resistencia ambiental nivel y otras limitaciones empresariales.
Proceso de Definición de la Arquitectura del Sistema
3. Enfoque INCOSE – Arquitectura del sistema
• Elaboración (cont)
– Definición de arquitecturas candidatas y selección de la preferida.
• El objetivo del proceso AD es proporcionar la "mejor" arquitectura posible hecha de varias
arquitecturas candidatas; analizar, evaluar y comparar los elementos e interfaces adecuados
del sistema, es decir :
– La arquitectura que responde, en el mejor de los casos, a todas las partes interesadas y los
requisitos del sistema, en función de los límites o márgenes acordados de cada requisito.
– La forma preferida de hacer esto es produciendo m; y luego seleccionando el más
adecuado.
• Las arquitecturas candidatas se definen de acuerdo con criterios o controladores para
construir un conjunto de elementos del sistema (por ejemplo, separar, reunir, conectar y
desconectar la red de elementos del sistema y sus interfaces físicas).
– Los criterios o impulsores pueden incluir la reducción del número de interfaces, elementos
del sistema que se pueden probar por separado, modularidad (es decir, baja
interdependencia), reemplazabilidad de elementos del sistema durante el mantenimiento,
tecnología compatible, proximidad de elementos en el espacio, manipulación (por ejemplo,
peso, volumen, medios de transporte) y optimización de recursos e información compartida
entre elementos.
– Métodos y técnicas de modelado.
• El modelado, la simulación y la creación de prototipos utilizados durante la definición de la
arquitectura pueden reducir significativamente el riesgo de falla en el sistema terminado.
• Los ingenieros de sistemas utilizan técnicas de modelado y simulación en sistemas
grandes y complejos para gestionar el riesgo de falla en el cumplimiento de la misión del
sistema y los requisitos de rendimiento.
• Estos los realizan mejor los expertos en la materia que desarrollan y validan los modelos,
realizan las simulaciones y analizan los resultados.
Arquitectura en Ingeniería
de Software
Proceso de Definición de Arquitectura
Ingeniería de Software
Arquitectura Lógica
 Una arquitectura de software, también
denominada arquitectura lógica,
consiste en un conjunto de patrones y
abstracciones coherentes que
proporcionan un marco definido y claro
para interactuar con el código fuente del
software.
Proceso de Definición de Arquitectura
Ingeniería de Software
Arquitectura Física
 La arquitectura física del sistema es la
que representa la adecuación de todos
los componentes físicos que intervienen
en un sistema para su correcto
funcionamiento y despliegue, entra dentro
de la etapa de diseño de software y esta
paralelo a los procesos de arquitectura de
software.
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
 Categorías de patrones
• Patrones de arquitectura: Aquellos que expresan un esquema
organizativo estructural fundamental para sistemas de software.
• Patrones de diseño: Aquellos que expresan esquemas para
definir estructuras de diseño (o sus relaciones) con las que
construir sistemas de software.
• Dialectos: Patrones de bajo nivel específicos para un lenguaje de
programación o entorno concreto.
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
 Objetivos de los patrones
Los patrones de diseño pretenden:
• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no pretenden:
• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.
• No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el
mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en
un caso particular puede no ser aplicable. «Abusar o forzar el uso de los patrones
puede ser un error».
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
 Patrones de arquitectura
 Los patrones arquitectónicos, o patrones de arquitectura,
también llamados arquetipos ofrecen soluciones a
problemas de arquitectura de software en ingeniería de
software.
 Dan una descripción de los elementos y el tipo de
relación que tienen junto con un conjunto de restricciones
sobre cómo pueden ser usados.
 Un patrón arquitectónico expresa un esquema de
organización estructural esencial para un sistema de
software, que consta de subsistemas, sus
responsabilidades e interrelaciones.
 En comparación con los patrones de diseño, los patrones
arquitectónicos tienen un nivel de abstracción mayor.
Proceso de Definición de Arquitectura
Ingeniería de Software
Patrones arquitectónicos
 Patrones de arquitectura
 Los patrones arquitectónicos, o patrones de arquitectura,
también llamados arquetipos ofrecen soluciones a
problemas de arquitectura de software en ingeniería de
software.
 Dan una descripción de los elementos y el tipo de
relación que tienen junto con un conjunto de restricciones
sobre cómo pueden ser usados.
 Un patrón arquitectónico expresa un esquema de
organización estructural esencial para un sistema de
software, que consta de subsistemas, sus
responsabilidades e interrelaciones.
 En comparación con los patrones de diseño, los patrones
arquitectónicos tienen un nivel de abstracción mayor.
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
 Patrones de arquitectura
 Uno de los aspectos más importantes de los patrones
arquitectónicos es que encarnan diferentes atributos
de calidad.
 Por ejemplo, algunos patrones representan soluciones
a problemas de rendimiento y otros pueden ser
utilizados con éxito en sistemas de alta disponibilidad.
 Como primer paso de la fase de diseño, un arquitecto
de software escoge qué patrones arquitectónicos
mejor ofrecen las calidades deseadas para el sistema.
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
 Patrones de arquitectura
 Uno de los aspectos más importantes de los patrones
arquitectónicos es que encarnan diferentes atributos
de calidad.
 Por ejemplo, algunos patrones representan soluciones
a problemas de rendimiento y otros pueden ser
utilizados con éxito en sistemas de alta disponibilidad.
 Como primer paso de la fase de diseño, un arquitecto
de software escoge qué patrones arquitectónicos
mejor ofrecen las calidades deseadas para el sistema.
Proceso de Definición de Arquitectura
Ingeniería de Software

Patrones arquitectónicos
Ejemplos de patrones arquitectónicos incluyen los siguientes:
1. Patrón de capas
2. Patrón cliente-servidor
3. Patrón maestro-esclavo
4. Patrón de filtro de tubería
5. Patrón de intermediario
6. Patrón de igual a igual
7. Patrón de bus de evento
8. Modelo-vista-controlador
9. Patrón de pizarra
10. Patrón de intérprete
https://medium.com/@maniakhitoccori/los-10-patrones-comunes-de-arquitectura-de-software-
d8b9047edf0b
Proceso de Definición de Arquitectura
Ingeniería de Software
Patrones arquitectónicos
 Dominios en el diseño de Patrones
 Control de acceso. Hay muchas situaciones en las cuales el acceso a
datos, características y funcionalidad son limitadas a la definición de
los usuarios. Desde un punto de vista arquitectónico, acceder a
determinadas partes del software debe tener un riguroso control.
 Concurrencia. Muchas aplicaciones deben manejar múltiples tareas de
forma que simule el paralelismo. Hay muchas formas de manejar esta
concurrencia y cada una puede ser presentada por un patrón
arquitectónico diferente.
 Distribución. El problema de distribución dirige el problema de forma
en que los sistemas o componentes se comunican con otros en un
entorno distribuido. El patrón más común para afrontar el problema es
the broker. Actuando como un middleware entre el componente
cliente y el servidor. El cliente envía un mensaje al broker y éste se
encarga de completar la conexión.
 Persistencia. Los datos persistentes son almacenados en bases de
datos o archivos y pueden ser leídos o modificados por otros procesos
más adelante. En los entornos orientados a objetos esto va más allá y
lo que puede ser accedido o modificable son las propiedades de los
objetos.
Proceso de Definición de Arquitectura
Ingeniería de Software

Pasos para diseñar una arquitectura

1. Definir qué patrones de arquitectura vamos a utilizar.
2. Definir qué componentes voy a utilizar y qué componentes voy a crear.
3. Validar si existen dependencias con componentes externos (con
proveedores) y cómo se van a desarrollar estos.
4. Integrar los componentes internos con los componentes externos.
Referencias
 https://www.redalyc.org/pdf/496/49642141016.pdf Enfoque de Arquitectura de
Solución
 https://medium.com/@maniakhitoccori/los-10-patrones-comunes-de-
arquitectura-de-software-d8b9047edf0b Patrones de Arquitectura de SW
 http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.php?media=materias:s2_conc
eptosdemodelado.pdf Modelado y Diseño de Arquitectura de SW
 https://www.mastergeoinformatica.es/wp-content/uploads/2016/06/FSI-SI-T2-
ArquitecturaSI.pdf Arquitectura de SI
 http://academicos.azc.uam.mx/jfg/diapositivas/adsi/Unidad_10.pdf Modelos
de arquitectura de sw
 http://uoc.gitlab.io/2014/Ing.Componentes/2.pdf Arquitectura de SW
 https://www.youtube.com/watch?v=ZjxTNGpgP4k Introducción a la
Arquitectura de Software – Universidad de los Andes