А когда нужно сделать разработку? Вчера. Подобная ситуация знакома как начинающему, так и опытному консультанту SAP, независимо от функционального направления. Насколько бы ни подходило стандартное решение SAP заказчику, рано или поздно возникнет потребность в незначительной доработке системы, пусть даже самой небольшой. Именно от правильности написания спецификации на разработку зависит и скорость реализации, и качество необходимой доработки. Как правило, процесс подготовки и реализации спецификации колеблется между двумя крайностями: функциональный консультант впервые или достаточно редко готовит подобные документы, однако опыт ответственного ABAP-разработчика позволяет сгладить неточности и шероховатости технического задания. И, наоборот, даже самая искусно написанная консультантом спецификация будет реализовываться чрезвычайно медленно и, с большой вероятностью, ошибочно по причине отсутствия опыта со стороны программиста.
На практике баланс в подготовке и реализации спецификации достигается достаточно редко. Прослеживается следующая закономерность: чем меньше времени потрачено на написание технического задания консультантом, тем больше времени затрачивается на разъяснение программисту сути разработки и отыскание алгоритмических ошибок в процессе тестирования. Сложность программы, к сожалению, увеличивает трудоемкость тестирования разработки и может привести к тому, что большая часть программы останется «черным ящиком» как для функционального консультанта, так и для конечного пользователя. Не зря говорится, что «пожар легче предупредить, чем потушить».
Несмотря ни на что, приступаем к подготовке многострадальной спецификации. Первая сложность, с которой сталкиваемся, – это реалистичная оценка трудозатрат на формирование документа спецификации. Допустим, как-то оценили, что дальше? Описываем требования заказчика и готовим тестовые данные. Все? Разработка выполнена. Тестируем «2 + 2 = 4», верно. А вот сколько будет «2 + 3»? Такого задания в спецификации описано не было. Тогда в лучшем случае получим равенство «2 + 3 = 4». Сложность вторая – доскональное описание алгоритмов, проверок и данных, пусть даже вполне очевидных. Исправили, доработали. Тестируем, все верно, «2 + 3 = 5». А все ли пользователи имеют полномочия на выполнение суммирования? Это третья, но не последняя сложность. Знакомо? Таким образом, приведенный выше пример иллюстрирует необходимость формирования универсальных требований к разработкам без акцентирования внимания на характере прикладной задачи. Предлагается применение обобщенной структуры описания программ.
Цель и задачи
Цель данной работы заключается в формировании универсальных требований к пользовательским программам на языке SAP ABAP. Для достижения поставленной цели решаются следующие задачи:
- рассмотрение обобщенной структуры описания программ;
- обзор требований к программным разработкам;
- апробация предлагаемых требований.
1. Обобщенная структура описания программ
Запуская транзакцию в SAP-системе, мы имеем дело со стандартными и пользовательскими программами. Стандартные программы входят в базовый комплект поставки системы SAP и максимально интегрированы с прочими приложениями. Пользовательские программы разрабатываются под конкретные требования заказчика и часто содержат непродуманную логику взаимодействия со стандартными компонентами SAP. Выделим разновидности пользовательских разработок, следуя [1]:
- новые программы (X,Y,Z-программы);
- новые печатные формуляры (X,Y,Z-программы печати формуляров);
- новые отчеты (X,Y,Z-отчеты);
- расширения стандартных программ, формуляров и отчетов.
Все приложения имеют схожие составные части независимо от вида пользовательской разработки, исключением являются лишь расширения. В работе [2] предложена обобщенная структура описания разработок, включающая:
- экран селекционных данных;
- экран отображения выбранных данных;
- экран результатов обработки выбранных данных.
Допустим, необходимо изменить текст определенных позиции документов материалов. Селекционный экран программы служит своеобразным фильтром, позволяющим ограничить начальную выборку данных, например, такими параметрами как «Год», «Документ материала» и др. (рис.1а).
Рис. 1. Обобщенная структура описания пользовательской программы: а) селекционный экран; б) экран отображения выбранных данных; в) экран результатов обработки выбранных данных
Выбранные данные отображаются на следующем экране программы. Что же это дает? Во-первых, проверку корректности селекции данных. Во-вторых, возможность последующей обработки выбранных данных. В-третьих, при отсутствии необходимости в отображении выбранных данных экран можно скрыть от пользователя (рис.1б). Вручную указав необходимые позиции документов материалов, запускается процесс их изменения. Рис.1в иллюстрирует экран результатов обработки выбранных данных.
Полный текст статьи: http://stepanovd.com/science/article/26-2014-4-design