Метод анализа компромиссов в архитектуре - Architecture tradeoff analysis method

В программная инженерия, метод анализа компромиссов архитектуры (ATAM) - это процесс снижения рисков, используемый на ранних этапах жизненный цикл разработки программного обеспечения.

ATAM был разработан Институт программной инженерии на Университет Карнеги Меллон. Его цель - помочь выбрать подходящий архитектура для программной системы, обнаружив компромиссы и точки чувствительности.

ATAM наиболее выгоден на ранних этапах жизненного цикла разработки программного обеспечения, когда затраты на изменение архитектуры минимальны.

Преимущества ATAM

Ниже приведены некоторые из преимуществ процесса ATAM:[1]

  • выявленные риски на ранних этапах жизненного цикла
  • усиление взаимодействия между заинтересованными сторонами
  • уточнены требования к атрибутам качества
  • улучшенная архитектурная документация
  • документированная основа архитектурных решений

Процесс ATAM

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

Этапы процесса ATAM

ATAM формально состоит из девяти шагов, описанных ниже:[2]

  1. Представьте ATAM - представьте концепцию ATAM заинтересованным сторонам и ответьте на любые вопросы о процессе.
  2. Существующие бизнес-драйверы - каждый участник процесса представляет и оценивает бизнес-драйверы для рассматриваемой системы.
  3. Представьте архитектуру - архитектор представляет команде архитектуру высокого уровня с «соответствующим уровнем детализации».
  4. Определите архитектурные подходы - команда представляет и обсуждает различные архитектурные подходы к системе.
  5. Сгенерируйте служебное дерево атрибутов качества - определите основные бизнес-требования и технические требования к системе и сопоставьте их с соответствующим архитектурным свойством. Представьте сценарий для данного требования.
  6. Анализируйте архитектурные подходы - анализируйте каждый сценарий, оценивая их по приоритету. Затем архитектура оценивается по каждому сценарию.
  7. Проведите мозговой штурм и определите приоритеты сценариев - среди более широкой группы заинтересованных сторон, представьте текущие сценарии и расширьте их.
  8. Анализируйте архитектурные подходы - выполните шаг 6 еще раз с дополнительными знаниями более широкого сообщества заинтересованных сторон.
  9. Представьте результаты - предоставьте всю документацию заинтересованным сторонам.

Эти шаги разделены на две фазы: Этап 1 состоит из шагов 1-6, и после этого этапа становятся известны состояние и контекст проекта, основные архитектурные требования и состояние архитектурной документации. Этап 2 состоит из шагов 7-9 и завершает оценку.[3]

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

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

  1. ^ «Метод анализа компромиссов в архитектуре». Институт программной инженерии Карнеги-Меллона. Получено 2018-04-20.
  2. ^ Бас, Лен; Клементс, Пол; Казман, Рик (9 апреля 2003 г.). Архитектура программного обеспечения на практике, второе издание. Эддисон Уэсли Профессионал.[страница нужна ]
  3. ^ Рик Казман; Марк Кляйн; Пол Клементс. «ATAM: метод оценки архитектуры» (PDF). Институт программной инженерии Карнеги-Меллона. п. 39f. Получено 2018-04-20.

внешняя ссылка