Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1)

Подробности

Опубликовано: 08.09.2019 10:26

Автор: Степанов Дмитрий Юрьевич

Просмотров: 31029

Аннотация: в работе рассматривается процедура Fit/Gap-анализа и последующее оценивание разработок, описывается RICEF-классификация и принципы проектирования программ, дается структура и содержание функциональной спецификации на разработку на примере системы SAP ERP, вводятся типовые функциональные требования для отражения в документе спецификации. 
Скачать: PDF (статья, части 1, 2), PDF (выпуск №7).
Ключевые слова: спецификация на разработку программного продукта, спецификация на разработку программного обеспечения, ABAP-спецификация, техническая спецификация на разработку, SAP спецификация на разработку, техническое задание на доработку SAP, задание на разработку, функциональная спецификация SAP, спецификация на разработку ABAP, разработка по спецификации SAP.

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.

Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2].

К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.

Цель работы состоит в рассмотрении типовой структуры и содержания спецификации на доработку информационных систем, особенностей проектирования приложений и их отражения в документе спецификации, а также формировании универсальных требований к разрабатываемым программам. Для наглядности приводятся практические примеры из ERP-системы от компании SAP AG. Статья дополняет и расширяет содержание работ [8, 9], призвана восполнить пробелы ERP-аналитиков и консультантов при подготовке функциональной спецификации на разработку пользовательских программ. Реализация вышеуказанной цели потребует проработки следующих вопросов:

• Fit/Gap-анализ и оценивание разработок;
• RICEF классификация разработок и принципы проектирования программ;
• моделирование приложения и подготовка к написанию спецификации;
• структура и содержание спецификации на разработку;
• функциональные требования и их отражение в спецификации;
• обработка спецификации после ее реализации.

1. Fit/Gap-анализ и оценивание разработок

1.1. Проведение Fit/Gap-анализа 

Кроме того, запускается фоновая задача по планированию материалов и отслеживаются результаты её работы. В случае выявления некорректно созданных документов после запуска ROP, идентифицируется причина и устраняются последствия. Чаще всего причинами ошибочно созданных документов являются несовершенство введения данных или ошибки пользователей при реализации процессов в КИС. Выполнив несколько раз упомянутые активности, ответственные пользователи получают опыт, позволяющий обрабатывать большие объёмы данных при последующем увеличении числа планируемых по ROP материалов.

Анализ, проектирование, конфигурирование и доработка, а также тестирование и внедрение ERP-системы на предприятии потребуют от полу года до полутора лет. Именно поэтому ведется группирование ключевых событий, работ и задач на этапы, уровни и команды, о чем подробно рассказывается в статье [10]. Выделение уровней имплементации КИС соответствует классическому подходу к описанию бизнес-архитектуры предприятия, дополненному активностями по управлению изменениями и непосредственно проектом (рис.1).

На уровне изменений решаются задачи оценивания численности человеческого персонала, его обучения работе с ERP-системой, а также перехода к продуктивному использованию КИС как с технической, так и бизнес точек зрения. Уровень проекта обеспечивает планирование, контроль выполнения и корректировку отклонений в ходе реализации задач всех уровней [11]: процессы, данные, приложения, техника и изменения.

Потребность в доработке информационной системы изначально определяется на этапе анализа, в последующем описывается на фазе проектирования и реализуется в процессе разработки. Очевидно, что разработка затрагивает самые содержательные уровни проекта внедрения ERP: процессы, данные, приложения и технику. В ходе выполнения процедуры Fit/Gap-анализа идентифицируются, описываются и приоритизируются бизнес-требования пользователей [12], которые согласно каскадной методологии внедрения КИС [13] ведутся в документе Матрицы отслеживания требований.

Рис. 1. Группирование работ и задач для: а) описания бизнес-архитектуры предприятия;
б) проекта внедрения ERP-системы

Определение 2. Матрица отслеживания требований (Requirement Traceability Matrix, RTM) – это таблица, позволяющая отслеживать ход обработки бизнес, пользовательских и функционально-технических требований от момента их идентификации до реализации посредствам конфигурирования и/или доработки корпоративной информационной системы.

