SlideShare a Scribd company logo
Опыт применения
метода ATAM
для оценки архитектуры
Игорь Беспальчук
Руководитель проектов дирекции архитектуры
09.11.2016
ГРУППА КОМПАНИЙ CUSTIS
 20 лет на российском ИТ-рынке
 Масштабные проекты для отраслевых лидеров
и организаций с высокой динамикой бизнес-процессов: Банка
России, Газпромбанка, ГК «Спортмастер»
(розничных сетей «Спортмастер», O'STIN, FUNDAY)
 Работа на стратегическое развитие клиентов,
решение критически важных бизнес-задач средствами ИТ,
поддержка передовых технологических проектов
2 | 17
О чем доклад
 В индустрии существуют методы
оценки архитектуры софта
 Мы пробовали применять самый известный из них
(ATAM — Architecture Tradeoff Analysis Method)
 Расскажем о том, что получилось
 Если совсем коротко о результатах:
 Польза есть
 Есть и сложности
Оценка архитектуры
Что это и зачем нужно
Архитектурный подход
Зачем нужна оценка архитектуры?
 Прямое назначение:
 Позволяет выявить/смягчить риски
до старта массированной разработки
 Вынуждает проверять соответствие архитектуры
требованиям и трассировку к бизнес-целям
 Вынуждает обосновывать принятые решения, выявлять
недостатки и совершенствовать архитектуру
Зачем нужна оценка архитектуры?
 Сопутствующие выгоды:
 Проявляет архитектуру, форсирует ее коммуникацию и
понимание
 Проявляет/улучшает качество и полноту входных материалов
(архитектурно-значимых требований/драйверов),
выявляет конфликты/дыры в исходных требованиях
 Проявляет недостатки многих смежных процессов
Опыт CUSTIS
до ATAM
Процедура «Защита архитектуры»
 Разрабатывалась в 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. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
17
Атрибуты качества
18
Сценарии качества
19
Дерево полезности
20
Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
21
Пример
анализа
одного
сценария
22
Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
23
Опыт применения ATAM в SEI
 SEI провел ~500 (!) сессий оценки в самых разных
коммерческих, государственных, военных проектах
 Есть интересная статистика по результатам оценок
 Статья 2006 года
«Risk Themes Discovered Through Architecture
Evaluations»
Какие другие методы оценки есть?
 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)
Технический анализ (продолжение)
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Продолжили генерацию сценариев
 Провели приоритизацию
(с применением техники голосования получилось быстро,
организованно и достаточно убедительно)
 Провели анализ одного (!) сценария
Сценарий #: 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)
Технический анализ (окончание)
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Пообсуждали неясные места в методе
и его применимость (~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

More Related Content

What's hot

А.Левенчук -- Essence для управления технологиями
А.Левенчук -- Essence для управления технологиямиА.Левенчук -- Essence для управления технологиями
А.Левенчук -- Essence для управления технологиями
Anatoly Levenchuk
 
Стандартизация предмета системной инженерии
Стандартизация предмета системной инженерииСтандартизация предмета системной инженерии
Стандартизация предмета системной инженерии
Anatoly Levenchuk
 
Системная инженерия как технология мышления
Системная инженерия как технология мышленияСистемная инженерия как технология мышления
Системная инженерия как технология мышления
Anatoly Levenchuk
 
Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)
Anatoly Levenchuk
 
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельностиА.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
Anatoly Levenchuk
 
Тьюториал "Введение в системную инженерию" (14 января 2013)
Тьюториал "Введение в системную инженерию" (14 января 2013)Тьюториал "Введение в системную инженерию" (14 января 2013)
Тьюториал "Введение в системную инженерию" (14 января 2013)
Anatoly Levenchuk
 
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
Alexander Shamanin
 
В.Мизгулин -- программа магистратуры по системной инженерии
В.Мизгулин -- программа магистратуры по системной инженерииВ.Мизгулин -- программа магистратуры по системной инженерии
В.Мизгулин -- программа магистратуры по системной инженерии
Anatoly Levenchuk
 
А.Левенчук -- плохая модульность
А.Левенчук -- плохая модульностьА.Левенчук -- плохая модульность
А.Левенчук -- плохая модульность
Anatoly Levenchuk
 
А.Левенчук -- Essence в варианте для системной инженерии
А.Левенчук -- Essence в варианте для системной инженерииА.Левенчук -- Essence в варианте для системной инженерии
А.Левенчук -- Essence в варианте для системной инженерии
Anatoly Levenchuk
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектирования
Anatoly Levenchuk
 
А.Левенчук -- смычка кортекса и экзокортекса
А.Левенчук -- смычка кортекса и экзокортексаА.Левенчук -- смычка кортекса и экзокортекса
А.Левенчук -- смычка кортекса и экзокортекса
Anatoly Levenchuk
 
Практики жизненного цикла систем машинного обучения
Практики жизненного цикла систем машинного обученияПрактики жизненного цикла систем машинного обучения
Практики жизненного цикла систем машинного обучения
CEE-SEC(R)
 
Юрий Бабин -- многокритериальная оптимизация в инженерных проектах
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахЮрий Бабин -- многокритериальная оптимизация в инженерных проектах
Юрий Бабин -- многокритериальная оптимизация в инженерных проектах
Anatoly Levenchuk
 
Семантические информационные модели и ISO 15926
Семантические информационные модели и ISO 15926Семантические информационные модели и ISO 15926
Семантические информационные модели и ISO 15926
Anatoly Levenchuk
 
Мастер-класс: Системное мышление
Мастер-класс: Системное мышлениеМастер-класс: Системное мышление
Мастер-класс: Системное мышление
CEE-SEC(R)
 
А.Левенчук -- развитие личности
А.Левенчук -- развитие личностиА.Левенчук -- развитие личности
А.Левенчук -- развитие личности
Anatoly Levenchuk
 
