Arquitectura de software

Arquitectura de software es la estructura abstracta de un sistema de software y la disciplina de crear dichas estructuras y sistemas. Cada estructura comprende elementos de software, relaciones entre ellos y propiedades tanto de elementos como de relaciones.

La arquitectura de un sistema de software es una metáfora, análoga a la arquitectura de un edificio. Funciona como un modelo para el sistema y el proyecto en desarrollo, que la gestión del proyecto puede utilizar más tarde para extrapolar las tareas necesarias para ser ejecutadas por los equipos y las personas involucradas.

La arquitectura de software se trata de tomar decisiones estructurales fundamentales que son costosas de cambiar una vez implementadas. Las opciones de arquitectura de software incluyen opciones estructurales específicas de las posibilidades en el diseño del software.

Por ejemplo, los sistemas que controlaban el vehículo de lanzamiento del transbordador espacial tenían el requisito de ser muy rápidos y muy fiables. Por lo tanto, sería necesario elegir un lenguaje de computación en tiempo real apropiado. Además, para satisfacer la necesidad de confiabilidad, se podría elegir tener múltiples copias redundantes y producidas de forma independiente del programa, y ejecutar estas copias en hardware independiente mientras se verifican los resultados.

La documentación de la arquitectura de software facilita la comunicación entre las partes interesadas, captura decisiones tempranas sobre el diseño de alto nivel y permite la reutilización de componentes de diseño entre proyectos.

Software_Arquitectura_Actividades

Alcance

Las opiniones varían en cuanto al alcance de las arquitecturas de software:

• Estructura del sistema macroscópico: esto se refiere a la arquitectura como una abstracción de alto nivel de un sistema de software que consiste en una colección de computacional componentes junto con conectores que describen la interacción entre estos componentes.
• Lo importante, lo que sea que sea: esto se refiere al hecho de que los arquitectos de software deben preocuparse por aquellas decisiones que tienen un alto impacto en el sistema y sus partes interesadas.
• Lo que es fundamental para entender un sistema en su entorno
• Cosas que la gente percibe como difíciles de cambiar: ya que el diseño de la arquitectura tiene lugar al comienzo del ciclo de vida de un sistema de software, el arquitecto debe centrarse en decisiones que "tienen que" ser correctas la primera vez. Siguiendo esta línea de pensamiento, los temas de diseño arquitectónico pueden convertirse en no-arquitectura una vez que se pueda superar su irreversibilidad.
• Un conjunto de decisiones de diseño arquitectónico: la arquitectura de software no debe considerarse meramente un conjunto de modelos o estructuras, sino que debe incluir las decisiones que conducen a estas estructuras particulares, y la racionalidad detrás de ellas. Esta visión ha llevado a una investigación sustancial sobre la gestión del conocimiento de la arquitectura de software.

No existe una distinción clara entre la arquitectura de software y el diseño y la ingeniería de requisitos (consulte los campos relacionados a continuación). Todos son parte de una "cadena de intencionalidad" desde intenciones de alto nivel hasta detalles de bajo nivel.

Características

La arquitectura de software exhibe lo siguiente:

Multitud de partes interesadas: los sistemas de software deben atender a una variedad de partes interesadas, como gerentes comerciales, propietarios, usuarios y operadores. Todas estas partes interesadas tienen sus propias preocupaciones con respecto al sistema. Equilibrar estas preocupaciones y demostrar que se abordan es parte del diseño del sistema. Esto implica que la arquitectura implica tratar con una amplia variedad de preocupaciones y partes interesadas, y tiene una naturaleza multidisciplinar.

Separación de preocupaciones: la forma establecida para que los arquitectos reduzcan la complejidad es separar las preocupaciones que impulsan el diseño. La documentación de la arquitectura muestra que todas las preocupaciones de las partes interesadas se abordan modelando y describiendo la arquitectura desde puntos de vista separados asociados con las diversas preocupaciones de las partes interesadas. Estas descripciones separadas se denominan vistas arquitectónicas (consulte, por ejemplo, el modelo de vista arquitectónica 4+1).

