Птички и пчелки. Как документировать сложное просто

Deutsche BankDeutsche Bank Technology Centre, LLC

Птички и пчёлки.Как документировать сложное просто.

1

Kristina ErofeevaAnalyst Days 2016


Кристина Ерофеева,человек и аналитик

Доклад отражает личное мнение и взгляды автора, которые могут не совпадать с мнением и позицией ООО «Технологический Центр Дойче Банка»

Об авторе

Deutsche BankDeutsche Bank Kristina ErofeevaAnalyst Days 2016Deutsche Bank Technology Centre, LLC

Причем тут птички?

— Информация слишком сложна для восприятия

— Аналитик, который должен был использовать упрощающие аналогии, не сделал этого

— Всё пропало



— Мы собрали бизнес-требования;— Они непротиворечивы, правильны, их достаточно, чтобы описать

всю функциональность системы;— Они организованы определенным образом;

— Но, при достижении некоторой сложности системы, структура бизнес-требований не подходит для разработки

В чём проблема?



— Система делает отчеты по транзакциям— 7 разных регулирующих органов— 6 разных типов сделкок— 40 событий различной бизнес-природы— 30+ разных типов отчетов (по нескольку для каждого регулятора)— Несколько временных отсечек (сразу, в конце дня, за неделю)

— Бизнес экспертиза распределена во-первых по типам сделок, во-вторых по регулирующим органам

— Структура системы предолагает единообразную обработку всех отчетов

Например:



— Дорогая и/или долгая разработка— Неоптимальный код, много переделок— Copy & Paste как способ справиться со сложностью

— Перенос на команду разработки ожидания экспертизы в предметной области

Почему это проблема?


Декомпозиция бизнес-требований

05/01/2023 2010 DB Blue template

7



— Одно бизнес-требование можно разделить на несколько требований помельче

— Каждое из требований помельче должно описывать только один атомарный аспект создания фукнциональности

— Например: кто? в какой момент? да/нет? какой статус?

Важно: при делении бизнес-требований каждое из них всё ещё остаётся именно БИЗНЕС-требованием, без деталей реализации.

Как декомпозировать?



— Бизнес-сценарии:Новая сделка => Отклонено (ошибка валидации) => Новая сделкаЗакрытие сделки => Отклонено => Закрытие сделки— Как декомпозировать:Как отчитываться по событиям определенного типа (новое, закрытие)Какая реакция на ошибки валидации во всех случаях— Как удобно обобщить:(Событие) => если отклонено => (Событие того же типа)

Например:



Оптимизация организации требований

10



Тождественные преобразования: немного магии, немного здравого смысла

— Можно:— Найти похожие параметры в разных объектах— Заменить значимыми числами и поправочными коэффициентами— Попробовать вынести часть формулы «за скобку»— Привести формулу к «единому знаменателю» — Замена логического параметра числовым (сторона сделки

меняется на + или -)

Как оптимизировать?

11



Система осуществляет торговые операции, торговля происходит валютными парами (у которых есть первая валюта сделки, вторая валюта сделки)

Необходимо добавить функциональность обложения сделок комиссией

Например:

12



Комиссия 1: Кол-во по первой валюте сделки * Коэффициент1Комиссия 2: Кол-во во второй валюте сделки * курс пересчёта из первой валюты во вторую * Коэффициент2 Комиссия 3: Количество в единицах некоторой третьей валюты * курс пересчёта из третьей валюты во вторую * Коэффициент3Комиссия 4: Количество по нескольким сделкам (объединённым каким-либо принципом) * Коэффициент4

Комиссия итого: Количество * (при необходимости) Курс пересчёта * Коэффициент

Например:

13



Сборка структуры функциональных требований

14



Поэтапное построение структуры функциональных требований

15

— Мы отталкиваемся не от сценариев использования и бизнес-нужд, а от архитектуры/структуры разрабатываемой системы

— Все ситуации, которые могут произойти в определённой части системы, делятся на 5-7 групп, которые с точки зрения реализации требуют единой обработки

— Выделяется общая часть обработки всего, и некоторые ветвления для более узких групп требований

Единого идеального способа построения структуры, по мнению автора, не существует. Поэтому…


Как проверить оптимальность полученной структуры?

16

- Если вы всё ещё видите это выражение лица у команды разработки, что-то идёт не так

- Если всё идет как надо – это выражение лица будет у бизнес-пользователей, которые будут смотреть в полученные функциональные требования



— Проблема 1: при декомпозиции / организации / сборке аналитик может допустить ошибки, бизнес-пользователь может их не заметить, и тогда код разойдется с бизнес-требованиями

— Возражение к проблеме: если преобразование структуры не делает и не «вербализирует» аналитик, то то же самое неявно делает каждый участник команды разработки.Причем, каждый сделает это по-своему.

— Способы преодоления: инженер по тестированию читает и бизнес-, и функциональные требования при составлении сценариев тестирования

— Кросс-проверка другими функциональными аналитиками

Привнесённые проблемы и как с ними справиться



— Проблема 2: при различной структуре бизнес и функциональных требований возможны те же последствия, как и для неоптимальной архитектуры ПО: структура функциональных требований не поддерживает изменение бизнес-требований во времени

— Способы преодоления: если есть возможность – исследовать бизнес-требования такого рода в прошлом, чтобы определить потенциальные «зоны подвижности».Как и с архитектурой ПО, нет надёжного способа преодоления. Но это не значит, что структура функциональных требований и/или архитектура ПО в принципе бесполезны.

— Кросс-проверка другими функциональными аналитиками

Привнесённые проблемы и как с ними справиться



— Система работает стабильно (потому что код структурирован хорошо)

— При изменении функциональных требований – очевидно, какие части системы нуждаются в доработке

— Система работает понимаемо для бизнес-пользователей, и можно выявить несоответствия в ожиданиях и результате, хоть и после сопротивления бизнес-пользователей

— Всё это в целом дает ощущение безопасности от сложной системы

Что получится в итоге


Deutsche BankDeutsche Bank Technology Centre, LLC 20

Спасибо за внимание

Вопросы?



Данный материал не является предложением или предоставлением какой-либо услуги. Данный материал предназначен исключительно для информационных и иллюстративных целей и не предназначен для распространения в рекламных целях. Любой анализ третьих сторон не предполагает какого-либо одобрения или рекомендации. Мнения, выраженные в данном материале, являются актуальными на текущий момент, появляются только в этом материале и могут быть изменены без предварительного уведомления. Эта информация предоставляется с пониманием того, что в отношении материала, предоставленного здесь, вы будете принимать самостоятельное решение в отношении любых действий в связи с настоящим материалом, и это решение является основанным на вашем собственном суждении, и что вы способны понять и оценить последствия этих действий. ООО "Дойче Банк Техцентр" не несет никакой ответственности за любые убытки любого рода, относящихся к этому материалу.

05/01/2023 2010 DB Blue template

21

Education

Птички и пчелки. Как документировать сложное просто