А.Левенчук -- как выжить в эпоху перемен перемен
А.Левенчук -- как выжить в эпоху перемен переменА.Левенчук -- как выжить в эпоху перемен перемен
А.Левенчук -- как выжить в эпоху перемен перемен
Anatoly Levenchuk
 
Системноинженерное мышление в непрерывном образовании
Системноинженерное мышление в непрерывном образованииСистемноинженерное мышление в непрерывном образовании
Системноинженерное мышление в непрерывном образовании
Anatoly Levenchuk
 
А.Ефремов -- встречи Русского отделения INCOSE
А.Ефремов -- встречи Русского отделения INCOSEА.Ефремов -- встречи Русского отделения INCOSE
А.Ефремов -- встречи Русского отделения INCOSE
Anatoly Levenchuk
 

What's hot (20)

А.Левенчук -- Essence для управления технологиями
А.Левенчук -- Essence для управления технологиямиА.Левенчук -- Essence для управления технологиями
А.Левенчук -- Essence для управления технологиями
 
Стандартизация предмета системной инженерии
Стандартизация предмета системной инженерииСтандартизация предмета системной инженерии
Стандартизация предмета системной инженерии
 
Системная инженерия как технология мышления
Системная инженерия как технология мышленияСистемная инженерия как технология мышления
Системная инженерия как технология мышления
 
Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)
 
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельностиА.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
А.Левенчук -- процессы, проекты, кейсы, практики и прочие описания деятельности
 
Тьюториал "Введение в системную инженерию" (14 января 2013)
Тьюториал "Введение в системную инженерию" (14 января 2013)Тьюториал "Введение в системную инженерию" (14 января 2013)
Тьюториал "Введение в системную инженерию" (14 января 2013)
 
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017
 
В.Мизгулин -- программа магистратуры по системной инженерии
В.Мизгулин -- программа магистратуры по системной инженерииВ.Мизгулин -- программа магистратуры по системной инженерии
В.Мизгулин -- программа магистратуры по системной инженерии
 
А.Левенчук -- плохая модульность
А.Левенчук -- плохая модульностьА.Левенчук -- плохая модульность
А.Левенчук -- плохая модульность
 
А.Левенчук -- Essence в варианте для системной инженерии
А.Левенчук -- Essence в варианте для системной инженерииА.Левенчук -- Essence в варианте для системной инженерии
А.Левенчук -- Essence в варианте для системной инженерии
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектирования
 
А.Левенчук -- смычка кортекса и экзокортекса
А.Левенчук -- смычка кортекса и экзокортексаА.Левенчук -- смычка кортекса и экзокортекса
А.Левенчук -- смычка кортекса и экзокортекса
 
Практики жизненного цикла систем машинного обучения
Практики жизненного цикла систем машинного обученияПрактики жизненного цикла систем машинного обучения
Практики жизненного цикла систем машинного обучения
 
Юрий Бабин -- многокритериальная оптимизация в инженерных проектах
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахЮрий Бабин -- многокритериальная оптимизация в инженерных проектах
Юрий Бабин -- многокритериальная оптимизация в инженерных проектах
 
Семантические информационные модели и ISO 15926
Семантические информационные модели и ISO 15926Семантические информационные модели и ISO 15926
Семантические информационные модели и ISO 15926
 
Мастер-класс: Системное мышление
Мастер-класс: Системное мышлениеМастер-класс: Системное мышление
Мастер-класс: Системное мышление
 
А.Левенчук -- развитие личности
А.Левенчук -- развитие личностиА.Левенчук -- развитие личности
А.Левенчук -- развитие личности
 
А.Левенчук -- как выжить в эпоху перемен перемен
А.Левенчук -- как выжить в эпоху перемен переменА.Левенчук -- как выжить в эпоху перемен перемен
А.Левенчук -- как выжить в эпоху перемен перемен
 
Системноинженерное мышление в непрерывном образовании
Системноинженерное мышление в непрерывном образованииСистемноинженерное мышление в непрерывном образовании
Системноинженерное мышление в непрерывном образовании
 
А.Ефремов -- встречи Русского отделения INCOSE
А.Ефремов -- встречи Русского отделения INCOSEА.Ефремов -- встречи Русского отделения INCOSE
А.Ефремов -- встречи Русского отделения INCOSE
 

Viewers also liked

М.Акоев -- системная динамика и мышление
М.Акоев -- системная динамика и мышлениеМ.Акоев -- системная динамика и мышление
М.Акоев -- системная динамика и мышление
Anatoly Levenchuk
 
А.Левенчук -- преподавание системного мышления
А.Левенчук -- преподавание системного мышленияА.Левенчук -- преподавание системного мышления
А.Левенчук -- преподавание системного мышления
Anatoly Levenchuk
 
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
Alexander Shamanin
 
Безлюдные организации и их проблемы
Безлюдные организации и их проблемыБезлюдные организации и их проблемы
Безлюдные организации и их проблемы
Anatoly Levenchuk
 
М.Гайворонский -- опыт разработки САУ двигателя
М.Гайворонский -- опыт разработки САУ двигателяМ.Гайворонский -- опыт разработки САУ двигателя
М.Гайворонский -- опыт разработки САУ двигателя
Anatoly Levenchuk
 
Ali Mousavi -- Event modeling
Ali Mousavi -- Event modeling Ali Mousavi -- Event modeling
Ali Mousavi -- Event modeling
Anatoly Levenchuk
 
Richard Crisp -- predictable development for the IoT
Richard Crisp -- predictable development for the IoTRichard Crisp -- predictable development for the IoT
Richard Crisp -- predictable development for the IoT
Anatoly Levenchuk
 
А.Левенчук -- автоматизация образования
А.Левенчук -- автоматизация образованияА.Левенчук -- автоматизация образования
А.Левенчук -- автоматизация образования
Anatoly Levenchuk
 
О.Савин -- оптимизация архитектуры
О.Савин -- оптимизация архитектурыО.Савин -- оптимизация архитектуры
О.Савин -- оптимизация архитектуры
Anatoly Levenchuk
 