Для каждого бизнес-требования относящегося к категории Gap в документе RTM указывается тип, сложность и процент ре-использования разработки, кроме того наименование подготавливаемой функциональной спецификации.

Определение 3. Функциональная спецификация на разработку (Functional Specification) – документ, описывающий технические детали разрабатываемой программы, позволяющей реализовать требования к информационной системе. Детали решения включает концептуальную схему программы, алгоритмы обработки данных и заполнения полей, структуру и взаимосвязь реализуемых таблиц баз данных.

Тип разработки определяется на основе RICEF-классификации всех пользовательских программ. Позже мы поговорим о данной классификации более подробно. 

Определение 4. RICEF (сокращение от Report, Interface, Conversion, Enhancement и Form) – это классификация всех программных разработок на отчет, интерфейс, программу обработки данных, расширение и печатную форму [14].

Сложность программы чаще всего задается следующей шкалой:

• низкая;
• средняя;
• высокая;
• очень высокая.

Процент переиспользования характеризует величину ре-использования уже имеющейся программной разработки, обладающей функционалом схожим с требуемым. Введение тройки «тип – сложность - % ре-использования» позволяет унифицировать процесс оценивания трудозатрат всех видов разработки. 

Определение 5. Трудозатраты – это количество дней, затрачиваемое на выполнение работы силами одного человеческого ресурса, выражается в единице измерения человеко-дни. Срок выполнения работы имеет следующую зависимость от трудозатрат: Срок выполнения работы = Трудозатраты / Количество человеческих ресурсов.

Для каждой пары «тип - сложность» приводится экспертная оценка трудозатрат в разрезе таких задач, как:

• подготовка спецификации;
• разработка;
• проведения функционально-модульного тестирования,

значение которых может быть понижено при указании не нулевого %-переиспользования. Оценка ведется единожды и завершается не позже окончания фазы анализа. Назовем документ содержащий расчет трудозатрат для всех комбинаций типов и сложностей программ Оценщиком трудозатрат разработки. Пример фрагмента Оценщика и RTM даны на рис.2.

Определение 6. Оценщик трудозатрат разработки (RICEF Estimator) – это матрица, определяющая плановые трудозатраты на подготовку функциональной спецификации, разработку программы и ее функционально-модульное тестирование для каждого вида разработки RICEF и сложности.

Рис. 2. Пример фрагмента: а) RICEF Estimator;
б) RTM с указанием трудозатрат разработки на основе Оценщика

1.2. Оценивание RICEF-разработок

Использование Оценщика обеспечивает единый подход к определению плановых трудозатрат, необходимых для формирования спецификации на разработку. В случае, если разработка представляет собой совокупность нескольких программ, оценивание на основе RICEF Estimator проводится независимо для каждой из ее частей, а итоговые трудозатраты суммируются. Применение плановых значений трудозатрат соответствует PDCA-циклу (цикл Деминга), являющегося основой проектного менеджмент и постулирующего следующее: выполнению любой задачи предшествует шаг планирования, после чего ведется выполнение запланированных работ, далее контроль хода исполнения, а также корректировка возникших план-факт отклонений [11].

Индикативная оценка трудозатрат, необходимых для подготовки спецификации на разработку всевозможных видов программ дана на рис.3. Следуя данным рисунка, становится очевидным: формирование даже самой простой спецификации потребует значительных усилий в 4-7 человеко-дней. Указанная оценка должна быть принята во внимание еще на этапе планирования сроков. Игнорирование плановых трудозатрат, в частности их занижение, приведет к ожидаемым негативным последствиям: качество спецификации оставит желать лучшего, а сэкономленное время планомерно распределится на стадию разработки для устранения дефектов функционально-модульного тестирования.

Рис. 3. Индикативная оценка трудозатрат подготовки спецификации
(как часть документа RICEF Estimator)

Предварительно оценив время, необходимое для подготовки спецификации на разработку, обратимся к теории, для чего охарактеризуем виды разработок, а также введем базовые принципы, которым должна удовлетворять пользовательская программа на примере использования продукта SAP ERP.

