Как Вы документируете доработки

[ushastik]

Уважаемый All, участвую в проекте, где сделаны довольно большие доработки, я бы сказал, разработки . Вопрос, в каком виде (надо / не надо) оформлять проектную документацию на них. Я понимаю, что код стандартных приложений не документирован, но по крайней мере он поддерживается производителем, в случае же оригинальных разработок "на заказ" не рискуем ли мы получить неподдерживаемо монстра через пару лет ? Что необходимо требовать в проектной документации, чтобы другой специалист смог это поддерживать ? Спасибо.

[Shark]

Документировать необходимо - это железно!

Мы ведем документацию в двух видах

1. Заполняем таблицу измененных элементов, с указанием разработчика, проекта, цели изменений
2. По данному FD оформляем AD, с указанием всех изменений в стандартном функционале + описание алгоритмов

FD и AD связанно храним в накопленном опыте.

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

Другое дело, когда работы ведуться в авральном режиме - тогда уже не до документации

[EVGL]

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

Что касается чисто технической документации, то, по моему опыту, таблицы с именами элементов только захламляют папку проекта. Из названия элемента или поля уже должно быть ясно, за что он отвечает. Пример: "xxxDocumentTable.InvoiceAmountCur" вместо "TabKr.Sum22". А проект со всеми элементами, оставленный в приложении, и перекрестные ссылки отметают дальнейшие вопросы. Для сложных разработок полезно иметь модель данных, нарисованную в каком-либо CASE-средстве.

[ushastik]

Спасибо большое. Буду знать, за что бороться