Архитектурно значимые требования
Архитектурно значимые требования компьютерной системы — это требования, которые оказывают измеримое влияние на архитектуру . [1] Это может включать требования как к программному обеспечению, так и к аппаратному обеспечению. Они представляют собой подмножество требований , подмножество, которое влияет на архитектуру системы измеримыми способами.
Связь с нефункциональными требованиями и атрибутами качества.
[ редактировать ]Архитектурно значимые требования лишь недавно, в 2016 году, были признаны важным понятием. Говоря об архитектуре, термины «нефункциональные требования» или «атрибуты качества» . часто используются [2] Однако недавние эмпирические исследования показывают, что для программной системы не все нефункциональные требования влияют на ее архитектуру , а функциональные требования также могут влиять на ее архитектуру. [1] [3] Это исследование показывает, что при обсуждении архитектуры программного обеспечения стоит различать, какие требования к программному обеспечению являются архитектурно значимыми, а также являются ли они функциональными. [3]
Характеристики
[ редактировать ]Архитектурно значимые требования можно охарактеризовать со следующих сторон. [1]
Описательные характеристики
[ редактировать ]Архитектурно значимые требования часто трудно определить и сформулировать, они имеют тенденцию выражаться расплывчато, ими изначально пренебрегают, они имеют тенденцию быть скрытыми внутри других требований и являются субъективными, изменчивыми и ситуативными. Другие требования также могут демонстрировать эти описательные характеристики. Однако значимость архитектурно значимых требований сделала эти проявления уникальными и сложными.
Индикаторы
[ редактировать ]Требование, которое имеет широкий эффект, нацелено на компромиссные точки, является строгим (ограничивающим, ограничивающим, не подлежащим обсуждению), нарушающим предположения или труднодостижимым, вероятно, будет архитектурно значимым.
Показатели архитектурной значимости, о которых сообщается в литературе, включают:
- Требование связано с высокой стоимостью бизнеса и/или техническим риском.
- Это требование вызывает обеспокоенность особенно влиятельной заинтересованной стороны.
- Требование носит уникальный характер, т. е. ни одна из обязанностей уже существующих компонентов в архитектуре его не касается.
- Это требование имеет характеристики QoS/SLA, которые отличаются от всех тех, которые уже удовлетворяются развивающейся архитектурой.
- Это требование привело к перерасходу бюджета или недовольству клиентов в предыдущем проекте с аналогичным контекстом.
OpenUP [4] и Питер Илес [5] обсудим дополнительные критерии архитектурной значимости в нескольких статьях и презентациях. На Европейской конференции по архитектуре программного обеспечения в 2020 году обсуждались семь критериев архитектурной значимости: ценность/риск для бизнеса, обеспокоенность заинтересованных сторон, уровень качества, внешние зависимости, сквозные аспекты, уникальность, источник проблем в прошлых проектах. Эти критерии описаны в « Тест архитектурной значимости » .
Эвристика
[ редактировать ]Когда требование определяет программной системы атрибуты качества ; относится к его основным функциям; накладывает на него ограничения; или определяет среду, в которой он будет работать, он, вероятно, будет архитектурно значимым.
см. в обсуждении дизайна и архитектуры в разделе «Архитектура программного обеспечения» Дополнительные критерии архитектурной значимости .
выявление
[ редактировать ]Как и все нефункциональные требования и атрибуты качества. [6] требования, архитектурно значимые требования должны быть определены SMART- способом. Сценарии атрибутов качества [2] являются одним из способов достижения критериев S (конкретный) и M (измеренный) в SMART. Институт программной инженерии рекомендует для этой цели провести семинары по атрибутам качества. [7] Было предложено сделать анализ и проектирование архитектуры легкими и гибкими; Деревья атрибутов качества для определенных жанров приложений и технологических областей могут поддерживать такие подходы. [8]
Важно сообщить выявленные архитектурно значимые требования и любые другие архитектурные артефакты в обозначениях и на языке, которые понятны целевой аудитории (в частности, заинтересованным сторонам бизнеса ). [9]
Влияние
[ редактировать ]Архитектурно значимые требования используются при проектировании программного обеспечения для стимулирования и обоснования архитектурных решений ; если они не удовлетворяются должным образом, они способствуют накоплению технического долга . Например, несоблюдение требований безопасности и соответствия усложняет аудит системы и процессов и увеличивает риск результатов аудита. [10] Образцовые советы о том, как обращаться с атрибутами качества системы (включая архитектурно значимые требования), доступны в литературе. [11] [12]
См. также
[ редактировать ]- Архитектурное решение
- Архитектурный образец
- Атрибутно-ориентированный дизайн
- Список атрибутов качества системы
- Нефункциональное требование
- Разработка требований
- Архитектура программного обеспечения
- Архитектура решения
- Архитектура систем
Ссылки
[ редактировать ]- ^ Jump up to: а б с Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .
- ^ Jump up to: а б Басс, Лен; Клементс, Пол (2003). Архитектура программного обеспечения на практике . Эддисон Уэсли. ISBN 978-0321154958 .
- ^ Jump up to: а б Экхардт, Йонас; Фогельсанг, Андреас; Фернандес, Даниэль (2016). Действительно ли «нефункциональные» требования нефункциональны? - Исследование нефункциональных требований на практике (PDF) . 38-я Международная конференция по программной инженерии . Ассоциация вычислительной техники.
- ^ «Концепция: Архитектурно значимые требования» . Архивировано из оригинала 17 октября 2016 года . Проверено 19 августа 2016 г.
- ^ «Питер Илс на ResearchGate» .
- ^ «Атрибуты качества» (PDF) .
- ^ «Семинар по атрибутам качества SEI» .
- ^ Килинг, Майкл (2015). «Легкость и гибкость: новые тенденции в архитектуре программного обеспечения по итогам конференций SATURN» . Программное обеспечение IEEE . 32 (3): 7–11. дои : 10.1109/MS.2015.65 .
- ^ Шуленклоппер, Йохем (2016). «Почему они этого просто не понимают: общение об архитектуре с заинтересованными сторонами из бизнеса». Программное обеспечение IEEE . 33 (3): 13–19. дои : 10.1109/MS.2016.67 . S2CID 1309474 .
- ^ К. Юлиш и др., Соответствие замыслу - преодоление пропасти между аудиторами и ИТ-архитекторами. Архивировано 21 сентября 2017 г. в Wayback Machine Computers & Security 30 (6-7): 410-426 (2011).
- ^ «Реализация атрибутов качества системы» .
- ^ А. Ротем-Гал-Оз, Шаблоны SOA, Мэннинг, 2012.