2. RICEF-классификация разработок и принципы проектирования программ

2.1. Классификация разработок RICEF

Корпоративная информационная система состоит из большое числа программных разработок. RICEF-классификация позволяет отнести каждую из программ к определенному типу разработки, что накладывает ограничения как на структуру спецификации, так и время ее подготовки. Классификация RICEF расшифровывается следующим образом  [14]:

• R – report или отчет, позволяющий отображать данные ERP-системы конечному пользователю в определенном формате без возможности изменения;
• I – interface или интерфейс, обеспечивает как получение данных в систему ERP из внешней подсистемы, так и обратную передачу;
• C – conversion или программа обработки, призванная выполнять операции по созданию, изменению и удалению данных ИС;
• F – form или печатная форма, схожа с разработкой вида отчет, но отображает данные в регламентированном законодательством порядке для целей последующей распечатки и визирования;
• E – enhancement или расширение, дополняющее работу программ указанных выше логикой, продиктованной бизнес потребностями.
  

Примеры программ согласно RICEF-классификации даны на рисунке ниже. На практике возможна ситуация, когда программная разработка состоит из множества взаимосвязанных подпрограмм. В этом случае классификации подлежит каждая подпрограмма, являющаяся частью сложного приложения. 

Рис. 4. Примеры программ в SAP ERP по классификации RICEF с указанием кодов транзакций:
а) отчет; б) интерфейс; в) программа обработки данных; г) расширение; д) печатная форма

2.2. Принципы проектирования программ

Проектируемая RICEF-программа, в последующем отражаемая в спецификации на разработку, должна удовлетворять ряду правил. Например, быть масштабируемой в случае увеличения числа пользователей, гибкой к будущим изменениям, решать задачу оптимальным образом и прочее. Рассмотрим принципы разработки программ, заданные, но не ограниченные следующими предметными областями: 

• теория управления системами;
• системный анализ;
• программирование. 

2.2.1. Принципы теории управления

Среди принципов теории управления: программный, по обратной связи, по возмущению и комбинированный, ведению программных разработок наиболее релевантно правило обратной связи [15]. Применительно к ERP-системам данный принцип заключается в следующем: разрабатываемая программа должна обеспечивать максимальное информирование пользователя о ходе работы, что немаловажно в случае возникновения непредвиденных обстоятельств и ошибок. Рис.5 демонстрирует пример реализации данного принципа в SAP ERP: при попытке сохранить документ Поступления к Заказу на Закупку было выявлено, что не заполнены обязательные поля, о чем система сообщает пользователю в информативном сообщении об ошибке.

Рис. 5. Пример возникновения ошибки в SAP ERP при попытке сохранить Приход,
не заполнив обязательные поля данных (транзакция MIGO)

2.2.2. Принципы системного анализа

В процесс разработки ERP-программ системный анализ привносит следующие принципы [16]:

• функциональности;
• развития;
• неопределенности.

Принцип функциональности подразумевает, что структура разрабатываемой программы КИС должна целиком и полностью определяться изначально поставленной задачей. Поэтому чрезмерно сложная, состоящая из большого числа кнопок, пунктов меню и подэкранов программа – неудачная попытка решения различных задач средствами одной программной разработки. Конечно, только в том случае, если программа не представляет собой автоматизированное рабочее место сотрудника, объединяющее множество подпрограмм, каждую из которых можно запустить независимо (рис.6).

Рис. 6. Пример печати формуляра в SAP ERP через: а) независимую программу печати (транзакция MB90); б) программу регистрации прихода продукции с возможностью запуска печати через дополнительный пункт меню (транзакция MIGO)

С течением времени каждая программа претерпевает изменения, т.е. развивается. Например, из-за введения новых законодательных требований, увеличения числа пользователей системы и прочее. Принцип развития диктует необходимость проектирования ERP-программ с учетом данного обстоятельства. Именно поэтому в SAP ERP заданная программа успешно функционирует со всевозможными объектами и типами данных, а также на различных организационных уровнях (рис.7). Следуя данному принципу, разработка отчета, который будет корректно работать, к примеру, только для одного завода, но не всех имеющихся, будет ошибочной.

