En ingeniería de software y diseño de arquitectura de software , las decisiones arquitectónicas son decisiones de diseño que abordan requisitos importantes desde el punto de vista arquitectónico ; se perciben como difíciles de hacer [1] y/o costosos de cambiar. [2]
Las decisiones arquitectónicas influyen e impactan en las características no funcionales de un sistema. Cada decisión arquitectónica describe un problema de diseño concreto y arquitectónicamente significativo (también conocido como problema de diseño, decisión requerida) para el cual existen varias soluciones potenciales (también conocidas como opciones, alternativas). Una decisión arquitectónica captura el resultado de un proceso de selección de opciones consciente, a menudo colaborativo, y proporciona una justificación del diseño.para el resultado de la toma de decisiones, por ejemplo, haciendo referencia a uno o más de los atributos de calidad abordados por la decisión arquitectónica y respondiendo preguntas de "por qué" sobre el diseño y la selección de opciones. Las decisiones arquitectónicas se refieren a un sistema de software como un todo, o a uno o más de los componentes centrales de dicho sistema. Los tipos de decisiones arquitectónicas son la selección de tácticas y patrones arquitectónicos, de tecnologías de integración y de middleware, así como estrategias y activos de implementación relacionados (tanto productos comerciales como proyectos de código abierto). [3]
El diseño de arquitectura de software es un problema perverso , [4] ; por lo tanto, las decisiones arquitectónicas son difíciles de acertar. A menudo, no existe una única solución óptima para un conjunto dado de problemas de diseño de arquitectura. La toma de decisiones arquitectónicas es una responsabilidad central de los arquitectos de software; [5] Se puede encontrar en línea una motivación adicional para/de la importancia de las decisiones arquitectónicas como un concepto de primera clase en la arquitectura de software. [6]
El fundamento se mencionó en una definición temprana de arquitectura de software de Perry/Woolf, [7] pero no se investigó mucho hasta 2004, cuando se llevó a cabo un taller sobre decisiones arquitectónicas y Gestión del conocimiento arquitectónico en Groningen, NL. Las primeras publicaciones se remontan a este taller. [8] [9] A partir de 2006, la gestión del conocimiento arquitectónico y las comunidades de investigación de decisiones arquitectónicas ganaron impulso y se publicaron varios artículos en las principales conferencias de arquitectura de software, como la Conferencia Europea sobre Arquitectura de Software (ECSA), la Calidad de la Arquitectura de Software (QoSA ) y (Working) International Conference on Software Architecture (ICSA). Un libro de Springer resumió el estado del arte a partir de 2009,[10] y un estudio de mapeo sistemático de 2013 [11] compila y analiza resultados de investigación cada vez más recientes.
En la práctica, siempre se ha reconocido la importancia de tomar las decisiones correctas, por ejemplo, en los procesos de desarrollo de software como OpenUP ; existen muchas plantillas y prácticas para la documentación de decisiones. Siete de estas plantillas se comparan en. [12] El estándar más reciente para descripciones de arquitectura, ISO/IEC/IEEE 42010:2011 tiene una entidad de justificación dedicada y brinda recomendaciones detalladas sobre qué decisiones arquitectónicas capturar y qué propiedades de una decisión arquitectónica tomar. registro en el registro de decisiones. [13]
Antes de que se pueda tomar una decisión, se debe articular la necesidad de una decisión: ¿qué tan urgente y qué tan importante es el DA? ¿Tiene que hacerse ahora o puede esperar hasta que se sepa más sobre los requisitos y el sistema en construcción? Tanto la experiencia personal como colectiva, así como los métodos y prácticas de diseño reconocidos, pueden ayudar en la identificación de decisiones; Se ha propuesto que el equipo de desarrollo de software Agile debe mantener una cartera de decisiones que complemente la cartera de productos del proyecto. [14]