Цитата:
Сообщение от
Yoil
На самом деле надо и 1) и 2).
Касаемо 1): требуйте, чтоб в списке версий в обджект дизайнере на каждом модифицированном объекте стоял код задачи (например, если объект модифицировался под задачи А01, М23 и ЕН12, то в списке версий должно быть перечисленно А01;М23;ЕН12).
В самом коде в объекте тоже доработки должны быть выделены
Во-первых, в триггере Documentation написано что-нибудь вроде
26/09/07 Mega}{aker V03 Правил функцию CheckCreateAndDestroyAll
Далее, в самой функции CheckCreateAndDestroyAll модифицированный код выделен как-нить наподобие
// V03 26/09/07 Mega}{aker >>
код...
// V03 26/09/07 Mega}{aker <<
А вот в пункте 2), в перечне, должно быть уже описание задачи с кодом V03, A01 и т.д.
я бы еще просила писать словами зачем нужен этот новый код. Но здесь не рекомендую перебарщивать и требовать комментарии на обнуление переменных. А вот если разработчики замутили модификацию со сложным алгоритмом, циклами и пр. Словесные комментарии просто необходимы. Я обычно следую правилу: если с одного взгляда на строку (или кусок взаимосвязанных строк) программного кода понятно, что она делает, то комментарий не пишем, если нет, и требуется просмотреть код и подумать головой, то пишем обязательно....
Поставщики могут отказаться писать комментарии, ну тогда пусть алгоритмы дают или проверяйте и внимательно читайте ТЗ (они-то уж у Вас должны быть
). ТЗ не должны отличаться от разаработанной функциональности.
Цитата:
Сообщение от
Yoil
Другое дело, не факт, что поставщики будут все это делать...
Ага, если в договоре не прописано, то отказываться будут. Рекомендую ссылаться на стандарты разработки в системе Navision. Есть и такие. Тогда все, что описал Yoil получите.
А список доработок, скорее всего должен быть предусмотрен договором.