По итогам Инфостарта май-июнь 2024...
Доклад Романа Пионтика по подходу "Архитектура как код" на фреймворке SEAF
Роман является лидером в РФ в практической реализации методологии АаС
А вот как подход АаС на практике соединить с фреймворком SEAF об этом рассказывает Станислав Султанов.
Станислав реализовал связь SEAF (Dochub) с СППР 1С.
Получается сейчас лидерство за реализацией современного подхода в блоке 1С за Султановым.
Он в своём мастер-классе на Инфостарте предметно показывает как в СППР работать с описанием КОРПОРАТИВНОЙ архитектуры ИС и процессов
и при поддержке Романа Пионтика создаёт описание как Архитектор 2.0 на уровне организации с подведением к функциям и метаданным конфигурации 1С (ЕРП).

Вдогонку к предыдущему посту...
Всё новое - хорошо забытое старое.
В своё время к этому подходу и реализации была близка система "Дракон" (Тышов, Араптанов) (ей вроде лет 20 , как минимум?).
Если внимательно её изучите, то можете увидеть много знакомых вещей.
Что же не хватило Дракону?
На мой взгляд - более чёткой методологии, которая лучше выражена в подходе АаС.
Это те самые "карточки".
Почему "карточки" должны войти в основу технологии и СППР и других систем описания архитектур ИТ и бизнеса - об этом и многом другом в моём докладе на Инфостарт.

По итогам Инфостарта опубликована статья
"СППР – технология применения, недостающая функциональность. Основные альтернативы – "Архитектура как код" и "Шаблон архитектуры""
Можно ли, окружив СППР доработками, повысить её эффективность?
Есть ли такие доработки в готовом виде на рынке?
Дисклеймер: данная статья не повторяет доклад, а лишь излагает мысли и акценты, которые докладчику показались прошедшими мимо слушателей.

За доклады Инфостарта можно проголосовать постфактум для обратной связи авторам.
Вот здесь https://event.infostart.ru/analysis_pm2024/video/
Отмечайте звёздочками понравившиеся доклады.
Ваша поддержка авторам очень важна и помогает корректировать подготовку к докладам и оценку их значимости для сообщества.

На подумать:
Уже давным-давно существует Бизнес-Студио, где можно описывать процессы и их формализовывать.
Давно существует Дракон, в котором можно описывать бизнес-процессы, бизнес-цели, требования
и связывать их с кодом разработки.
Да, там нет подгрузки метаданных и извлечения архитектуры из кода и связки их с объектами графики (описания) - но ведь можно и сделать самим.
Сейчас мейнстримит подход "Архитектура как код", где можно описывать информационные системы, бизнес-цели и документы по проекту.
Почему же всё это не стало стандартом в нашей отрасли?
Под стандартом понимается - стали использовать все и все считают что с этой системой/подходом работать обязательно - это выгодно, полезно и эффективно и иначе никак нельзя.
Если сейчас выйдет какая-то система, решающая все недостатки СППР станет ли она стандартом?
Или, как бы её ни сделали, обязательно наткнётся ровно на те же проблемы что и упомянутые выше системы?
И что в ней должно быть обязательно, чтобы проблемы предшественников обойти?
Ваше мнение?

Эта статья для тех, кто размышляет стоит ли в СППР реализовать управление кодом.
В статье интересная мысль - что разделение на монолиты и микросервисы слишком примитивно и не помогает в определении архитектуры приложений, а лишь запутывает.
https://habr.com/ru/articles/825532/

