Sesion 8 - Defincion de La Arquitectura V2

Gestión de la Ingeniería
de Sistemas
SESIÓN 8: PROCESO DE DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA
EXPLICAR ALCANCE DE LA SESION 8
Proceso de definición de Arquitectura del Sistema

1. Enfoque de INCOSE
2. Patrones de Arquitectura de Software
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
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]
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.
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.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
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.
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.
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.
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.
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.
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.
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.
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).

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.
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).
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]).

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.

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 .
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.

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.
 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.
 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.).
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
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
• 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 Definición de Diseño 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 de Definición de Arquitectura (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.
• 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
• 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.
• 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
• 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 comprender Actividades
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 para el
que se necesita la solución a fin de establecer una mejor comprensión de las preocupaciones • Prepárese para la
de las partes interesadas.
definición de
– Analice los requisitos del sistema y etiquete requisitos no funcionales, que influirán
fuertemente en definición de los elementos de la solución.
arquitectura
– Captar las preocupaciones de las partes interesadas relacionadas con la arquitectura • Desarrollar puntos de
– Establecer el enfoque para definir la arquitectura. vista de la arquitectura
– Asegúrese de que los elementos o servicios habilitadores estén disponibles. • Desarrollar modelos y
– Desarrollar puntos de vista de la arquitectura. vistas de arquitecturas
• Con base en las preocupaciones identificadas de las partes interesadas, establezca o candidatas.
identifique los puntos de vista de la arquitectura asociados, los tipos de modelos de • Relacionar la
apoyo que facilitan el análisis y la comprensión del punto de vista y los marcos de arquitectura con el
arquitectura relevantes para apoyar el desarrollo de los modelos y las vistas.. diseño
• Evaluar candidatos de
arquitectura
• Gestionar la arquitectura
seleccionada
• Actividades (cont)
– Desarrollar modelos y vistas de arquitecturas candidatas.
• Utilizando técnicas y herramientas de modelado relevantes, y junto con el proceso de Actividades
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, • Prepárese para la
intercambios e interacciones del sistema de interés con elementos externos. Esta tarea definición de
permite la definición o comprensión de los escenarios operativos esperados y / o arquitectura
comportamientos del sistema dentro de su contexto de uso. • Desarrollar puntos de
• Definir entidades arquitectónicas (p. Ej., Funciones, flujos de entrada / salida, elementos vista de la arquitectura
del sistema, interfaces físicas, características arquitectónicas, elementos de información / • Desarrollar modelos y
datos, contenedores, nodos, enlaces, recursos de comunicación, etc.), que abordan los vistas de arquitecturas
diferentes tipos de requisitos del sistema (p. Ej. , requisitos funcionales, requisitos de candidatas.
interfaz, requisitos ambientales, condiciones operativas [confiabilidad, factores humanos, • Relacionar la
etc.], limitaciones [dimensiones físicas, producción, mantenimiento, eliminación]). arquitectura con el
• Relacionar entidades arquitectónicas con conceptos, propiedades, características, diseño
comportamientos, funciones y / o restricciones que son relevantes para las decisiones de • Evaluar candidatos de
la arquitectura del sistema de interés. Esto da lugar a características arquitectónicas (por arquitectura
ejemplo, generalidad, modularidad, operabilidad, eficiencia, simplicidad). • Gestionar la arquitectura
seleccionada
• 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
• 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.
arquitectura
– La definición incluye las interfaces internas entre los elementos del
sistema y las interfaces externas con otros sistemas.. • Gestionar la arquitectura
seleccionada
– 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.
• 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.
– 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
• 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
• 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
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
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
• 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.
• 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.
• 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.
• 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.
– 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)
– 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.
– 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.
– 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
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.
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.
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.
 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».
 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.
 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.
 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.
 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.
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
1. Patrón de capas
 Este patrón se puede utilizar para estructurar programas que se pueden