А.Левенчук -- корпоративный искусственный интеллект
А.Левенчук -- корпоративный искусственный интеллектА.Левенчук -- корпоративный искусственный интеллект
А.Левенчук -- корпоративный искусственный интеллект
Anatoly Levenchuk
 
А.Левенчук -- инженерия психики и киберпсихики
А.Левенчук -- инженерия психики и киберпсихикиА.Левенчук -- инженерия психики и киберпсихики
А.Левенчук -- инженерия психики и киберпсихики
Anatoly Levenchuk
 
В.Батоврин -- заметки о системной инженерии в СССР.
В.Батоврин -- заметки о системной инженерии в СССР.В.Батоврин -- заметки о системной инженерии в СССР.
В.Батоврин -- заметки о системной инженерии в СССР.
Anatoly Levenchuk
 
А.Арендарчук -- концептуальные схемы ресурсоснабжения
А.Арендарчук -- концептуальные схемы ресурсоснабженияА.Арендарчук -- концептуальные схемы ресурсоснабжения
А.Арендарчук -- концептуальные схемы ресурсоснабжения
Anatoly Levenchuk
 
A.Levenchuk -- Machine learning engineering
A.Levenchuk -- Machine learning engineeringA.Levenchuk -- Machine learning engineering
A.Levenchuk -- Machine learning engineering
Anatoly Levenchuk
 
A.Levenchuk -- visuomotor learning in cyber-phisical systems
A.Levenchuk -- visuomotor learning in cyber-phisical systemsA.Levenchuk -- visuomotor learning in cyber-phisical systems
A.Levenchuk -- visuomotor learning in cyber-phisical systems
Anatoly Levenchuk
 
А.Левенчук -- privacy и нейронет
А.Левенчук -- privacy и нейронетА.Левенчук -- privacy и нейронет
А.Левенчук -- privacy и нейронет
Anatoly Levenchuk
 
Сергей Кравченко -- порождающее проектирование
Сергей Кравченко -- порождающее проектированиеСергей Кравченко -- порождающее проектирование
Сергей Кравченко -- порождающее проектирование
Anatoly Levenchuk
 
Системная инженерия в России
Системная инженерия в РоссииСистемная инженерия в России
Системная инженерия в России
Anatoly Levenchuk
 
Подход DEMO к описанию архитектуры организаций
Подход DEMO к описанию архитектуры организацийПодход DEMO к описанию архитектуры организаций
Подход DEMO к описанию архитектуры организацийAnatoly Levenchuk
 

Viewers also liked (19)

М.Акоев -- системная динамика и мышление
М.Акоев -- системная динамика и мышлениеМ.Акоев -- системная динамика и мышление
М.Акоев -- системная динамика и мышление
 
А.Левенчук -- преподавание системного мышления
А.Левенчук -- преподавание системного мышленияА.Левенчук -- преподавание системного мышления
А.Левенчук -- преподавание системного мышления
 
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...
 
Безлюдные организации и их проблемы
Безлюдные организации и их проблемыБезлюдные организации и их проблемы
Безлюдные организации и их проблемы
 
М.Гайворонский -- опыт разработки САУ двигателя
М.Гайворонский -- опыт разработки САУ двигателяМ.Гайворонский -- опыт разработки САУ двигателя
М.Гайворонский -- опыт разработки САУ двигателя
 
Ali Mousavi -- Event modeling
Ali Mousavi -- Event modeling Ali Mousavi -- Event modeling
Ali Mousavi -- Event modeling
 
Richard Crisp -- predictable development for the IoT
Richard Crisp -- predictable development for the IoTRichard Crisp -- predictable development for the IoT
Richard Crisp -- predictable development for the IoT
 
А.Левенчук -- автоматизация образования
А.Левенчук -- автоматизация образованияА.Левенчук -- автоматизация образования
А.Левенчук -- автоматизация образования
 
О.Савин -- оптимизация архитектуры
О.Савин -- оптимизация архитектурыО.Савин -- оптимизация архитектуры
О.Савин -- оптимизация архитектуры
 
А.Левенчук -- корпоративный искусственный интеллект
А.Левенчук -- корпоративный искусственный интеллектА.Левенчук -- корпоративный искусственный интеллект
А.Левенчук -- корпоративный искусственный интеллект
 
А.Левенчук -- инженерия психики и киберпсихики
А.Левенчук -- инженерия психики и киберпсихикиА.Левенчук -- инженерия психики и киберпсихики
А.Левенчук -- инженерия психики и киберпсихики
 
В.Батоврин -- заметки о системной инженерии в СССР.
В.Батоврин -- заметки о системной инженерии в СССР.В.Батоврин -- заметки о системной инженерии в СССР.
В.Батоврин -- заметки о системной инженерии в СССР.
 
А.Арендарчук -- концептуальные схемы ресурсоснабжения
А.Арендарчук -- концептуальные схемы ресурсоснабженияА.Арендарчук -- концептуальные схемы ресурсоснабжения
А.Арендарчук -- концептуальные схемы ресурсоснабжения
 
A.Levenchuk -- Machine learning engineering
A.Levenchuk -- Machine learning engineeringA.Levenchuk -- Machine learning engineering
A.Levenchuk -- Machine learning engineering
 
A.Levenchuk -- visuomotor learning in cyber-phisical systems
A.Levenchuk -- visuomotor learning in cyber-phisical systemsA.Levenchuk -- visuomotor learning in cyber-phisical systems
A.Levenchuk -- visuomotor learning in cyber-phisical systems
 
А.Левенчук -- privacy и нейронет
А.Левенчук -- privacy и нейронетА.Левенчук -- privacy и нейронет
А.Левенчук -- privacy и нейронет
 
Сергей Кравченко -- порождающее проектирование
Сергей Кравченко -- порождающее проектированиеСергей Кравченко -- порождающее проектирование
Сергей Кравченко -- порождающее проектирование
 
Системная инженерия в России
Системная инженерия в РоссииСистемная инженерия в России
Системная инженерия в России
 
