Система автоматизированного проектирования и контроля разработки: как мы «докрутили» СППР

Проектная документация редко становится предметом гордости команды. Обычно это сотни артефактов, разрозненные системы, ручная синхронизация и ощущение, что половина работы уходит не на разработку, а на обслуживание процесса. Мы попробовали изменить эту логику: не отказаться от привычных инструментов, а собрать вокруг них единый контур проектирования. Рассказываем, что из этого получилось.

Привет, Хабр! Мы — Анастасия Назарец, Артем Вожаков и Антон Филин из отраслевого центра компетенций IBS в машиностроении. В этой статье расскажем, почему решили сделать собственную систему проектирования прикладных решений при живой «1С:СППР» и как новая комплексная система реализации проектов улучшила не только нашу жизнь, но и жизнь заказчиков.

С чего все началось

На проектах комплексной автоматизации с бюджетом свыше 30 миллионов рублей мы традиционно ведем структурированную информацию в связке Confluence+Jira. Пока работа идет внутри команды, такой подход удобен. Но сложности начинаются ближе к завершению проекта, когда нужно передать заказчику накопленную базу знаний и проектную документацию. Проблемы возникают, даже если заказчик сам использует Confluence, чего уж говорить про компании с альтернативными системами. Перенос информации быстро превращается в отдельный проект.

В определенный момент мы добавили в этот контур российскую систему проектирования прикладных решений «1С:СППР». Но и этого оказалось недостаточно. В типовых конфигурациях 1С нет стандартизированного механизма проектирования объектов метаданных. Из-за этого проектные решения в Confluence существуют отдельно от реальной структуры метаданных. Хотя СППР содержит инструменты для работы со структурой объектов и сравнения изменений, сценария полноценной совместной работы Confluence и СППР на практике мы тогда не нашли.

В результате из проекта в проект повторялась одна и та же история: мы вручную заполняли таблицы описания изменений конфигурации, собирали документы, а после завершения проекта все это фактически отправлялось на полку без повторного использования на других проектах.

Стало понятно, что нужен другой подход. Нам было необходимо:

• снизить трудоемкость проектирования и разработки в комплексных проектах 1С;

• создать системное решение для совместной с заказчиком работы по проектированию и разработке решения;

• обеспечить передачу структурированных данных проекта по результату его выполнения;

• стандартизировать проектирование объектов метаданных.

Перед командой поставили конкретные задачи:

• доработать СППР под новые объекты проектирования: функциональные области, бизнес-процессы, объекты данных, связи между ними;

• реализовать полноценную интеграцию СППР и Confluence в отношении ключевых объектов проектирования;

• подготовить целевую конфигурацию системы, включающую наиболее подходящие расширения для СППР, с учетом методологии IBS;

• разработать обучающий курси комплект документации.

Проектом занималась команда из пяти человек: директор проекта, три архитектора и разработчик.

Ключевые особенности разработанного решения

• логика группировки объектов соответствует методологии IBS: Confluence+Jira+СППР;

• универсальный механизм статусов — аналог Handy Status для проектных сущностей в Confluence;

• версионирование объектов на базе механизма 1С «История данных» и отчеты по сравнению версий;

• механизм быстрого создания связей и трассировки объектов по аналогии с Jira/Confluence;

• интеграция с Confluence: генерация XML для спецификации на разработку и проектных решений по корпоративному шаблону нажатием одной кнопки, загрузка данных и связей Requirement Yogi;

• интеграция с Jira в части загрузки задач разработки по эпикам;

• механизм проектирования профилей доступа;

• визуальное проектирование интеграций: мэппинг атрибутов объектов метаданных, произвольные сообщения в форматах XML/JSON;

• механизм проектирования изменений объектов метаданных и интеграционных потоков через запросы на изменения (request for change, RFC);

• поддержка расширений в части проектирования и работы с метаданными;

• контроль жизненного цикла изменений от требований заказчика до исправлений в конфигурации;

• интеграция с «1С:Документооборот»: хранение и согласование проектных документов, согласование техпроектов;

• универсальный обмен данных через Excel при помощи модуля миграции.

Как все устроено

Логическая модель данных (схема связей артефактов проекта)

Отказываться от Jira и Confluence мы не собирались. Нужно было придумать, как разумно использовать три системы сразу, не дублировать работу и не сойти с ума.

Получилась следующая функциональная архитектура:

По наполненности и возможностям анализа СППР в итоге приблизилась к Confluence. Исключение осталось одно — полноценная работа с Word-документами.

С помощью механизма обратной интеграции XML-код можно сгенерировать в СППР и одним действием перенести в Confluence.

Архитектура интеграций

На современных проектах ограничения по информационной безопасности становятся все жестче. Возможность работать с заказчиком в общем контуре есть далеко не всегда.

Поэтому базовый сценарий выглядит так: СППР разворачивается на нашей стороне и подключается к Jira и Confluence. Для передачи изменений используется регулярная выгрузка данных в шаблон миграции и последующая загрузка в СППР заказчика.

