Документирование изменений в конфигурации #630994

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

В свое время все доработки снеговика вел только в хранилище там и писал всякие примечания к версиям. Потом надоело, в коде только коментю.

мне хватает вордовского файла

лень ну и чтобы враги недогадались чего я там на г0внокодил..

вычисляется на раз, это не клюшки

вот по этому и не документирую :)

собираюсь вести. Уже года два как((( Но лень сильнее

а что есть такие продукты!? ТЗ в ворде + Визио

Зачем что-то придумывать, если есть отчет по изменениям в конфигураторе

5 лет назад, еще во время работы в Рарусе, была самописка на клюшках, без нее учитывать изменения во всех конфах было бы нереально. Сейчас самописка на УФ.

Стараюсь вести учет по тикетам в Jire, при помещении в хранилище в комментах ставлю № и наименование тикета, + html описание изменений в юзер-режиме, для оповещения пользователей.

Была бы полноценная работа с хранилищем, цены бы не было. Сделали бы бранчи, тикеты прям в конфигураторе - цены бы не было. Я б даже купил.

Пардон за повторение.

а картинки вы в html  пихаете?

Интересно в чем клюшки? Получалось ли перехватывать изменения, которые внесены в конфигураторе?

Делал на основе Выглядит примерно так: и

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

формы то не управляемые. неинтересно..

Хех, сложно html поле перенести на управляемую форму? :)) Ну, мы работаем в тоооолстом клиенте, нам пофиг на плюшки)

Какая то мелка доработка не нуждается. но если вы пишете некую подсистему, пересекающуюся с типовым функционалом, то еще как надо.

Ибо через полгода уже забудешь что там наворотил

жгу камменты в коде

Для левых конфигураций использую ОбщийМакет, где по порядку нумеруются задачи выполненны (без планов и пожеланий,  только то что сделанно). В комментариях пишу номер задачи типа #123.

Дайте ссылку где почитать про документирование изменений при разработке ПО.

Нет, все руками вносили

Комменты в коде по конкретным изменениям, табличка в общем макете с общим описанием изменений, заявителями, датами исполнения. Аналогично в доп. обработках/отчетах.

подниму ветку

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

дополнительный функционал "старается" быть описанным в обход типовой конфигурации - а доп функционал как документируете?

просто коммент вставляем со своим ником и датой.

см п - специально же указал. Составляется карта изменений и хранится в виде отдельного макета