Подход DEMO к описанию архитектуры организаций
Подход DEMO к описанию архитектуры организацийПодход DEMO к описанию архитектуры организаций
Подход DEMO к описанию архитектуры организаций
 

Similar to И.Беспальчук -- оценка архитектуры по ATAM

Разработка требований и Проектирование интерфейсов
Разработка требований и Проектирование интерфейсовРазработка требований и Проектирование интерфейсов
Разработка требований и Проектирование интерфейсовDenis Beskov
 
Процесс проектирования ИТ-решений
Процесс проектирования ИТ-решенийПроцесс проектирования ИТ-решений
Процесс проектирования ИТ-решений
Максим Смирнов
 
Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Dima Dzuba
 
Методология ведения проектов
Методология ведения проектовМетодология ведения проектов
Методология ведения проектов
AlexanderAvva
 
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11ANDREY ZAKHODYAYCHENKO
 
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Andrey Zakhodyaychenko
 
А.Сачик. О подходах стандарта по разработке требований ISO 29148
А.Сачик. О подходах стандарта по разработке требований ISO 29148А.Сачик. О подходах стандарта по разработке требований ISO 29148
А.Сачик. О подходах стандарта по разработке требований ISO 29148
Anatoly Levenchuk
 
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUAREТехники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
SQALab
 
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
Denis Diakonov
 
Оценка эффективности работы аналитика
Оценка эффективности работы аналитикаОценка эффективности работы аналитика
Оценка эффективности работы аналитика
SQALab
 
Analyst Days 2014
Analyst Days 2014Analyst Days 2014
Analyst Days 2014
Natalia Zhelnova
 
Разработка веб-сервисов осень 2013 лекция 3
Разработка веб-сервисов осень 2013 лекция 3Разработка веб-сервисов осень 2013 лекция 3
Разработка веб-сервисов осень 2013 лекция 3Technopark
 
Как выжить глобальной корпорации?
Как выжить глобальной корпорации?Как выжить глобальной корпорации?
Как выжить глобальной корпорации?
CEE-SEC(R)
 
Проект внедрения КИС
Проект внедрения КИСПроект внедрения КИС
Проект внедрения КИС
Sergey Timofeev
 
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
DataArt
 
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
SQALab
 
Развитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТРазвитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТ
CUSTIS
 
Развитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТРазвитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТ
CodeFest
 
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
Yury Vetrov
 

Similar to И.Беспальчук -- оценка архитектуры по ATAM (20)

Разработка требований и Проектирование интерфейсов
Разработка требований и Проектирование интерфейсовРазработка требований и Проектирование интерфейсов
Разработка требований и Проектирование интерфейсов
 
Процесс проектирования ИТ-решений
Процесс проектирования ИТ-решенийПроцесс проектирования ИТ-решений
Процесс проектирования ИТ-решений
 
Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4
 
Методология ведения проектов
Методология ведения проектовМетодология ведения проектов
Методология ведения проектов
 
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
 
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
 
А.Сачик. О подходах стандарта по разработке требований ISO 29148
А.Сачик. О подходах стандарта по разработке требований ISO 29148А.Сачик. О подходах стандарта по разработке требований ISO 29148
А.Сачик. О подходах стандарта по разработке требований ISO 29148
 
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUAREТехники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
 
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
Опыт внедрения "Lean" и "Kaizen" на предприятиях группы Sibelco Rus. Доклад н...
 
Оценка эффективности работы аналитика
Оценка эффективности работы аналитикаОценка эффективности работы аналитика
Оценка эффективности работы аналитика
 
Analyst Days 2014
Analyst Days 2014Analyst Days 2014
Analyst Days 2014
 
Разработка веб-сервисов осень 2013 лекция 3
Разработка веб-сервисов осень 2013 лекция 3Разработка веб-сервисов осень 2013 лекция 3
Разработка веб-сервисов осень 2013 лекция 3
 
Как выжить глобальной корпорации?
Как выжить глобальной корпорации?Как выжить глобальной корпорации?
Как выжить глобальной корпорации?
 
Проект внедрения КИС
Проект внедрения КИСПроект внедрения КИС
Проект внедрения КИС
 
Scrum framework
Scrum frameworkScrum framework
Scrum framework
 
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...
 
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
Проектируем среду проектирования. Процесс взаимодействия Бизнеса, ИТ и постав...
 
Развитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТРазвитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТ
 
Развитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТРазвитие управления проектами и критериев качества в ИТ
Развитие управления проектами и критериев качества в ИТ
 
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
 

More from Anatoly Levenchuk

Contemporary Systems Engineering (oct 2022)
Contemporary Systems Engineering (oct 2022)Contemporary Systems Engineering (oct 2022)
Contemporary Systems Engineering (oct 2022)
Anatoly Levenchuk
 
Open-endedness curriculum at EEM Institute
Open-endedness curriculum at EEM InstituteOpen-endedness curriculum at EEM Institute
Open-endedness curriculum at EEM Institute
Anatoly Levenchuk
 
Праксиология и системное мышление
Праксиология и системное мышлениеПраксиология и системное мышление
Праксиология и системное мышление
Anatoly Levenchuk
 
А.Левенчук -- стейкхолдерское мастерство
А.Левенчук -- стейкхолдерское мастерствоА.Левенчук -- стейкхолдерское мастерство
А.Левенчук -- стейкхолдерское мастерство
Anatoly Levenchuk
 
А.Левенчук -- Практики системной инженерии
А.Левенчук -- Практики системной инженерииА.Левенчук -- Практики системной инженерии
А.Левенчук -- Практики системной инженерии
Anatoly Levenchuk
 
А.Левенчук -- визуальное мышление
А.Левенчук -- визуальное мышлениеА.Левенчук -- визуальное мышление
А.Левенчук -- визуальное мышление
Anatoly Levenchuk
 
А.Левенчук -- системное развитие личности
А.Левенчук -- системное развитие личностиА.Левенчук -- системное развитие личности
А.Левенчук -- системное развитие личности
Anatoly Levenchuk
 