descomponer en grupos de subtareas, cada una de las cuales se encuentra
en un nivel particular de abstracción. Cada capa proporciona servicios a la
siguiente capa superior.
 Las 4 capas más comúnmente encontradas de un sistema de información
general son las siguientes.
• Capa de presentación (también conocida como capa UI )
• Capa de aplicación (también conocida como capa de servicio )
• Capa de lógica de negocios (también conocida como capa de dominio )
• Capa de acceso a datos (también conocida como capa de persistencia )
 Uso
• Aplicaciones de escritorio generales.
• Aplicaciones web de comercio electrónico.
Ejemplos de patrones arquitectónicos incluyen
los siguientes:
2. Patrón cliente-servidor
 Este patrón consiste en dos partes; un servidor y
múltiples clientes . El componente del servidor
proporcionará servicios a múltiples componentes del
cliente. Los clientes solicitan servicios del servidor y el
servidor proporciona servicios relevantes a esos clientes.
Además, el servidor sigue escuchando las solicitudes de
los clientes.
 Uso
• Aplicaciones en línea como correo electrónico, uso
compartido de documentos y banca.
Ejemplos de patrones arquitectónicos incluyen los
siguientes:
3. Patrón Maestro-Esclavo
 Este patrón consiste en dos partes; maestro y esclavos . El
componente maestro distribuye el trabajo entre
componentes esclavos idénticos y calcula el resultado final de
los resultados que devuelven los esclavos.
 Uso
• En la replicación de la base de datos, la base de datos
maestra se considera como la fuente autorizada y las bases
de datos esclavas se sincronizan con ella.
• Periféricos conectados a un bus en un sistema informático
(unidades maestra y esclava).
siguientes:
4. Patrón Filtro de Tuberías
 Este patrón se puede usar para estructurar sistemas que
producen y procesan una secuencia de datos. Cada paso de
procesamiento se incluye dentro de un componente
de filtro . Los datos que se procesarán se pasan a través de
las tuberías . Estas tuberías se pueden utilizar para el
almacenamiento en búfer o con fines de sincronización.
 Uso
• Compiladores: Los filtros consecutivos realizan análisis léxico,
análisis sintáctico y generación de código.
• Flujos de trabajo en bioinformática.
siguientes:
5. Patrón Intermedio (del agente)
 Este patrón se usa para estructurar sistemas distribuidos con
componentes desacoplados. Estos componentes pueden interactuar
entre sí mediante invocaciones de servicios remotos. Un
componente de intermediario es responsable de la coordinación de
la comunicación entre los componentes .
 Los servidores publican sus capacidades (servicios y características) a
un intermediario. Los clientes solicitan un servicio del intermediario
y el intermediario redirecciona al cliente a un servicio adecuado
desde su registro.
 Uso
• Software de Message Broker como Apache ActiveMQ , Apache
Kafka , RabbitMQ y JBoss Messaging .
siguientes:
6. Patrón de Igual a Igual (P2P)
 En este patrón, los componentes individuales se conocen
como pares. Los pares pueden funcionar tanto como
un cliente, solicitando servicios de otros pares, y como
un servidor, proporcionando servicios a otros pares. Un par
puede actuar como un cliente o como un servidor o como
ambos, y puede cambiar su rol dinámicamente con el tiempo.
 Uso
• Redes de intercambio de archivos como Gnutella y G2
• Protocolos multimedia como P2PTV y PDTP .
siguientes:
7. Patrón de bus de evento
 Este patrón trata principalmente con eventos y tiene 4
componentes principales; fuente de evento , escucha de
evento , canal y bus de evento . Las fuentes publican
mensajes en canales particulares en un bus de eventos. Los
oyentes se suscriben a canales particulares. Los oyentes son
notificados de los mensajes que se publican en un canal al
que se han suscrito anteriormente.
 Uso
• Desarrollo de Android
• Servicios de notificación por ejemplo Publicador-Suscriptor
8. Patrón de Modelo Vista-Controlador (MVC)
 Este patrón, también conocido como patrón MVC, divide una aplicación
