SlideShare a Scribd company logo
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
1
ФОРМИРОВАНИЕ УНИВЕРСАЛЬНЫХ ТРЕБОВАНИЙ
К ПОЛЬЗОВАТЕЛЬСКИМ ПРОГРАММАМ ПРИ ПОДГОТОВКЕ
СПЕЦИФИКАЦИИ НА ABAP-РАЗРАБОТКУ
Степанов Дмитрий Юрьевич
stepanov@mirea.ru, mail@stepanovd.com
«Московский государственный технический университет радиотехники,
электроники и автоматики» (МГТУ МИРЭА)
Аннотация: используя обобщенную структуру описания программ,
формулируются универсальные требования к пользовательским разработкам
для подготовки технической спецификации.
Ключевые слова: спецификация на разработку, ABAP, SAP, КИС.
UNIVERSAL REQUIREMENTS TO ABAP-PROGRAMS
WHILE PREPARING SOFTWARE MODULE SPECIFICATION
Dmitry Yu Stepanov
stepanov@mirea.ru, mail@stepanovd.com
Moscow state technical university of radio-engineering, electronics and automation
(MSTU MIREA)
Abstract: there is general program description structure considered in the
paper. Using proposed structure an approach to functional specification preparation
is suggested including universal requirements to client specific ABAP-programs.
Keywords: program specification, ABAP, SAP, ERP.
А когда нужно сделать разработку? Вчера. Подобная ситуация знакома как
начинающему, так и опытному консультанту SAP, независимо от
функционального направления. Насколько бы ни подходило стандартное
решение SAP заказчику, рано или поздно возникнет потребность в
незначительной доработке системы, пусть даже самой небольшой. Именно от
правильности написания спецификации на разработку зависит и скорость
реализации, и качество необходимой доработки.
Как правило, процесс подготовки и реализации спецификации колеблется
между двумя крайностями: функциональный консультант впервые или
достаточно редко готовит подобные документы, однако опыт ответственного
ABAP-разработчика позволяет сгладить неточности и шероховатости
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
2
технического задания. И, наоборот, даже самая искусно написанная
консультантом спецификация будет реализовываться чрезвычайно медленно и,
с большой вероятностью, ошибочно по причине отсутствия опыта со стороны
программиста.
На практике баланс в подготовке и реализации спецификации достигается
достаточно редко. Прослеживается следующая закономерность: чем меньше
времени потрачено на написание технического задания консультантом, тем
больше времени затрачивается на разъяснение программисту сути разработки и
отыскание алгоритмических ошибок в процессе тестирования. Сложность
программы, к сожалению, увеличивает трудоемкость тестирования разработки
и может привести к тому, что большая часть программы останется «черным
ящиком» как для функционального консультанта, так и для конечного
пользователя. Не зря говорится, что «пожар легче предупредить, чем
потушить».
Несмотря ни на что, приступаем к подготовке многострадальной
спецификации. Первая сложность, с которой сталкиваемся, – это реалистичная
оценка трудозатрат на формирование документа спецификации. Допустим, как-
то оценили, что дальше? Описываем требования заказчика и готовим тестовые
данные. Все? Разработка выполнена. Тестируем «2 + 2 = 4», верно. А вот
сколько будет «2 + 3»? Такого задания в спецификации описано не было. Тогда
в лучшем случае получим равенство «2 + 3 = 4». Сложность вторая –
доскональное описание алгоритмов, проверок и данных, пусть даже вполне
очевидных. Исправили, доработали. Тестируем, все верно, «2 + 3 = 5». А все ли
пользователи имеют полномочия на выполнение суммирования? Это третья, но
не последняя сложность. Знакомо?
Таким образом, приведенный выше пример иллюстрирует необходимость
формирования универсальных требований к разработкам без акцентирования
внимания на характере прикладной задачи. Предлагается применение
обобщенной структуры описания программ.
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
3
ЦЕЛИ И ЗАДАЧИ
Цель данной работы заключается в формировании универсальных
требований к пользовательским программам на языке SAP ABAP. Для
достижения поставленной цели решаются следующие задачи:
 рассмотрение обобщенной структуры описания программ;
 обзор требований к программным разработкам;
 апробация предлагаемых требований.