Impulsado por la calidad: los enfoques clásicos de diseño de software (p. ej., la programación estructurada de Jackson) estaban impulsados por la funcionalidad requerida y el flujo de datos a través del sistema, pero la perspectiva actual es que la arquitectura de un sistema de software está más estrechamente relacionado con sus atributos de calidad, como la tolerancia a fallas, la compatibilidad con versiones anteriores, la extensibilidad, la confiabilidad, la capacidad de mantenimiento, la disponibilidad, la seguridad, la facilidad de uso y otras características similares. Las preocupaciones de las partes interesadas a menudo se traducen en requisitos sobre estos atributos de calidad, que se denominan de diversas formas requisitos no funcionales, requisitos extrafuncionales, requisitos de comportamiento o requisitos de atributos de calidad.

Estilos recurrentes: al igual que la arquitectura de edificios, la disciplina de la arquitectura de software ha desarrollado formas estándar para abordar las preocupaciones recurrentes. Estas "formas estándar" son llamados por varios nombres en varios niveles de abstracción. Los términos comunes para soluciones recurrentes son estilo arquitectónico, táctica, arquitectura de referencia y patrón arquitectónico.

Integridad conceptual: término introducido por Fred Brooks en su libro de 1975 The Mythical Man-Month para denotar la idea de que la arquitectura de un sistema de software representa una visión general de lo que debe hacer y cómo debe hacerlo. Esta visión debe separarse de su implementación. El arquitecto asume el papel de "guardián de la visión", asegurándose de que las adiciones al sistema estén en línea con la arquitectura, preservando así la integridad conceptual.

Restricciones cognitivas: una observación realizada por primera vez en un artículo de 1967 por el programador informático Melvin Conway de que las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones. Al igual que con la integridad conceptual, fue Fred Brooks quien lo presentó a una audiencia más amplia cuando citó el artículo y la idea en su elegante clásico The Mythical Man-Month, llamándolo "Conway's Ley."

Motivación

La arquitectura de software es un "intelectualmente comprensible" abstracción de un sistema complejo. Esta abstracción proporciona una serie de beneficios:

• Da una base para el análisis del comportamiento de los sistemas de software antes de que se haya construido el sistema. La capacidad de verificar que un futuro sistema de software cumple con las necesidades de sus partes interesadas sin tener que construirlo representa una reducción sustancial de costos y riesgos. Se han desarrollado varias técnicas para realizar dichos análisis, como ATAM o creando una representación visual del sistema de software.
• Proporciona una base para la reutilización de elementos y decisiones. Una arquitectura de software completa o partes de ella, como estrategias y decisiones arquitectónicas individuales, pueden ser reutilizadas en múltiples sistemas cuyos interesados requieren atributos de calidad similares o funcionalidad, ahorro de costos de diseño y mitigación del riesgo de errores de diseño.
• Soporta decisiones de diseño temprano que impactan la vida de desarrollo, despliegue y mantenimiento de un sistema. Conseguir las decisiones tempranas y de alto impacto es importante para prevenir los sobrecostos presupuestarios.
• Facilita la comunicación con los interesados, contribuyendo a un sistema que satisfaga mejor sus necesidades. La comunicación sobre sistemas complejos desde el punto de vista de los interesados les ayuda a comprender las consecuencias de sus requisitos establecidos y las decisiones de diseño basadas en ellos. La arquitectura da la capacidad de comunicarse sobre las decisiones de diseño antes de que se implemente el sistema, cuando todavía son relativamente fáciles de adaptar.
• Ayuda en la gestión de riesgos. La arquitectura del software ayuda a reducir los riesgos y las posibilidades de fracaso.
• Permite la reducción de costos. La arquitectura de software es un medio para gestionar riesgos y costos en proyectos complejos de TI.

Historia