Основные объекты системы

Как это выглядит на практике

Интерфейс СППР — подсистема «Проектирование» под методологию IBS

Важно уточнить, что мы используем СППР не совсем по ее прямому назначению. 1С создавали этот программный продукт для проектирования конфигураций. Мы же реализуем в ней коммерческие проекты, где конфигураций может быть много, а процессы могут перетекать из одной конфигурации в другую. Логику работы системы пришлось адаптировать.

Работа с объектами

На примере одного из требований:

Требования можно классифицировать по тематике, источникам и важности. Мы также добавили поля для детального описания требования, фиксации разрывов и способа реализации.

Два механизма оказались особенно полезными:

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

— «Статус» — гибкая модель контроля состояния, которая позволяет отслеживать десятки параллельных процессов согласования и реализации.

Концептуальная схема связей и статусов:

Для интеграции с Confluence дополнительно появился реквизит «Код миграции», чтобы больше не заниматься ручным сопоставлением объектов.

Описание объектов метаданных

Загрузка описания метаданных осуществляется через типовую обработку «Загрузка метаданных». Основной справочник — «Объекты метаданных», а также подчиненные ему «Реквизиты, формы, команды».

Проектирование изменений

Когда появляется понимание целевых доработок, начинается детальная проработка изменений. Процесс выглядит так:

1. Создаем технический проект — агрегирующую сущность для бизнес-задачи. По сути, аналог эпика в Jira.

2. Формируем запросы на изменения в разрезе объектов метаданных и интеграционных потоков.

3. Связываем их с требованиями, объектами данных и другими аналитиками.

4. Проводим согласование и включаем запросы на изменения в технический проект.

Концептуальная схема изменения метаданных:

Документ «Запросы на изменения» можно создать в системе с нуля, быстро заполнить с помощью редактора метаданных и автоматически сгенерировать на его основе текст спецификации на разработку по нашему внутреннему стандарту.

Раньше каждый объект метаданных означал ручное заполнение таблиц, проверку данных, создание задачи в Jira и подготовку текста СНР. Теперь система сама генерирует XML для вставки в Confluence, проверяет стандарты наименования объектов и реквизитов и автоматически формирует структуру документов. По сути, мы убрали значительную часть механической работы.

Миграция данных и массовые корректировки

Загрузка данных из Confluence и Jira

Согласование в «1С:Документооборот»

Отчеты и трассировки

Мы подготовили набор универсальных и преднастроенных отчетов. Вот пример отчета с анализом функционально-технических требований:

Там, где раньше загрузка проектной базы на тысячи документов в Confluence занимала минуты или часы, теперь результаты отображаются практически мгновенно.

А где же ИИ?

Прямой интеграции СППР с GPT-моделями пока нет. Но ИИ уже можно использовать как вспомогательный инструмент.

Например, на одном из проектов нужно было спроектировать интеграцию 1С и SAP. Мы сформировали описание интеграционного потока в DeepSeek, загрузили результат в СППР и получили готовый каркас схемы, который осталось только уточнить и согласовать.

После этого одним действием перенесли данные в Confluence:

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

Эффекты от использования

• активное вовлечение заказчика в процессы проектирования за счет создания аналитических инструментов проектированияв его среде и, как следствие, значительное увеличение скорости приемки отчетных документов проекта;

• сокращение трудозатрат на написание проектных решений до 40%;

• сокращение трудозатрат на написание спецификаций на разработку до 25%;

• исключение человеческого фактора и ошибокв документации при написании проектных документов, содержащих описание метаданных;

• автоматический контроль соответствия проектной и фактической структуры метаданных.

Чтобы достичь этих эффектов, важно заранее проговорить с заказчиком ряд условий:

1. Формирование команды проекта на стороне заказчика с выделением архитектора системы, владельцев и кураторов процессов со стороны ИТ по каждой функциональной области.

2. Обучение команды заказчика типовым решениям 1С до начала реализации проекта.

3. Обучение команды заказчика работев СППР IBS.

4. Организация на стороне заказчика базы «1С:Документооборот 3.0» для согласования проектной документации, бесшовно интегрированной с СППР.

5. Подготовка заказчиком изолированной инфраструктуры среды моделирования до начала реализации проекта с обеспечением возможности передачи и получения данных из внешних систем в ресурсы среды моделирования.

6. Подготовка, согласование и выполнение заказчиком строгого регламента согласования проектной документации, определяющего длительность и состав этапов согласования.

7. Вовлечение команды заказчика в процессы согласования проектной документации по мере готовности отдельных блоков.

Что дальше

В бэклоге уже лежат:

• поддержка BPMN;

• развитие механизма запросов на изменения;

• средства визуализации;

• развитие инструментов управления разработкой.

Если интересно посмотреть отдельные механизмы подробнее, задавайте вопросы в комментариях или пишите сразу в телеграм Артему или Анастасии.