1. ОБОБЩЕННАЯ СТРУКТУРА ОПИСАНИЯ ПРОГРАММ
Запуская транзакцию в SAP-системе, мы имеем дело со стандартными и
пользовательскими программами. Стандартные программы входят в базовый
комплект поставки системы SAP и максимально интегрированы с прочими
приложениями. Пользовательские программы разрабатываются под конкретные
требования заказчика и часто содержат непродуманную логику взаимодействия
со стандартными компонентами SAP. Выделим разновидности
пользовательских разработок, следуя [1]:
 новые программы (X,Y,Z-программы);
 новые печатные формуляры (X,Y,Z-программы печати формуляров);
 новые отчеты (X,Y,Z-отчеты);
 расширения стандартных программ, формуляров и отчетов.
Все приложения имеют схожие составные части независимо от вида
пользовательской разработки, исключением являются лишь расширения. В
работе [2] предложена обобщенная структура описания разработок,
включающая:
 экран селекционных данных;
 экран отображения выбранных данных;
 экран результатов обработки выбранных данных.
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
4
Допустим, необходимо изменить текст определенных позиции документов
материалов. Селекционный экран программы служит своеобразным фильтром,
позволяющим ограничить начальную выборку данных, например, такими
параметрами как «Год», «Документ материала» и др. (рис.1а).
а)
5100000000
Документ
материала
Обработка документов материалов
2014Год
5100000006
Завод
Статус Документ Позиция
5100000000 10
5100000000 20
5100000001 30
5100000001 40
5100000002 20
5100000003 10
5100000004 10
Краткий текст
Сертификат №121
б) Обработка документов материалов
5100000005 20 №1, 2, 3
5100000006 20
Год
2014
2014
2014
2014
2014
2014
2014
2014
2014
Статус Документ Позиция
5100000000 10
5100000000 20
5100000001 30
5100000001 40
5100000002 20
5100000003 10
5100000004 10
Краткий текст
Сертификат №121
в) Обработка документов материалов
5100000005 20 №1, 2, 3
5100000006 20
Год
2014
2014
2014
2014
2014
2014
2014
2014
2014
Рисунок 1. Обобщенная структура описания пользовательской
программы: а) селекционный экран; б) экран отображения выбранных данных;
в) экран результатов обработки выбранных данных
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
5
Выбранные данные отображаются на следующем экране программы. Что
же это дает? Во-первых, проверку корректности селекции данных. Во-вторых,
возможность последующей обработки выбранных данных. В-третьих, при
отсутствии необходимости в отображении выбранных данных экран можно
скрыть от пользователя (рис.1б).
Вручную указав необходимые позиции документов материалов,
запускается процесс их изменения. Рис.1в иллюстрирует экран результатов
обработки выбранных данных.
2. ОПИСАНИЕ ТРЕБОВАНИЙ К ПОЛЬЗОВАТЕЛЬСКИМ
ПРОГРАММАМ В СПЕЦИФИКАЦИИ НА РАЗРАБОТКУ
Написать в спецификации, конечно же, можно очень многое, а забыть –
еще больше. Для исключения последнего воспользуемся обобщенной
структурой описания программ, тогда спецификация на разработку будет
включать следующие разделы:
 блок общей постановки задачи;
 экран селекционных данных;
 экран отображения выбранных данных;
 экран результатов обработки выбранных данных;
 блок тестовых данных.
Рассмотрим каждый из разделов спецификации подробнее и сформулируем
универсальные требования к реализуемым пользовательским программам.
Блок общей постановки задачи
Что, собственно говоря, не так, и какой подход предлагается для решения?
Ответы на данные вопросы должны содержаться в разделе общей постановки
задачи. Прочитав постановку задачи, человек, пусть даже не знакомый с
системой SAP, должен понять суть проблемы и уловить основные мотивы
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
6
подготовки документа. Например, можно воспользоваться следующей
структурой описания [3]:
 исходное поведение системы (модель AS IS);
 описание проблемной области;
 целевое поведение системы (модель TO BE);
 предлагаемое решение.