La comparación entre el diseño de software y la arquitectura (civil) se estableció por primera vez a fines de la década de 1960, pero el término "arquitectura de software" no vio un uso generalizado hasta la década de 1990. El campo de la informática se había encontrado con problemas asociados con la complejidad desde su formación. Los desarrolladores resolvieron problemas anteriores de complejidad eligiendo las estructuras de datos correctas, desarrollando algoritmos y aplicando el concepto de separación de preocupaciones. Aunque el término "arquitectura de software" es relativamente nuevo en la industria, los principios fundamentales del campo han sido aplicados esporádicamente por los pioneros de la ingeniería de software desde mediados de la década de 1980. Los primeros intentos de capturar y explicar la arquitectura de software de un sistema eran imprecisos y desorganizados, a menudo caracterizados por un conjunto de diagramas de caja y línea.

La arquitectura de software como concepto tiene su origen en la investigación de Edsger Dijkstra en 1968 y David Parnas a principios de la década de 1970. Estos científicos enfatizaron que la estructura de un sistema de software es importante y que lograr la estructura correcta es fundamental. Durante la década de 1990 hubo un esfuerzo concertado para definir y codificar aspectos fundamentales de la disciplina, con trabajo de investigación concentrado en estilos arquitectónicos (patrones), lenguajes de descripción de arquitectura, documentación de arquitectura y métodos formales.

Las instituciones de investigación han desempeñado un papel destacado en el fomento de la arquitectura de software como disciplina. Mary Shaw y David Garlan de Carnegie Mellon escribieron un libro titulado Arquitectura de software: perspectivas sobre una disciplina emergente en 1996, que promovía conceptos de arquitectura de software como componentes, conectores y estilos. Los esfuerzos del Instituto de Investigación de Software de Irvine de la Universidad de California en la investigación de arquitectura de software se dirigen principalmente a estilos arquitectónicos, lenguajes de descripción de arquitectura y arquitecturas dinámicas.

IEEE 1471-2000, "Práctica recomendada para la descripción de la arquitectura de sistemas intensivos en software", fue el primer estándar formal en el área de la arquitectura del software. Fue adoptado en 2007 por ISO como ISO/IEC 42010:2007. En noviembre de 2011, IEEE 1471–2000 fue reemplazada por ISO/IEC/IEEE 42010:2011, "Ingeniería de sistemas y software: descripción de la arquitectura" (publicado conjuntamente por IEEE e ISO).

Mientras que en IEEE 1471, la arquitectura de software se refería a la arquitectura de "sistemas intensivos en software", definidos como "cualquier sistema donde el software aporta influencias esenciales para el diseño, la construcción, la implementación y la evolución del sistema como un todo", la edición de 2011 va un paso más allá al incluir las definiciones de sistema ISO/IEC 15288 e ISO/IEC 12207, que abarcan no solo hardware y software, sino también "humanos, procesos, procedimientos, instalaciones, materiales y entidades naturales". Esto refleja la relación entre la arquitectura del software, la arquitectura empresarial y la arquitectura de la solución.

Actividades de arquitectura

Hay muchas actividades que realiza un arquitecto de software. Un arquitecto de software generalmente trabaja con los gerentes de proyecto, analiza los requisitos significativos desde el punto de vista arquitectónico con las partes interesadas, diseña una arquitectura de software, evalúa un diseño, se comunica con los diseñadores y las partes interesadas, documenta el diseño arquitectónico y más. Hay cuatro actividades principales en el diseño de arquitectura de software. Estas actividades de arquitectura central se realizan de forma iterativa y en diferentes etapas del ciclo de vida de desarrollo de software inicial, así como a lo largo de la evolución de un sistema.

Análisis arquitectónico es el proceso de comprender el entorno en el que funcionará un sistema propuesto y determinar los requisitos para el sistema. La entrada o los requisitos para la actividad de análisis pueden provenir de cualquier número de partes interesadas e incluir elementos tales como:

• qué hará el sistema cuando esté en funcionamiento (los requisitos funcionales)
• qué tan bien el sistema cumplirá requisitos de funcionamiento no funcionales como fiabilidad, operabilidad, eficiencia de rendimiento, seguridad, compatibilidad definida en ISO/IEC 25010:2011 estándar
• tiempo de desarrollo de requisitos no funcionales tales como la sostenibilidad y la transferibilidad definidas en la norma ISO 25010:2011
• requisitos empresariales y contextos ambientales de un sistema que puede cambiar con el tiempo, como preocupaciones jurídicas, sociales, financieras, competitivas y tecnológicas

Los resultados de la actividad de análisis son aquellos requisitos que tienen un impacto medible en la arquitectura de un sistema de software, denominados requisitos arquitectónicamente significativos.

Síntesis arquitectónica o diseño es el proceso de creación de una arquitectura. Dados los requisitos arquitectónicamente significativos determinados por el análisis, el estado actual del diseño y los resultados de cualquier actividad de evaluación, se crea y mejora el diseño.

La evaluación de la arquitectura es el proceso de determinar qué tan bien el diseño actual o una parte de él satisface los requisitos derivados durante el análisis. Una evaluación puede ocurrir siempre que un arquitecto esté considerando una decisión de diseño, puede ocurrir después de que se haya completado una parte del diseño, puede ocurrir después de que se haya completado el diseño final o puede ocurrir después de que se haya construido el sistema. Algunas de las técnicas de evaluación de arquitectura de software disponibles incluyen el método de análisis de compensación de arquitectura (ATAM) y TARA. Los marcos para comparar las técnicas se analizan en marcos como SARA Report y Architecture Reviews: Practice and Experience.

Evolución de la arquitectura es el proceso de mantener y adaptar una arquitectura de software existente para cumplir con los cambios en los requisitos y el entorno. Como la arquitectura de software proporciona una estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente afectarían su estructura fundamental. Como tal, la evolución de la arquitectura se preocupa por agregar nuevas funcionalidades, así como por mantener la funcionalidad y el comportamiento del sistema existentes.

La arquitectura requiere actividades de apoyo fundamentales. Estas actividades de apoyo tienen lugar a lo largo del proceso de arquitectura de software central. Incluyen la gestión del conocimiento y la comunicación, el razonamiento del diseño y la toma de decisiones, y la documentación.

Actividades de apoyo a la arquitectura

Las actividades de apoyo a la arquitectura de software se llevan a cabo durante las actividades de arquitectura de software central. Estas actividades de apoyo ayudan a un arquitecto de software a realizar análisis, síntesis, evaluación y evolución. Por ejemplo, un arquitecto tiene que recopilar conocimientos, tomar decisiones y documentar durante la fase de análisis.

