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

Анализ разработки программного обеспечения и его оценка стали устоявшейся практикой среди проектировщиков ПО. Исследовательские группы предлагают различные методы для оценки качества архитектуры ПО. Ниже приведен список доступных сегодня методов, поддерживающих анализ атрибутов качества ПО:

  1. SAAM, Software Architecture Analysis Method
  2. ATAM, Architecture Trade-off Analysis Method
  3. CBAM, Cost Benefit Analysis Method
  4. ALMA, Architecture Level Modifiability Analysis
  5. FAAM, Family - Architecture Analysis Method

SAAM - первый широко распространенный метод анализа архитектуры ПО.Изначально SAAM создавался для оценки модифицируемости, но позже был расширен для анализа архитектуры относительно показателей качества, таких как модифицируемость, портируемость, расширяемость, интегрируемость и функциональный охват.
Шаги в SAAM:

  1. Разработка сценариев: Определение типов деятельности, которые система должна поддерживать. Основная трудность при разработке сценариев заключается в определении основных видов применения, пользователей, атрибутов качества и наиболее важное - всех предполагаемых будущих изменений в системе.
  2. Описание архитектур(ы): SAAM представляет кандидатов архитектур(ы)
  3. Классификация и расстановка приоритетов сценариев: На этом этапе анализа сценарии классифицируются на прямые и косвенные. Прямой сценарий поддерживается кандидатом архитектуры. Косвенный сценарий - последовательность событий, при которой реализация архитектуры должна перенести изменения. Приоритет сценариев основан на процедуре голосования, результаты голосования будут представлять собой набор косвенных сценариев, которые считаются наиболее вероятны.
  4. Индивидуальная оценка косвенных сценариев: В случае косвенного сценария SAAM описывает, как архитектура должны быть изменена, чтобы соответствовать сценарию. Для каждого косвенного сценария должны быть определены архитектурные изменения, необходимые для облегчения этого сценария вместе с затронутыми компонентами новой системы и усилиями по осуществлению этих изменений.
  5. Оценка взаимодействия сценариев: Когда два или более сценариев хотят изменить одни и те же компоненты архитектуры, затронутые компоненты должны быть изменены или разделены на подкомпоненты, чтобы избежать взаимодействия различных сценариев.
  6. Создание общей оценки: Наконец, каждому сценарию присваивается вес с точки зрения их относительной важности для успеха системы. На основе этого взвешивания может быть предложен общий рейтинг, если сравниваются несколько архитектур.

Роли в SAAM:

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

Метод анализа архитектурных компромиссов (ATAM). ATAM – это доработанная и улучшенная версия SAAM, которая позволяет пересматривать архитектурные решения относительно требований параметров качества и того, насколько хорошо эти решения отвечают конкретным целевым показателям качества.
Шаги в ATAM:

  1. Фаза презентации:
    1. Презентация ATAM
    2. Представление бизнес двигателей
    3. Представление архитектуры
  2. Фаза исследования и анализа:
    1. Определение архитектурных подходов
    2. Создание вспомогательного дерева атрибутов качества: Атрибуты качества, которые составляют систему “полезности”, выявляются и разносятся на разные уровни дерева.
    3. Анализ архитектурных подходов: На основе приоритетных сценариев, определенных на предыдущем этапе, архитектурные подходы, которые соответствуют этим сценариям, выявляются и анализируются.
  3. Фаза тестирования:
    1. Мозговой штурм и расставление приоритетов сценариев: Команда ATAM вместе с заинтересованными сторонами расставляют приоритеты сценариям путем голосования.
    2. Повторный анализ архитектурных подходов
  4. Фаза отчетности:
    1. Презентация результатов: Задокументированные архитектурные стили, окончательный набор сценариев и их приоритетов, риски, точки чувствительности. Однако ATAM не предлагает способы решения вышеуказанных выводов.

Роли в ATAM:

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

Метод анализа рентабельности (Cost Benefit Analysis Method, CBAM). Метод CBAM основное внимание уделяет анализу затрат, выгод и планированию последствий архитектурных решений.

Шаги в CBAM:

  1. Выберите сценарии и связанные с ними стратегии в области архитектуры
  2. Оценка качества и атрибутов
  3. Количественная оценка преимуществ каждого архитектурного стиля
  4. Подсчет стоимости каждого архитектурного стиля и расчет времени на его внедрение
  5. Вычисление “желания” внедрения каждого архитектурного стиля
  6. Принятие решения

Роли в CBAM:

  • Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
  • Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
  • Команда CBAM не имеет прямого отношения к выбору архитектуры ПО, но проводит CBAM сессию.

Анализ модифицируемости на уровне архитектуры (Architecture Level Modifiability Analysis, ALMA). ALMA оценивает модифицируемость архитектуры для систем бизнес-аналитики.

Шаги в ALMA:

  1. Установите цель анализа
  2. Опишите архитектуру ПО
  3. Выявите сценарии, которые могут влиять на модифицируемость архитектуры
  4. Оцените сценарии из предыдущего пункта
  5. Интерпретируйте результаты: полученные результаты используются для прогнозирования затрат на техническое обслуживание.

Роли в ALMA:

  • Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
  • Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
  • Команда ALMA не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.

Метод оценки семейства архитектур (Family Architecture Assessment Method, FAAM). FAAM оценивает архитектуры семейства информационных систем с точки зрения возможности взаимодействия и расширяемости.

Шаги в FAAM:

  1. Определите цель оценки
    1. Установите объем и содержание системы-семьи
    2. Установить будущие планы для семьи (интероперабельности,а также изменения растяжимости)
    3. Предоставьте указания заинтересованным сторонам, чтобы помочь им генерировать требования
  2. Подготовка требований к системе качества
  3. Подготовьте архитектуру
  4. Обзор артефактов
  5. Проверка архитектуры на соответствие установленным в пункте 2 требованиям с акцентом на легкость интеграции
  6. Отчет об итогах и предложения

Роли в FAAM:

  • Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
  • Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
  • Команда FAAM не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.
Метод Оценка
Качества
Метрика Описание процесса Сильные
стороны
Слабые
стороны
Типы систем,
к которым применим
SAAM МодифицируемостьКлассификация
сценариев
Разумное Определение потенциальных областей высокой сложности
Открыт для любого
архитектурного описания
Нет явной метрики качества
Не отображает шаги
Все
ATAM Модифицируемость Точки чувствительности
Компромисные точки
Поддерживается ATA
Хорошее Генерация сценариев основана на требованиях
Применим для статических и динамических свойств
Вспомогательное дерево качества
Требует глубоких технических знаний Все
CBAM Затраты и выгоды Время и затраты Разумное Предоставляет бизнес измерения для определенных изменений системы
Вносит ясность в неопределенность, связанную с оценками
Определение цен и выгоды может быть сделано участниками в открытой форме Все
ALMA Модифицируемость Влияние оценки
Модифицируемость предсказываемой модели
Разумное Критерий остановки генерации сценариев Ограниченное множество случаев изучения
Концентрируется на статических свойствах
Бизнес информационные системы
FAAM Совместимость и расширяемость Различные специализированные таблицы и диаграммы Очень хорошее Акцент на расширении прав и возможностей команд Доказан только в определенной среде
Концентрируется на статических свойствах
Системы-семьи
  1. Paul Clements, Rick Kazman and Mark Klein
  2. Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2002. ATAM: Method for architecture evaluation”: ATAM - Architecture Trade-off Analysis Method report