Рис. 7. Пример отчета в SAP ERP, в котором можно указывать различные организационные уровни для просмотра складских запасов (транзакция MB52)

Рис. 8. Пример ошибки в SAP ERP при неправильном заполнении значения даты
(транзакция MB51)

Неопределенность в работе программы должна быть сведена к минимуму. Однако никто не застрахован от неправильных данных, подаваемых на вход программы пользователем системы. Сложность заключается в том, что анализ того, почему программа выдала тот или иной ошибочный результат на основе неправильно заполненных входных данных, займет гораздо больше времени нежели исключение возможности возникновения подобной ситуации. Поэтому «защита от дурака» требует организации всевозможных проверок для вводимых данных, что является содержанием принципа неопределенности (рис.8).

2.2.3. Принципы программирования

Обратимся к базовым правилам ведения программных разработок, среди которых можно выделить принципы [3-5]:

• модульности;
• функциональной избирательности;
• «по умолчанию»;
• надежности.
  

Ситуация, когда один и тот же программный код многократно повторяется в тексте приложения согласно принципу модульности обрабатываться следующим образом: повторяющийся участок описывается единожды в виде процедуры, далее, если по ходу работы требуется выполнить этот участок кода, осуществляется запуск процедуры по ссылке. Принцип применим и для подготовки спецификации на разработку, что, к сожалению, ухудшает читабельность документа, так как приходится постоянно «перепрыгивать» между страницами, однако значительно сокращает трудозатраты в случае частого изменения документа (рис.9).

Рис. 9. Пример использования функционального модуля ‘FI_CHART_OF_ACCOUNT_DETERMINE’ различными программами SAP ERP (транзакция SE37)

Часто используемые программы должны находиться в оперативной памяти компьютера для возможности их быстрого запуска, что задает принцип функциональной избирательности. Примерами применения данного принципа в работе ERP-систем служат фоновые программы, выполняемые на регулярной основе вне поля зрения конечных пользователей, чаще всего в ночное время (рис.10). 

Рис. 10. Пример монитора запланированных фоновых задач в SAP ERP (транзакция SM37)

Суть принципа «по умолчанию» однозначно определяется из его названия: все, что может уменьшить число ручных операций выполняемых пользователем, в частности, автоматическое заполнение данных в поля ввода программы, значительно облегчают ему жизнь. С точки зрения отражения требования в документе спецификации и сложности его разработки, казалось бы, мелочь, однако для конечных потребителей ERP-системы – это существенное сокращение трудозатрат (рис.11).

Рис. 11. Пример реализации принципа «по умолчанию» в SAP ERP за счет ручного указания пользовательских параметров (а) и их автозаполнение в поля отчета по складским запасам (б), используя транзакции SU01 и MMBE соответственно

Часто мы описываем и в дальнейшем реализуем программные разработки по созданию документов в ERP-системе, предполагая, что приложение будет запускаться довольно редко и на небольшом объеме данных. Исходя из этого, логика функционирования программы нередко оставляет желать лучшего. Допустим, как быть в случае, если программа отработала некорректно и созданные данные требуется аннулировать? Правило надежности говорит о том, что любая программа, создающая или изменяющая данные в КИС, должна обеспечивать возможность их последующего нахождения для целей корректировки или удаления. Именно поэтому в системе SAP ERP большая часть программ разработана и разделена на операции: создание, изменение, удаление и отображение в виде списка (рис.12).

Рис. 12. Пример пользовательского меню SAP ERP, содержащего программы по созданию, изменению и просмотру Заказов на Закупку (транзакции ME21N, ME22N и ME23N)

3. Моделирование приложения и подготовка к написанию спецификации

Нередко применение принципов разработки приложений привносит все новые и новые требования к реализации. В первую очередь давайте разберемся с тем, что же такое требование.

Определение 7. Требование – это настойчивая просьба выполнить что-либо, в контексте внедрения ERP-систем категоризируется на бизнес, пользовательские и функционально-технические. Первые две категории требований часто определяются законодательными изменениями и наиболее трудозатратными бизнес-операциями.