• Gestión y comunicación del conocimiento es el acto de explorar y gestionar el conocimiento que es esencial para diseñar una arquitectura de software. Un arquitecto de software no trabaja en aislamiento. Obtienen insumos, requisitos funcionales y no funcionales, y contextos de diseño, de diversos interesados; y proporciona productos a los interesados. El conocimiento de la arquitectura del software es a menudo tácito y se mantiene en los jefes de los interesados. La actividad de gestión del conocimiento de la arquitectura del software consiste en encontrar, comunicar y conservar el conocimiento. Dado que los problemas de diseño de arquitectura de software son intrincados e interdependientes, una brecha de conocimiento en el razonamiento de diseño puede llevar a un diseño incorrecto de arquitectura de software. Ejemplos de actividades de gestión y comunicación del conocimiento incluyen la búsqueda de patrones de diseño, prototipado, preguntando desarrolladores y arquitectos experimentados, evaluando los diseños de sistemas similares, compartiendo conocimiento con otros diseñadores e interesados, y documentando experiencia en una página wiki.
• Design reasoning and decision making es la actividad de evaluar las decisiones de diseño. Esta actividad es fundamental para las tres actividades básicas de arquitectura de software. Consiste en reunir y asociar contextos de decisión, formular problemas de decisión de diseño, encontrar opciones de solución y evaluar los intercambios antes de tomar decisiones. Este proceso se produce en diferentes niveles de granularidad de decisiones, evaluando importantes requisitos arquitectónicos y decisiones de arquitectura de software, y análisis de arquitectura de software, síntesis y evaluación. Ejemplos de actividades de razonamiento incluyen la comprensión de los impactos de un requisito o un diseño sobre atributos de calidad, cuestionando las cuestiones que un diseño podría causar, la evaluación de posibles opciones de solución, y la evaluación de los intercambios entre soluciones.
• Documentación es el acto de grabar el diseño generado durante el proceso de arquitectura de software. El diseño del sistema se describe utilizando varias opiniones que frecuentemente incluyen una visión estática que muestra la estructura del código del sistema, una visión dinámica que muestra las acciones del sistema durante la ejecución, y una vista de despliegue que muestra cómo se coloca un sistema en hardware para la ejecución. La vista 4+1 de Kruchten sugiere una descripción de las opiniones comúnmente utilizadas para documentar la arquitectura del software; Documenting Software Architectures: Views and Beyond tiene descripciones de los tipos de notaciones que podrían utilizarse dentro de la descripción de la vista. Ejemplos de actividades de documentación están escribiendo una especificación, registrando un modelo de diseño del sistema, documentando un diseño racional, desarrollando un punto de vista, documentando opiniones.

Temas de arquitectura de software

Descripción de la arquitectura del software

La descripción de la arquitectura de software involucra los principios y prácticas de modelado y representación de arquitecturas, utilizando mecanismos tales como lenguajes de descripción de arquitectura, puntos de vista de arquitectura y marcos de arquitectura.

Lenguajes de descripción de arquitectura

