Опыт применения метода ATAM для оценки архитектуры

Опыт применения
метода ATAM
для оценки архитектуры
Игорь Беспальчук
Руководитель проектов дирекции архитектуры
09.11.2016

Группа компаний CUSTIS
 20 лет на российском ИТ-рынке
 Масштабные проекты для отраслевых лидеров
и организаций с высокой динамикой бизнес-процессов: Банка
России, Газпромбанка, ГК «Спортмастер»
(розничных сетей «Спортмастер», O'STIN, FUNDAY)
 Работа на стратегическое развитие клиентов,
решение критически важных бизнес-задач средствами ИТ,
поддержка передовых технологических проектов
2 | 17

О чем доклад
 В индустрии существуют методы
оценки архитектуры софта
 Мы пробовали применять самый известный из них
(ATAM — Architecture Tradeoff Analysis Method)
 Расскажем о том, что получилось
 Если совсем коротко о результатах:
 Польза есть
 Есть и сложности

Оценка архитектуры
Что это и зачем нужно

Архитектурный подход

Зачем нужна оценка архитектуры?
 Прямое назначение:
 Позволяет выявить/смягчить риски
до старта массированной разработки
 Вынуждает проверять соответствие архитектуры
требованиям и трассировку к бизнес-целям
 Вынуждает обосновывать принятые решения, выявлять
недостатки и совершенствовать архитектуру

Зачем нужна оценка архитектуры?
 Сопутствующие выгоды:
 Проявляет архитектуру, форсирует ее коммуникацию и
понимание
 Проявляет/улучшает качество и полноту входных материалов
(архитектурно-значимых требований/драйверов),
выявляет конфликты/дыры в исходных требованиях
 Проявляет недостатки многих смежных процессов

Процедура «Защита архитектуры»
 Разрабатывалась в 2013 году
 Проводилась несколько раз
 Все придумывали сами
(как мы это любим)
 Перед этим были на семинаре
Питера Хрущки,
где был краткий обзор ATAM
и где подхватили саму идею

Что получилось в результате
самодеятельности?
Хорошее
 Архитектура проявлялась
 Архитектура обсуждалась
 Архитектура улучшалась
 Риски всплывали
 Сомнительные решения
 Потеря трассировки
к бизнес-целям
 Дырки в требованиях
Плохое
 Было очень долго
 Было неуправляемо
 Риторика «защиты»
демотивировала
 Ценность результатов для
управленца не всегда ясна
 Плохо тиражируемо

Когда ничего не получается –
прочитай инструкцию учебник
 Книжку купили в 2013 году
 Прочитали — в 2015…

“
”
Еще в 1970-х стало понятно, что при
организации сессий оценки дизайна нельзя
просто посадить людей в одну комнату
и попросить оценить дизайн. Вместо этого
нужно давать задания, для выполнения
которых дизайн должен быть хорошим
Нестрогая цитата из книжки
* Кстати, ту же логику организации коллективной работы
мы видим на стратегических сессиях c методологами школы СМД

Про ATAM
Architecture Trade-off Analysis Method
Теория

Отличия ATAM от «самоделки CUSTIS»
 Строгая процедура, роли и порядок действий
 Четко обозначенные предметы рассмотрения
(атрибуты и сценарии качества)
 Жесткие форматы бизнес-значимых результатов,
которые нужно получить
(риски, компромиссы, etc)
 Риторика «совместного исследования»

Коротко про историю ATAM
 Разработан в Software Engineering Institute (CMU SEI)
 Практическое применение — с 1998 года,
оригинальная статья-отчет — 2000 года
 Не первый метод, но самый известный
и широко используемый

Этапы ATAM
Этап Операции Описание Участники Длительность
(вариант)
0 Подготовка Достижение договоренностей
и планирование. Определение
проекта, области анализа, состава
участников
Руководство группы
оценки,
ответственные за
проект
По ситуации
1 Оценка Выявление требований к качеству,
анализ архитектурных подходов,
создание дерева полезности
Группа оценки,
ответственные за
проект
1 день,
перерыв
2-3 недели
2 Оценка Верификация дерева полезности
стейкхолдерами, анализ
архитектурных подходов с их
точки зрения
Группа оценки,
ответственные
за проект,
стейкхолдеры
2 дня
3 Доработка Представление сводного отчета Группа оценки,
заказчик оценки
1 неделя

Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
 Составление отчетов
9. Представление результатов
17

Атрибуты качества
18

Сценарии качества
19

Дерево полезности
20

21

Пример
анализа
одного
сценария
22

23

Опыт применения ATAM в SEI
 SEI провел ~500 (!) сессий оценки в самых разных
коммерческих, государственных, военных проектах
 Есть интересная статистика по результатам оценок
 Статья 2006 года
«Risk Themes Discovered Through Architecture
Evaluations»

Опыт применения метода ATAM для оценки архитектуры

Какие другие методы оценки есть?
 ATAM — риски, коллаборация со стейкхолдерами
 LAAAM — сравнение двух вариантов дизайна через
систему весов, много offline
 См. доклад от NVision нв SECR 2013
 CBAM — рационализация выбора между вариантами
через финансовые модели
 ARID — легкая оценка небольших фрагментов
 QAW — разработка сценариев качества

ATAM в CUSTIS
От теории — к практике

Цели
 Попробовать более структурированный метод оценки
 Если получится хорошо, то:
 Использовать в проектах
 Растить имидж
 Предлагать клиентам

Состав участников
 Ведущий, фасилитатор
 Заказчик оценки, менеджер дивизиона
 Архитектор
 Группа оценки, смежные архитекторы
 Приглашенные «и. о. стейкхолдеров»

Хронология
 Июль 2015 — первые предложения применить ATAM
 Август 2015 — решение об апробации,
создана рабочая группа
 Октябрь 2015 — выбор проекта «Витрина учета»
 22.12, 24.12, 30.12, 21.01 — 4 дня по 4 часа
и 08.02 – 1.5 часа
Сложность №1. Для любого коллаборативного
метода тяжело согласовать время со всеми
участниками

Отличия от «эталонного» ATAM
 Без реальных стейкхолдеров
 Не так жестко были ограничены расписанием —
продлевали там, где не успевали
(начальный тайминг составлял 2 дня по 4 часа)

День 0 (17.11.2016)
Вводная встреча
 2 часа, широкий круг участников (9 человек)
 Рассказ про метод
 Рассказ про проект
 Ответы на вопросы

День 1 (22.12.2016)
Технический анализ
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Еще раз вспомнили про проект
 Заслушали доклад про архитектуру
(задавали много вопросов, заглублялись, затянулось)
 Выписали архитектурные драйверы
(самые значимые требования, цели, ограничения)
 Выделили архитектурные решения
 Начали генерировать дерево качества
и сценарии (и хорошо пошло)

День 2 (24.12.2016)
Технический анализ (продолжение)
 Продолжили генерацию сценариев
 Провели приоритизацию
(с применением техники голосования получилось быстро,
организованно и достаточно убедительно)
 Провели анализ одного (!) сценария

Сценарий #: 12 Сценарий:
ZZZ отработало 1 год. Суммарный объем данных ZZZ и данных систем-
источников, специально хранящихся для выгрузки в ZZZ, занимает менее
200 Гб в оперативном хранилище.
Атрибут(ы) Хранимые данные
Условия
Стимул
Реакция
Архитектурные решения Чувствительность
Компромисное
решение
Риск Без риска
17. События изменения рейса приводят к генерации
сторнирующих и обновляющих операций в журнале
исходящих операций конкретного потребителя,
по операциям относящимся к данному рейсу
S1 NR1
1. Выделение единого Модуля консистентности (ZZZ) S2 NR2
2. Интеграция учетных систем / Дисп и ZZZ через шину
(BBB)
S3 T1 NR3
7. Системы источники передают, а операционный слой
хранит данные в формате систем-источников,
преобразование данных в формат получателей выполняет
адаптер для потребителя
S4 NR4
20. Для разных потребителей готовятся отдельные
порции, с отдельным журналом связи порций
и сообщений
S5 T3 NR5
24. Предусмотрена архивация входящих и исходящих
данных ZZZ
NR6
6. Обогащение данными для каждого получателя делается
индивидуально (отдельное API), с уникальными
интерфейсами в системах-источниках
S6 T2 NR7
S1 — Зависимость от необходимого горизонта изменения задним числом.
NR1-NR3 — Не является рисковым, т. к. по оценке на 60 дней нужно 162 Гб для хранения событий/операций с учетом
четырехкратного дублирования в ZZZ.
S2 — Дублирование учетных событий источников в ZZZ создает существенный объем данных, порядок которого соответствует
граничному размеру.
S3, T1 — Использование BBBа увеличивает хранимый объем данных, с другой стороны асинхронный характер взаимодействия

День 3 (30.12.2016)
Технический анализ (окончание)
 Пообсуждали неясные места в методе
и его применимость (~50 мин)
 Посмотрели «домашнее задание» архитектора —
анализ второго сценария
(это оказалось очень скучно!)
 Провели анализ еще двух сценариев
 В одном — уткнулись в отсутствие модели производительности
 В другом — уткнулись в непроработанность требований
по перевыгрузке

День 4 (21.01.2016)
Опрос «стейкхолдеров»
 4 часа, широкий состав участников (8 человек) —
включая «и. о. стейкхолдеров»
 Напомнили про метод
 Напомнили про проект
 Показали по диагонали предыдущие результаты
(непонятно, было ли полезно)
 Провели мозговой штурм среди стейкхолдеров,
сгенерировали еще десяток сценариев
(акцент оказался на совсем других атрибутах качества!)
 Приоритизировали новые сценарии
(также путем голосования)

День 5 (08.02.2016)
Анализ последнего сценария
 1.5 часа, узкий круг участников
 Провели анализ еще одного сценария,
самого приоритетного из второй порции сценариев

Результаты
Что мы получили за эти дни?

Виды результатов (очевидные)
 Презентация проекта
 Описание архитектуры
 Аудио-запись (лучше сразу делать видео)
с рассказом о проекте, системе и архитектуре
 …продолжение на следующем слайде…

Виды результатов (предписанные ATAM)
 Каталог значимых архитектурных решений (вырос вдвое)
 Сценарии качества (дерево качества) с приоритетами
 Перечень рискованных решений
(создающих угрозу для значимых атрибутов качества)
 Перечень компромиссных решений
(улучшающих одни значимые атрибуты качества за счет других)
 Перечень сильных решений, удерживающих качество
 Перечень проблемных вопросов и рисков
за границей методики оценки
 …продолжение на следующем слайде…

Виды результатов (дополнительные)
 Выявлены и зафиксированы
 Пропущенные стейкхолдеры и требования
 Скрытые решения в архитектуре
 Конфликт интересов с клиентом, значимый для архитектуры
 Темные места и отсутствующие модели в архитектуре
 Исправление неверных ожиданий
 Дополнительные вопросы для анализа и обсуждения с СМ
 Некоторые архитектурные решения изменены
 Некоторые архитектурные модели разработаны в процессе
 (+ неартифицируемые результаты
лучшего понимания и коммуникации)

Пример риска с обоснованием
 Решение № 30: Изменения «неучетных» аналитик
отражаются потребителям в последующих порциях
сторнированием исходящих операций со старым
значением и созданием новых с новым значением
 В сценарии с быстрым (10 ч*ч) добавлением новой
для ZZZ аналитики это решение рискованно:
 Требуется написание логики → мы можем не уложиться
в целевые трудозатраты
 Добавление же «учетной» аналитики решается
настройкой справочников инженерами

Примеры измененных решений
Было Стало Причина
Хранение входящих
операций в операционном
слое атрибутным
хранением
Для хранения используется
оригинальный формат
XML, в котором ZZZ
получает сообщения от
модулей-источников
Поиск по атрибутному
хранению,
инстанцирование
сущностей и пр. более
медленные. Возможности
работы с XML современных
СУБД впечатляют, в т. ч.
есть индексирование
Все входящие события
идут в единый
операционный слой (и
события учетных систем, и
события неучетных систем)
За частью данных ZZZ все
же сам обращается
к модулям-источникам
Сокращение трудозатрат
ZZZ хостится на тех же
серверах, что и YYY
Заменили на XXX Нагрузка на ZZZ
приличная, причем
большая часть потока
данных — от XXX. Сервера
XXX значительно более
мощные

Пример компромисса
 Решение № 28: Сообщения через BBB передаются
в «человекочитаемом» формате (XML или JSON), но сжимаются
 «Человекочитаемый» формат предпочтителен для удобства
поддержки (сокращение времени поддержки)
 Но требует в разы больше места для передачи/хранения,
чем бинарный или сжатый формат
 Сжатие
 Решает проблему размера сообщения и производительности
BBBа
 Решает проблему размера БД ZZZ (сценарий 12)
 Но либо ломает удобство поддержки (сценарии 23, 24): время
разбирательств увеличивается
 Либо требует не заложенных в проект затрат на доработки
BBB.API и BBB.Монитора

Примеры «темных мест» в архитектуре
и системных требованиях
 Отсутствует какая-либо модель производительности,
позволяющая делать оценки
— сделана после мероприятия
 Никак не прорабатывались сценарии начальной
инициализации и перезагрузки данных — при высоких рисках
можно не влезть в разумное время и объемы данных
— требования были уточнены позже

Пример ошибочных ожиданий
 Начальная оценка в одном из сценариев
модифицируемости — 10 ч*ч
 Оценка после анализа — 40 ч*ч

Затраты
 План: 115 ч*ч
 Факт: 168 ч*ч
 Защиты «по старинке»
тоже стоили от 100 до 200 ч*ч
 Преимущества ATAM
 Планируется легче
 Движение структурировано
 Затраты управляемы
Сложность №2. Любое коллаборативное
мероприятие стоит дорого
33,75 33,5
31,67 30,83
18
6,5 6 6
2
0
5
10
15
20
25
30
35
40

Это много или мало?
 Уместно вспомнить исследование Барри Боэма
“The ROI of System Engineering”
Размер
проекта
(KSLOC)
Оптимальные
затраты
на СИ, %
Снижение
затрат
за счет СИ, %
10 5 18
100 20 38
1000 26 63
10000 33 92
*СИ — практики системной инженерии

Субъективные впечатления
Главное от каждого участника

Заказчик оценки
 Для маленьких проектов (~1000ч*ч) — дорого,
если удастся сохранить объемы затрат (~160ч*ч),
это вполне посильно для проектов в 5000ч*ч
 Более структурно и системно организованно,
чем предыдущие попытки оценки архитектуры,
ощущение более предсказуемого результата на
выходе
 Есть мысль, что все-таки основная ценность наших
проектов в правильном проектировании СТА/ИА, и
хорошо бы такие или похожие практики научиться
делать для СТА/ИА

Архитектор
 В результате обсуждения некоторые решения сразу «поплыли»,
а некоторые были изменены уже после проведения оценки
 После оценки:
 Были проработаны структуры данных всех компонентов
 Атрибутное хранение заменено на XML
 Проработано сопоставление входных операций 1:M
 Некоторые существующие диаграммы перерисованы проще и понятнее,
в целом картина стала более связной
 Неожиданные результаты:
 Тема производительности БД «выплыла» как потенциально рисковая.
До оценки требование к производительности декларировалось,
но не прорабатывалось
 Обнаружили, что для расчетной нагрузки ZZZ начальную инициализацию провести
за оговоренный срок невозможно
 Необходимость процедур переинициализации и сверки остатков

PM, эксперт группы оценки
 Медленно двигались по процессу из-за периодических «сваливаний»
в обсуждения и проектирований решений. Нужно более жесткое
модерирование
 Были проблемы с подготовленными шаблонами — местами в них
была заложена излишняя жесткость, некоторые сценарии работы
с артефактами были не предусмотрены
 В процессе оценки были подняты важные вопросы, о которых ранее
не думали; выявлены недоработки документации и проектирования;
спроектированы новые и выявлены скрытые архитектурные решения
 Все это позволило лучше понимать, почему принято то или иное решение;
осознать существующие риски; повысить качество документации.
Работа проделана с пользой
 После оценки я:
 Иначе «порезал» скоуп проекта в поисках оптимизации трудозатрат
 Иначе смотрю на проект в целом и его архитектуру в частности

И. о. стейкхолдера №1
 В целом создалось ощущение правильной идеи мероприятия.
Подумал, что если бы некое подобное действо было проведено
на старте проекта X, это позволило бы вскрыть ключевые
проблемы предполагавшейся архитектуры, в результате
проект мог бы пойти в совершенно другой плоскости либо
мотивированно мог быть свернут в самом начале
 Но как и в любом деле тут главное — «без фанатизма», чтобы
вложенные усилия (а учитывая кол-во вовлеченного народу,
трудозатраты распухают очень быстро) оправдались
результатом. Для небольших проектов возможно стоит
сознательно отказаться от заглубления в детали
и пробегаться большим составом лишь «по верхам», при этом
не стремясь прийти к какому-то согласованному результату,
рассматривая мероприятие лишь как способ получения сырья
для детальной проработки в более тесном составе

И. о. стейкхолдера №2
 Выступала в роли представителя службы
сопровождения системы
 Понравилось, что на каком-то этапе в голосе людей,
проектировавших систему, слышалось удивление
и удовлетворение. Значит, удалось поднять какие-то
неожиданные вопросы, показавшиеся им полезными
 Интересна идея с голосованием за важность разных
кейсов. Если проводить такое голосование открыто
среди заказчиков, то процесс эксплуатации, возможно,
будет более осознанным

Фасилитатор
 Тезис про «нужно выдавать задания, а не рассказывать
и не задавать общие вопросы» проявился во всей красе
 Динамика группы и включенность участников была очень
неоднородна по процессу — этим нужно уметь играть
 Нужно смелее реконструировать метод и использовать
отдельные его части для сборки под конкретный проект
(вспоминаем ситуационную инженерию методов)
 Например, в нашей ситуации без внешних стейкхолеров
можно было быстрее переходить к анализу, сильно сократив
обзор проекта и архитектуры
 Другой пример: режим работы «один сделал — остальные
смотрят и проверяют» на порядок менее эффективен,
чем совместная работа
Сложность №3. Метод надо пересобирать
под ситуацию, не все части всегда одинаково
полезны

Что дальше? Пока только идеи
 Пробовать еще, на других проектах
 Жестче управлять таймингом,
смотреть, как это повлияет на результаты
 Выделять отдельные практики,
в частности — генерации сценариев (QAW)
 И использовать их на этапе проектирования архитектуры
 Пробовать облегченные варианты
(Lightweight ATAM, LAAAM, etc)
 Попробовать что-то похожее для оценки СТА/ИА
 Выявление требований и сценариев
 Подходы к организации процесса
 Трассировка решений к бизнес-ценности
 Смелее адаптировать процедуру под ситуацию,
после того, как стали понятны механизмы

Выводы
 Изучать методы отрасли крайне полезно
(хотя бы после того, как сам наступил на грабли)
 В том числе вдаваться в детали, читать книги, учиться,
потому что поверхностного понимания может не хватить
для результата
 Оценка архитектуры — необходимый хотя бы в малом объеме
элемент процесса проектирования
(если вообще применяется архитектурный подход)
 ATAM во многих аспектах лучше «самоделки» CUSTIS
(с другими технологиями и методологиями обычно происходит то же самое)
 Хотя это, конечно, не панацея и не серебряная пуля,
никакого волшебства. И не покрывает всех аспектов
 В чистом виде ATAM (как любой метод) малоприменим (тяжеловат)
 Но если подойти с пониманием, разобрать и пересобрать
под ситуацию конкретного проекта, то принесет большой
и приемлемый по затратам (окупаемый вдолгую) профит

Где почитать подробнее про ATAM
и другие методы оценки архитектуры?
 Кратко на русском — в книге
«Архитектура ПО на практике» Л.Басса и др.

Как организовать у себя?
 Это сложно (особенно в первый раз), но посильно
 Есть книги, презентации, статьи, тренинги
 Есть опыт других компаний

Спасибо за внимание!
Игорь Беспальчук
bespalchuk@custis.ru
www.linkedin.com/in/iamhere2
Видео-канал CUSTIS
https://vimeo.com/custis

Опыт применения метода ATAM для оценки архитектуры

More Related Content

Similar to Опыт применения метода ATAM для оценки архитектуры (11)

More from CUSTIS (20)

Опыт применения метода ATAM для оценки архитектуры