Уважаемые, поделитесь вашими мыслями.

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

Таск-трекер? Не, не слышал...

http://catalog.mista.ru/public/1179638/
я в таком виде сделал :)
автоматически создаётся документация,
чтоб отмазаться от начальства :)

(1) Таск-трекер?

Вопрос не в том, как вести эти изменения "для себя". Вопрос в том - есть ли стандарт для описания измененного функционала?

Как оформить описание сделанных изменений так, чтобы заказчик 1. Понимал, что у него внедрено (описание предметной области). 2. Чтобы разработчик, придя к этому заказчику, воспользовавшись этим описанием, +- понимал как проводить обновления типового функционала, как продолжать разработку нетипового (описание для разработчика).

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

(4) Спасибо. У вас регламенты идут как приложения к техзаданиям?

(4)
> вещи комментируем прямо в коде.
Ну вот садится новый разработчик обновлять и каждый раз ему морщить лоб почему здесь такая строчка кода и как его срастить с типовой...
Есть ведь еще аспект - тестирование после обновления. Хочется отдать конфигурацию, которая не просто обновлена, но и протестирована по кускам функционала, который нетиповой, по которому возможны ошибки после обновления или после добавления изменений.

(4) >в приложениях в регламенты.

А как это выглядит?

(6) Ты уточни, речь про тиражный продукт или кастомизацию? Весьма разные подходы.

(7) Приложение 1. Регламент информационного обмена баз данных ...

Приложение N Печатные формы документов, журналов, отчетов.
и т.д.

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

(8) Нет, речь не про тиражный продукт.
(10) "при обновлениях - трагедия, то стоит от этого отказаться"
Трагедия - неэффективное расходование времени.
"я слышал некоторым даже нравится копаться в чужом... коде)"
А про тех, кому нравится платить за непрогнозированное время при копании чужого кода - слышали?

(11) если мы говорим про оптимизацию с точки зрения тех кто платит - то это стоит немалых трудозатрат. вам понадобится у себя вести тех документацию клиента, создать базу знаний, регистрировать все тикеты и отчеты по исполнению, а главное заставить тех кто эти тикеты закрывает писать подробные отчеты по изменениям и посадить менеджера контролировать эту отчетность. вам нужен будет специалист который знает программный продукт лучше любого продвинутого пользователя заказчика который сможет уточнить проблему, найти решение и закрывать 80-95% обращений без передачи их разработчикам.

короче полноценный аутсорс, несколько линий поддержки, все по взрослому.

Короч. Вопрос не про организацию оперативной разработки.

Вопрос про описание программного продукта. ПП уже есть. Заказчик хочет иметь описание продукта, которым он владеет. Разработка велась на базе типовой, нужно описание того, что внедрено сверху.

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

Причем должно быть описание и для, условно, пользователя (это описание можно сделать в документах, структура которых похожа на техзадание по ГОСТу, разделяя эти описания по рубрикам), и для разработчика - какие объекты изменены, в рамках какой логической модели.

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

Заранее всем спасибо за любые соображения на эту тему.

(14) ГОСТы есть и для "руководства пользователя", и для "руководства программиста".

(15) Стандарты безусловно есть, внутренние. В базе ИТС я их не встречал. Но глядя на структуру документации к типовым, их несложно увидеть.

(17) Да? Номер ГОСТа для описания такого руководства "для разработчика" можно?

(18) 34

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

(20) " поэтому клиенты как правило довольствуются устным объяснением, ибо письменное недешево."
- угу.
причем в письменном варианте хотят чтобы было написано где находится кнопка "сделать всё"..

(21) А в этом случае приходится давать ссылку:

http://button.dekel.ru/

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

По идее, есть такая СППР. Ее на сайте в ИТС можно увидеть.

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

(23) "По идее, есть такая СППР."

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

"Детализация функций системы до уровня объектов метаданных является творческим процессом и не может быть формализована." из  главы 4.4. "Проектирование объектов метаданных" как бы явно говорит, что стандарта нет. И связь между логической моделью и архитектурой проекта устанавливается "творчески"...

(0) самая лучшая документация это код. Если код хорошо написан, то он сам расскажет, что он делает

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

(24) мало того, что аутсорсеры говорят о такой практике ее применения, но этого же никто не делает "задним числом".

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

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

(26) А их мало еще и потому, что в 80% практической работы ими никто не интересуется. Я пытался себя предлагать одно время в таком качестве. Спроса просто нет. На фоне обычных 1с-ников тех-писателей никто и никогда не ищет.

(14) "(трудился и его отдел, и фирмы-аутсорсеры, последовательно документация не велась" - в этом ответ на твой вопрос. Ты не можешь гарантировать,что ПП не изменялся кем то еще. Провели вы аудит, описали изменения. Завтра директор заказал доработку у франча и тот внес изменения и описание не сделал. Данные в документации актуальность потеряли. Если у заказчика нет человека, который контролирует все изменения, то это мартышкин труд

(0) Если кратко-изучай,тестируй и описывай. Не ясно кому это надо и кто за это заплатит. Волшебной кнопки на эту тему нет, от слова "совсем"

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

(25) позвольте не согласиться. Идет постоянная борьба между наглядность и функциональностью. То что хорошо читается, практически всегда неоптимально)

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

(0) лично мне нравится так: пишем комментарий в коде: дату, кто сделал, номер задания во внешней системе учета задач.

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

(35) А если уже и 1с не доступна?

(33) Тогда я прошу их декомпозировать задачу...

(36) просто мне попадалось такое. База 1С. Перепаханая вдоль и поперек УПП. И куча пометок - задача такая, тогда-то, такой-то.
Спрашиваю - и где оно? Ответ - а нету. Аутсорсерам регали задачи в их таск-деске и все было нормально. Потом договор с ними закончился и они ушли.

(38) А почему их отпустили без бекапа?

(39) как ты представляешь передачу бэкапа внутренней системы учета задач аутсорсера? в которой помимо этого заказчика могут быть десятки (или сотни) других?
видимо такие люди договоры заключали... что остались без документации и без списка задач/описаний решений.

(40) Вообще-то задачи заказчика являются собственностью заказчика...

(41) вот он и сделал с этой собственностью то, что ничего не сделал :-)

(0) "Были ли у вас заказы на описания изменений, сделанных в конфигурациях заказчика? В каком виде вы делали и предоставляли эти описания заказчику?"- по сути это перелопатить весь механизм и собрать заново. По трудозатратом примерно столько же, сколько написание самого алгоритма. Сильно сомневаюсь, что заказчик захочет этого.
Вообще, мне кажется, подобные запросы появляются тогда, когда меняется команда разработки и новая "не тянет". Тогда идут попытки перевести с одного языка (код) на другой более понятный. Хотя для разработчика код должен являться родным языком.  Бывает такое, что в ходе разработки были допущены ошибки или умышленные ограничения, но тут надо смотреть на исходное задание. Было ли оно и на сколько формализовано.

(34) лично мне нравится так: пишем комментарий в коде: дату, кто сделал, номер задания во внешней системе учета задач.
Так много аутсорсеров работает. На сегодняшний момент, наверное, это вершина педантичности, потому что некоторые не учитывают изменения вообще никак.
(43)Да? А вот у меня такой чуйство, что такая документация должна быть вообще у всех заказчиков, у кого велась собственная разработка.

Хотя...
Дожили. Теперь надо думать, как автоматизировать учет автоматизации.

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

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