Архитектурно значимые требования - это те требования, которые оказывают измеримое влияние на архитектуру компьютерной системы . [1] Это может включать требования как к программному обеспечению, так и к оборудованию. Они представляют собой подмножество требований , подмножество, которое влияет на архитектуру системы измеримым образом.
Связь с нефункциональными требованиями и атрибутами качества
В течение довольно долгого времени [ расплывчатые ] архитектурно значимые требования не признавались важным понятием. Когда говорят об архитектуре, часто используются нефункциональные требования или атрибуты качества . [2] Однако недавние эмпирические исследования показывают, что для программной системы не все нефункциональные требования влияют на ее архитектуру , и требования , которые не являются нефункциональными требованиями, также могут влиять на ее архитектуру. [1] [3] Итак, архитектурно значимые требования - это ценное понятие, которое предлагается использовать, когда речь идет о требованиях в отношении архитектуры. [3]
Характеристики
Архитектурно значимые требования можно охарактеризовать с помощью следующих аспектов. [1]
Описательные характеристики
Архитектурно значимые требования часто трудно определить и сформулировать, они имеют тенденцию выражаться расплывчато, ими изначально пренебрегают, они обычно скрыты в рамках других требований и являются субъективными, изменчивыми и ситуативными. Другие требования также могут продемонстрировать эти описательные характеристики. Однако значимость архитектурно значимых требований делала эти проявления уникальными и сложными.
Индикаторы
Требование, которое имеет широкий эффект, нацелено на компромиссы, является строгим (ограничивающим, ограничивающим, не подлежащим обсуждению), нарушающим предположения или труднодостижимым, вероятно, будет иметь архитектурное значение.
Индикаторы архитектурной значимости, о которых сообщалось в литературе, включают:
- Требование связано с высокой стоимостью бизнеса и / или техническим риском.
- Требование вызывает озабоченность у особо важной (влиятельной) заинтересованной стороны.
- Требование носит уникальный характер, например, ни одна из обязанностей уже существующих компонентов в архитектуре не касается его.
- Требование имеет характеристики QoS / SLA, которые отличаются от тех, которые уже удовлетворяются развивающейся архитектурой.
- Требование вызвало перерасход бюджета или недовольство клиентов в предыдущем проекте с аналогичным контекстом.
OpenUP [4] и Питер Eeles (IBM) обсуждает дополнительные критерии для архитектурного значения в ряде статей и докладов [5]
Эвристика
Когда требование определяет атрибуты качества программной системы , относится к основным функциям программной системы, накладывает ограничения на программную систему , определяет среду, в которой будет работать программная система, это, вероятно, будет иметь архитектурное значение.
См. Обсуждение дизайна и архитектуры в разделе «Архитектура программного обеспечения» для получения дополнительных критериев архитектурной значимости.
Выявление
Подобно всем нефункциональным требованиям и требованиям атрибутов качества [6] , архитектурно значимые требования должны быть определены в соответствии с SMART . Сценарии атрибутов качества [2] - это один из способов достижения критериев S (специфический) и M (измеренный) в SMART. Институт программной инженерии рекомендует для этого семинары по атрибутам качества. [7] Было предложено сделать анализ архитектуры и проектирование легкими и гибкими; деревья атрибутов качества для определенных жанров приложений и областей технологий могут поддерживать такие подходы. [8]
Важно передать выявленные архитектурно значимые требования и любые другие архитектурные артефакты в нотации и на языке, понятном целевой аудитории (послушайте: заинтересованные стороны бизнеса ). [9]
Влияние
Архитектурно значимые требования используются при разработке программного обеспечения для обоснования архитектурных решений ; если они не удовлетворены должным образом, они способствуют накоплению технического долга . Например, несоблюдение требований безопасности и соответствия усложняет аудиторские проверки системы и процессов и увеличивает риск результатов аудита. [10] Примерные советы о том, как учитывать атрибуты качества системы (включая архитектурно значимые требования), доступны в литературе. [11] [12]
Смотрите также
Рекомендации
- ^ a b c Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеризация архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. DOI : 10.1109 / MS.2012.174 . ЛВП : 10344/3061 .
- ^ а б Бас, Лен; Клементс, Пол (2003). Архитектура программного обеспечения на практике . Эддисон Уэсли. ISBN 978-0321154958.
- ^ а б Экхардт, Йонас; Фогельсанг, Андреас; Фернандес, Даниэль (2016). Действительно ли «нефункциональные» требования нефункциональны? - Исследование нефункциональных требований на практике (PDF) . 38-я Международная конференция по программной инженерии . Ассоциация вычислительной техники.
- ^ «Архивная копия» . Архивировано из оригинала на 2016-10-17 . Проверено 19 августа 2016 .CS1 maint: заархивированная копия как заголовок ( ссылка )
- ^ http://www.architecting.co.uk/presentations/Architecting%20Large-Scale%20Systems.pdf
- ^ «Атрибуты качества» (PDF) .
- ^ «Семинар по атрибутам качества SEI» .
- ^ Килинг, Майкл (2015). «Легкость и гибкость: новые тенденции в архитектуре программного обеспечения по результатам конференций SATURN». Программное обеспечение IEEE . 32 (3): 7–11. DOI : 10.1109 / MS.2015.65 .
- ^ Шуленклоппер, Йохем (2016). «Почему они просто не понимают: общение об архитектуре с заинтересованными сторонами». Программное обеспечение IEEE . 33 (3): 13–19. DOI : 10.1109 / MS.2016.67 .
- ^ . К. Julischдр Compliance дизайн - преодоление пропасти между аудиторами и ИТ - архитекторы Архивировано 2017-09-21 в Wayback Machine Компьютеры и безопасности 30 (6-7): 410-426 (2011)
- ^ «Внедрение атрибутов качества системы» .
- Перейти ↑ A. Rotem-Gal-Oz, SOA Patterns, Manning, 2012.