Излишняя детализация решения на данном этапе преждевременна и
необходима лишь для понимания предлагаемого подхода к решению. По
усмотрению разработчика может быть предложен иной подход к реализации
задачи. Значительно упрощает понимание как самой задачи, так и
предлагаемого решения описание, например, в графическом виде (рис.1).
Подготовка данного раздела закреплена целиком и полностью за
функциональным консультантом, в то время как описание последующих
блоков, за исключением тестовых данных, может находиться в сфере
ответственности разработчика.
Требования к селекционному экрану программы
Первый шаг – запуск программы на выполнение. Запустили транзакцию
«Обработка документов материалов», а сработала печать формуляра?
Неправильно, наименование транзакции должно отражать конечный результат
работы программы. Что, собственно, следует из определения транзакции [4].
Возвращаясь к приведенному примеру, корректнее было бы назвать
транзакцию «Печать формуляра».
Как обобщить программу, решая вполне конкретную задачу? Ответ,
никаких константных переменных. Константы выносятся в дополнительную
настройку [5]:
 добавив поля на селекционном экране программы;
 используя ракурс константных величин TWARV (тр. SM30);
 на основе собственной настроечной таблицы;
 при помощи пользовательских наборов (тр. GS01).
Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268
http://stepanovd.com/article_2014_4_design.html
7
Каждый из способов имеет свои сильные и слабые стороны. Например, вывод
всех возможных параметров на селекционный экран в значительной степени
отягощает понимание программы, однако можно воспользоваться вариантом
транзакции для скрытия части полей. Ракурс TWARV используется всеми
модулями системы SAP, что чревато переносом в продуктивную систему
«лишних» записей. Применение собственной настроечной таблицы исключает
последнее, однако требует трудозатрат по созданию нового объекта системы.
Возможность ведения лишь одного признака является ахиллесовой пятой
применения пользовательских наборов.
Имея ограниченные права, возможно ли увидеть все документы? Да.
Разрабатывая пользовательскую программу, необходимо позаботиться о
проверке полномочий непосредственно в самом тексте программы (рис.2а),
иначе максимум, что вы получите, проверку на код запускаемой транзакции
(рис.2б).
а)
б)
Рисунок 2. Объекты полномочий на основе:
а) прикладного компонента; б) кода транзакции
Таким образом, основными требованиями при описании селекционного
экрана пользовательской … Полный текст статьи доступен по ссылке:
http://stepanovd.com/article_2014_4_design.html?lang=RU.

More Related Content

PDF
Технология разработки программного обеспечения
PDF
Лабораторные практические работы
PDF
Технология разработки программного обеспечения
PDF
Рабочая учебная программа
PDF
Лекции и задания по рнр
PDF
презентация по дисциплине технология разработки программного обеспечения
PDF
технология разработки программного обеспечения
PPTX
ППК л2 2011
Технология разработки программного обеспечения
Лабораторные практические работы
Технология разработки программного обеспечения
Рабочая учебная программа
Лекции и задания по рнр
презентация по дисциплине технология разработки программного обеспечения
технология разработки программного обеспечения
ППК л2 2011

What's hot (17)

PDF
PDF
Сборник практических задании по Php
PDF
программа курса Управление проектами с помощью MS Project, 2013
PPTX
Внедрение CASE-технологий
PDF
Requirement modelling in software creation process
PDF
лек11 3
DOC
оп.05 основы программирования
PDF
Проектирование Программных Систем. Лекция 01
PDF
Модифицируемость программных систем
PDF
DDD: проблемы и решения при отражении модели предметной области в код
PDF
методическая разработка урока готово
PDF
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
PPT
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
PDF
613.программирование в visual с++ с использованием библиотеки mfc учебное по...
PDF
Статья «Анализ, проектирование и разработка корпоративных информационных сист...
PPTX
«трудности при разработке сложных распределённых систем на Java. способы реше...
PPTX
Создание презентаций
Сборник практических задании по Php
программа курса Управление проектами с помощью MS Project, 2013
Внедрение CASE-технологий
Requirement modelling in software creation process
лек11 3
оп.05 основы программирования
Проектирование Программных Систем. Лекция 01
Модифицируемость программных систем
DDD: проблемы и решения при отражении модели предметной области в код
методическая разработка урока готово
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
613.программирование в visual с++ с использованием библиотеки mfc учебное по...
Статья «Анализ, проектирование и разработка корпоративных информационных сист...
«трудности при разработке сложных распределённых систем на Java. способы реше...
Создание презентаций
Ad

