Los requisitos arquitectónicamente significativos son aquellos requisitos que tienen un efecto medible en la arquitectura de un sistema informático . [1] Esto puede incluir requisitos tanto de software como de hardware. Son un subconjunto de requisitos , el subconjunto que afecta la arquitectura de un sistema de formas identificables y mensurables.
Relación con los requisitos no funcionales y los atributos de calidad.
Durante bastante tiempo, los requisitos arquitectónicamente significativos [ vagos ] no fueron reconocidos como una noción importante. Cuando se habla de arquitectura, a menudo se utilizan requisitos no funcionales o atributos de calidad . [2] Sin embargo, estudios empíricos recientes muestran que, para un sistema de software , no todos los requisitos no funcionales afectan su arquitectura , y los requisitos que no son requisitos no funcionales también pueden afectar su arquitectura. [1] [3] Por lo tanto, los requisitos arquitectónicamente significativos es una noción valiosa que se sugiere usar cuando se habla de requisitos en relación con la arquitectura. [3]
Caracteristicas
Los requisitos arquitectónicamente significativos se pueden caracterizar a partir de los siguientes aspectos. [1]
Características descriptivas
Los requisitos de importancia arquitectónica a menudo son difíciles de definir y articular, tienden a expresarse de manera vaga, tienden a descuidarse inicialmente, tienden a ocultarse dentro de otros requisitos y son subjetivos, variables y situacionales. Otros requisitos también podrían demostrar estas características descriptivas. Sin embargo, la importancia de los requisitos arquitectónicamente significativos hizo que estas manifestaciones fueran únicas y desafiantes.
Indicadores
Un requisito que tiene un efecto amplio, tiene como objetivo puntos de compensación, es estricto (restrictivo, limitante, no negociable), que rompe los supuestos o es difícil de lograr es probable que sea arquitectónicamente significativo.
Los indicadores de importancia arquitectónica que se han informado en la literatura incluyen:
- El requisito está asociado con un alto valor comercial y / o riesgo técnico.
- El requisito es una preocupación de una parte interesada particularmente importante (es decir, influyente).
- El requisito tiene un carácter único, por ejemplo, ninguna de las responsabilidades de los componentes ya existentes en la arquitectura lo aborda.
- El requisito tiene características de QoS / SLA que se desvían de todas las que ya están satisfechas por la arquitectura en evolución.
- El requisito ha provocado sobrecostos presupuestarios o insatisfacción del cliente en un proyecto anterior con un contexto similar.
El OpenUP [4] y Peter Eeles (IBM) discute criterios adicionales para la importancia arquitectónica en varios artículos y presentaciones [5]
Heurísticas
Cuando un requisito especifica los atributos de calidad de un sistema de software, se refiere a las características principales de un sistema de software, impone restricciones a un sistema de software , define el entorno en el que se ejecutará el sistema de software, es probable que sea arquitectónicamente significativo.
Consulte la discusión de diseño frente a arquitectura en arquitectura de software para obtener criterios adicionales de importancia arquitectónica.
Sonsacamiento
Como todos los requisitos no funcionales y los requisitos de atributos de calidad [6] , los requisitos arquitectónicamente significativos deben especificarse de forma INTELIGENTE . Los escenarios de atributos de calidad [2] son una forma de lograr los criterios S (específicos) y M (medidos) en SMART. El Instituto de Ingeniería de Software recomienda talleres de atributos de calidad para este esfuerzo. [7] Se ha sugerido que el análisis y el diseño de la arquitectura sean ligeros y flexibles; Los árboles de atributos de calidad para ciertos géneros de aplicaciones y dominios de tecnología pueden respaldar dichos enfoques. [8]
Es importante comunicar los requisitos arquitectónicamente significativos obtenidos, y cualquier otro artefacto arquitectónico, en una notación y un lenguaje que sea comprensible para el público objetivo (escuche: partes interesadas del negocio ). [9]
Impacto
Los requisitos arquitectónicamente significativos se utilizan en el diseño de software para impulsar y justificar decisiones arquitectónicas ; si no se satisfacen adecuadamente, contribuyen a la acumulación de deuda técnica . Por ejemplo, el incumplimiento de los requisitos de seguridad y cumplimiento complica las auditorías de aseguramiento de procesos y sistemas y aumenta el riesgo de que se produzcan hallazgos de auditoría. [10] En la literatura se encuentran disponibles consejos ejemplares sobre cómo abordar los atributos de calidad del sistema (incluidos los requisitos arquitectónicamente significativos). [11] [12]
Ver también
Referencias
- ^ a b c Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". Software IEEE . 30 (2): 38–45. doi : 10.1109 / MS.2012.174 . hdl : 10344/3061 .
- ^ a b Bass, Len; Clements, Paul (2003). Arquitectura de software en práctica . Addison Wesley. ISBN 978-0321154958.
- ^ a b Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016). ¿Son los requisitos "no funcionales" realmente no funcionales? - Una investigación de los requisitos no funcionales en la práctica (PDF) . La 38ª Conferencia Internacional de Ingeniería de Software . Asociación para Maquinaria de Computación.
- ^ "Copia archivada" . Archivado desde el original el 17 de octubre de 2016 . Consultado el 19 de agosto de 2016 .CS1 maint: copia archivada como título ( enlace )
- ^ http://www.architecting.co.uk/presentations/Architecting%20Large-Scale%20Systems.pdf
- ^ "Atributos de calidad" (PDF) .
- ^ "El Taller de Atributos de Calidad SEI" .
- ^ Keeling, Michael (2015). "Ligero y Flexible: Tendencias Emergentes en Arquitectura de Software de las Conferencias SATURN". Software IEEE . 32 (3): 7-11. doi : 10.1109 / MS.2015.65 .
- ^ Schulenklopper, Jochem (2016). "Por qué simplemente no lo entienden: comunicar sobre la arquitectura con las partes interesadas del negocio". Software IEEE . 33 (3): 13-19. doi : 10.1109 / MS.2016.67 .
- ^ K. Julisch et al., Cumplimiento por diseño: unir el abismo entre auditores y arquitectos de TI Archivado 2017-09-21 en Wayback Machine Computers & Security 30 (6-7): 410-426 (2011)
- ^ "Implementación de atributos de calidad del sistema" .
- ^ A. Rotem-Gal-Oz, Patrones SOA, Manning, 2012.