Комментарии по теме

«Ко­рре­кти­ро­вка таблиц базы данных с помощью ABAP»
Олег Точенюк:
Андрей а вам никто никогда не говорил, что обновлять таблицы базы данных SAP категорически запрещено, независимо от того чем обусловлены такие желания. Свои Z-таблицы, да сколько угодно, но......
«Практика освоения ABAP CDS для не­про­гра­мми­сто­в. Часть 1»
Михаил Вронский:
Большое спасибо за статью. Написана хорошим языком, даны правильные формулировки - с полнотой и логической последовательностью.
«Тра­нза­кция SM02: сообщения в SAP системе»
Олег Башкатов:
С помощью ФМ TH_POPUP можно отправить сообщение конкретному пользователю :-)

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

ABAP начинающим

21 октября 2020, 23:34

Практически каждый SAP-новичок, пришедший на проект внедрения ERP-системы, сталкивается с задачей написания функциональной спецификации и дальнейшего тестирования ABAP-разработки. Казалось бы, задача весьма несложная, но не для специалиста, только ступившего на путь SAP. Конечно, никто не доверит SAP-новобранцу подготовку по-настоящему сложной спецификации, поэтому, как правило, на них возлагается один из самых простых с технической точки зрения видов разработки – печатные формуляры (F по категоризации RICEFW). В то же время, эти формуляры являются самыми трудоёмкими для тестирования и поддержки - малейшее изменение в реализации бизнес-процесса или функции приведёт к неработоспособности алгоритмов выборок.

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

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

Функциональная спецификация согласуется с представителями бизнеса. Последние не всегда, вернее сказать, никогда, не вдаются в технические детали решения, описанные в спецификации. Спрашивается - как сделать так, чтобы они «нашли» себя, вернее, свои требования в документе? На мой взгляд, правильным будет включение в спецификацию описания исходных требований и верхнеуровневое решение с использованием моделей AS-IS и TO-BE.

Я перечислил только несколько наиболее критичных моментов, которые необходимо учесть при создании функциональной спецификации. Информацию на эту тему можно найти и в интернете, в качестве примера приведу статью по подготовке ABAP-спецификаций. Однако наиболее правильная картина планирования, подготовки и тестирования спецификации может сложиться лишь при внимательном изучении практических примеров, в частности, ранее подготовленных и реализованных спецификаций на ABAP-разработки. Последнее будет показано в рамках мастер-класса «Функциональная спецификация на разработку SAP-программ для новичков: от планирования до подготовки на примере отчетов, интерфейсов и программ обработки».

Будет интересно!

Дмитрий Степанов