Maksimus написал:
В принципе, наверно, достаточно будет ответить на эти вопросы и можно будет подвести итог по подготовке проектной команды к внедрению
Попробуем сформировать не крупный текст для формирования окончательных выводов.
Вопросы подготовки основной группы уже можно пропустить - не мало обсудили, да и особых разногласий не было!
По разработчикам - почти сошлись на уровне знакомства с системой в рамках sap01.
Осталось определиться с ТЗ.
Какие ж они бывают? Очень разные.
1. Постановщик и разработчик одно лицо - достаточно редкий случай, но я такое встречал.
Тогда, как любил шутить "Вечерний квартал" о Шуфриче - "министр чрезвычайных ситуаций полного цикла - сам создает проблему, сам ее решает". Вот и в случае, когда постановщик и разработчик одно лицо - ТЗ может и не быть совсем, но если в этой цепочке присутствует некто "Заказчик", который минимум должен получить удовлетворение результатом, а максимум - оплатить труд, стоит сформировать ТЗ. Но ТЗ в этом случае сосредотачивается вокруг двух разделов:
А) Определение с какими параметрами разработка запускается;
Б) Интерфейс, который предоставляется пользователю;
В) Что является результатом.
2. Разработчик профессионал в функциональном направлении.
В этом случае ТЗ может быть сформировано в одно-два предложения, далее РЕАЛЬНЫЕ примеры:
А) Текущая сводная задолженность по дебиторам/кредиторам общей суммой (раздельно по Дт., Кт.) и разложенная по срокам возникновения (сроки - до 30 дней, от 31 до 60, от 61 до 90, от 91 до 180, свыше 180). Сводную задолженность формировать по связанным в учетных записях дебиторах/кредиторах. Любая указанная сумма по требованию представляется в развернутом до документа виде, позволять проваливаться в документ. Проверка полномочий - просмотр документов дебиторов и кредиторов.
Б) Предыдущий отчет сделать не по текущей задолженности, а с возможностью задавать отчетную дату.
3. Нормальный разработчик.
Самый стандартный случай - формализации подлежит полный перечень всех параметров запуска разработки с конкретным указанием parameters or select-option. Обязательно указываются все предполагаемые к использованию таблицы. Если связь между таблицами идет по совпадающим полям (типа knb1-kunnr = kna1-kunnr) то такие связи не указываются. Если связь требует более сложных условий стоит их прописать
(Через таблицу CSSL связываемся с таблицей COST, где определяем тариф операции. В таблицу CSSL заходим полным ключом: KOKRS = VBRP-KOKRS; KOSTL = определяем из рабочего места, LSTAR = AFRU-LEARR; GJAHR = Год с поля AFRU-BUDAT. ). Обязателен раздел проверки полномочий, а если разработка является не отчетом, а вызывает своим выполнением какие-либо действия - подробнейшим образом описываются все проверки, которые должны быть выполнены ДО запуска основной части разработки. Иногда (часто) стоит формализовать сразу все сообщения, которые конечный пользователь получит при не выполнении той или иной проверки.
4. "Кодер".
Все, что было указано для нормального разработчика + максимальная формализация полей, их связей, последовательностей обработки (Стоимость Основного средства на первое января отчетного года формируется по данным таблицы ANLC – Поля значений Основного средства. Первоначальная стоимость = ANLC-KANSW - Первоначальная стоимость нарастающим итогом + ANLC-KAUFW - Повышение восстановительной стоимости нарастающим итогом; Начисленная амортизация = ANLC-KNAFA - Типовая амортизация нарастающим итогом + ANLC-KSAFA - Особая амортизация нарастающим итогом + ANLC-KAAFA - Внеплановая амортизация нарастающим итогом + ANLC-KAUFN - Корректировка типовой амортизации с повыш. коэффициентом НИт).
Искренне надеюсь, что примеры различных вариантов ТЗ полностью продемонстрировали все их разновидности.
Теперь о реальных проблемах, которые могут возникнуть (и возникают) из-за поверхностного знакомства разработчиков с системой, из-за их доверия постановщику. В первую очередь все проблемы возникают из-за того, что системы разработки слишком далеки от продуктивных систем по наполнению информацией и если в системе разработки находится порядка 50 учетных записей дебиторов/кредиторов - то разработчику совершенно все равно с какой стороны начинать поиск дебиторов/кредиторов для их последующей связи по налоговым реквизитам. Вот только, когда в Продуктивной системе оказывается 1 000 кредиторов и 100 000 дебиторов - тут уж разница огромная в направлении подхода. Но такие случаи крайне редки.
Намного больше проблем возникает при отладке в реальных условиях связок select/loop - увы, даже на ОЧЕНЬ похожих системах это работает порой крайне по разному. Даже продуктивная система и восстановленная из резервной копии на аналогичном железе продуктивная система дают разные результаты - ведь на копии не возможно повторить нагрузку от пары сотен активных пользователей. Вот и получается, что описанный в ТЗ последовательный сбор данных, их доукомплектация могут быть реализованы разными методами - от тупого следования по ТЗ, до реальных попыток постараться максимально комбинировать опробованные на Продуктивной системе методы. Причем, чаще лучший результат дает именно их комбинация.
Тут выход один - реальный опыт разработчика! Именно реальный и именно на конкретной системе, где впоследствии и будет постоянно использоваться разработка!