Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки
В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.
В больших проектах причина неудачи чаще лежит не в профессиональном уровне команды, а в готовности Заказчика дойти до конца и получить отдачу от вложенных собственных усилий. Ситуация должна сложится так, чтобы цели проекта совпадали с кратко и среднесрочными целями Заказчика.
Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.
Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.
Спустя 2 месяца у нас уже была первая версия Технического Задания, которая состояла из 200 страниц основного ТЗ и 200 страниц приложений к нему с описаниями различных форм и бизнес алгоритмов. Надо сказать, что до этого я видел основное ТЗ на всю корпоративную ИС и на момент внедрения оно состояло всего из 600 страниц. Поэтому ещё в ходе разработки ТЗ на модуль всё чаще возникала мысль, что с таким объемом требований велика вероятность, что мы не взлетим, а если взлетим, то очень не быстро.
После того как ребята из нашего выделенного центра разработки в EPAM озвучили трудоемкость реализации в 6500 часов и длительностью 1,5 года разработки стало ясно что точно не взлетим.
Бизнес-процесс и процедуры, которые нужно было автоматизировать, были живыми и постоянно адаптировались под изменения внутри компании и вовне, как под рыночные, так и под требования Центрального Банка России.
Через полтора года те «штаны», которые мы сошьем для них будут им либо малы либо не подойдут вообще, а это выброшенные на ветер деньги, время и ресурсы разработки. Достаточно один раз попробовать через это пройти, чтобы понять что это точно не вариант и карьерное самоубийство в рамках компании. После этого ничего серьезного уже не доверят.
Отсюда последовал вывод, что Waterfall годится для небольших проектов и тех, где автоматизируемые процессы не подвержены постоянным изменениям. Нужно было что-то другое, предполагающее раннюю доставку и при этом, чтобы это было понятно всем кто вовлечен в процесс разработки. В идеале Waterfall, но не Waterfall. Им оказался Rational Unified Process.
Два слова о контексте
Компания разрабатывает и развивает собственную корпоративную ИС взяв за основу платформу Pivotal CRM. Причина самостоятельной разработки КИС и дополнительных функциональных модулей к ней это отсутствие на отечественном рынке каких бы то ни было альтернатив и дорогая стоимость приобретения западных аналогов в 2000-е годы.
Помимо сотрудников компании в КИС работают сотрудники более 200 компаний Партнеров по всей стране (B2B). Как упоминалось выше, разработка находится на аутсорсинге в компании EPAM Systems. На стороне компании оставлены бизнес-аналитика и управление проектами.
Что не так с методологией Waterfall (особенности и недостатки каскадной модели)
Эта методология Мать для всех последующих и является универсальной. По этой методологии были разработаны первые программы.
Основы, которые держат эту Методологию и заложены в ней:
- От начала и до конца спроектированный конечный результат.
(Архитектурный Проект Результата)
- Инструкция по сборке конечного результата.
(План реализации проекта)
- Последовательная реализация проекта.
Анализ, проектирование, сборка, тестирование и передача в эксплуатацию
- Сопротивление изменениям в Проекте Результата и Инструкции по сборке в процессе реализации проекта.
Изменения в проекте
- Результат проекта доставляется единой поставкой в конце проекта.
Динамика сборки результата проекта
Для того, чтобы реализовать длительный проект по Waterfall со сроками более 1-2 лет нужно сделать предположения о той бизнес-среде, потребностях клиентов и компании, которые будут на момент завершения проекта (допущения связанные с бизнес-целями Проекта). Также нужно предположить и заложить ориентировочную стоимость ресурсов на каждый год жизни проекта (допущения связанные с планом реализации Проекта).
Чем больше содержание проекта, трудоемкость и сроки реализации, тем больше допущений закладывается в проект, которые могут оказаться как верными так и не верными. Самые критичные — это допущения связанные с бизнес-целями Проекта, если они оказываются не верными то все вложенные в проект ресурсы, деньги и время обесцениваются.
Попытки внести существенные изменения в Проект Конечного Результата по ходу реализации требуют цикла перепроектирования Конечного Результата и Инструкции по сборке. Существенные изменения часто не позволяют продолжать уже начатые по первоначальному плану работы и приводят к переделке того, что уже было сделано.
По этой причине команда проекта и стейкхолдеры сопротивляются существенным изменениям в проекте, только если обстоятельства и сыгравшие/обнаружившиеся риски не ставят весь проект под сомнение в необходимости его продолжать. Когда изменения всё-таки вносятся они чаще всего приводят к дополнительным затратам и удлинению сроков. Возросшая длительность опять порождает новые требования и новые изменения. Это словно замкнутый круг из которого невозможно выйти победителем. Отсюда происходит постоянное вылетание из первоначальных сроков и бюджета.
Поэтому эта Методология подходит проектам строительства зданий и сооружений, типа атомной электростанции, но не годится для разработки Продуктов под быстро меняющиеся среды, в которых они будут применяться. У которых срок жизни Продукта в изначальном виде без внесения изменений меньше 5 лет.
Идея итеративной разработки призвана устранить связанные с допущениями риски, дать возможность быстро получить обратную связь, сократить масштаб потерь от неверных бизнес допущений и внести изменения в Проект Конечного Результата на основе обратной связи полученной по окончанию очередной итерации.
Преимущества Rational Unified Process
Методология RUP была целенаправленно разработана для разработки больших программных систем.
Новация №1, заложенная в её основу, это «Бизнес-моделирование» и связанные с ним Сценарии Использования (Use Case).
Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
Главная задача при разработке корпоративной ИС обеспечить непрерывность поддерживаемого бизнес-процесса. Когда ткань бизнес-процесса рвется, то встают все следующие за ним этапы в производственной цепочке, а порой и весь бизнес объемом в десятки миллиардов рублей.
Пример остановки торгов Московской биржейНа фондовом, валютном и срочном рынках Московской биржи нештатная ситуация … Последний раз биржа приостанавливала торги 1 сентября, но это коснулось только секции «Основной рынок». Этот сбой стал четвертым за последние четыре месяца. — Lenta.ru
Поэтому в основе разработки корпоративной ИС лежит проектирование нового бизнес-процесса на основе её использования, чтобы заменить один процесс на другой и сотни людей с определенного дня начали работать по другому чем привыкли до этого. В этом главное и основное отличие разработки корпоративной ИС от других видов программного обеспечения.
Новация №2: На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
Наличие отдельных компонент позволяет их переиспользовать и заменять одни на другие. Чем больше компоненты используются совместно тем выше вероятность сломать соседний бизнес-сценарий при внесении изменений в компоненту. Также наличие общих компонент ограничивает скорость и масштаб последующих работ по развитию системы. Если одна команда занимается тем, что меняет какую-то общую компоненту, то другая не может начать работы по её изменению до тех пор пока первая не закончит работы и не отладит свой бизнес-сценарий использования.
Новация №3: Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.
В Waterfall от того нет итераций, так как порой невероятно сложно разделить функциональные требования на самодостаточные блоки и реализовывать их итерациями. Я не говорю, что этого нельзя сделать, можно, но чаще всего результатом этого будет не работающий прототип ИТ-решения, а какая-то часть будущей программы. От этого бизнесу не становится легче, работающий прототип он так и получит через год, наличие итераций здесь помогает, но не сильно.
Вот так выглядит концепт RUP в упрощенном виде:
Каждый бизнес-сценарий разворачивается в системные сценарии использования. Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа...). На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы). Подсистемы разбиваются на компоненты. Компоненты содержат исполняемый код.
Основная идея RUP выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев. Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.
Как мы применили RUP
Шаг №1 — Я договорился с руководителем об использовании отличного от принятого в компании шаблона технического задания. В основу нового ТЗ легли бизнес и системные сценарии использования. Это решение было принято раньше чем решение о работе по RUP и по ряду причин о которых можно прочесть в моей статье «Каким должно быть ТЗ на корпоративную ИС?» (ссылка в конце этой статьи в разделе «Что ещё почитать»).
Шаг №2 — Спроектировали целевой бизнес-процесс и подготовили первую версию ТЗ. После того как получили оценки трудоемкости и длительности реализации приняли решение, что попробуем использовать RUP для этого проекта. Разбили целевой бизнес-процесс на 5 бизнес-процедур / 5 этапов реализации проекта. Первая версия ТЗ стала концепцией / дорожной картой по продвижению к целевому процессу.
Шаг №3 — Определились со стратегий автоматизации: двигаться от входной или выходной точки всего бизнес-процесса.
Первая стратегия «от входной точки» создаёт напряжение и заставляет автоматизировать все остальные этапы в цепочке. В последующие этапы бизнес-процесса перестают поступать первичные данные, которые необходимы им для работы.
Вторая стратегия «от выходной точки» не имеет этого напряжения, но и не имеет тех данных и истории, которые создаются и накапливаются на предыдущих этапах. Нужен регулярный перенос необходимой информации в КИС.
Пошли по первой стратегии. Проблему обеспечения последующих этапов необходимой информацией решили выгрузкой данных в Excel. Получили неожиданный эффект в виде растущей мотивации бизнес-пользователей полностью перейти из Excel в КИС вместе с соответствующей поддержкой и готовностью выделять время на работу с бизнес-аналитиком по проработке требований.
Шаг №4 — Подготовили ТЗ на первую часть модуля системы (вторую итерацию). Пока велась разработка первой части, готовили ТЗ на вторую часть (третью итерацию).
Первой итерацией была подготовка Концептуального Технического Задания где прописали полностью бизнес-процесс с использованием КИС, а также разработали первую версию архитектуры будущего модуля.
Шаг №5 — После выхода первой части модуля и старта его опытной эксплуатации, начали готовить дополнение к ТЗ на первую часть и ТЗ на третью часть (четвертую итерацию). В дополнение вошли те требования, что были упущены в начале и те что оказались неудачными в плане использования.
Результат — На всё про всё у нас действительно ушло 1,5 года. Работающий прототип (первая часть модуля системы) был получен спустя 6 месяцев с даты старта проекта. Остальные приходили уже через каждые 2 месяца.
С точки зрения архитектуры компоненты нового функционального модуля были заточены исключительно под него и не использовали компоненты основной ИС. Это позволило:
- Стабилизировать работу системы целиком при возникновении ошибок, порождаемых регулярно вносимыми изменениями в модуль, так и модуль от ошибок изменений вносимых в общий функционал ИС.
- Вести работы по развитию существующего функционала КИС параллельно разработке нового модуля.
Хоть RUP напрямую ассоциируется и связан с нотациями UML, для описания бизнес и системных сценариев использования не обязательно использовать именно их, подойдут и другие нотации. Главное, чтобы используемые нотации были понятны и Бизнес-Пользователям, которые будут согласовывать-утверждать постановку, и Системным Аналитикам и Разработчикам которые будут дальше работать с Техническим Заданием переводя его в проектную-техническую документацию. Мы для описания бизнес-сценария использовали eEPC и ARIS, а также требования нотаций IDEF0/3 для задания рамок системным сценариям: вход процесса, выход процесса, исполнитель.
Статья «Каким должно быть ТЗ на корпоративную ИС?» даст представление о том, как выглядит бизнес-сценарий и системный сценарий использования. В оригинале руководства по RUP не рекомендуется делать наброски пользовательских интерфейсов при составлении системных сценариев, но мы посчитали их необходимыми так как облегчают понимание и бизнес и системного сценариев засчёт визуализации их элементов. Это было практически первым прототипом системы хотя и не кликабельным.
После этого проекта написанное ТЗ стало новым шаблоном (стандартом). Также проект повлиял на весь технологический-производственный процесс разработки ПО в компании сделав его ритмичным.
Немного теории для понимания технической стороны методологии RUP и как её применять
Каждая итерация в RUP это классический Waterfall, содержащий все 5 этапов работ по сбору требований и их анализу, проектированию, разработке, тестированию и доставке. Но RUP также вводит такое понятие как фазы для проекта: Сбор требований и Анализ, Проектирование, Построение, Внедрение.
Теперь об этом подробнее.
Первая итерация, Фаза Анализ
Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс. Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.
Компания-Заказчик — это Банк. Он решает, что хочет начать предоставлять своим клиентам услугу по удаленной выдаче наличных при помощи банкоматов, установленных в офисах клиентов и на станциях метро.
Для оказания данной услуги, нужно разработать и доработать имеющееся у банка программное обеспечение. В ходе сбора требований и их анализа было выделено три крупных процедуры в бизнес-сценарии услуги:
- Загрузка наличных в банкомат Сотрудниками банка.
- Выдача наличных Клиенту по его запросу со счёта в банке.
- Учет количества загруженных и выданных купюр.
В этой итерации ещё нет работ связанных с проектированием архитектуры будущей системы, разработки программы, тестирования и доставки. RUP не ставит условий, что они обязательно нужны, но по своему усмотрению вы можете их выполнить.
Вторая итерация, Фаза Анализ
После того как бизнес сценарии определены, собранные требования раскладываются по шагам бизнес-сценария и системным сценариям. На этом этапе также выявляются те шаги бизнес-сценариев, что были не выявлены в первой итерации.
В ходе второй итерации были выявлены две дополнительные процедуры к основному бизнес-сценарию:
Для обеспечения доступности услуги выдачи наличных в режиме 24/7.
- Мониторинг и нотификация, направляемая банкоматом в банк, об окончании в нём наличных.
- Мониторинг и нотификация о работоспособности банкомата или наличия на нем проблем/ошибок в работе.
Результатом этой итерации становятся:
- На 90% законченные бизнес-сценарии.
- Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
- Собранные требования структурированы по бизнес и системным сценариям.
Третья итерация, Фаза Проектирование
Выявленным бизнес сценариям выставляются приоритеты реализации и самые важные из них становятся предметом проработки на данной итерации. В отобранных бизнес-сценариях выделяются первичные шаги-этапы, которые являются базой для всех последующих и без которых реализация остальных не имеет смысла. Для этих этапов детализируются сценарии использования системы.
Законченный результат передается Системным Аналитикам и Архитектору для моделирования того, что будет происходит внутри системы. Выделяются классы, кооперации между ними, последовательности взаимодействия. Формируется базовое представление об архитектуре будущей системы, выделяются подсистемы, компоненты системы и их распределение по узлам ИТ-решения.
Уже в этой итерации могут быть начаты работы по разработке и результатом итерации станет готовый прототип, поддерживающий выполнение первичных шагов-этапов ключевого бизнес-сценария. Его уже можно показывать пользователям для сбора обратной связи и уточнения требований.
Этот прототип не передается в опытную или промышленную эксплуатацию, так как заложенная в основу архитектура является первым пробным шаром и в последующих итерациях будет скорректирована.
Четвертая итерация, Фаза Проектирование
Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
На этой итерации происходит проработка первичных шагов-этапов остальных бизнес-сценариев. Причина по которой прорабатываются они, а не последующие шаги для ключевых бизнес-сценариев, это определение будущей архитектуры всей программы.
Каждый бизнес-сценарий может потребовать для своей реализации каких-то специфических компонент будущей системы и по этой причине архитектурные решения для каждого бизнес-сценария должны быть согласованы между собой.
Результатом этой итерации станут:
- Архитектурные решения для каждого бизнес-сценария.
- Согласованный проект общей архитектуры системы 1.0
- Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.
Пятая итерация, Фаза Построения
Стартует параллельно четвертой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию. Предполагается, что к моменту старта итерации уже получена обратная связь по результатам тестирования пользователями прототипа, изготовленного во время третьей итерации. Здесь происходит проработка остальных шагов-этапов ключевого бизнес-сценария и связанных с ними системных сценариев использования.
Предполагается, что к моменту начала этапа работ «Проектирование», уже будет выполнена реализация (разработка) четвертой итерации и начато тестирование второй версии прототипа.
Происходит уточнение согласованного проекта общей архитектуры системы после которого внесение каких-то концептуальных изменений в него практически сводится к нулю, но всё ещё возможно, так как остаются не реализованными полностью вторичные бизнес-сценарии.
Результатом итерации становятся:
- Полностью реализованный ключевой бизнес сценарий.
- Согласованный проект общей архитектуры системы 2.0
- Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.
Здесь уже возможна передача системы для опытной эксплуатации бизнес-пользователям так как система уже перестаёт быть прототипом и в большей степени похожа на ту, что будет передана бизнес-пользователям как её финальный вариант.
Шестая итерация, Фаза Построения
Стартует параллельно пятой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
Прописываются остальные шаги-этапы вторичных бизнес-сценариев и связанных с ними системных сценариев использования. Предполагается что к началу данной итерации выполнено тестирование второй версии прототипа, изготовленной вовремя четвертой итерации и получена обратная связь от пользователей по работе с первичными шагами-этапами вторичных бизнес-сценариев.
Результатом итерации становятся:
- Полностью реализованные вторичные бизнес сценарии.
- Финальный проект общей архитектуры системы 3.0
- Четвертая версия системы, реализующая все бизнес-сценарии.
Начинается полноценная опытная эксплуатация системы бизнес-пользователями и примерка её под промышленное использование.
Седьмая итерация, Фаза Внедрения
Здесь происходит внесение каких-то критических изменений в реализацию бизнес-сценариев, выявленных в ходе опытной эксплуатации и не позволяющих полноценно использовать систему в промышленной эксплуатации.
Восьмая итерация, Фаза Внедрения
На этой итерации проводятся работы по повышению удобства использования системы пользователями и оптимизации изготовленных решений. Пользователей в первую очередь интересует скорость и пропускная способность их участков. Происходит передача системы на поддержку. Проводятся формальные процедуры по завершению и закрытию проекта.
Подитог
Методология RUP не ставит условий по количеству итераций и их распределению по фазам. Концепт фаз и итераций введен для снижения рисков, потребности в ресурсах, задания ритма реализации проекта и предоставления возможности внести требуемые изменения при разработке большой информационной системы.
График зависимости срока проекта от времени начала выявления проблем в ИТ-продукте
Результат каждой итерации уточняет план следующей и даёт больше понимания о том понадобятся ли нам дополнительные ресурсы для следующей итерации, нужны ли будут дополнительные итерации для завершения фазы. Начать работать над проектом может минимальная команда из нескольких человек и её расширение будет обосновываться планом следующей итерации.
Результаты завершения фазы уточняют план и экономику проекта. Здесь принимаются решения продолжать ли проект, нужно ли сузить или расширить содержание проекта (объем бизнес-требований), чтобы остаться в бизнес рамках: нужного срока доставки результата проекта, его стоимости (бюджета) и доходности (рентабельности вложений).
Заключение
Понимаю, что не просто поменять принятые в компании устои как реализовывать ИТ-проекты, особенно если в компании работает Проектный Офис с методологией написанной на основе PMBoK и ГОСТ-ов. Если прочитав статью понимаете что ближайшая перспектива это всё-таки Waterfall, то рекомендую попробовать реализовать следующий минимум:
- Прописать автоматизируемый бизнес-процесс на основе использования ИС. Это больше чем на 50% готовая пользовательская документация и приемочные тесты.
- Заложить в проект время на то, что как минимум 1 раз в течении года придётся выполнить полный комплекс работ по перепроектированию, подготовке и согласованию изменений в проектную документацию.
- Помножить трудоемкость работ по разработке на 1,5. Так как треть сделанной работы придется выкинуть и появятся новые требования. Длительность этапа разработки тоже стоит помножить на 1,5.
- Разделить бюджет проекта на две части: создание и развитие.
На развитие заложить примерно 30% от всего бюджета проекта на создание. Это нужно затем, что когда закончите проект возникнет промежуточное состояние — проект реализован, но не принят на сопровождение.
Принятие на сопровождение, как правило, сопровождается процедурами согласования и выделения бюджета и ресурсов на сопровождение. При этом после окончания проекта начинается самая горячая фаза, когда пользователи будут требовать реализации критических доработок, которые не вошли в содержание (рамки) проекта, но их точно нужно делать и из чего-то финансировать до тех пор пока система не будет принята на сопровождение и переведена на бюджет поддержки.
Это позволит мягко договорится с Заказчиками об окончании фазы реализации проекта, выполненной согласно ТЗ.
На мой взгляд:
- Waterfall – это первая передача (первая скорость с релизом раз в год),
- RUP – вторая (релиз раз в квартал),
- Scrum – третья (релиз раз в две недели / месяц),
- Kanban вместе с автоматической сборкой обновления (Continuous Integration), автоматическим тестированием (Acceptance Test-Driven Development), автоматической доставкой и развертыванием (Continuous Deployment) – четвертая (релиз раз в день).
Что ещё почитать по теме для освоения RUP
- Статья «Каким должно быть ТЗ на корпоративную ИС?»
В статье делается упор на то, что после разработки и создания КИС, начнётся этап её развития. На этом этапе потребуется разработка как новых Технических Заданий на новые функциональные модули, так и внесение изменений в ранее разработанные ТЗ на существующие модули системы в связи с внесением изменений в сценарии их использования.
Обратите внимание на комментарии под статьёй. Они шире раскрывают материал и самой статьи про ТЗ и этой статьи про RUP.
- Книга «Унифицированный процесс разработки программного обеспечения»
Это настольная книга в которой есть всё что нужно, чтобы понять и научиться делать проекты по RUP.
Первая и основная сложность — это научиться проектировать не существующие бизнес-процессы / бизнес-сценарии. Чтобы подступится к ним я рекомендую научиться описывать существующие, после чего проектирование нового взамен старого уже не будет таким сложным.
Авторы книги предлагают для моделирования бизнес-процессов использовать UML, но всё таки книга заточена на проектирование информационной системы и в меньшей степени на проектирование бизнес-процессов. Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском). Понятие процесса которое заложено в этой методологии является основой для стандартов ISO и PMI. И уже после этого расширять свои знания и умения по использованию других нотаций.
- Изучения языка моделирования напрямую связано с необходимостью освоения какого-либо инструмента. RUP предполагает что вы будете использовать линейку продуктов Rational от IBM. Я рекомендую воспользоваться бесплатной демо-версией Business Studio. В этом видео с 12 минуты объясняется как строить модели с помощью данного инструмента.