А.Левенчук -- Будущее девелопмента
А.Левенчук -- Будущее девелопментаА.Левенчук -- Будущее девелопмента
А.Левенчук -- Будущее девелопмента
Anatoly Levenchuk
 
А.Левенчук -- Системное мышление в инженерии предприятий
А.Левенчук -- Системное мышление в инженерии предприятийА.Левенчук -- Системное мышление в инженерии предприятий
А.Левенчук -- Системное мышление в инженерии предприятий
Anatoly Levenchuk
 
А.Левенчук -- аппаратное ускорение аналитики в BigData
А.Левенчук -- аппаратное ускорение аналитики в BigDataА.Левенчук -- аппаратное ускорение аналитики в BigData
А.Левенчук -- аппаратное ускорение аналитики в BigData
Anatoly Levenchuk
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектирования
Anatoly Levenchuk
 
Future of Engineering
Future of EngineeringFuture of Engineering
Future of Engineering
Anatoly Levenchuk
 
А.Левенчук -- безлюдные (дез)организации
А.Левенчук -- безлюдные (дез)организацииА.Левенчук -- безлюдные (дез)организации
А.Левенчук -- безлюдные (дез)организации
Anatoly Levenchuk
 
А.Левенчук -- предпринимательство: кейс NVIDIA
А.Левенчук -- предпринимательство: кейс NVIDIAА.Левенчук -- предпринимательство: кейс NVIDIA
А.Левенчук -- предпринимательство: кейс NVIDIA
Anatoly Levenchuk
 
А.Левенчук -- системный фитнес
А.Левенчук -- системный фитнесА.Левенчук -- системный фитнес
А.Левенчук -- системный фитнес
Anatoly Levenchuk
 
А.Левенчук -- интеллект-стек 2016
А.Левенчук -- интеллект-стек 2016А.Левенчук -- интеллект-стек 2016
А.Левенчук -- интеллект-стек 2016
Anatoly Levenchuk
 
А.Левенчук -- тренажёр клуба одиноких мозгов
А.Левенчук -- тренажёр клуба одиноких мозговА.Левенчук -- тренажёр клуба одиноких мозгов
А.Левенчук -- тренажёр клуба одиноких мозгов
Anatoly Levenchuk
 

More from Anatoly Levenchuk (17)

Contemporary Systems Engineering (oct 2022)
Contemporary Systems Engineering (oct 2022)Contemporary Systems Engineering (oct 2022)
Contemporary Systems Engineering (oct 2022)
 
Open-endedness curriculum at EEM Institute
Open-endedness curriculum at EEM InstituteOpen-endedness curriculum at EEM Institute
Open-endedness curriculum at EEM Institute
 
Праксиология и системное мышление
Праксиология и системное мышлениеПраксиология и системное мышление
Праксиология и системное мышление
 
А.Левенчук -- стейкхолдерское мастерство
А.Левенчук -- стейкхолдерское мастерствоА.Левенчук -- стейкхолдерское мастерство
А.Левенчук -- стейкхолдерское мастерство
 
А.Левенчук -- Практики системной инженерии
А.Левенчук -- Практики системной инженерииА.Левенчук -- Практики системной инженерии
А.Левенчук -- Практики системной инженерии
 
А.Левенчук -- визуальное мышление
А.Левенчук -- визуальное мышлениеА.Левенчук -- визуальное мышление
А.Левенчук -- визуальное мышление
 
А.Левенчук -- системное развитие личности
А.Левенчук -- системное развитие личностиА.Левенчук -- системное развитие личности
А.Левенчук -- системное развитие личности
 
А.Левенчук -- Будущее девелопмента
А.Левенчук -- Будущее девелопментаА.Левенчук -- Будущее девелопмента
А.Левенчук -- Будущее девелопмента
 
А.Левенчук -- Системное мышление в инженерии предприятий
А.Левенчук -- Системное мышление в инженерии предприятийА.Левенчук -- Системное мышление в инженерии предприятий
А.Левенчук -- Системное мышление в инженерии предприятий
 
А.Левенчук -- аппаратное ускорение аналитики в BigData
А.Левенчук -- аппаратное ускорение аналитики в BigDataА.Левенчук -- аппаратное ускорение аналитики в BigData
А.Левенчук -- аппаратное ускорение аналитики в BigData
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектирования
 
Future of Engineering
Future of EngineeringFuture of Engineering
Future of Engineering
 
А.Левенчук -- безлюдные (дез)организации
А.Левенчук -- безлюдные (дез)организацииА.Левенчук -- безлюдные (дез)организации
А.Левенчук -- безлюдные (дез)организации
 
А.Левенчук -- предпринимательство: кейс NVIDIA
А.Левенчук -- предпринимательство: кейс NVIDIAА.Левенчук -- предпринимательство: кейс NVIDIA
А.Левенчук -- предпринимательство: кейс NVIDIA
 
А.Левенчук -- системный фитнес
А.Левенчук -- системный фитнесА.Левенчук -- системный фитнес
А.Левенчук -- системный фитнес
 
А.Левенчук -- интеллект-стек 2016
А.Левенчук -- интеллект-стек 2016А.Левенчук -- интеллект-стек 2016
А.Левенчук -- интеллект-стек 2016
 
А.Левенчук -- тренажёр клуба одиноких мозгов
А.Левенчук -- тренажёр клуба одиноких мозговА.Левенчук -- тренажёр клуба одиноких мозгов
А.Левенчук -- тренажёр клуба одиноких мозгов
 