Имплементация ERP-систем, ориентированных на средний и малый бизнес, преимущественно ведется на основе водопадной методологии внедрения информационных систем [13]. Как дополнение к данной методологии часто применяется V-модель разработки через тестирование (рис.13). Особенностью модели является то, что она определяет и устанавливает четкое соответствие между видами требований и испытаний. Так вводятся бизнес, пользовательские и функциональные требования.

Рис. 13. V-модель разработки через тестирование

Первые два вида требований задаются бизнес-пользователями и носят общий и достаточно верхнеуровневый характер. Детали таких требований преимущественно отсутствуют либо могут по-разному трактоваться. Именно поэтому они подлежат детальной проработки и уточнению для получения четко сформулированных потребностей, реализацию которых легок проверить по результатам завершения разработки. Третий вид требований – функциональные, относящиеся к программной реализации и необходимые консультанту для проработки технических деталей, без которых решение будет неработоспособно.

Существует ряд способов идентификации требований, описание которых дано в [12]. Особо хочется отметить методы демонстрации системы заказчику и прототипирования, наиболее часто используемые на практике. Суть демонстрации (или Workshop, рабочая встреча) состоит в следующем: заказчику показывается существующая программная система в демо-режиме или на презентационных слайдах, после чего ведется уточнение и детализация требований. Прототипирование применяется, когда бизнес потребности не могут быть явно сформулированы, в этому случае создается предварительный рабочий макет программы, на основе которого совместными усилиями пользователей и специалистов определяются требования. 

3.1. Проектирование структуры и логики работы программы

Идентифицированные пользовательские требования, относящиеся к категории Gap, а также соответствующие им функциональные потребности, отражаются в спецификации на разработку. В будущем данные требования будут покрыты программной разработкой в ERP-системе. Для этого, руководствуясь PDCA-принципом и предварительно оценив трудозатраты, ведется проектирование предварительной концепции решения как в текстовом, так и графическом видах. 

Текстовое описание предполагает отражение наиболее критичных моментов работы программы, в то время как графическое – задание ее логической структуры. 

В отличие от привычных всем офисных программ (например, MS Word и Excel, Lotus Notes и др.), ERP-системы оперируют большими данными. Поэтому отображение информации осуществляется преимущественно на экранные формы схожие с электронными таблицами, что удобно для целей последующего анализа. Ранее в статье [8] была введена трехуровневая структура описания программ, суть которой сводится к выделению в программной разработке экранов: селекционного, выбранных и обработанных данных. Используя данную структуру, осуществляется графическое моделирование программы, для чего визуализируются ее экраны и задаются логические взаимосвязи между ними (рис.14).  

Определение 8. Трехуровневая структура описания программы – это способ моделирования структуры RICEF-программы, состоящий из описания селекционного экрана, экранов выбранных и обработанных данных, а также логики перехода между ними.

Рис. 14. Пример моделирования программы на основе трехуровневой структуры описания

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

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

Рис. 15. Применимость обобщенной структуры для описания сложных I и С-программ

Рис.15 демонстрирует применимость обобщенной структуры для моделирования программных разработок, состоящих из большого числа пользовательских экранов. Проектирование целесообразно вести, когда количество экранов больше или равно трем, в противном случае непросто понять логику работы приложения. Пример моделирования сложной программы, состоящей из шести экранов дан на рисунке ниже. 

Рис. 16. Моделирование сложной программы на основе обобщенной структуры: а) селекционный экран; б) экран выбранных данных; в) экран обработанных данных; г-е) вспомогательные функциональные подэкраны

3.2. Моделирование экранов, объектов и таблиц данных

Моделирование структуры программы помимо демонстрации логики взаимодействия экранов косвенно позволяет решать еще одну задачу – оценивать объем работ на проработку документа спецификации. Ведь каждый введенный пользовательский экран потребует описания полей данных и алгоритма их заполнения. Например, если программа описывается трехуровневой структурой, то в спецификации потребуется задать:

• поля селекционного экрана;
• поля экрана выбранных данных;
• алгоритм заполнения полей экрана выбранных данных, используя поля селекционного экрана;
• поля экрана обработанных данных;
• алгоритм заполнения полей экрана обработанных данных, используя поля селекционного экрана и экрана выбранных данных.

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

• вида (параметр, диапазон значений, индикатор, радио-кнопка);
• обязательности заполнения;
• значения по умолчанию.

Рис. 17. Пример селекционного экрана: а) описание в спецификации на разработку; б) реализация экрана в SAP ERP на примере транзакции MRBR

Отличие вида поля «параметр» и «диапазон значений» заключается в том, что первый позволяет вводить только одно единственное значение, в то время как второй – множество. Пример описания селекционного экрана и его возможная реализация в системе SAP ERP дан на рис.17.

При описании полей экранов выбранных и обработанных данных указываются все те же название, тип и размерность данных, кроме того задаются функции обработки, такие как: фильтрация, сортировка, суммирование, подсуммирование и др. (рис.18).

Рис. 18. Пример экрана выбранных данных: а) описание в спецификации на разработку;
б) реализация экрана в SAP ERP на примере транзакции MRBR

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

• графически в виде блок-схемы алгоритма [17];
• в текстовом виде на основе SQL-запросов на русском или английском языках [18];
• произвольным текстом.

Описание алгоритма в виде блок-схемы достаточно трудоемко, поэтому осуществляется только для задания самых важных и сложных моментов работы программы. Использование языка структурированных запросов к данным (SQL, Structured Query Language) позволяет единообразно описывать алгоритмы, что немаловажно для международных проектов внедрения КИС. И, наконец, произвольное текстовое описание применяется достаточно редко и чаще всего новичками.

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

• определяется главная таблица баз данных, обеспечивающая информацией большее число полей;
• осуществляется выборка данных из главной таблицы;
• находятся прочие таблицы для заполнения всех оставшихся полей, связанные с главной;
• ведется выборка данных из прочих таблиц.

Рис. 19. Принцип заполнения полей экрана выбранных данных

С одной стороны заполнение полей экрана выбранных данных осуществляется на основе входных параметров селекционного экрана, что представляет собой некое сопоставление; с другой – определяются главные и прочие таблицы данных, используя алгоритмы выборки. Объединяя первое со втором, получаем процедуру по описанию логики заполнения второго экрана программы. Более того, поля экранов могут заполняться статическими значениями, хранимыми в таблице баз данных, и динамическими, рассчитанными по определенной формуле на основе статических.

Подробнее рассмотрим пример на рис.20. Описание логики заполнения полей экрана выбранных данных можно разбить на три части:

• алгоритмы выборки данных из главной и прочих таблиц, на основе селекционных ограничений;
• сопоставление полей экрана выбранных данных и селекционного, если данные передаются без изменений; в противном случае задание источника данных из главной или прочих таблиц, или алгоритма динамической обработки;
• алгоритм удаления данных из массива найденных.

Рис. 20. Пример описания алгоритма заполнения полей экрана выбранных данных
в спецификации на разработку

Если программа относится к категории «С – программа обработки данных», экран выбранных данных вероятнее всего будет содержать кнопку, изменяющую информацию системы. Функционирование кнопки описывается схожим образом, для чего задаются:

• предпосылки;
• логика выборки и обработки данных;
• выходные результаты.

Рис. 21. Пример описания функциональной кнопки для транзакции

Пример описания кнопки дан на рис.21. Из рисунка видно, что процедура, отвечающая за изменение, применяется к позициям экрана выбранных данных, имеющих статические или динамические значения. Полученные выходные результаты будут в последующем отображены в экране обработанных данных.

Задание полей и алгоритмов заполнения экрана обработанных данных ведется аналогично экрану выбранных данных с тем лишь отличием, что выборка осуществляется с использованием информации, полученной при срабатывании функциональных кнопок (рис.22).

Рис. 22. Пример экрана обработанных данных: а) описание правила заполнения в спецификации на разработку; б) реализация экрана в SAP ERP на примере транзакции MRBR

Моделирование сложных программ потребует больших усилий, в частности, если речь идет о создании программной С-разработки с нуля, возникнут дополнительные шаги проектирования и ведения таблиц баз данных, для чего необходимо:

