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

бумажка.

(1) неужели все используют этот универсальный носитель? Других вариантов нет?

Типовая 1с конфа есть для разработки. Только я ее не смотрел.

Ищу тоже в чем проектировать.

сппр

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

(0)
>Поделитесь опытом, пжлста. В чем ведете разработку конфигурации?
>В конфигураторе
/тема

(0) Все это баловство. Слишком много связей и, в случае активной разработки, очень быстро изменяется.

Поэтому, самый дельный совет - (1).

(0) В голове самое наилучшее.

Бумажка и прочее требуется для доведения замысла до других разработчиков, при работе в команде.

Если они не умеют в конфигураторе видеть "описание самой конфы, ее логики, взаимосвязей"

(0) Принцип декомпозиции никто не отменял. Ну а если нужна групповая работа над архитектурой, то можно СППР, или Enterprise Architect, или Cradle RM, или System Architect.

(0) голова + бумага + камменты в коде. Как-то так...

(8) >> Слишком много связей и, в случае активной разработки, очень быстро изменяется.

Именно поэтому "бумажка" никак не подходит.

Удержать в голове все объекты и их взаимосвязи для конфигурации, включающей более одной подсистемы (раздела учета), нереально. Любые доработки и дальнейшие модификации такой системы будут выполняться в виде повторного изобретения того, что  уже и так в ней есть. Только лишь из-за того, что кто-то что-то забыл (не удержалось в голове).
Не говоря уже о случаях смены ключевых фигур проекта - архитектора(ов), консультанта(ов), методиста(ов), ведущего(их) программиста(ов).

(5) Сама 1с делает на ней

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

(14) да вот хрена лысого!
Давеча смотрел в демку СППР 2.0, так там напрочь отсутствует функция рисования функций. Они превратили СППР в инструмент для документирования готового, а не для проектирования. Проектируют они в чем-то другом. Возможно - в голове да на маркерной доске.

(12) Вот тут уже интересно. Расскажите, плиз, какого уровня у вас проекты.  Что вы такого разрабатываете, что нужна цела система контроля взаимосвязей?

*нужна целая... (далее по тексту)

(17) Виндовс разрабатывает

(0) Разработай конфигурацию для разработки конфигурации, а потом разрабатывай конфигурацию.

а по СППР посоветуйте  курсы/обучение

(20) а в чем проектировать конфигурцию для разработки конфигураций?

(22) Рекурсия!

(4) А что именно вы хотите проектировать? Среда -только инструмент. Предмет в чем у вас описан?

(13) +100500
Правда, наличие документации по взаимосвязям тоже не очень спасает, так как с ней нужно ознакомится. А кто ж это будет делать?)

(16) так документирование это самый востребованный функционал СППР

А я вот ощущаю нехватку инструмента для проектирования программного кода. Блок-схемы не предлагать.

(0) Trello + Confluence

(27) https://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258

Канбан доска (задачи и чек листы) / Trello / битрикс 24
Записи совещаний, бумага.

(28) а на славянском языке есть?

для сабжа в 1с есть очень полезная фиговина, называется "подсистемы"

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

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

(27) Код не надо проектировать, его надо создавать.
Используя, при этом, что-нибудь более адекватное, чем текст.

(30) Ага, на древнеславянском))
Если серьёзно, в 2002 году эту книгу издали на русском языке но перевод был отвратительный.
В 2014 и 2017 её переиздали, эти издания не смотрел, но переводчик тот же.
https://www.ozon.ru/context/detail/id/8747662/

(11) Когда до тиража доходит, комментов левых не должно быть (относящихся к какой-то там стадии проектирования). И чего тогда делать будешь?

(34) уж комменты выпилить и имена функций поменять-проще простого.

(35) Ты не понял. Чего тогда делать будешь с хранящейся в комментах структурой тиражной конфы, если в тиражной конфе эта информация затерта? Лазить в хранилище разработки?