Доклад Султанова
Моделирование архитектуры с контролем фактической реализации

Вести с партнёрского форума 1С

С докладом по СППР выступал Станислав Султанов.
Презентация к докладу приложена к следующему посту.
Тем, кто хочет понять в каком направлении, возможно, 1С будет развивать СППР
и как планировать свою работу с СППР в будущем стоит ознакомиться с презентацией доклада.

Далеко не факт, что сказанное в докладе будет реализовано в СППР и не факт что именно в таком виде.
Но Станислав и 1С открыты к обмену мыслями, идеями.
Султанов есть в нашем чате, поэтому можете там задать вопросы или поднять тему дискуссии,
возможно, он подключится к общению, ну или suls@1c.ru для контактов.


Напомню, что Станислав Султанов - разработчик интеграции с DocHub на основе типовой СППР.
Это отличие его проекта от других разработок СППР+ (Сазонов), Архитектор СППР (Запорожский), ERP-tools (Ермолаев) или Sunrise+СППР (БИА),
которые основаны на коренных переработках архитектуры СППР.

Проект DocHub / Архитектура как код (АаС)- это современный, модный тренд в проектировании архитектур бизнеса, ИС и ПО),
продвигаемый в РФ Пионтиком Романом (Сбер и иные крупные проекты).
Поэтому, тем кто заинтересован в движении в направлении АаС, к докладу Султанова стоит присмотреться внимательно,
чтобы понять как, на каких подходах, идеях, трендах, возможно, в этом направлении будет расти СППР /1С.

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

У микрософт Windows вышел релиз 24h
И там есть такое "И, наконец, Microsoft планирует добавить в «Проводник» поддержку систем контроля версий, таких как Git. Это позволит отслеживать изменения и комментарии в проектах без необходимости запуска специализированных приложений или открытия веб-сервисов."

Кто знает что это такое?
Как-то можно это совместить с разработкой?
Есть идеи как это можно совместить с СППР и её версиями объектов?

Новости из общения в чате:
Один из разработчиков модов СППР попался в давно ожидавшую его ловушку.
Его непрямым образом попросили предъявить доказательства работоспособности и полезности его системы для аналитиков.
Такая ловушка ждёт любого кто делает свою разработку для проектирования какой-то системы.

Есть посыл: если твоя система работает и реально помогает проектировать ПО, то покажи как ты проектируешь на своей системе её саму.

И вот здесь сразу отпадает потребность создавать какие-то бюрократические архитектурные комитеты или гит-репозитории и сообщества.
Зачем?
Выложи систему в общий доступ (облако), дай входы и роли любому желающему.
И аналитики начнут там создавать Требования, связывать их с метаданными.
Добровольцы-архитекторы начнут там делать Техпроекты и создавать функциональное описание.
Также там можно будет записывать бизнес-процессы по проектированию
И там же баг-трекер организовать.
Вуаля!
Версия на версии сидит и релизом погоняет и все идеи от народа идут в разработку
Сиди и кодь по техзаданиям, расширяй функционал.
И, самое главное, нарабатывай методику работы с системой, которая сама себя распространяет в сообществе и становится стандартом.

В мире найма в 1С
Из разговоров с ЛПР в интеграторах, вопросов на собеседованиях,
которые проходят не менее 1 раза в неделю,
заметен тренд, что у крупных игрокам на рынке 1С возник тренд, который бы назвал так:
"куда бы пристроить команду".
На рынке получается есть нужда в контрактах на внедрение или новую ветвь бизнеса.
Сокращаются доходы?
Грозит сокращение команд?
Какие у вас есть наблюдения на эту тему?

PS При этом даже у крупных интеграторах в публикуемых подходах
очень простенькие подходы даже просто к управлению требованиями.
Типа "есть Конфлюэнс, ура, мы на коне управления требованиями".
Какие новые направления, когда идей то по управлению требованиями/архитектурой нет.

Число ежемесячных запросов запросов по 1С СППР
выросло с 200 до 1000 за период с 01.01.18 по 30.09.24
Пятикратный рост за 7 лет

Как бы ответ на вопрос - нужна ли маленьким командам СППР или почему маленькие команды не пользуются СППР