• определить классы данных;
• определить таблицы для классов данных;
• нормализовать таблицы минимум до третьей нормальной формы (3НФ);
• исключить из нормализации поля, позволяющие формировать минимальную отчетность.

Разделение этапов проектирования классов и таблиц баз данных сделано неслучайно. Дело в том, что на начальных шагах моделирования детальная информация о составе данных может отсутствовать, более того с течением времени она изменятся. Нормализовывать таблицы нужно тоже с умом: несмотря на то, что 3НФ постулирует вынесение не ключевых атрибутов, зависящих от других не ключевых полей в отдельные таблицы [18], на практике данный принцип часто игнорируют в угоду получения минимальной информативной отчетности напрямую из таблиц.

3.3. Способы поиска таблиц баз данных в SAP ERP

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

Применительно к системе SAP ERP доступны следующие способы выявления стандартных таблиц баз данных [19]:

• нажатие кнопки F1 в поле и последующее чтение технической информации;
• применение пакетов разработок, группирующих таблицы данных для каждой из предметных областей (транзакция SE80);
• использование трассировщика SQL-запросов, обращающихся к базам данных через стандартные команды SELECT, DELETE и UPDATE (транзакция ST21);
• использование функциональных модулей, содержащих в себе последовательность SQL-запросов и выдающих необходимый конечный результат (транзакция SE37),

кроме того вне зависимости от прикладной информационной системы большая часть таблиц баз данных, а также их ER-диаграммы (Entity Relationship, диаграммы взаимосвязи таблиц) доступны в сети интернет. Ссылка на 2-ю часть статьи.

Литература

1. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
2. О’Лири Д. ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение и эксплуатация / Пер. с англ. Водянова Ю.И. – М.: Вершина, 2004. – 272 с.
3. Кнут Д. Искусство программирования, том 1. Основные алгоритмы. / Пер. с англ. под ред. Козаченко Ю. - М.: Вильямс, 2006. – 720 с.
4. Архангельский А.Я. Программирование в C++ Builder. – М.: Бином, 2010. – 1508 с.
5. Котеров И.В., Симдянов И.В. PHP7. – СПб.: БХВ-Петербург, 2017. – 1088 c.
6. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
7. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
8. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268. – URL: http://stepanovd.com/science/26-article-2014-4-design.
9. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений [Электронный ресурс] // Официальный сайт Дмитрия Степанова  – Режим доступа: https://stepanovd.com/training/12-erp/52-erp-8-applicationlevel (дата обращения 01.09.2019).
10. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238. – URL: http://stepanovd.com/science/31-article-2015-2-erpthpr.
11. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013. – 589 p.
12. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3. – c.180-191. – URL: http://stepanovd.com/science/30-article-2015-1-erpappl.
13. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
14. Кречмер Р., Вейс В. Разработка приложений SAP R/3 на языке АВАР/4. - М.: Лори. 1998.
15. Ким Д.П. Теория автоматического управления: линейные системы. – М.: ФИЗМАТЛИТ, 2003. – 288 с.
16. Антонов А.В. Системный анализ. – М.: Высшая школа, 2008. – 456 с.
17. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2014. – 330 с.
18. Грофф Д.Р., Вайнберг П.Н., Оппель Э.Д. SQL. Полное руководство. – М.: Вильямс, 2014. – 960 с.
19. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc., 1999. – 591 p.
20. Лодон Дж., Лодон К. Управление информационными системами. / Пер. с англ. под ред. Трутнева Д.Р. - СПб.: Питер, 2005. - 912 с.

Выходные данные статьи

Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. – 2019. – №3(7). – С. 29-52. – URL: https://corpinfosys.ru/29-archive/2019-7/66-2019-7-functionalspec.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №7

1. Учет материально-производственных запасов на предприятии (часть 2).
2. 1С в облачных технологиях «фреш»;
3. Особенности миграции данных в SAP ERP;
4. Подготовка функциональных спецификаций на разработку (часть 1);
5. Проблемы ведения централизованных закупок в ERP-системах.