В продолжение вчерашнего поста.
Статья с идеей (вновь возникшей в который раз) хранить код в бинарном виде, как бы уже в виде синтаксического дерева (не АСТ).
Инструменты для построения синтаксического дерева есть. 1С в пролёте. Пока.
Это к вопросу на докладе Инфостарт "зачем тащить в СППР код".
Ну вот, возможный вариант ответа - не код, а пропарсенный особым образом код.
Опять же diff`ы может проще создавать.
И от бинарного формата один шаг до XML.
И ссылки на реальный опыт создания мультиязыкового IDE

И, бинго, в этом комменте собственно описывается прототип формализации кода в графическом виде фактически,
а на самом деле в формате современных no/low code систем.
Привет Дракону, который до этого не дошёл. Но сколько же здравых идей было зарыто в этом Драконе, это делает честь создателю.
А раз есть формализация кода, значит, возможно предварительное архитектурное описание.
Вот вам основа для управления кодом через архитектуру.
Вот ответ на вопрос зачем "тащить код" в СППР.

Книжка "BABOOK Руководство к своду знаний по бизнес-анализу v3" на Озоне стоит около 10тр
Вроде раньше это всё размещалось в сети бесплатно, или нет никогда такого не было?
Кто прочитал её полностью - была какая-нибудь польза?

По ходу работы у специалиста часто собирается своя библиотека электронной литературы.
Чтобы управлять библиотекой есть программы.
Я пользуюсь Calibre. Она бесплатная.

А теперь какая связь между Calibre и СППР?
В одном очень интересном решении, которое бы здорово было бы реализовать в СППР.
В Calibre любую книгу из центрального списка можно мышкой "бросить" на списки серий, тегов, авторов, идентификаторов в окне слева
и книге присвоится нужный реквизит.
Вот бы в СППР список требований или метаданных или функций также можно было "бросать" мышкой на проекты, метаданные, процессы и происходила бы связка по аналитикам.
ООООЧЕНЬ удобно.
На заметку тем, кто "пилит" СППР. Посмотрите как работает этот функционал - реально классное решение.

Теперь же собственно о самой Calibre - что там ещё есть:
- работает с огромным количеством форматов книг, ворд, эксель и т.п.
- может работать с видео, графическими файлами, html
- собирает файлы из указанного вами каталога или архива и пытается расшифровать их в карточку - присвоить серию, определить автора. издательство и т.п.
- позволяет мэппить книги (видео и т.п.) по аналитикам.
- ОЧЕНЬ ВАЖНО - позволяет создавать библиотеки с удалённым доступом, т.е. собранную свою библиотеку можно сделать доступной себе в любом месте через интернет
Я так делал через MailRu облако.
- можно добавлять аддоны
- есть конвертер форматов
- есть возможность самому писать скрипты (шаблоны) для обработки файлов
- есть переводчик (пока не пробовал)
- загрузка новостей
Чего не хватает (или пока не нашёл):
- не очень точно работает автомэппинг. Плохо берёт djvu и иногда текстовые и вордовские файлы со сдвинутым или отсутствующим титульным листом
- нет автоматического автодайджеста через ЧатЖПТ для составления кратких содержаний книг и выводов, но есть возможность присоединять файлы к книге
- нельзя редактировать книгу любого формата, т.е. создавать в ней метки (EPUB можно и в него можно сконвертировать много форматов)
- html (сохранённые сайты) бывает ползёт при конвертации
- связи/обмена с Obsidian или аналогичным инструментом майндмэппинга.

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

UPD
- есть связь с Obsidian
- есть перевод книг из текста в аудио
- может связываться с библиотеками, выдающими электронные книги для чтения (см. коммент к посту)
- может работать с Флибустой (но не нашёл как обойти один момент)

Вот это продвигается как поддерживаемое государством
(ДИТ города Москвы по крайней мере)
как "станки" для разработки ПО
- операционная система ОС МОС
- git репозиторий со сборкой пакетов и управление проектами https://abf.io/
- что-то вроде документирования и трекеров задач
На уровне школы - но хотя бы есть.

Интересная тема в завтрашней конференции Раруса (18 июля).
Да и весь список тем весьма привлекателен.
Но следует заметить, СППР подаётся как инструмент для разработки и для разработчика.
Увы, видимо, и Рарус не может похвастаться умением использовать СППР для проектирования ПО.

Прямо сейчас идёт трансляция Рарус по СППР
UPD вот здесь запись конференции

Стартовал проект от Александра Сазонова СППР+

Кто интересуется вопросами оценки затрат труда программистов на проекте (до проекта)
и ищет методологический базис для оценки, рекомендуется копать от методик
CMMI и SWEBOK (по последней ссылке сразу качается файл pdf со стандартом на санкционном языке)

Главные тезисы:
- программирование это давным-давно коллективная игра
- в большой разработке проблемы чаще из-за управления (архитектуры), а не из-за технических кризисов (умения писать код)
- организация процесса разработки и процесс управления проектом разработки - это две сильно разные вещи

А тем, кто интересуется как подсчитать-спрогнозировать затраты не только на программистов,
но и на других членов команды (архитекторов, аналитиков, консультантов, тестировщиков, менеджеров),
тем стоит порыть идеи здесь.

Вот здесь способ оценки задач не в часах.
А прямо скажем в попугаях.
Хотя ряд полезных мыслей есть, например, небольшой классификатор задач по сложности.
Ну и как бы вы это положили бы на СППР?
https://habr.com/ru/companies/selectel/articles/830848/

Какое интересное описание встретилось в материалах по 1С ЕРП


Описание процессов
Для описаний процессов поддержана выгрузка и последующая загрузка в другую
информационную базу. При выгрузке возможна замена ссылок на объекты информационной базы
на скриншоты этих объектов. При загрузке описаний предусмотрена возможность сравнение и
объединение текстов описаний в выгрузке и в текущей базе.

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

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

Ещё тема на обсуждение из материалов к той же ERP 2.5.18:

"Замена остаточного регистра накопления «Заказы клиентов» на оборотный
«Распоряжения на отгрузку»"

Мы видим, что состоялся факт - один вид регистра заменился на другой.
На пользователя это скорее всего не повлияло.
Но в коде явно существенное изменение.

А теперь приз вопрос в студию:
А если бы как архитектор, работающий в СППР, сделали бы такое изменение в объектах метаданных и алгоритмах,
то как бы вы в СППР это описывали?
Т.е. как бы описали в начале с одним регистром, а потом как бы отразили в СППР всю цепочку изменений на другой регистр.

Ох, Рарус и словоплёты.
Сделали кликбейтный заголовок к своему выступлению и излагают совершенно другую вещь.

Что ожидалось услышать: как к СППР или иной какой 1С прикрутили систему описания бизнес-процессов или систему напиcания кода как в Knime,
чтобы аналитики, архитекторы и просто пользователи могли донести до программиста какую-то схему, а он по ней построил код решения.

Вместо этого излагается методологическое решение внутри 1С ERP, которое позволило без модификации кода типовой конфигурации
описать работу авиакомпании.
Неплохое решение, весьма интересное.
Там, кстати, за основу выбрана сущность "Работа самолёта" - номенклатура вокруг которой работает производственный учёт в 1С ERP.
Аплодисменты.
Но это не no-code решение.

А теперь представьте что эта задача попалась бы вам и вашей СППР.
Как бы вы её решали в СППР.
Напоминаю суть: Архитектор Рарус выработал решение на основе определения сущностей и управления настройками 1С ERP, которое не требует кодовой доработки.
Как это описать в СППР?
Ведь решение выстроено вокруг не метаданного, а "объекта данных" - сущности у Раруса, вокруг элемента справочника "Номенклатура" для простоты.
Плюс настройки 1С.

Напоминаю, что в модели ERP от 1С, которая выпускалась для СППР настройки конфигурации присутствовали как элемент справочника "Функции" СППР1.

Сегодня в канале СППР+ ожидается развёрнутая публикация.

Кто искал теорию по оценке трудозатрат на проекте
Вот лёгкий материальчик для чтения.
Там есть про "Оценщик трудозатрат разработки (RICEF Estimator)"
И простенькая таблица базовых действий при разработке с оценкой в трудоднях.
Вперёд, колхозники!