Добрый день! Возможно, заголовок не совсем соответствует сути данной темы, но есть весьма актуальная проблема и хотелось бы ознакомиться с вашим опытом организации процесса управления изменениями в SAP-системе. Если тема поднималась ранее, то прошу кинуть в меня ссылкой. Итак, классика. 3 системы: DEV->QAS->PRD с настроенным транспортом. В системе разработки (DEV) производятся настройки, разработка программного кода и предварительное тестирование. В системе контроля качества (QAS) производится эталонное тестирование и обучение. В продуктивной системе (PRD) производится промышленная эксплуатация ПО.
В идеальной бизнес среде существует циклы в последовательности: разработка - тестирование - эксплуатация - разработка и т.д. (не рассматриваю возвращение на доработку из тестирования). На практике задачи по доработке поступают одна за другой, при этом они имеют разный приоритет. От приоритета зависит очередность разработки и тестирования. Трудоемкость и срок как правило не учитывается. Поэтому зачастую цикл нарушается и возникает следующие ситуации (утрировано): I. Объект А в PRD. 1. Объект А изменен в DEV по задаче 1, становится A’, далее транспортный запрос деблокируется и переносится в QAS. 2. Объект А’ изменен в DEV с высшим приоритетом по задаче 2. Становится А’’. Транспортный запрос деблокируется и переносится в QAS. В соответствии с приоритетом, тестирование функциональности объекта A’ останавливается и производится тестирование функциональности объект A’’. Тестирование успешно – подлежит переносу в PRD. Однако функциональность объекта A’ не прошла эталонного тестирования и не должна быть перенесена в PRD. Что делать с A’, а точнее с его запросом? II. Объект B в PRD. 1. Объект B изменен в DEV по задаче 1, становится B’. 2. Объект B изменен в DEV с высшим приоритетом по задаче 2, становится B’’ в том же транспортном запросе. В соответствии с приоритетом, производится тестирование функциональности объекта B’’. Тестирование успешно – подлежит переносу в QAS. Что делать с изменениями объекта B’? Ответ на вопрос у меня есть - в нашем случае, это "пляска с бубном", манипуляции с транспортными запросами, зачастую нарушение принципов разработки в одной системе, т.к. приходится исправлять объекты в системе QAS, для того, чтобы не переносить в PRD не протестированную функциональность, что, разумеется, не может положительно сказаться как на производительности процесса изменений (приходится вручную перебрасывать объекты транспортных запросов, комментировать не уместный программный код и т.д.), так и на стабильности программного кода. Проблема, очевидно, в дисциплине процесса имплементации разработок. Но бизнес не желает дисциплинироваться и, по-правде говоря, имеет на это право, т.к. обеспечивает фин. ресурсом и заказывает музыку. --------------------------------------------------------------------------------------------------- Могли бы вы описать как в вашем случае реализуется многопоточная разработка? Спасибо!
|
|