Презентация доклада с конференции CEE SECR 2013 (http://2013.secr.ru/) о методе принятия решений по выбору архитектуры ПО.

1. Девятая независимая
научно-практическая конференция
«Разработка ПО 2013»
23 - 25 октября, Москва
Фаза проектирования
без конфликтов
Дзюба Дмитрий
«Энвижн – Программные решения»
NVision Group

2. «Энвижн – Программные решения»
R&D – центр «СПБ»
R&D – центр «Минск»
Санкт - Петербург
HQ Дивизиона
Москва
R&D - центр «Москва»
Краснодар
R&D - центр «Прага»
R&D – центр «Краснодар»
Центры компетенции:
•
Россия: Нижний Новгород, Екатеринбург, Новосибирск, Владивосток
•
Украина: Киев
•
Индия: Мумбай, Ченнай
•
Пакистан: Лахор

3. Наши продукты
CRM
Pay-ment
system
Interconnect
billing
Billing
Bonus
Manageme
nt system
Mediation
Portal
Self care
IVR
Work
Flow
Resource
Inven-tory
Monitorin
g
Clea-ring
House
BUS
IN platform
SCP
Trouble
ticketing
Service
Provisionin
g
Reports

4. Наши клиенты
Россия
Украина
Беларусь
Чехия
Пакистан
Индия
 Более 150 млн.
абонентов
 Более 5 млн.
платежей в сутки
 5 тыс. соединений в
секунду

5. У нас есть
проекты
 Протяженные по времени
проекты
 Большое количество
разрабатываемых систем
 Даже первая итерация
достаточно трудоемкая!

6. У проектов бывает
заказчик
 При разработке
продукта приходится
учитывать
множественные,
иногда
требования заказчиков.

7. Мы работаем
в распределенной команде
 Состав команды:
20+ человек
 Территориальная
распределенность
(разные города и
страны)
 Для общения
используются
несколько языков

8. Мы делаем системы
класса
 К системе предъявляются
высокие требования
по надежности и
производительности
 Неработоспособность
системы - угроза бизнесу
компании.

9. пристального внимания:
качество проектирования продуктов
 Непрерывная проверка
качества решения
на всех этапах
разработки.

10. Факторы,
усложняющие командную работу
 Географическая удаленность членов команды
 Языковой барьер
 Фаза проектирования стимулирует создание
формальных документов.
Общение становится более формальным!

11.  Бесконечные переписки
 Невозможность выбора лучшего решения
 Команда делится на «группы»,
отстаивающие свои варианты.
:
 Сдвиг плана создания проектной документации
 Конфликты внутри команды.

12. Причины проблемы
 Споры: кто более опытный специалист?
 Ролевой конфликт в команде.
 Обида за напрасный труд.
 Чужой дизайн: тяжело понять (языковой барьер)
и тяжело принять (самолюбие).

13. Подход к решению задачи

14. Agile-манифест
 Люди и взаимодействие
важнее процессов и инструментов
 Работающий продукт
важнее исчерпывающей документации
 Сотрудничество с заказчиком
важнее согласования условий контракта
 Готовность к изменениям
важнее следования первоначальному
плану
14

15. Lightweight Architecture Alternative
Assessment Method (LAAAM)
 http://blogs.msdn.com/b/jeromyc/archive/2005/08/27/45
7081.aspx
Jeromy Carriere's WebLog
 http://www.infoq.com/news/2011/07/low-ceremony-architecture
Manuel Pais

16. Начало: все против
• Нужно время – хотя бы три или пять дней, а мы и
так уже отстаем от плана …
• Метод ничего не гарантирует!

17. Люди и взаимодействие
Kansas City Shuffle
Позитивные переходы:
 от межличностного
конфликта –
к технической дискуссии
Кадры из фильма: Lucky Number Slevin
 от безрезультативного
«чьё решение лучше» к конструктивному
обсуждению
критериев выбора

18. выявляем проблемную область
Что делаем:
 Локализуем спорную
часть дизайна системы.
 Отвечаем на вопрос:
Почему не можем
выбрать одно из двух
решений?
Как делаем:
 К ответу на вопросы
принимаем
только технические
причины!
 В нашей команде
только отличные
специалисты!

19. Диагностика проблемы
Основная причина проблемы:
конфликт производительности и надежности
(сопровождаемости) системы
что-то «не так» со скоростью twitter
что-то «cломалось» в презентации microsoft

20. Шаг 1: Клин-клином вышибают
Делаем описание решений:
 Концептуальный дизайн фиксирует основные
моменты решений, концентрируясь на различиях
(architecture tradeoffs).
 Создаем небольшой документ нотации,
понятной всей проектной команде.
 Время чтения документа: не более 10 минут.

21. Пример: типовой проект
из жизни биллинговых систем
 Есть несколько
биллинговых систем
 Бизнес-цель:
предоставить
пользователю один счет
за услуги разных систем
 Пользователь делает
один платеж за все!
Billing #01
Единый счет
Сгенерированн
ые счета
DATABASE
Billing # n
Сгенерированн
ые счета
Единый счет

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

23. Пример:
решение №1 - «быстрое»
Как только система
в регионе окончила
формирование счета –
данные передаются в
«центр».
Почему: чем быстрее
выставим счет, тем
скорее он попадет
клиенту и его оплатят!
Billing #01
Billing # n
Единый счет

24. Пример:
решение №2 - «надежное»
Из центра по расписанию
запрашиваем данные
в биллингах и, если счет
выставлен, собираем данные
в единый счет.
Почему: в биллингах данные
могут меняться совершенно
самостоятельно.
Нам не нужны проблемы
с целостностью данных!
Billing #01
Billing # n
Единый счет

25. Итого
Решение №1
Решение №2
Плюс: кажется,
что работает быстрее за
счет отсутствия задержек.
Плюс: кажется,
что работает надежнее
за счет централизации
управления.
Минус: контроль
целостности данных
распределен между
системами.
Минус: замедление.

26. Шаг 2:
устанавливаем приоритет требований
 Формирование требований в виде сценариев
использования по принципу:
воздействие – реакция на воздействие.
 Условие: каждому требованию –
как минимум один сценарий
 Сценарии выбираются так, чтобы выявить
расхождения в решениях.

27. Шаг 3: формируем «вычислимый»
критерий принятия решения
 На основе субъективных оценок приоритетов и
субъективных оценок соответствия решения
заявленному требованию делается вычисление.
 Это не объективное сравнение,
а «виртуальный арбитр»

28. Дерево качества
упрощенный пример – упрощенное дерево
Качество
Производительность (0.25)
Поддерживаемость (0.75)
Время отклика (0.75)
Гибкость (0.6111)
Сценарий 1. (0.25)
-
Сценарий 2. (0.75)
Обучаемость (0.2778)
-
Масштабирование (0.25)
Расширяемость (0.1111)
-
-

29. Два ключевых сценария
№ Событие
Место
Реакция
Нагрузка
Измерение
1
Выставлены счета
Во всех
биллингах
Данные собраны в ЕС
6
биллинговых
систем
10000 единых
счетов
5000
единичных
счетов
в биллинг
1 час
2
Выставлены счета
при условии, что
часть счетов не
соответствует
правилам ЕС
Во всех
биллингах
Данные собраны в ЕС
Аналогично
пункту 1.
1 час

30. Как устанавливаются веса?
Формула веса
Где k – приоритет атрибута,
N – количество сравниваемых атрибутов.
Легко видеть, что сумма таких весов равна 1.

31. Сравниваем сценарии
 Решаем, какая архитектура «лучше»
для данного сценария
 Выставляем оценки по критериям:
 0 – не реализуется
 1 – сценарий трудно достижим
 2 – Сценарий реализуем, но с ограничениями
 3 – Полностью соответствует
 4 – Высшая оценка

32. Сравнение решений
с точки зрения сценариев
Командная работа в компании Энвижн – Программные решения

33. Считаем «вес» архитектуры
Сценарий
Сценарий
№1
Сценарий
№2
Сумма
Вес
.25*.75*.25
.25*.75*.75
Архитектура
№1 - оценка
Архитектура №1 вес
3
3*.25*.75*.25=
0,140625
2
2*.25*.75*.75=
0,28125
0,421875
Архитектура
№2 - оценка
Архитектура
№2 - вес
2
2*.25*.75*.2
5=
0,09375
3
3*.25*.75*.7
5=
0,421875
0,515625

35. Правило №1
 Создавать дерево до того, как придуман сценарий и
сравнивать решения.
 Это дает возможность "обмануть" команду и увести
от сравнения решений к сравнению требований.

36. Правило №2
 При выборе весов пользуйтесь красочными образами,
характеризующими конкретное решение: «если будет
превышено время отклика у протокольного адаптера,
у абонента пропадет связь, он будет страдать» и т.д.
 Пусть сценарии придумает человек, который нейтрально
относится к решениям.
 «Идеальный сценарист» - архитектор другого проекта.

37. Правило №3
• Веса сценариев распределяются только по
формуле!
• Иногда мы не могли расставить приоритеты, и
приходилось голосовать.
• В этих случаях у команды было меньше доверия
к результату сравнения.

38. Правило №4
 Необходим Product Owner.
 Заказчик, как правило, не требует увеличения
скорости модификации системы и улучшения
удобства эксплуатации
 Нужен серьёзный внутренний заказчик.

39. Итого
 Срок подготовки и выбора решения по данному
сценарию - 3-7 рабочих дней.
 Иногда требуется делать по 2 итерации выбора.
 Мы испытали этот метод на 4 крупных проектах.
Процедура всегда приводила к выбору решения
и снятию конфликтов!
 Это не «вычисление лучшей архитектуры»,
это - способ конструктивно договориться!

40. СПАСИБО ЗА ВНИМАНИЕ
ddzuba@nvision-group.com
40