======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