Differences

This shows you the differences between two versions of the page.

--- mdd:overview [2016/12/23 22:44] – created yaroshenkopolina
+++ mdd:overview [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+======Scenario-Based Software Architecture Evaluation Software Architecture Evaluation Methods: An Overview======
+Оригинал: Mugurel T. Ionita, Dieter K. Hammer, Henk Obbink\\
+[[http://www.win.tue.nl/oas/architecting/aimes/papers/Scenario-Based%20SWA%20Evaluation%20Methods.pdf]]
+====Введение====
+Анализ разработки программного обеспечения и его оценка стали устоявшейся практикой среди проектировщиков ПО. Исследовательские группы предлагают различные методы для оценки качества архитектуры ПО. Ниже приведен список доступных сегодня методов, поддерживающих анализ атрибутов качества ПО:
+  - SAAM, Software Architecture Analysis Method
+  - ATAM, Architecture Trade-off Analysis Method
+  - CBAM, Cost Benefit Analysis Method
+  - ALMA, Architecture Level Modifiability Analysis
+  - FAAM, Family - Architecture Analysis Method
+====Software Architecture Analysis Method(SAAM)====
+SAAM - первый широко распространенный метод анализа архитектуры ПО.Изначально SAAM создавался для оценки модифицируемости, но позже был расширен для анализа архитектуры относительно показателей качества, таких как модифицируемость, портируемость, расширяемость, интегрируемость и функциональный охват.\\
+**Шаги в SAAM:**
+  - **Разработка сценариев: ** Определение типов деятельности, которые система должна поддерживать. Основная трудность при разработке сценариев заключается в определении основных видов применения, пользователей, атрибутов качества и наиболее важное -  всех предполагаемых будущих изменений в системе.
+  - **Описание архитектур(ы): ** SAAM представляет кандидатов архитектур(ы)
+  - **Классификация и расстановка приоритетов сценариев: ** На этом этапе анализа сценарии классифицируются на прямые и косвенные. Прямой сценарий поддерживается кандидатом архитектуры. Косвенный сценарий - последовательность событий, при которой реализация архитектуры должна перенести изменения. Приоритет сценариев основан на процедуре голосования, результаты голосования будут представлять собой набор косвенных сценариев, которые считаются наиболее вероятны.
+  - **Индивидуальная оценка косвенных сценариев: **  В случае косвенного сценария SAAM описывает, как архитектура должны быть изменена, чтобы соответствовать сценарию. Для каждого косвенного сценария должны быть определены архитектурные изменения, необходимые для облегчения этого сценария вместе с затронутыми компонентами новой системы и усилиями по осуществлению этих изменений.
+  - **Оценка взаимодействия сценариев: ** Когда два или более сценариев хотят изменить одни и те же компоненты архитектуры, затронутые компоненты должны быть изменены или разделены на подкомпоненты, чтобы избежать взаимодействия различных сценариев.
+  - **Создание общей оценки: ** Наконец, каждому сценарию присваивается вес с точки зрения их относительной важности для успеха системы. На основе этого взвешивания может быть предложен общий рейтинг, если сравниваются несколько архитектур.
+**Роли в SAAM:**
+  * **Внешние заинтересованные стороны** не принимают участия в процессе разработки архитектуры ПО. Их роль заключается в представлении бизнес-целей проекта, обеспечении атрибутов качества системы и представлении прямых и косвенных сценариев вместе с их приоритетами и классификацией.
+  * **Внутренние заинтересованные стороны** играют роль анализа, определения и представления архитектурных концепций.
+  * **Команда SAAM** проводит сеанс оценки SAAM. Состоит из оценщиков, экспертов в предметной области приложения, внешних экспертов (необязательно), и секретаря.
+====Architecture Trade-off Analysis Method(ATAM)====
+Метод анализа архитектурных компромиссов (ATAM). ATAM – это доработанная и улучшенная версия SAAM, которая позволяет пересматривать архитектурные решения относительно требований параметров качества и того, насколько хорошо эти решения отвечают конкретным целевым показателям качества.\\
+**Шаги в ATAM:**
+  - **Фаза презентации:**
+    - Презентация ATAM
+    - Представление бизнес двигателей
+    - Представление архитектуры
+  - **Фаза исследования и анализа:**
+    - Определение архитектурных подходов
+    - Создание вспомогательного дерева атрибутов качества: Атрибуты качества, которые составляют систему "полезности", выявляются и разносятся на разные уровни дерева.
+    - Анализ архитектурных подходов: На основе приоритетных сценариев, определенных на предыдущем этапе, архитектурные подходы, которые соответствуют этим сценариям, выявляются и анализируются.
+   - **Фаза тестирования:**
+    - Мозговой штурм и расставление приоритетов сценариев: Команда ATAM вместе с заинтересованными сторонами расставляют приоритеты сценариям путем голосования.
+    - Повторный анализ архитектурных подходов
+  - **Фаза отчетности: **
+    - Презентация результатов: Задокументированные архитектурные стили, окончательный набор сценариев и их приоритетов, риски, точки чувствительности. Однако ATAM не предлагает способы решения вышеуказанных выводов.
+**Роли в ATAM:**
+  * **Внешние заинтересованные стороны** не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
+  * **Внутренние заинтересованные стороны** принимают непосредственное участие в процессе разработки ПО архитектуры. Их роль заключается в анализе, определение и реализации архитектуры.
+  * **Команда ATAM** должна быть внешней по отношению к команде разработчиков по причинам нейтральности. Она приглашается, чтобы провести оценивание.
+====Cost Benefit Analysis Method(CBAM)====
+Метод анализа рентабельности (Cost Benefit Analysis Method, CBAM). Метод CBAM основное внимание уделяет анализу затрат, выгод и планированию последствий архитектурных решений.
+**Шаги в CBAM:**
+  - Выберите сценарии и связанные с ними стратегии в области архитектуры
+  - Оценка качества и атрибутов
+  - Количественная оценка преимуществ каждого архитектурного стиля
+  - Подсчет стоимости каждого архитектурного стиля и расчет времени на его внедрение
+  - Вычисление "желания" внедрения каждого архитектурного стиля
+  - Принятие решения
+**Роли в CBAM:**
+  * **Внешние заинтересованные стороны** не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
+  * **Внутренние заинтересованные стороны** принимают непосредственное участие в процессе разработки ПО архитектуры.
+  * **Команда CBAM** не имеет прямого отношения к выбору архитектуры ПО, но проводит CBAM сессию.
+====Architecture Level Modifiability Analysis(ALMA)====
+Анализ модифицируемости на уровне архитектуры (Architecture Level Modifiability Analysis, ALMA). ALMA оценивает модифицируемость архитектуры для систем бизнес-аналитики.
+**Шаги в ALMA:**
+  - Установите цель анализа
+  - Опишите архитектуру ПО
+  - Выявите сценарии, которые могут влиять на модифицируемость архитектуры
+  - Оцените сценарии из предыдущего пункта
+  - Интерпретируйте результаты: полученные результаты используются для прогнозирования затрат на техническое обслуживание.
+**Роли в ALMA:**
+  * **Внешние заинтересованные стороны** не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
+  * **Внутренние заинтересованные стороны** принимают непосредственное участие в процессе разработки ПО архитектуры.
+  * **Команда ALMA** не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.
+====Family - Architecture Analysis Method(FAAM)====
+Метод оценки семейства архитектур (Family Architecture Assessment Method, FAAM). FAAM оценивает архитектуры семейства информационных систем с точки зрения возможности взаимодействия и расширяемости.
+**Шаги в FAAM:**
+  - Определите цель оценки
+    - Установите объем и содержание системы-семьи
+    - Установить будущие планы для семьи (интероперабельности,а также изменения растяжимости)
+    - Предоставьте указания заинтересованным сторонам, чтобы помочь им генерировать требования
+  - Подготовка требований к системе качества
+  - Подготовьте архитектуру
+  - Обзор артефактов
+  - Проверка архитектуры на соответствие установленным в пункте 2 требованиям с акцентом на легкость интеграции
+  - Отчет об итогах и предложения
+**Роли в FAAM:**
+  * **Внешние заинтересованные стороны** не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
+  * **Внутренние заинтересованные стороны** принимают непосредственное участие в процессе разработки ПО архитектуры.
+  * **Команда FAAM** не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.
+====Таблица сравнения различных методов анализа архитектуры ПО====
+^ Метод ^ Оценка\\ Качества^ Метрика^ Описание процесса ^Сильные\\ стороны^Слабые\\ стороны^Типы систем,\\ к которым применим^
+^ SAAM  | Модифицируемость|Классификация\\ сценариев| Разумное | Определение потенциальных областей высокой сложности\\ Открыт для любого\\ архитектурного описания| Нет явной метрики качества\\ Не отображает шаги| Все|
+^ ATAM  | Модифицируемость | Точки чувствительности\\ Компромисные точки\\ Поддерживается ATA | Хорошее | Генерация сценариев основана на требованиях\\ Применим для статических и динамических свойств\\ Вспомогательное дерево качества | Требует глубоких технических знаний | Все |
+^ CBAM  | Затраты и выгоды| Время и затраты | Разумное | Предоставляет бизнес измерения для определенных изменений системы\\ Вносит ясность в неопределенность, связанную с оценками| Определение цен и выгоды может быть сделано участниками в открытой форме| Все |
+^ ALMA  | Модифицируемость | Влияние оценки\\ Модифицируемость предсказываемой модели| Разумное |Критерий остановки генерации сценариев| Ограниченное множество случаев изучения\\ Концентрируется на статических свойствах| Бизнес информационные системы |
+^ FAAM  | Совместимость и расширяемость | Различные специализированные таблицы и диаграммы | Очень хорошее |Акцент на расширении прав и возможностей команд | Доказан только в определенной среде\\ Концентрируется на статических свойствах| Системы-семьи |\\
+====Список литературы====
+  - Paul Clements, Rick Kazman and Mark Klein
+  - Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2002. ATAM: Method for architecture evaluation”: ATAM - Architecture Trade-off Analysis Method report