Метод анализа компромиссов архитектуры
В обеспечения разработке программного метод анализа компромиссов архитектуры ( ATAM ) — это процесс снижения рисков, используемый на ранних этапах жизненного цикла разработки программного обеспечения .
ATAM был разработан Институтом программной инженерии Университета Карнеги-Меллон . Его цель — помочь выбрать подходящую архитектуру для программной системы путем обнаружения компромиссов и точек чувствительности.
ATAM наиболее выгоден, когда он выполняется на ранних стадиях жизненного цикла разработки программного обеспечения, когда затраты на изменение архитектуры минимальны.
Преимущества ATAM [ править ]
Ниже приведены некоторые преимущества процесса ATAM: [1]
- выявленные риски на ранних этапах жизненного цикла
- усиление коммуникации между заинтересованными сторонами
- уточненные требования к атрибутам качества
- улучшенная документация по архитектуре
- документированная основа архитектурных решений
Процесс ATAM [ править ]
Процесс ATAM состоит из сбора заинтересованных сторон для анализа бизнес-факторов (функциональность системы, цели, ограничения, желаемые нефункциональные свойства ) и извлечения из этих драйверов атрибутов качества, которые используются для создания сценариев. Эти сценарии затем используются в сочетании с архитектурными подходами и архитектурными решениями для анализа компромиссов, точек чувствительности и рисков (или отсутствия рисков). Этот анализ можно преобразовать в темы рисков и их воздействия, после чего процесс можно повторить. В каждом цикле анализа процесс анализа переходит от более общего к более конкретному, исследуя вопросы, которые были обнаружены в предыдущем цикле, до тех пор, пока архитектура не будет точно настроена и не будут рассмотрены темы рисков.
Этапы процесса ATAM [ править ]
Формально ATAM состоит из девяти этапов, описанных ниже: [2]
- Презентация ATAM – Представьте концепцию ATAM заинтересованным сторонам и ответьте на любые вопросы о процессе.
- Присутствуют бизнес-факторы – все участники процесса представляют и оценивают бизнес-факторы рассматриваемой системы.
- Презентация архитектуры — архитектор представляет команде архитектуру высокого уровня с «соответствующим уровнем детализации».
- Определить архитектурные подходы — команда представляет и обсуждает различные архитектурные подходы к системе.
- Создайте дерево утилит атрибутов качества – определите основные бизнес- и технические требования системы и сопоставьте их с соответствующим архитектурным свойством. Представьте сценарий для данного требования.
- Анализ архитектурных подходов. Анализируйте каждый сценарий, оценивая его по приоритету. Затем архитектура оценивается по каждому сценарию.
- Проведите мозговой штурм и расставьте приоритеты в сценариях – среди более широкой группы заинтересованных сторон представьте текущие сценарии и расширяйте их.
- Анализ архитектурных подходов. Повторите шаг 6, используя дополнительные знания более широкого сообщества заинтересованных сторон.
- Представление результатов – предоставить всю документацию заинтересованным сторонам.
Эти шаги разделены на две фазы: Фаза 1 состоит из шагов 1–6, и после этой фазы становятся известны состояние и контекст проекта, основные архитектурные требования и состояние архитектурной документации. Фаза 2 состоит из шагов 7–9 и завершает оценку. [3]
См. также [ править ]
- болезни
- Архитектурно-ориентированный метод проектирования
- Многокритериальный анализ решений
- засуха
- Метод анализа архитектуры программного обеспечения , предшественник метода анализа компромиссов архитектуры.
- Архитектурная аналитика
Ссылки [ править ]
- ^ «Метод анализа компромиссов в архитектуре» . Институт программной инженерии Карнеги-Меллона . Проверено 20 апреля 2018 г.
- ^ Басс, Лен ; Клементс, Пол; Казман, Рик (9 апреля 2003 г.). Архитектура программного обеспечения на практике, второе издание . Эддисон Уэсли Профессионал. [ нужна страница ]
- ^ Рик Казман; Марк Кляйн; Пол Клементс. «ATAM: Метод оценки архитектуры» (PDF) . Институт программной инженерии Карнеги-Меллона. п. 39ф . Проверено 20 апреля 2018 г.