Краткий вывод: Им проще и быстрее любую мысль/требование забить в код, а потом исправлять ошибки,
чем тратить время на проектирование.

Резюме: Поэтому вопрос применения СППР не размер команды или проекта,
а фактор времени, которое согласны на проектирование выделять и оплачивать.
Как в том анекдоте про алкоголика, обезьяну и банан на потолке - чё тут думать, тут прыгать надо.

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

Все ушли на сегодняшний ERP-форум от 1С?
Если есть информация оттуда, делитесь, пожалуйста, здесь в чате.
Про СППР особенно, если хоть слово скажут.

Есть ли у кого-то сложности с комментированием постов в этом канале?
Возникает ли какое-либо препятствие в виде
- капчи
- кнопки "присоединиться" (пишут она есть, но мне она не видна)
- что-то другое
Если что- пишите здесь или админу.

Вот собственно для чего СППР и нужна.
В этой статье на примере проблем со внедрением ERP с цифрами
и рассказывается как реально состоят дела с успешными внедрениями.
Тут самое интересное - цифры реальной оценки ожиданий бизнеса от внедрения ERP, причин срыва ожиданий.
Здесь озвучивается необходимость "системной зрелости" организации для повышения шанса на успех внедрения ERP.
А системность и означает, что прежде чем что-то сделать/внедрить надо продумать/спроектировать.
А СППР инструмент именно для этого.

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

Из чата по Businness Studio про одну из методик работы с СППР. В частности о обходе проблемы сппр из-за отсутствия связки бизнес процессов с требованиями (но это по мнению автора сообщения). По тексту чата также упоминается о связке СППР с BS.
Это группа конференции по Проектированию бизнес архитектур. Вроде не публичная, не нашёл её прямой ссылки.

В СППР есть достаточно неплохой инструмент учета требований. При регистрации требования можно сгруппировать по тематикам, разделам и т.д, Но есть одна недоработка: в типовой СППР требование связывается с проектным решением только в техническом проекте, а это уже поздний этап проектирования. Для того чтобы связывать требования с процессами приходится делать небольшую доработку СППР, добавив на форму шага процесса табличку с возможностью указания требований, с которыми шаг связан, Далее создаем технические проекты, связываем их с процессами/функциями, потом в техпроект техархитекторы накидывают метаданные. далее на изменения, описанные в техпроекте вешаем задачи на разработку. Техпроект имеет версию релиза, по готовности всех задач решаем в какой релиз входит техпроект. Релиз техпроекта тестируется и идет в прод. Теперь в обратную сторону: есть код в 1С, в нем есть ссылка на задачу, в задаче есть ссылка на техпроект, техпроект содержит основание для разработки: требования, ошибки и т.д. есть описание изменений по объектам и функциям... Функция у нас тоже связана с требованием. Теперь по требованиям: можно посмотреть в каких техпроектах светится объект метаданных, какие требования были в каких техпроектах. как они менялись между релизами или просто исторически.

Это классный механизм. Применяли при внедрении ЕРП(2017 году) . Одновременно работало 12 команд подрядчиков. Очень помогла связка BS - СППР. Очень рекомендую к применению

Колесо реализации архитектуры предприятия
Наглядный интерактивны круглый граф и компактное текстовое изложение
Для тех кто ищет варианты описания архитектуры на проекте
- можете прикинуть как это удастся положить на СППР.

Для тех кто ищет методику как в СППР соединить бы проектирование архитектуры с проектированием ПО
и считает что это разные понятия.
Тут интересный постулат
"Проектирование программного обеспечения против архитектуры программного обеспечения"

В чате на пробу включен механизм репутации.
Можно поддержать и подбодрить полезного автора ответом "спасибо" или "thanks" или "++"
Особенно просим "молчунов" поддерживать и направлять дискуссию в сторону интересного автора, если не хотите сами высказываться.
Если против механизма репутации - напишите в комментах, общественное мнение имеет значение.
UPD
Текущие стандартные слова повышения репутации:
спасибо,++,дякую,рәхмәт,thank,tnx,+1,благодарю,благодарствую,👍🏻,🤝
UPD1
Пока видно что сработало от админа, но не сработала от участника.
Также непонятно где эти звёзды числятся :)))