Un lenguaje de descripción de arquitectura (ADL) es cualquier medio de expresión utilizado para describir una arquitectura de software (ISO/IEC/IEEE 42010). Se han desarrollado muchas ADL de propósito especial desde la década de 1990, incluyendo AADL (estándar SAE), Wright (desarrollado por Carnegie Mellon), Acme (desarrollado por Carnegie Mellon), xADL (desarrollado por UCI), Darwin (desarrollado por Imperial College London), DAOP-ADL (desarrollado por la Universidad de Málaga), SBC-ADL (desarrollado por la Universidad Nacional Sun Yat-Sen) y ByADL (Universidad de L'Aquila, Italia).

Miradores de arquitectura

4+1 modelo de visión arquitectónica.

Las descripciones de la arquitectura de software suelen organizarse en vistas, que son análogas a los diferentes tipos de planos realizados en la arquitectura de edificios. Cada vista aborda un conjunto de problemas del sistema, siguiendo las convenciones de su punto de vista, donde un punto de vista es una especificación que describe las notaciones, el modelado y las técnicas de análisis para usar en una vista que expresa la arquitectura en cuestión. desde la perspectiva de un conjunto determinado de partes interesadas y sus preocupaciones (ISO/IEC/IEEE 42010). El punto de vista especifica no solo las preocupaciones enmarcadas (es decir, a abordar), sino también la presentación, los tipos de modelos utilizados, las convenciones utilizadas y cualquier regla de consistencia (correspondencia) para mantener una vista consistente con otras vistas.

Marcos de arquitectura

Un marco de arquitectura captura las "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" (ISO/CEI/IEEE 42010). Un marco generalmente se implementa en términos de uno o más puntos de vista o ADL.

Estilos y patrones arquitectónicos

Un patrón arquitectónico es una solución general y reutilizable para un problema común en la arquitectura de software dentro de un contexto determinado. Los patrones arquitectónicos a menudo se documentan como patrones de diseño de software.

Siguiendo la arquitectura de construcción tradicional, un 'estilo arquitectónico de software' es un método de construcción específico, caracterizado por las características que lo hacen notable" (estilo arquitectónico).

Un estilo arquitectónico define: una familia de sistemas en términos de un patrón de organización estructural; un vocabulario de componentes y conectores, con limitaciones en cómo se pueden combinar.

Los estilos arquitectónicos son reutilizables 'paquetes' de decisiones de diseño y limitaciones que se aplican a una arquitectura para inducir cualidades deseables elegidas.

Hay muchos patrones y estilos arquitectónicos reconocidos, entre ellos:

• Blackboard
• Cliente-servidor (2-tier, 3-tier, n-tier, cloud computing expositor este estilo)
• Base de componentes
• Data-centric
• Evento impulsado (o invocación implícita)
• Capa (o arquitectura multicapa)
• Arquitectura de microservicios
• Aplicación monolítica
• Peer-to-peer (P2P)
• Tubos y filtros
• Plug-ins
• Arquitectura reactiva
• Transferencia estatal representativa (REST)
• Basado en normas
• Servicios orientados
• No compartió ninguna arquitectura
• Arquitectura basada en el espacio

Algunos tratan los patrones arquitectónicos y los estilos arquitectónicos como lo mismo, algunos tratan los estilos como especializaciones de patrones. Lo que tienen en común es que tanto los patrones como los estilos son modismos para que los arquitectos los usen, "proporcionan un lenguaje común" o "vocabulario" con los que describir clases de sistemas.

Arquitectura de software y desarrollo ágil

También existe la preocupación de que la arquitectura de software lleve a un gran diseño inicial, especialmente entre los defensores del desarrollo de software ágil. Se han desarrollado una serie de métodos para equilibrar las ventajas y desventajas del diseño inicial y la agilidad, incluido el método ágil DSDM que exige un "Fundamentos" fase durante la cual "lo suficiente" se sientan las bases arquitectónicas. IEEE Software dedicó un número especial a la interacción entre agilidad y arquitectura.

Erosión de la arquitectura de software

La erosión de la arquitectura de software (o "deterioro") se refiere a la brecha observada entre la arquitectura planificada y real de un sistema de software tal como se realiza en su implementación. La erosión de la arquitectura de software ocurre cuando las decisiones de implementación no logran completamente la arquitectura según lo planeado o violan las restricciones o los principios de esa arquitectura.

Como ejemplo, considere un sistema estrictamente en capas, donde cada capa solo puede usar los servicios provistos por la capa inmediatamente debajo de ella. Cualquier componente del código fuente que no observe esta restricción representa una violación de la arquitectura. Si no se corrigen, tales violaciones pueden transformar la arquitectura en un bloque monolítico, con efectos adversos en la comprensibilidad, mantenibilidad y capacidad de evolución.

Se han propuesto varios enfoques para abordar la erosión. "Estos enfoques, que incluyen herramientas, técnicas y procesos, se clasifican principalmente en tres categorías generales que intentan minimizar, prevenir y reparar la erosión de la arquitectura. Dentro de estas amplias categorías, cada enfoque se desglosa aún más reflejando las estrategias de alto nivel adoptadas para abordar la erosión. Estos son la conformidad de la arquitectura orientada al proceso, la gestión de la evolución de la arquitectura, la aplicación del diseño de la arquitectura, la vinculación de la arquitectura con la implementación, la autoadaptación y las técnicas de restauración de la arquitectura que consisten en recuperación, descubrimiento y reconciliación."

Existen dos técnicas principales para detectar violaciones arquitectónicas: modelos de reflexión y lenguajes específicos de dominio. Las técnicas del modelo de reflexión (RM) comparan un modelo de alto nivel proporcionado por los arquitectos del sistema con la implementación del código fuente. También hay lenguajes específicos de dominio que se enfocan en especificar y verificar las restricciones arquitectónicas.

Recuperación de arquitectura de software

La recuperación (o reconstrucción, o ingeniería inversa) de la arquitectura de software incluye los métodos, las técnicas y los procesos para descubrir la arquitectura de un sistema de software a partir de la información disponible, incluida su implementación y documentación. La recuperación de la arquitectura a menudo es necesaria para tomar decisiones informadas frente a documentación obsoleta o desactualizada y erosión de la arquitectura: decisiones de implementación y mantenimiento que divergen de la arquitectura prevista. Existen prácticas para recuperar la arquitectura de software como análisis de programas estáticos. Esta es una parte de los temas cubiertos por la práctica de inteligencia de software.

Campos relacionados

Diseño

La arquitectura es diseño, pero no todo diseño es arquitectónico. En la práctica, el arquitecto es quien traza la línea entre la arquitectura de software (diseño arquitectónico) y el diseño detallado (diseño no arquitectónico). No existen reglas o pautas que se ajusten a todos los casos, aunque ha habido intentos de formalizar la distinción. De acuerdo con la hipótesis de intención/localidad, la distinción entre diseño arquitectónico y diseño detallado se define por el criterio de localidad, según el cual una declaración sobre el diseño de software no es local (arquitectura).) si y solo si un programa que lo satisface puede expandirse a un programa que no lo hace. Por ejemplo, el estilo cliente-servidor es arquitectónico (estratégico) porque un programa que se basa en este principio se puede expandir a un programa que no sea cliente-servidor, por ejemplo, agregando nodos de igual a igual.