interactiva en 3 partes, como
1. modelo — contiene la funcionalidad y los datos básicos
2. vista : muestra la información al usuario (se puede definir más de una vista)
3. controlador : maneja la entrada del usuario
 Esto se hace para separar las representaciones internas de información de las
formas en que se presenta y acepta la información del usuario. Desacopla los
componentes y permite la reutilización eficiente del código.
 Uso
• Arquitectura para aplicaciones World Wide Web en los principales lenguajes
de programación.
• Marcos web como Django y Rails .
9. Patrón de Pizarra
 Este patrón es útil para problemas para los que no se conocen
estrategias de solución deterministas. El patrón de pizarra consta de 3
componentes principales.
• pizarra : una memoria global estructurada que contiene objetos del
espacio de solución
• fuente de conocimiento : módulos especializados con su propia
representación
• componente de control : selecciona, configura y ejecuta módulos.
 Todos los componentes tienen acceso a la pizarra. Los componentes
pueden producir nuevos objetos de datos que se agregan a la pizarra. Los
componentes buscan tipos particulares de datos en la pizarra, y pueden
encontrarlos por coincidencia de patrones con la fuente de conocimiento
existente.
 Uso
• Reconocimiento de voz
• Identificación y seguimiento del vehículo
• Identificación de la estructura proteica
• Sonar señala la interpretación.
siguientes:
10. Patrón de Interprete

 Este patrón se usa para diseñar un componente que interpreta
programas escritos en un lenguaje dedicado. Especifica principalmente
cómo evaluar las líneas de programas, conocidas como oraciones o
expresiones escritas en un idioma particular. La idea básica es tener una
clase para cada símbolo del idioma.
 Uso
• Lenguajes de consulta de base de datos como SQL.
• Idiomas utilizados para describir los protocolos de comunicación.
Patrones arquitectónicos Ventajas y Deventajas
siguientes:
10. Patrón de Interprete

 Este patrón se usa para diseñar un componente que interpreta
programas escritos en un lenguaje dedicado. Especifica principalmente
cómo evaluar las líneas de programas, conocidas como oraciones o
expresiones escritas en un idioma particular. La idea básica es tener una
clase para cada símbolo del idioma.
 Uso
• Lenguajes de consulta de base de datos como SQL.
• Idiomas utilizados para describir los protocolos de comunicación.
 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.
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.
Otro enfoque de Definición de Arquitectura de Software:

https://www.lucidchart.com/blog/es/como-disenar-una-arquitectura-de-
software
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

Sesion 8 - Defincion de La Arquitectura V2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesion 8 - Defincion de La Arquitectura V2

Cargado por

Copyright:

Formatos disponibles

Gestión de la Ingeniería

Proceso de definición de Arquitectura del Sistema

• Enfoque de INCOSE (ISO15288):

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

¿Qué es la arquitectura de Sistemas?

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

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

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

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

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

• Creación de modelos intermedios , como los modelos de arquitectura lógica, facilita la

• Las actividades de arquitectura requieren pasar varias iteraciones entre el desarrollo de

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

• La arquitectura general de un sistema puede tener propiedades de diseño o

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

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

2 Enfoque basado en procesos

• El propósito del proceso de Arquitectura del sistema es generar alternativas

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

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

2 Enfoque basado en procesos

2.2.3 Desarrollar modelos y vistas de arquitecturas candidatas (cont)

• Relacionar entidades arquitectónicas con conceptos, propiedades, características, comportamientos, funciones y / o

2 Enfoque basado en procesos

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 Enfoque basado en procesos

• Este proceso puede crear varios artefactos, como documentos de

Entrada Actividades Salida

10. Patrón de Interprete

10. Patrón de Interprete

Pasos para diseñar una arquitectura

Otro enfoque de Definición de Arquitectura de Software:

También podría gustarte

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