Viewers also liked (8)

PPTX
Tips on How to Travel Cheap
PDF
McMichael THESIS
PDF
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
PDF
30001793235465_report
PDF
Semester Project 4: Projection of Expansion: Assens to Ejby
PPTX
Trizetto presentation, mike toney
PDF
SOS Brochure P
Tips on How to Travel Cheap
McMichael THESIS
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
30001793235465_report
Semester Project 4: Projection of Expansion: Assens to Ejby
Trizetto presentation, mike toney
SOS Brochure P
Ad

Similar to Статья «Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку» (20)

PPTX
методология Rad (46)
PPTX
Автоматизированное проектирование эис (Case технология)
PPTX
DDD - модель вместо требований
PDF
Domain-Driven Design: Модель вместо требований
PPTX
DDD requirements AnalystDays-2014 Tsepkov
PPS
ПВПС
PPT
Sep reqm-lec1
PDF
Практический подход к систематизации требований при проектировании информацио...
PPT
Trpo 8 проект_инерфейса
PPTX
20 объект. экранная форма
PDF
Issue 7-4-functionalspec
PPTX
Inroducing SAP ABAP - Presentation with basics SAP ABAP
PPS
лекция 6
PPTX
Ddd happy dev-2013-tsepkov
PPTX
разработка технического задания 1
PPTX
Лекция на тему "Разработка технического задания"
PPTX
разработка технического задания
PPT
Практический анализ по RUP
PPTX
Управление требованиями - это не только требования. Для CEE-SECR-2015. Анна А...
методология Rad (46)
Автоматизированное проектирование эис (Case технология)
DDD - модель вместо требований
Domain-Driven Design: Модель вместо требований
DDD requirements AnalystDays-2014 Tsepkov
ПВПС
Sep reqm-lec1
Практический подход к систематизации требований при проектировании информацио...
Trpo 8 проект_инерфейса
20 объект. экранная форма
Issue 7-4-functionalspec
Inroducing SAP ABAP - Presentation with basics SAP ABAP
лекция 6
Ddd happy dev-2013-tsepkov
разработка технического задания 1
Лекция на тему "Разработка технического задания"
разработка технического задания
Практический анализ по RUP
Управление требованиями - это не только требования. Для CEE-SECR-2015. Анна А...

More from ph.d. Dmitry Stepanov (20)

