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

"Первым выступит Евгений Филиппов — эксперт по технологическим вопросам, автор «Настольной книги эксперта».
Евгений покажет, как моделировать бизнес-процессы произвольной системы в СППР в IDEF0. Евгений построит организационную модель и смоделирует работу 1200 человек, занятых проектной деятельностью с помощью оснастки нагрузочного тестирования. Крутой эксперимент, который погрузит в работу с СППР 2 и нагрузочным тестированием."

Ожидается митап на просторах нашей страны, где выступит участник нашего чата Евгений Филиппов.
Не даю ссылок дабы не сочли рекламой.

Евгений, но крайне интересно как же "моделировать бизнес-процессы произвольной системы в СППР в IDEF0",
некоторые сомневаются что это возможно, в типовой СППР по крайней мере.

Да и 1С как бы заявляет IDEF0 в СППР больше для функций.
В разделе БП в СППР они графику BPMN дают.

Очень ждём комментариев.

По предыдущей публикации в чате СППР пошла дискуссия
о том как вместо Процессов в СППР использовать Функции.

У сторонника такого метода, Евгения Филиппова, вышла статья
в «Вестнике компьютерных и информационных технологий», 2024, том 21, № 9"
под интригующим названием
"МОДЕЛИРОВАНИЕ ИРРАЦИОНАЛЬНЫХ РЕШЕНИЙ, ПРИНИМАЕМЫХ ПРИ УПРАВЛЕНИИ ИТ-ПРОЕКТАМИ", где
в разделе "Компьютерная модель" есть небольшое изложение об использовании СППР.

Ранее у Филиппова выходила статья, где также есть описание использования СППР как инструмента,
"Применение технологий нагрузочного тестирования для моделирования
процессов обучения сотрудников заказчика
// Вестник компьютерных и информационных технологий. 2023 Т. 20, № 3. C. 50 – 60.

Две статьи рассказывают что методика связанная с исполнением на СППР
работает на конкретных решениях.

Заявлена новая фича от 1С по выгрузке-загрузке конфигураций, расширений, внешних отчетов и обработок в/из файлы(ов).
Как думаете чем будет отличаться от штатного функционала СППР?
По логике СППР грузит из хранилищ,
а новая фича импорта-экспорта будет работать без подключения к инфобазе.

Как по мне, 1С вполне логично сделала блок Процессов в СППР.
И это соответствует порядку работы аналитиков на проекте.
1С задумывала описание Процессов, как действие в отрыве от описания функциональности проектируемого ПО.
Т.е. аналитики могут описывать бизнес-процессы работы клиента не задумываясь о том, какой в итоге ПО будет внедрён.
И без привязки к функциям и ролям.
Предполагалось, что описание Функциональности будет сделано отдельно и описание Профилей отдельно.
А после того как два описания Процессов и Функций (Профилей) будут готовы должен быть был выполнен мэппинг Функций (профилей) на процессы.
Поэтому логично выглядит, что в процессах требуется указывать Функции и Профили (Исполнителей) по принципу один=к=одному.
В тоже время при описании функций и профилей нормально что допускается отношение много-ко-многим.

Чтобы могло быть заменой или конкурентом или расширением СППР в будущем?

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

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

Попался на просторах интернета расклад по доходам ИТ специалистов.
Вроде результат обследования не по вакансиям, а по реальным доходам на ноябрь 2024.
Что скажете - реалистично?
Особенно по архитекторам, аналитикам.

Чем в таких случаях могло бы помочь СППР?
И чем помог стаж в 25 лет в 1С?
Опишите как бы вы в этом случае организовали бы работу и смогли бы применить СППР.

В базу знаний по СППР:
Один из участников чата сделал и развивает функционал для СППР по управлению сборкой.
Вот здесь сквозной пример процесса разработки в СППР, Git, EDT от аналитика до выпуска релиза.
Видео почти на 4 часа с последовательным и обстоятельным рассказом и демонстрацией.

Оффтопик
Попробовал здесь онлайн переводчик pdf и ворд файлов и презентаций pptx
Три файла в месяц в бесплатном варианте позволяют перевести.
Понимает и переводит схемы в pdf-файле, но не совсем аккуратно
расставляет надписи на схемах.

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

Статья по итогам доклада на весеннем Инфостарт 2024 о том как делать описание проектного решения. Статья хорошо структурирует изложение на самом докладе, даже можно сказать статья лучше доклада доносит тему.

Итоги канала за 2024 год:
1. Прирост подписчиков за год более 400 человек. За 3 года более 1300 человек.
2. 25% подписчиков читают статьи в первые 24 часа после публикации. (без учёта прочтения неподписчиками)
3. 25% подписчиков - женщины

Очень качественная статья про расчёт себестоимости в 1С.
Изложение на очень простом уровне с визуализацией.
Изложена история изменений расчета с/с от УПП, БП3, до ERP.

Что тут можно извлечь тем, кто работает с СППР?
Здесь вам стоит задуматься как бы вы в СППР отразили бы разработку алгоритма модификации себестоимости
от требований через функциональное описание к техпроектам.
Ведь расчет с/с это ряд регистров + кусок кода в модулях + ещё ряд объектов.
И это не всё.
Как бы вы в СППР отразили такие объекты как
- компоновку аналитик затрат (ведь это не просто метаданные, но ещё и данные)
- граф расчета себестоимости
- распределение затрат
- итерации распределения
ведь они ещё и "плывут" с каждой модификацией требований?

Такой аспект: как в СППР отражать такую сущность как "Формула".

Интересный технический момент, который, возможно, можно использовать при формализации сущности "граф" в СППР:
Если мы запускаем 1С с параметром «РежимеОтладки», у нас в журнал регистрации будет выведен граф затрат. И дальше можно его визуализировать – например, на сайте http://www.webgraphviz.com/.

Что скажете на тему: метод COCOMO и метод Функциональных Точек
для простой, недорогой и надёжной оценки сроков проектов -
можно ли сказать что метод ФТ это вариант метода СОСОМО?

Верно ли, что метод ФТ в отличие от СОСОМО не позволит оценить работу непрограммиста (т.е. аналитика, архитектора и т.п.)?

Для напоминания, что такое метод СОСОМО
и как его приложить к оценке проектов 1С
и как оценить работу не только программистов,
но и аналитиков, консультантов, архитекторов и менеджеров проекта
статья здесь

Контекст СППР тут заключается в том, что стоит ли в СППР (или его форки) тянуть не только метаданные, но и код).

Новый 2025 год встречаем с СППР версии 2.0.14.9
Из нового заявлено:
"Реализована возможность указания нескольких версий, в которых разрабатывается технический проект"
Однако....
Неужели можно версии технического проекта вести?
Кто уже успел распробовать?

Расширение СППР для коммуникаций по типу Bugzilla

Тема на подумать и обсудить:
Нужно ли пытаться при доработке СППР поддержать типовые "бумажные" проектные технологии внедрения 1С (ТКВ, ТБР).
Или нужно разработать "свою" проектную технологию под архитектуру и логику работы в СППР?
Если нужно поддержать типовые технологии, то в какой части/объеме?

Это в контексте вопроса нужно ли в СППР или разработках на её основе реализовывать полноценный блок управления проектами (на основе ТКВ и т.п. или иной методике) или ограничиться интеграцией с независимыми СУП в проект и шаги проекта СППР?