В продолжение вчерашнего поста.
Статья с идеей (вновь возникшей в который раз) хранить код в бинарном виде, как бы уже в виде синтаксического дерева (не АСТ).
Инструменты для построения синтаксического дерева есть. 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)"
И простенькая таблица базовых действий при разработке с оценкой в трудоднях.
Вперёд, колхозники!

Интересные мысли об аналитиках.
Изложено вполне системно.
Самое важный вывод - лучше тот аналитик, который работает быстрее, пусть выдаёт и не самое лучшее решение, лишь бы оно устраивало заказчика.
Сделать лучше, но качественней - это плохо, если это превышает ожидания заказчика, это ест лишнее время от проекта и от затрат у заказчика.
Ещё из искрящих моментов - наняли 50 аналитиков, уволили из них 35 (за год и менее судя по тексту).
UPD тезисы выше из статьи, а не мнение автора поста.

Потрясающая статья.
Мы тут печёмся как СППР внедрять и как с ней работать.
А ведь это вспомогательная система ИТ-ландшафта, а не основная.
В статье же изложено с нужного ракурса, именно с нужной точки зрения причины проблем автоматизации.
Косвенное подтверждение давнего вывода, что до 75-90% процентов проектов автоматизации за 20-30 лет мало/ или бес/ полезные проекты.

Здесь хороший теоретический свод про работу с требованиями.
Упоминается СППР как дополнение к Confluence и Jira, решающее основную проблему - сложность работы с требованиями как с элементами списка в Confluence

В "DNS технологии" используют СППР, по крайней мере, для ведения "Технических проектов" (понимаемых как задания на разработку).
Вообще в статье рассматривается технология разветвлённой разработки.
Где главная проблема - как не перегрузить хранилища конфигураций слиянием изменений и многоветочной разработкой.
По смыслу статьи, под каждый Техпроект открывается хранилище.
Т.е.
- для Техпроекта развёртывается хранилище конфигурации.
- Техпроект является разделителем направлений разработки и балансером нагрузки от разработчиков.

По смыслу Техпроекта в СППР он не является напрямую заданием на разработку (Разработчику).
Это агрегатор описаний планируемых модификаций.
Задания разработчику нарезаются из Техпроекта СППР отдельным видом документов СППР.
Была мысль использовать ещё один уровень Техпроектов для агрегации Техпроектов под отдельные виды разработки.

По запросу "СППР" ХХ выдаёт 101 вакансию за "всё время".
Это же число выходит при запросе "за месяц".
Чтобы это значило....

ЗАО "СППР"