PDF
Учет расчетов: форс-мажор
PDF
Стратегия тестирования в проектах имплементации ERP-систем
PDF
Автоматизация подбора лекарственных препаратов.
PDF
Стартапы
PDF
Критическое мышление как база оптимального решения при внедрении корпоративны...
PDF
Годовой бухгалтерский отчет организации за 2021 год
PDF
Soft skills в проектах внедрения корпоративных информационных систем
PDF
Банкротство юридического лица: процедуры и учет на этапе конкурсного производ...
PDF
Банкротство юридического лица: процедуры и учет на этапе конкурсного производ...
PDF
Обзор существующих методик технического обслуживания и ремонта оборудования
PDF
Сторителлинг как новая технология подачи информации
PDF
Концепции, методы и способы миграции основных и переменных данных в КИС (част...
PDF
Концепции, методы и способы миграции основных и переменных данных в КИС (част...
PDF
Концепции, методы и способы миграции основных и переменных данных в корпорати...
PDF
Применение спиралевидной модели внедрения для роботизации больницы.
PDF
Краткий обзор изменений в правовом регулировании информационных систем и техн...
PDF
Учет льготных кредитов МСП и настройка его детализации в информационной систе...
PDF
Применение Agile Scrum для реализации автоматизированного рабочего места врач...
PDF
Применение Agile Scrum для реализации автоматизированного рабочего места врач...
PDF
Исследование и разработка проекта процессной информационной системы управлени...
Учет расчетов: форс-мажор
Стратегия тестирования в проектах имплементации ERP-систем
Автоматизация подбора лекарственных препаратов.
Стартапы
Критическое мышление как база оптимального решения при внедрении корпоративны...
Годовой бухгалтерский отчет организации за 2021 год
Soft skills в проектах внедрения корпоративных информационных систем
Банкротство юридического лица: процедуры и учет на этапе конкурсного производ...
Банкротство юридического лица: процедуры и учет на этапе конкурсного производ...
Обзор существующих методик технического обслуживания и ремонта оборудования
Сторителлинг как новая технология подачи информации
Концепции, методы и способы миграции основных и переменных данных в КИС (част...
Концепции, методы и способы миграции основных и переменных данных в КИС (част...
Концепции, методы и способы миграции основных и переменных данных в корпорати...
Применение спиралевидной модели внедрения для роботизации больницы.
Краткий обзор изменений в правовом регулировании информационных систем и техн...
Учет льготных кредитов МСП и настройка его детализации в информационной систе...
Применение Agile Scrum для реализации автоматизированного рабочего места врач...
Применение Agile Scrum для реализации автоматизированного рабочего места врач...
Исследование и разработка проекта процессной информационной системы управлени...

Статья «Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку»

  • 1. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 1 ФОРМИРОВАНИЕ УНИВЕРСАЛЬНЫХ ТРЕБОВАНИЙ К ПОЛЬЗОВАТЕЛЬСКИМ ПРОГРАММАМ ПРИ ПОДГОТОВКЕ СПЕЦИФИКАЦИИ НА ABAP-РАЗРАБОТКУ Степанов Дмитрий Юрьевич stepanov@mirea.ru, mail@stepanovd.com «Московский государственный технический университет радиотехники, электроники и автоматики» (МГТУ МИРЭА) Аннотация: используя обобщенную структуру описания программ, формулируются универсальные требования к пользовательским разработкам для подготовки технической спецификации. Ключевые слова: спецификация на разработку, ABAP, SAP, КИС. UNIVERSAL REQUIREMENTS TO ABAP-PROGRAMS WHILE PREPARING SOFTWARE MODULE SPECIFICATION Dmitry Yu Stepanov stepanov@mirea.ru, mail@stepanovd.com Moscow state technical university of radio-engineering, electronics and automation (MSTU MIREA) Abstract: there is general program description structure considered in the paper. Using proposed structure an approach to functional specification preparation is suggested including universal requirements to client specific ABAP-programs. Keywords: program specification, ABAP, SAP, ERP. А когда нужно сделать разработку? Вчера. Подобная ситуация знакома как начинающему, так и опытному консультанту SAP, независимо от функционального направления. Насколько бы ни подходило стандартное решение SAP заказчику, рано или поздно возникнет потребность в незначительной доработке системы, пусть даже самой небольшой. Именно от правильности написания спецификации на разработку зависит и скорость реализации, и качество необходимой доработки. Как правило, процесс подготовки и реализации спецификации колеблется между двумя крайностями: функциональный консультант впервые или достаточно редко готовит подобные документы, однако опыт ответственного ABAP-разработчика позволяет сгладить неточности и шероховатости
  • 2. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 2 технического задания. И, наоборот, даже самая искусно написанная консультантом спецификация будет реализовываться чрезвычайно медленно и, с большой вероятностью, ошибочно по причине отсутствия опыта со стороны программиста. На практике баланс в подготовке и реализации спецификации достигается достаточно редко. Прослеживается следующая закономерность: чем меньше времени потрачено на написание технического задания консультантом, тем больше времени затрачивается на разъяснение программисту сути разработки и отыскание алгоритмических ошибок в процессе тестирования. Сложность программы, к сожалению, увеличивает трудоемкость тестирования разработки и может привести к тому, что большая часть программы останется «черным ящиком» как для функционального консультанта, так и для конечного пользователя. Не зря говорится, что «пожар легче предупредить, чем потушить». Несмотря ни на что, приступаем к подготовке многострадальной спецификации. Первая сложность, с которой сталкиваемся, – это реалистичная оценка трудозатрат на формирование документа спецификации. Допустим, как- то оценили, что дальше? Описываем требования заказчика и готовим тестовые данные. Все? Разработка выполнена. Тестируем «2 + 2 = 4», верно. А вот сколько будет «2 + 3»? Такого задания в спецификации описано не было. Тогда в лучшем случае получим равенство «2 + 3 = 4». Сложность вторая – доскональное описание алгоритмов, проверок и данных, пусть даже вполне очевидных. Исправили, доработали. Тестируем, все верно, «2 + 3 = 5». А все ли пользователи имеют полномочия на выполнение суммирования? Это третья, но не последняя сложность. Знакомо? Таким образом, приведенный выше пример иллюстрирует необходимость формирования универсальных требований к разработкам без акцентирования внимания на характере прикладной задачи. Предлагается применение обобщенной структуры описания программ.
  • 3. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 3 ЦЕЛИ И ЗАДАЧИ Цель данной работы заключается в формировании универсальных требований к пользовательским программам на языке SAP ABAP. Для достижения поставленной цели решаются следующие задачи:  рассмотрение обобщенной структуры описания программ;  обзор требований к программным разработкам;  апробация предлагаемых требований. 1. ОБОБЩЕННАЯ СТРУКТУРА ОПИСАНИЯ ПРОГРАММ Запуская транзакцию в SAP-системе, мы имеем дело со стандартными и пользовательскими программами. Стандартные программы входят в базовый комплект поставки системы SAP и максимально интегрированы с прочими приложениями. Пользовательские программы разрабатываются под конкретные требования заказчика и часто содержат непродуманную логику взаимодействия со стандартными компонентами SAP. Выделим разновидности пользовательских разработок, следуя [1]:  новые программы (X,Y,Z-программы);  новые печатные формуляры (X,Y,Z-программы печати формуляров);  новые отчеты (X,Y,Z-отчеты);  расширения стандартных программ, формуляров и отчетов. Все приложения имеют схожие составные части независимо от вида пользовательской разработки, исключением являются лишь расширения. В работе [2] предложена обобщенная структура описания разработок, включающая:  экран селекционных данных;  экран отображения выбранных данных;  экран результатов обработки выбранных данных.
  • 4. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 4 Допустим, необходимо изменить текст определенных позиции документов материалов. Селекционный экран программы служит своеобразным фильтром, позволяющим ограничить начальную выборку данных, например, такими параметрами как «Год», «Документ материала» и др. (рис.1а). а) 5100000000 Документ материала Обработка документов материалов 2014Год 5100000006 Завод Статус Документ Позиция 5100000000 10 5100000000 20 5100000001 30 5100000001 40 5100000002 20 5100000003 10 5100000004 10 Краткий текст Сертификат №121 б) Обработка документов материалов 5100000005 20 №1, 2, 3 5100000006 20 Год 2014 2014 2014 2014 2014 2014 2014 2014 2014 Статус Документ Позиция 5100000000 10 5100000000 20 5100000001 30 5100000001 40 5100000002 20 5100000003 10 5100000004 10 Краткий текст Сертификат №121 в) Обработка документов материалов 5100000005 20 №1, 2, 3 5100000006 20 Год 2014 2014 2014 2014 2014 2014 2014 2014 2014 Рисунок 1. Обобщенная структура описания пользовательской программы: а) селекционный экран; б) экран отображения выбранных данных; в) экран результатов обработки выбранных данных
  • 5. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 5 Выбранные данные отображаются на следующем экране программы. Что же это дает? Во-первых, проверку корректности селекции данных. Во-вторых, возможность последующей обработки выбранных данных. В-третьих, при отсутствии необходимости в отображении выбранных данных экран можно скрыть от пользователя (рис.1б). Вручную указав необходимые позиции документов материалов, запускается процесс их изменения. Рис.1в иллюстрирует экран результатов обработки выбранных данных. 2. ОПИСАНИЕ ТРЕБОВАНИЙ К ПОЛЬЗОВАТЕЛЬСКИМ ПРОГРАММАМ В СПЕЦИФИКАЦИИ НА РАЗРАБОТКУ Написать в спецификации, конечно же, можно очень многое, а забыть – еще больше. Для исключения последнего воспользуемся обобщенной структурой описания программ, тогда спецификация на разработку будет включать следующие разделы:  блок общей постановки задачи;  экран селекционных данных;  экран отображения выбранных данных;  экран результатов обработки выбранных данных;  блок тестовых данных. Рассмотрим каждый из разделов спецификации подробнее и сформулируем универсальные требования к реализуемым пользовательским программам. Блок общей постановки задачи Что, собственно говоря, не так, и какой подход предлагается для решения? Ответы на данные вопросы должны содержаться в разделе общей постановки задачи. Прочитав постановку задачи, человек, пусть даже не знакомый с системой SAP, должен понять суть проблемы и уловить основные мотивы
  • 6. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 6 подготовки документа. Например, можно воспользоваться следующей структурой описания [3]:  исходное поведение системы (модель AS IS);  описание проблемной области;  целевое поведение системы (модель TO BE);  предлагаемое решение. Излишняя детализация решения на данном этапе преждевременна и необходима лишь для понимания предлагаемого подхода к решению. По усмотрению разработчика может быть предложен иной подход к реализации задачи. Значительно упрощает понимание как самой задачи, так и предлагаемого решения описание, например, в графическом виде (рис.1). Подготовка данного раздела закреплена целиком и полностью за функциональным консультантом, в то время как описание последующих блоков, за исключением тестовых данных, может находиться в сфере ответственности разработчика. Требования к селекционному экрану программы Первый шаг – запуск программы на выполнение. Запустили транзакцию «Обработка документов материалов», а сработала печать формуляра? Неправильно, наименование транзакции должно отражать конечный результат работы программы. Что, собственно, следует из определения транзакции [4]. Возвращаясь к приведенному примеру, корректнее было бы назвать транзакцию «Печать формуляра». Как обобщить программу, решая вполне конкретную задачу? Ответ, никаких константных переменных. Константы выносятся в дополнительную настройку [5]:  добавив поля на селекционном экране программы;  используя ракурс константных величин TWARV (тр. SM30);  на основе собственной настроечной таблицы;  при помощи пользовательских наборов (тр. GS01).
  • 7. Актуальные проблемы современной науки. 2014. № 4 (78). c.258-268 http://stepanovd.com/article_2014_4_design.html 7 Каждый из способов имеет свои сильные и слабые стороны. Например, вывод всех возможных параметров на селекционный экран в значительной степени отягощает понимание программы, однако можно воспользоваться вариантом транзакции для скрытия части полей. Ракурс TWARV используется всеми модулями системы SAP, что чревато переносом в продуктивную систему «лишних» записей. Применение собственной настроечной таблицы исключает последнее, однако требует трудозатрат по созданию нового объекта системы. Возможность ведения лишь одного признака является ахиллесовой пятой применения пользовательских наборов. Имея ограниченные права, возможно ли увидеть все документы? Да. Разрабатывая пользовательскую программу, необходимо позаботиться о проверке полномочий непосредственно в самом тексте программы (рис.2а), иначе максимум, что вы получите, проверку на код запускаемой транзакции (рис.2б). а) б) Рисунок 2. Объекты полномочий на основе: а) прикладного компонента; б) кода транзакции Таким образом, основными требованиями при описании селекционного экрана пользовательской … Полный текст статьи доступен по ссылке: http://stepanovd.com/article_2014_4_design.html?lang=RU.