Hispanopedia Wiki
Articulo de referencia

Requisitos arquitectónicamente significativos

Los requisitos arquitectónicamente significativos son aquellos que tienen un efecto medible en la arquitectura de un sistema informático . [ 1 ] Esto puede incluir tanto requisi...

Hispanopedia WikiContenido en espanolLectura gratuita

Los requisitos arquitectónicamente significativos son aquellos que tienen un efecto medible en la arquitectura de un sistema informático . [ 1 ] Esto puede incluir tanto requisitos de software como de hardware. Son un subconjunto de requisitos que afectan la arquitectura del sistema de maneras medibles e identificables.

Relación con los requisitos no funcionales y los atributos de calidad.

Los requisitos arquitectónicamente significativos fueron reconocidos como un concepto importante solo recientemente, en 2016. Al hablar de arquitectura, se suelen utilizar los términos 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 funcionales también pueden afectarla. [ 1 ] [ 3 ] Esta investigación sugiere que, al hablar de arquitectura de software, vale la pena distinguir qué requisitos de software son arquitectónicamente significativos y si son funcionales. [ 3 ]

Características

Los requisitos arquitectónicamente significativos pueden caracterizarse por los siguientes aspectos. [ 1 ]

Características descriptivas

Los requisitos arquitectónicamente significativos suelen ser difíciles de definir y articular, tienden a expresarse de forma vaga, a ser inicialmente ignorados, a estar ocultos entre otros requisitos y son subjetivos, variables y situacionales. Otros requisitos también podrían presentar estas características descriptivas. Sin embargo, la importancia de los requisitos arquitectónicamente significativos hizo que estas manifestaciones fueran únicas y complejas.

Indicadores

Un requisito con un amplio impacto se centra en puntos de compromiso, es estricto (restringe, limita, no es negociable), rompe con los supuestos o es difícil de lograr, y es probable que tenga una importancia arquitectónica significativa.

Entre los indicadores de importancia arquitectónica que se han reportado en la literatura se incluyen:

  • Este requisito está asociado a un alto valor comercial y/o a un riesgo técnico.
  • Este requisito preocupa a una parte interesada particularmente influyente.
  • Este requisito tiene un carácter novedoso, ya que ninguna de las responsabilidades de los componentes existentes en la arquitectura lo contempla.
  • El requisito presenta características de QoS/SLA que difieren de las que ya satisface la arquitectura en evolución.
  • Este requisito provocó sobrecostes o insatisfacción del cliente en un proyecto anterior con un contexto similar.

OpenUP [ 4 ] y Peter Eeles [ 5 ] analizan criterios adicionales para la relevancia arquitectónica en varios artículos y presentaciones. En la Conferencia Europea sobre Arquitectura de Software de 2020 se abordaron siete criterios para la relevancia arquitectónica: valor/riesgo para el negocio, interés de las partes interesadas, nivel de calidad, dependencias externas, transversalidad, novedad y origen de problemas en proyectos anteriores.

Heurísticas

Cuando un requisito especifica los atributos de calidad de un sistema de software , hace referencia a sus características principales, le impone restricciones o define el entorno en el que se ejecutará, es probable que tenga una importancia arquitectónica significativa.

Consulte la sección sobre diseño frente a arquitectura en el apartado de arquitectura de software para obtener criterios adicionales de importancia arquitectónica.

Sonsacamiento

Al igual que todos los requisitos no funcionales y los atributos de calidad, [ 6 ] los requisitos arquitectónicamente significativos deben especificarse SMART . Los escenarios de atributos de calidad [ 2 ] son ​​una forma de lograr los criterios S (específicos) y M (medidos) en SMART. El Software Engineering Institute recomienda los Talleres de Atributos de Calidad para este fin. [ 7 ] Se ha sugerido que el análisis y el diseño de la arquitectura se mantengan ligeros y flexibles; los árboles de atributos de calidad para géneros de aplicaciones y dominios tecnológicos específicos pueden respaldar tales enfoques. [ 8 ]

Es esencial comunicar los requisitos arquitectónicamente significativos obtenidos y cualquier otro artefacto arquitectónico en una notación y un lenguaje comprensibles para el público objetivo (en particular, las partes interesadas del negocio). [ 9 ]

Impacto

Los requisitos arquitectónicamente significativos se utilizan en el diseño de software para guiar y justificar las 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 del sistema y del proceso, e incrementa el riesgo de hallazgos de auditoría. [ 10 ] En la literatura se encuentra disponible asesoramiento ejemplar sobre cómo abordar los atributos de calidad del sistema (incluidos los requisitos arquitectónicamente significativos). [ 11 ] [ 12 ]

Véase también

Referencias

  1. 123Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. Bibcode:2013ISoft..30b..38C. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
  2. 12Bass, Len; Clements, Paul (2003). Software Architecture in Practice. Addison Wesley. ISBN 978-0321154958.
  3. 12Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016). Are "Non-functional" Requirements really Non-functional? - An Investigation of Non-functional Requirements in Practice(PDF). The 38th International Conference on Software Engineering. Association for Computing Machinery.
  4. ↑"Concept: Architecturally Significant Requirements". Archived from the original on October 17, 2016. Retrieved August 19, 2016.
  5. ↑"Peter Eeles on ResearchGate".
  6. ↑"Quality Attributes"(PDF). sei.cmu.edu. Archived from the original(PDF) on October 16, 2012.
  7. ↑"The SEI Quality Attribute Workshop". February 8, 2018.
  8. ↑Keeling, Michael (2015). "Lightweight and Flexible: Emerging Trends in Software Architecture from the SATURN Conferences". IEEE Software. 32 (3): 7–11. Bibcode:2015ISoft..32c...7K. doi:10.1109/MS.2015.65.
  9. ↑Schulenklopper, Jochem (2016). "Why They Just Don't Get It: Communicating about Architecture with Business Stakeholders". IEEE Software. 33 (3): 13–19. Bibcode:2016ISoft..33c..13S. doi:10.1109/MS.2016.67. S2CID 1309474.
  10. ↑K. Julisch et al., Compliance by design - Bridging the chasm between auditors and IT architectsArchived 2017-09-21 at the Wayback Machine Computers & Security 30(6-7): 410-426 (2011)
  11. ↑"Implementing System-Quality Attributes".
  12. ↑A. Rotem-Gal-Oz, SOA Patterns, Manning, 2012.