Ingeniería de requisitos

La ingeniería de requisitos y la arquitectura de software pueden verse como enfoques complementarios: mientras que la arquitectura de software apunta al 'espacio de solución' o el "cómo", la ingeniería de requisitos aborda el "espacio del problema" o el 'qué'. La ingeniería de requisitos implica la obtención, negociación, especificación, validación, documentación y gestión de requisitos. Tanto la ingeniería de requisitos como la arquitectura de software giran en torno a las preocupaciones, necesidades y deseos de las partes interesadas.

Existe una superposición considerable entre la ingeniería de requisitos y la arquitectura de software, como lo demuestra, por ejemplo, un estudio sobre cinco métodos de arquitectura de software industrial que concluye que "las entradas (objetivos, restricciones, etc.) generalmente no son adecuadas. -definidos, y solo se descubren o comprenden mejor a medida que la arquitectura comienza a emerger" y que, si bien "la mayoría de las preocupaciones arquitectónicas se expresan como requisitos en el sistema, también pueden incluir un diseño obligatorio decisiones". En resumen, el comportamiento requerido afecta la arquitectura de la solución, que a su vez puede introducir nuevos requisitos. Los enfoques como el modelo Twin Peaks tienen como objetivo explotar la relación sinérgica entre los requisitos y la arquitectura.

Otros tipos de 'arquitectura'

Arquitectura informática

La arquitectura de computación apunta a la estructura interna de un sistema informático, en términos de componentes de hardware colaboradores como la CPU – o procesador – el autobús y la memoria.

Arquitectura de sistemas

La arquitectura de sistemas de término se ha aplicado originalmente a la arquitectura de sistemas que consiste tanto en hardware como software. La principal preocupación abordada por la arquitectura de sistemas es entonces la integración de software y hardware en un dispositivo de trabajo completo y correcto. En otro sentido común – mucho más amplio – el término se aplica a la arquitectura de cualquier sistema complejo que pueda ser de naturaleza técnica, sociotécnica o social.

Arquitectura empresarial

El objetivo de la arquitectura empresarial es "traducir la visión empresarial y la estrategia en una empresa eficaz". Los marcos de arquitectura empresarial, como TOGAF y el Marco Zachman, suelen distinguir entre diferentes capas de arquitectura empresarial. Aunque la terminología difiere del marco al marco, muchos incluyen al menos una distinción entre un capa de negocios, un aplicación (o información) capa, y un capa de tecnología. La arquitectura empresarial aborda entre otros la alineación entre estas capas, generalmente en un enfoque de arriba hacia abajo.