И.Беспальчук -- оценка архитектуры по ATAM

  • 1. Опыт применения метода ATAM для оценки архитектуры Игорь Беспальчук Руководитель проектов дирекции архитектуры 09.11.2016
  • 2. ГРУППА КОМПАНИЙ CUSTIS  20 лет на российском ИТ-рынке  Масштабные проекты для отраслевых лидеров и организаций с высокой динамикой бизнес-процессов: Банка России, Газпромбанка, ГК «Спортмастер» (розничных сетей «Спортмастер», O'STIN, FUNDAY)  Работа на стратегическое развитие клиентов, решение критически важных бизнес-задач средствами ИТ, поддержка передовых технологических проектов 2 | 17
  • 3. О чем доклад  В индустрии существуют методы оценки архитектуры софта  Мы пробовали применять самый известный из них (ATAM — Architecture Tradeoff Analysis Method)  Расскажем о том, что получилось  Если совсем коротко о результатах:  Польза есть  Есть и сложности
  • 6. Зачем нужна оценка архитектуры?  Прямое назначение:  Позволяет выявить/смягчить риски до старта массированной разработки  Вынуждает проверять соответствие архитектуры требованиям и трассировку к бизнес-целям  Вынуждает обосновывать принятые решения, выявлять недостатки и совершенствовать архитектуру
  • 7. Зачем нужна оценка архитектуры?  Сопутствующие выгоды:  Проявляет архитектуру, форсирует ее коммуникацию и понимание  Проявляет/улучшает качество и полноту входных материалов (архитектурно-значимых требований/драйверов), выявляет конфликты/дыры в исходных требованиях  Проявляет недостатки многих смежных процессов
  • 9. Процедура «Защита архитектуры»  Разрабатывалась в 2013 году  Проводилась несколько раз  Все придумывали сами (как мы это любим)  Перед этим были на семинаре Питера Хрущки, где был краткий обзор ATAM и где подхватили саму идею
  • 10. Что получилось в результате самодеятельности? Хорошее  Архитектура проявлялась  Архитектура обсуждалась  Архитектура улучшалась  Риски всплывали  Сомнительные решения  Потеря трассировки к бизнес-целям  Дырки в требованиях Плохое  Было очень долго  Было неуправляемо  Риторика «защиты» демотивировала  Ценность результатов для управленца не всегда ясна  Плохо тиражируемо
  • 11. Когда ничего не получается – прочитай инструкцию учебник  Книжку купили в 2013 году  Прочитали — в 2015…
  • 12. “ ” Еще в 1970-х стало понятно, что при организации сессий оценки дизайна нельзя просто посадить людей в одну комнату и попросить оценить дизайн. Вместо этого нужно давать задания, для выполнения которых дизайн должен быть хорошим Нестрогая цитата из книжки * Кстати, ту же логику организации коллективной работы мы видим на стратегических сессиях c методологами школы СМД
  • 13. Про ATAM Architecture Trade-off Analysis Method Теория
  • 14. Отличия ATAM от «самоделки CUSTIS»  Строгая процедура, роли и порядок действий  Четко обозначенные предметы рассмотрения (атрибуты и сценарии качества)  Жесткие форматы бизнес-значимых результатов, которые нужно получить (риски, компромиссы, etc)  Риторика «совместного исследования»
  • 15. Коротко про историю ATAM  Разработан в Software Engineering Institute (CMU SEI)  Практическое применение — с 1998 года, оригинальная статья-отчет — 2000 года  Не первый метод, но самый известный и широко используемый
  • 16. Этапы ATAM Этап Операции Описание Участники Длительность (вариант) 0 Подготовка Достижение договоренностей и планирование. Определение проекта, области анализа, состава участников Руководство группы оценки, ответственные за проект По ситуации 1 Оценка Выявление требований к качеству, анализ архитектурных подходов, создание дерева полезности Группа оценки, ответственные за проект 1 день, перерыв 2-3 недели 2 Оценка Верификация дерева полезности стейкхолдерами, анализ архитектурных подходов с их точки зрения Группа оценки, ответственные за проект, стейкхолдеры 2 дня 3 Доработка Представление сводного отчета Группа оценки, заказчик оценки 1 неделя
  • 17. Основная часть ATAM (этапы 1 и 2) по шагам  Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры  Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений  Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений  Составление отчетов 9. Представление результатов 17
  • 21. Основная часть ATAM (этапы 1 и 2) по шагам  Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры  Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений  Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений  Составление отчетов 9. Представление результатов 21
  • 23. Основная часть ATAM (этапы 1 и 2) по шагам  Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры  Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений  Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений  Составление отчетов 9. Представление результатов 23
  • 24. Опыт применения ATAM в SEI  SEI провел ~500 (!) сессий оценки в самых разных коммерческих, государственных, военных проектах  Есть интересная статистика по результатам оценок  Статья 2006 года «Risk Themes Discovered Through Architecture Evaluations»
  • 25.
  • 26.
  • 27. Какие другие методы оценки есть?  ATAM — риски, коллаборация со стейкхолдерами  LAAAM — сравнение двух вариантов дизайна через систему весов, много offline  См. доклад от NVision нв SECR 2013  CBAM — рационализация выбора между вариантами через финансовые модели  ARID — легкая оценка небольших фрагментов  QAW — разработка сценариев качества
  • 28. ATAM в CUSTIS От теории — к практике
  • 29. Цели  Попробовать более структурированный метод оценки  Если получится хорошо, то:  Использовать в проектах  Растить имидж  Предлагать клиентам
  • 30. Состав участников  Ведущий, фасилитатор  Заказчик оценки, менеджер дивизиона  Архитектор  Группа оценки, смежные архитекторы  Приглашенные «и. о. стейкхолдеров»
  • 31. Хронология  Июль 2015 — первые предложения применить ATAM  Август 2015 — решение об апробации, создана рабочая группа  Октябрь 2015 — выбор проекта «Витрина учета»  22.12, 24.12, 30.12, 21.01 — 4 дня по 4 часа и 08.02 – 1.5 часа Сложность №1. Для любого коллаборативного метода тяжело согласовать время со всеми участниками
  • 32. Отличия от «эталонного» ATAM  Без реальных стейкхолдеров  Не так жестко были ограничены расписанием — продлевали там, где не успевали (начальный тайминг составлял 2 дня по 4 часа)
  • 33. День 0 (17.11.2016) Вводная встреча  2 часа, широкий круг участников (9 человек)  Рассказ про метод  Рассказ про проект  Ответы на вопросы
  • 34. День 1 (22.12.2016) Технический анализ  4 часа, узкий состав участников (5 человек) — заказчик, архитектор, группа оценки  Еще раз вспомнили про проект  Заслушали доклад про архитектуру (задавали много вопросов, заглублялись, затянулось)  Выписали архитектурные драйверы (самые значимые требования, цели, ограничения)  Выделили архитектурные решения  Начали генерировать дерево качества и сценарии (и хорошо пошло)
  • 35. День 2 (24.12.2016) Технический анализ (продолжение)  4 часа, узкий состав участников (5 человек) — заказчик, архитектор, группа оценки  Продолжили генерацию сценариев  Провели приоритизацию (с применением техники голосования получилось быстро, организованно и достаточно убедительно)  Провели анализ одного (!) сценария
  • 36.
  • 37. Сценарий #: 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а увеличивает хранимый объем данных, с другой стороны асинхронный характер взаимодействия
  • 38. День 3 (30.12.2016) Технический анализ (окончание)  4 часа, узкий состав участников (5 человек) — заказчик, архитектор, группа оценки  Пообсуждали неясные места в методе и его применимость (~50 мин)  Посмотрели «домашнее задание» архитектора — анализ второго сценария (это оказалось очень скучно!)  Провели анализ еще двух сценариев  В одном — уткнулись в отсутствие модели производительности  В другом — уткнулись в непроработанность требований по перевыгрузке
  • 39. День 4 (21.01.2016) Опрос «стейкхолдеров»  4 часа, широкий состав участников (8 человек) — включая «и. о. стейкхолдеров»  Напомнили про метод  Напомнили про проект  Показали по диагонали предыдущие результаты (непонятно, было ли полезно)  Провели мозговой штурм среди стейкхолдеров, сгенерировали еще десяток сценариев (акцент оказался на совсем других атрибутах качества!)  Приоритизировали новые сценарии (также путем голосования)
  • 40. День 5 (08.02.2016) Анализ последнего сценария  1.5 часа, узкий круг участников  Провели анализ еще одного сценария, самого приоритетного из второй порции сценариев
  • 42. Виды результатов (очевидные)  Презентация проекта  Описание архитектуры  Аудио-запись (лучше сразу делать видео) с рассказом о проекте, системе и архитектуре  …продолжение на следующем слайде…
  • 43. Виды результатов (предписанные ATAM)  Каталог значимых архитектурных решений (вырос вдвое)  Сценарии качества (дерево качества) с приоритетами  Перечень рискованных решений (создающих угрозу для значимых атрибутов качества)  Перечень компромиссных решений (улучшающих одни значимые атрибуты качества за счет других)  Перечень сильных решений, удерживающих качество  Перечень проблемных вопросов и рисков за границей методики оценки  …продолжение на следующем слайде…
  • 44. Виды результатов (дополнительные)  Выявлены и зафиксированы  Пропущенные стейкхолдеры и требования  Скрытые решения в архитектуре  Конфликт интересов с клиентом, значимый для архитектуры  Темные места и отсутствующие модели в архитектуре  Исправление неверных ожиданий  Дополнительные вопросы для анализа и обсуждения с СМ  Некоторые архитектурные решения изменены  Некоторые архитектурные модели разработаны в процессе  (+ неартифицируемые результаты лучшего понимания и коммуникации)
  • 45. Пример риска с обоснованием  Решение № 30: Изменения «неучетных» аналитик отражаются потребителям в последующих порциях сторнированием исходящих операций со старым значением и созданием новых с новым значением  В сценарии с быстрым (10 ч*ч) добавлением новой для ZZZ аналитики это решение рискованно:  Требуется написание логики → мы можем не уложиться в целевые трудозатраты  Добавление же «учетной» аналитики решается настройкой справочников инженерами
  • 46. Примеры измененных решений Было Стало Причина Хранение входящих операций в операционном слое атрибутным хранением Для хранения используется оригинальный формат XML, в котором ZZZ получает сообщения от модулей-источников Поиск по атрибутному хранению, инстанцирование сущностей и пр. более медленные. Возможности работы с XML современных СУБД впечатляют, в т. ч. есть индексирование Все входящие события идут в единый операционный слой (и события учетных систем, и события неучетных систем) За частью данных ZZZ все же сам обращается к модулям-источникам Сокращение трудозатрат ZZZ хостится на тех же серверах, что и YYY Заменили на XXX Нагрузка на ZZZ приличная, причем большая часть потока данных — от XXX. Сервера XXX значительно более мощные
  • 47. Пример компромисса  Решение № 28: Сообщения через BBB передаются в «человекочитаемом» формате (XML или JSON), но сжимаются  «Человекочитаемый» формат предпочтителен для удобства поддержки (сокращение времени поддержки)  Но требует в разы больше места для передачи/хранения, чем бинарный или сжатый формат  Сжатие  Решает проблему размера сообщения и производительности BBBа  Решает проблему размера БД ZZZ (сценарий 12)  Но либо ломает удобство поддержки (сценарии 23, 24): время разбирательств увеличивается  Либо требует не заложенных в проект затрат на доработки BBB.API и BBB.Монитора
  • 48. Примеры «темных мест» в архитектуре и системных требованиях  Отсутствует какая-либо модель производительности, позволяющая делать оценки — сделана после мероприятия  Никак не прорабатывались сценарии начальной инициализации и перезагрузки данных — при высоких рисках можно не влезть в разумное время и объемы данных — требования были уточнены позже
  • 49. Пример ошибочных ожиданий  Начальная оценка в одном из сценариев модифицируемости — 10 ч*ч  Оценка после анализа — 40 ч*ч
  • 50. Затраты  План: 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
  • 51. Это много или мало?  Уместно вспомнить исследование Барри Боэма “The ROI of System Engineering” Размер проекта (KSLOC) Оптимальные затраты на СИ, % Снижение затрат за счет СИ, % 10 5 18 100 20 38 1000 26 63 10000 33 92 *СИ — практики системной инженерии
  • 53. Заказчик оценки  Для маленьких проектов (~1000ч*ч) — дорого, если удастся сохранить объемы затрат (~160ч*ч), это вполне посильно для проектов в 5000ч*ч  Более структурно и системно организованно, чем предыдущие попытки оценки архитектуры, ощущение более предсказуемого результата на выходе  Есть мысль, что все-таки основная ценность наших проектов в правильном проектировании СТА/ИА, и хорошо бы такие или похожие практики научиться делать для СТА/ИА
  • 54. Архитектор  В результате обсуждения некоторые решения сразу «поплыли», а некоторые были изменены уже после проведения оценки  После оценки:  Были проработаны структуры данных всех компонентов  Атрибутное хранение заменено на XML  Проработано сопоставление входных операций 1:M  Некоторые существующие диаграммы перерисованы проще и понятнее, в целом картина стала более связной  Неожиданные результаты:  Тема производительности БД «выплыла» как потенциально рисковая. До оценки требование к производительности декларировалось, но не прорабатывалось  Обнаружили, что для расчетной нагрузки ZZZ начальную инициализацию провести за оговоренный срок невозможно  Необходимость процедур переинициализации и сверки остатков
  • 55. PM, эксперт группы оценки  Медленно двигались по процессу из-за периодических «сваливаний» в обсуждения и проектирований решений. Нужно более жесткое модерирование  Были проблемы с подготовленными шаблонами — местами в них была заложена излишняя жесткость, некоторые сценарии работы с артефактами были не предусмотрены  В процессе оценки были подняты важные вопросы, о которых ранее не думали; выявлены недоработки документации и проектирования; спроектированы новые и выявлены скрытые архитектурные решения  Все это позволило лучше понимать, почему принято то или иное решение; осознать существующие риски; повысить качество документации. Работа проделана с пользой  После оценки я:  Иначе «порезал» скоуп проекта в поисках оптимизации трудозатрат  Иначе смотрю на проект в целом и его архитектуру в частности
  • 56. И. о. стейкхолдера №1  В целом создалось ощущение правильной идеи мероприятия. Подумал, что если бы некое подобное действо было проведено на старте проекта X, это позволило бы вскрыть ключевые проблемы предполагавшейся архитектуры, в результате проект мог бы пойти в совершенно другой плоскости либо мотивированно мог быть свернут в самом начале  Но как и в любом деле тут главное — «без фанатизма», чтобы вложенные усилия (а учитывая кол-во вовлеченного народу, трудозатраты распухают очень быстро) оправдались результатом. Для небольших проектов возможно стоит сознательно отказаться от заглубления в детали и пробегаться большим составом лишь «по верхам», при этом не стремясь прийти к какому-то согласованному результату, рассматривая мероприятие лишь как способ получения сырья для детальной проработки в более тесном составе
  • 57. И. о. стейкхолдера №2  Выступала в роли представителя службы сопровождения системы  Понравилось, что на каком-то этапе в голосе людей, проектировавших систему, слышалось удивление и удовлетворение. Значит, удалось поднять какие-то неожиданные вопросы, показавшиеся им полезными  Интересна идея с голосованием за важность разных кейсов. Если проводить такое голосование открыто среди заказчиков, то процесс эксплуатации, возможно, будет более осознанным
  • 58. Фасилитатор  Тезис про «нужно выдавать задания, а не рассказывать и не задавать общие вопросы» проявился во всей красе  Динамика группы и включенность участников была очень неоднородна по процессу — этим нужно уметь играть  Нужно смелее реконструировать метод и использовать отдельные его части для сборки под конкретный проект (вспоминаем ситуационную инженерию методов)  Например, в нашей ситуации без внешних стейкхолеров можно было быстрее переходить к анализу, сильно сократив обзор проекта и архитектуры  Другой пример: режим работы «один сделал — остальные смотрят и проверяют» на порядок менее эффективен, чем совместная работа Сложность №3. Метод надо пересобирать под ситуацию, не все части всегда одинаково полезны
  • 60. Что дальше? Пока только идеи  Пробовать еще, на других проектах  Жестче управлять таймингом, смотреть, как это повлияет на результаты  Выделять отдельные практики, в частности — генерации сценариев (QAW)  И использовать их на этапе проектирования архитектуры  Пробовать облегченные варианты (Lightweight ATAM, LAAAM, etc)  Попробовать что-то похожее для оценки СТА/ИА  Выявление требований и сценариев  Подходы к организации процесса  Трассировка решений к бизнес-ценности  Смелее адаптировать процедуру под ситуацию, после того, как стали понятны механизмы
  • 62. Выводы  Изучать методы отрасли крайне полезно (хотя бы после того, как сам наступил на грабли)  В том числе вдаваться в детали, читать книги, учиться, потому что поверхностного понимания может не хватить для результата  Оценка архитектуры — необходимый хотя бы в малом объеме элемент процесса проектирования (если вообще применяется архитектурный подход)  ATAM во многих аспектах лучше «самоделки» CUSTIS (с другими технологиями и методологиями обычно происходит то же самое)  Хотя это, конечно, не панацея и не серебряная пуля, никакого волшебства. И не покрывает всех аспектов  В чистом виде ATAM (как любой метод) малоприменим (тяжеловат)  Но если подойти с пониманием, разобрать и пересобрать под ситуацию конкретного проекта, то принесет большой и приемлемый по затратам (окупаемый вдолгую) профит
  • 63. Где почитать подробнее про ATAM и другие методы оценки архитектуры?  Кратко на русском — в книге «Архитектура ПО на практике» Л.Басса и др.
  • 64. Как организовать у себя?  Это сложно (особенно в первый раз), но посильно  Есть книги, презентации, статьи, тренинги  Есть опыт других компаний
  • 65. Спасибо за внимание! Игорь Беспальчук bespalchuk@custis.ru www.linkedin.com/in/iamhere2 Видео-канал CUSTIS https://vimeo.com/custis