За двадцать минут, отведённых на доклад, с пулеметной, как казалось, скоростью надо было изложить несколько ключевых тезисов по опыту использования СППР. Теперь, спустя некоторое время, в более спокойном режиме можно проанализировать, что же происходит в мире СППР.
Прежде, посмотрим на картинке, как выглядит упрощённо процесс работы в СППР, и сделаем изложение на её основе:
СППР есть, она работает, используется и вызывает интерес у всё большего круга специалистов. Но ей присущи несколько ключевых недостатков, снижающих эффект от её использования.
Однозначно, главный недостаток - это очень высокая степень трудоёмкости при работе с СППР.
Использование СПППР на проекте и в сопровождении само по себе очень сильно поможет навести порядок в работе командной цепочки: аналитик-консультант-архитектор-программист-тестировщик-руководитель проекта. Но какой ценой!
Суть СППР для бизнеса – это мэппинг требований и бизнес-процессов на какое-то ПО от 1С.
Для мэппинга необходимо, чтобы из кода ПО был выделен список метаданных и список процессов пользовательского уровня. Выделять метаданные 1С СППР умеет, а вот процессы (функции) нет. Именно на этом и происходят затраты времени командой – ей приходится вытаскивать из ПО список процессов (функций), по сути восстанавливать метамодель ПО. Это можно сделать вручную, но долго. Весь труд может отправить в корзину выход нового релиза.
Вследствие этого, за проблемой первой очереди – трудоёмкости, второй недостаток - в СППР не хватает функциональности. И, самое главное, функциональности по извлечению процессов из кода конфигурации. Собственно трудоёмкость и вызывается недостатком функциональности СППР по автоматическому извлечению функций из кода. Такая вот тавтология.
Поэтому все, кто хочет использовать СППР эффективно или сделать на основе СППР wow-продукт, должны решить проблему трудоёмкости – доработать именно это слабое место СППР – сделать автоматическое извлечение функций пользовательского уровня из кода.
Указанное в настоящей статье не единственный недостающий функционал в СППР, в самом докладе изложен перечень must have в СППР, без которого СППР не будет адекватным запросам рынка продуктом.
Тем не менее, практика использования СППР идёт уже более 10 лет, и многие успели реализовать тот или иной недостающий функционал. На основе различных готовых наработок можно через интеграцию резко повысить эффективность СППР.
При подготовке доклада мне пришлось провести исследование на основе предоставленных мне материалов и открытых данных ряда продуктов и методик, некоторые стоит выделить особо. Все важные детали приведены в докладе, здесь же выделим буквально по одному ключевому функционалу отдельных разработок.
Сначала стоит обратить внимание на блок «Бизнес-процессы», где особенно не хватает функционала отрисовки бизнес-процессов и их увязки с метаданными и функциями конфигурации. Здесь в лидеры вырывается BIA Technologies c ПО «Sunrise BPM для СППР». По их изложению они сделали свой движок, который может заменить импортные решения и реализовать привязку к объектам конфигурации. Также заявлено, что в разработке функционал отрисовки процессов из шаблонов.
Вслед за этим, смотрим на разработку Евгения Чекушкина «Управление сборкой GLI. Расширение для конфигурации 1С:СППР и процессы СППР в нотации EPC». Её сильная сторона не в отрисовке в EPC, а в том, что реализована связь от Требования к коду в Gitlab. Под Требование создаются информационные базы данных и кластеры, управляемые через СППР для создания ветви разработки, а под каждую БД ведётся ветка разработки кода в gitlab. Таким образом, получается сквозной контроль от Требования к коду разработки.
В итоге, интегрировав Sunrise BPM и Управление сборкой GLI к СППР, можно получить в руки куда более мощный инструмент для аналитиков (отрисовка) и разработчиков и руководителя проектов (привязка кода к требованию заказчика для объяснения, что именно сделано на проекте исходя из каких требований).
Далее следует упомянуть не столько ПО, сколько методологию «Архитектура как код», которая продвигается в РФ Романом Пионтиком и его сообществом, что уже выразилось в создании фреймворка SEAF + DocHub. По этой методологии вводится понятие «карточек элементов», с помощью которых описывается архитектура бизнеса и архитектура ИС. Это, в частности, карточки «Манифест» (аналог метаданного в 1С) и «Контракт» (аналог связи, процесса (функции) в 1С).
Идеология «карточек» это то, чего очень не хватает методологии СППР. Если реализовать «карточки» в явном виде в СППР, то очень многие функции, включая отрисовку бизнес-процессов и автоматическое создание списка процессов из кода, могут быть реализованы весьма просто, и позволят проводить интеграцию с SEAF Пионтика.
Интересна также функциональность DocHub для управления проектной документацией, архитектурными описаниями и для визуализации бизнес-процессов и функциональности ПО, в т.ч. для управления разработкой. Это реализация подхода к методологии «Архитектура как код» (АаС). Здесь «код» понимается не как простыни текста, которые пишет программист, а как числовое и символьное выражение объектов как карточек с реквизитами и в формате yaml.
И вот здесь стоит обратить внимание на наработки Станислава Султанова, который реализовал интеграцию СППР с DocHub. Это одновременно и конкурент другим отрисовщикам бизнес-процессов и архитектуры, а так же и отличное дополнение для тех, кто хочет документировать ход проекта и саму архитектуру. Решение от Султанова не оформлено в данный момент как отдельный продукт, но наработки демонстрировались им на мастер-классе Инфостарта на реальном примере.
К интересным фактам можно отнести то, что уже лет 20 существует российская разработка «Дракон» (создатель Тышов, докладчик на Инфостарте Араптанов), которая, по сути, предлагала то, что сейчас озвучивается как современная мейнстримовая методика «Архитектура как код». В «Драконе» есть и отрисовка бизнеса от KPI и бизнес-процессов, и графическое представление кода (функционала), выраженные как единый процесс.
Но…. «Дракон» почему-то не получил широкого распространения. На мой взгляд, по той причине, что «Архитектура как код» имеет лучшую методологическую основу в виде «карточек», а «Дракон» сосредоточился на концепции кода внутри функциональных обозначений графических схем, которая не всегда положительно встречается сообществом разработчиков (код – как текстовое значение реквизита узла графической схемы).
С другой стороны, если внимательно почитаете материалы по Dochub, то заметите, что там подход АаС предлагается для описания архитектуры бизнеса и архитектуры информационных систем, но как обязательный для описания функциональности ПО не заявляется. «Дракон» же реализовал методологию следования кода ПО за описанием бизнес-процессов и требований в графическом виде. В нём код разбивается на функции, как это описано графически в иерархическом дереве процессов. Фактически это означает, что разработка должна вестись строго в рамках архитектурного описания от архитектора, а не по воле программиста. Вот это и встречает неположительную реакцию разработчиков.
Кроме того, такой подход более-менее хорош при написании ПО с нуля и только ПО, создаваемого по идеологии микросервисов. Когда же речь идёт о «монолите», а конфигурации 1С и есть яркий пример «монолита», то драконовский подход плохо ложится на такие программы по той причине, что там не соблюдается строгое иерархическое дерево функциональности в коде.
Особенность «монолита» в том, что есть код, который укладывается в иерархическое дерево описания функций, и это код, задающий функции пользовательского уровня. И есть код, который укладывается в отдельные, не всегда иерархические деревья. Это «сервисный» код, который реализует функциональность, не интересующую пользователя, но ему необходимую. Например, функционал «Реализация» это пользовательский уровень и ветвь одного дерева. А функционал «Вывод динамического списка в окне выбора» - это сервисный код, пользователю он нужен, но обычно никогда не заявляется как требование. Последнее часто является платформенным кодом (функционалом), но бывает и кодом на уровне конфигурации. В итоге, архитектурное описание выглядит графически как «лес» деревьев, где, как минимум, одно дерево растёт перпендикулярно другим деревьям. Программисту трудно уложиться в требования такого архитектурного леса. Но, может, это должно стать обязательным, иначе как контролировать архитектуру ПО и соответствие ей кода? Деревья можно извлечь реверс-инжинирингом, и это не будет классическим деревом вызовов или AST-деревом.
В беседе с Романом Пионтиком был затронут этот вопрос, и он высказал мнение, что считает неактуальным жёстко регламентировать написание кода через архитектурный подход. После моего доклада также слушатели поднимали вопрос «зачем тащить код в СППР».
Фактически такая реакция означает, что сообщество разрабов не готово писать код в рамках жёстких архитектурных ограничений. Но, с другой стороны, если не выставлять формализованные архитектурные ограничения к коду, то невозможно автоматизированно отслеживать, как в действительности реализованы требования заказчика в коде и насколько разработка соответствует задуманному архитектором. Также невозможно заранее автоматизированно готовить (проектировать) тесты.
На этом фоне, возможно, будет интересным решение от Александра Сазонова, который готовит выпуск своего продукта, получившего рабочее название «СППР+» и доклад по нему на осенней конференции Инфостарт 2024.
В СППР+ обещают сделать сквозной процесс от отрисовки процессов до контроля реализации требований через код и метаданные. В т.ч. быстрый функционал дискретных сравнений и исправление архитектурных ограничений от 1С СППР вроде равенства Проекта и Конфигурации, неполноты загрузки реквизитов метаданных и расширения на обслуживание ПО не 1С и автоматический мэппинг объектов и связей.
Презентация из доклада и видео выступления доступны через Инфостарт.
