Архитектурно значимые требования - Architecturally significant requirements

Архитектурно значимые требования те требования, которые оказывают ощутимое влияние на компьютерную систему архитектура.[1] Это может включать требования как к программному обеспечению, так и к оборудованию. Они являются частью требования, подмножество, которое влияет на архитектуру системы измеримым образом.

Связь с нефункциональными требованиями и атрибутами качества

Довольно давно[нечеткий ] архитектурно значимые требования не были признаны важным понятием. Говоря об архитектуре, нефункциональные требования или же атрибуты качества часто используется.[2] Однако недавние эмпирические исследования показывают, что для программная система, не все нефункциональные требования влияют на его архитектура, и требования которые не являются нефункциональными требованиями, также могут повлиять на его архитектуру.[1][3] Итак, архитектурно значимые требования - это ценное понятие, которое предлагается использовать, говоря о требования по отношению к архитектуре.[3]

Характеристики

Архитектурно значимые требования можно охарактеризовать с помощью следующих аспектов.[1]

Описательные характеристики

Архитектурно значимые требования часто трудно определить и сформулировать, они, как правило, выражаются расплывчато, ими изначально пренебрегают, скрываются в других требованиях и являются субъективными, переменными и ситуативными. Другие требования также могут продемонстрировать эти описательные характеристики. Однако значимость архитектурно значимых требований делала эти проявления уникальными и сложными.

Индикаторы

Требование, которое имеет широкое действие, нацелено на компромиссные решения, является строгим (ограничивающим, ограничивающим, не подлежащим обсуждению), нарушающим предположения или труднодостижимым, вероятно, будет иметь архитектурное значение.

Показатели архитектурной значимости, о которых сообщалось в литературе, включают:

  • Требование связано с высокой стоимостью бизнеса и / или техническим риском.
  • Требование вызывает озабоченность у особо важной (влиятельной) заинтересованной стороны.
  • Требование носит уникальный характер, например ни одна из обязанностей уже существующих компонентов в архитектуре не касается этого.
  • Требование имеет характеристики QoS / SLA, которые отличаются от тех, которые уже удовлетворяются развивающейся архитектурой.
  • Требование вызвало перерасход бюджета или недовольство клиентов в предыдущем проекте с аналогичным контекстом.

В Открыть[4] и Питер Илес (IBM) обсуждают дополнительные критерии архитектурной значимости в нескольких статьях и презентациях.[5]

Эвристика

Когда требование определяет программную систему атрибуты качества, относится к основным функциям программной системы, накладывает ограничения на программная система, определяет среду, в которой будет работать программная система, она может иметь большое архитектурное значение.

См. Обсуждение дизайна и архитектуры под программная архитектура для дополнительных критериев архитектурной значимости.

Выявление

Как и все нефункциональные требования и атрибут качества[6] требования, архитектурно значимые требования должны быть указаны в УМНАЯ путь. Сценарии атрибутов качества[2] являются одним из способов достижения критериев S (конкретный) и M (измеренный) в SMART. В Институт программной инженерии рекомендует для этого семинары по атрибутам качества.[7] Было предложено сделать анализ архитектуры и проектирование легким и гибким; деревья атрибутов качества для определенных жанров приложений и областей технологий могут поддерживать такие подходы.[8]

Важно передать выявленные архитектурно значимые требования и любые другие архитектурные артефакты в обозначениях и на языке, понятном для понимания. целевая аудитория (слышите: бизнес заинтересованные стороны ).[9]

Влияние

Архитектурно значимые требования используются в разработка программного обеспечения гонять и оправдывать архитектурные решения; если они не удовлетворены должным образом, они способствуют накоплению технический долг. Например, несоблюдение требований безопасности и соответствия усложняет аудиторские проверки системы и процессов и увеличивает риск результатов аудита.[10] Примерные советы о том, как учитывать атрибуты качества системы (включая архитектурно значимые требования), доступны в литературе.[11][12]

Смотрите также

Рекомендации

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