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

Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье рассматривается пример подготовки документа функциональной спецификации на разработку в системе SAP ERP, в содержании которого выделены разделы требований, концептуального решения, описания структуры экранных форм и алгоритмов заполнения полей этих форм, ролей и полномочий, а также тестовых данных и допущений. Заполнение этих разделов в документе спецификации позволяет решить три основные задачи: понятность документа для бизнес-пользователей, наличие технических деталей предлагаемого решения и обработка неопределенностей. Описание экранов, полей в экранах, а также алгоритмов заполнения полей ведется единым способом и представляется достаточно компактно. Разделение логики заполнения полей на алгоритмы пред- и постобработки, разовое присвоение найденных значений полям обеспечивают легкость и читабельность содержимого документа спецификации.
СкачатьPDF (статья), PDF (выпуск №13).
Ключевые слова: спецификация для разработки, анализ ключевых особенностей, разработка RICEFW, проверка полномочий, экран выбранных данных, логика работы программы, кнопки редактирования данных, ALV-список, запуск транзакции, авторизационные права, функционально-модульные испытания, тестовые сценарии, исключение неоднозначностей, алгоритмы заполнения полей, ссылочный элемент, пользовательский экран, обработка неопределенностей.

Введение

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1].

Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].

Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

  • формирование требований к АС;
  • разработка концепции АС;
  • техническое задание;
  • эскизный проект;
  • технический проект;
  • рабочая документация;
  • ввод в действие;
  • сопровождение АС.

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

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

Цель и задачи

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

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

1. Типовая структура спецификации на разработку

Достаточно часто в проекте внедрения АС предлагается уникальная структура спецификации, подходящая или для всех видов разработок согласно классификации RICEFW или отдельно для каждой [5]. Практика показывает, попытка выделить отдельный шаблон для каждого вида разработок RICEFW не упрощает, а лишь усложняет процесс подготовки спецификации. Поэтому сосредоточим внимание на едином документе спецификации.

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

Типовая структура спецификации на разработку

Рис. 1.1. Типовая структура спецификации на разработку
  • первые два раздела содержат исходные требования, предъявляемые к системе, а также верхнеуровневое описание предполагаемой программы, заданное текстовыми комментариями или графической схемой. Наличие разделов является критичным, так как документ спецификации подтверждается бизнес-пользователями, не обладающими техническими навыками. Для согласования документа им важно увидеть начальные требования и попытаться понять общую модель решения, не вдаваясь в детали, приведенные в последующих разделах;
  • следующие разделы являются техническими. Главы, касающиеся экранов, ролей и полномочий, необходимы для описание экранных форм программы, а также алгоритмов их заполнения и проверки полномочий;
  • раздел тестовых данных достаточно часто встречается в документах спецификаций, однако весьма редко используется в ходе реального выполнения функционально-модульных испытаний;
  • и, наконец, допущения, описывающие открытые вопросы, на которые никто не смог дать ответ. Допущения позволяют сформулировать утверждение к открытому вопросу, что критично для построения решения. Это один из немногих способов обработки бизнес неопределенности.

2. Пример функциональной спецификации для разработки отчета в SAP ERP

Воспользуется типовой структурой спецификации, описанной на рис.1.1, и проанализируем пример подготовки документа для разработки отчета в системе SAP ERP (разделы 2.1-2.8). В качестве заказчика будем использовать тестовую организацию под названием ДСТ.

2.1. Оглавление

2.2. Требования
2.3. Концепция решения
2.4. Селекционный экран
2.5. Логика работы программы
2.6. Роли и полномочия
2.7. Тестовые данные
2.8. Допущения

2.2. Требования

Компания ДСТ занимается оптовыми продажами товаров. Большая часть продаваемой продукции закупается по импортной схеме. Импортная закупка требует учитывать сумму таможенных пошлин и сборов в стоимости закупаемых товаров, а также хранить данные ГТД (Грузовая таможенная декларация). В случае перепродажи продукции в сопроводительных документах (Счет-фактура) необходимо указывать номер исходной ГТД, полученной при оприходовании товара на склад. Согласно глобальному решению номер ГТД хранится в системе SAP ERP в признаках классификации партии, заполняемых при регистрации прихода товара транзакцией MIGO. Для целей контроля и прослеживаемости требуется разработать отчет, показывающий текущий складской запас SAP ERP с данными ГТД.

Таблица 2.2.1. Список требований
Gap № Требование
144 Разработать отчет, аналог MB52 с возможностью отображения признаков партий

2.3. Концепция решения

Функционал разрабатываемого отчета в SAP ERP близок к стандартной транзакции MB52. Результаты работы отчета обогащены данными признаков классификации партии, в частности ГТД. Отчет показывает ненулевой оцененный свободно используемый запас в разрезе оргуровней предприятия:

  • завод;
  • склад;
  • партия;
  • материал;
  • данные ГТД и прочее.

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

Типовая структура спецификации на разработку

Рис. 2.3.1. Структура и логика взаимодействия экранов отчета по запасам: а) селекционный экран; б) ALV-список выбранных данных

2.4. Селекционный экран

Реализация требования табл. 2.2.1 предполагает разработку программы, архитектура которой описана в 4.3. Детали разрабатываемого приложения приведены в таблице ниже (табл. 2.4.1).

Таблица 2.4.1. Детали разрабатываемой программы
Параметр Требование
Название программы Stock report with classification/Отчет по запасам с классификацией
Код программы ZRUIMSTKCLASSRPT
Название транзакции Stock report with classification/Отчет по запасам с классификацией
Код транзакции ZRUIMSTKCLASSRPT

Предполагаемый селекционный экран для ввода данных приведен в табл. 2.4.2 и схематически изображен на рис. 2.3.1.

Таблица 2.4.2. Селекционный экран программы
 № Наименование поля Категория (Parametrs, Select-Options, RadioButton, CheckBox) Тип (ссылка на элемент данных) Обязатель-ность для ввода

Значение по умолчанию

Selection criteria’s/Ограничения
1 Plant/Завод Parametrs MCHB-WERKS Х RU01
2 Storage location/Склад Select-Options MCHB-LGORT    
3 Material group/Группа материала Select-Options MARA-MATKL    
4 Material/ Материал Select-Options MCHB-MATNR    
5 Batch/Партия Select-Options MCHB-CHARG    
6 GTD/ГТД Select-Options      
Format/Формат
7 Format/Формат Parametrs     /ZGTD

После нажатие кнопки «Выполнить» осуществляется проверка полномочий согласно 2.6. В случае успеха осуществляется переход к экрану выбранных данных, описанному в 2.5.

2.5. Логика работы программы

Успешное выполнение проверки полномочий пользователя запускает экран выбранных данных в формате ALV-Grid (табл. 2.5.1). Экран должен содержать стандартные кнопки редактирования данных (рис. 2.5.1). Поля экрана упорядочиваются согласно заданному на селекционном экране формату («Формат» селекционного экрана).

Стандартные кнопки редактирования данных

Рис. 2.5.1. Стандартные кнопки редактирования данных
Таблица 2.5.1. Поля ALV-списка выбранных данных
 № Техническое название поля Элемент данных Тип данных Длина данных Краткий текст
1 WERKS MCHB-WERKS
 
- - Plant/Завод
2 LGORT  MCHB-LGORT  - - Storage location/Склад
3  MATKL MARA-MATKL  - - Material group/Группа материалов
4  WGBEZ60 T023-WGBEZ60  - - Material group name/ Наименование группы материалов
5 MATNR  MCHB-MATNR  - - Material/Материал
6  MAKTX MAKT-MAKTX  - - Material name/ Наименование материала
7 CHARG  MCHB-CHARG  - - Batch/Партия
8 CLABS  MCHB-CLABS  - - Valuated stock/ Оцененный запас
9 MEINS  MARA-MEINS  - - Base unit of measure/БЕИ
10 GTD_1  - CHAR 10 GTD part 1/ГТД часть 1
11 GTD_2  - DATS 8 GTD part 2/ГТД часть 2
12 GTD_3  - CHAR 10 GTD part 3/ГТД часть 3
13 GTD_4  - CHAR 10 GTD part 4/ГТД часть 4
14 GTD  - CHAR 38 GTD/ГТД

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

Таблица 2.5.2. Алгоритм заполнения полей ALV-списка выбранных данных
 № Техническое название поля Краткий текст Правило Алгоритм
 

1. Основной алгоритм выбора из таблицы остатков по партии MCHB

Select * from MCHB where
 WERKS = «Завод» селекционного экрана (если заполнен) and
 LGORT = «Склад» селекционного экрана (если заполнен) and
 MATNR = «Материал» селекционного экрана (если заполнен) and
 CHARG = «Партия» селекционного экрана (если заполнен) and
 CLABS > 0

 

2. Алгоритм выбора группы материалов

Loop at MCHB (step 1)
  Select MATKL from MARA where
    MATNR = MCHB-MATNR

 

3. Алгоритм выбора названия группы материалов

Loop at MARA (step 2)
  Select WGBEZ60 from T023 where
    MATKL = MARA-MATKL

 

4. Алгоритм выбора названия материала

Loop at MCHB (step 1)
  Select MAKTX from MAKT where
    MATNR = MCHB-MATNR

 

5. Алгоритм выбора базовой ЕИ материала

Loop at MCHB (step 1)
  Select MEINS from MARA where
    MATNR = MCHB-MATNR

 

6. Алгоритм выбора признака ГТД_1

Loop at MCHB (step 1)
  Select ATINN from CABN where // Выбрать код признака классификации
    ATNAM = ‘GTD_1’

  Select CUOBJ_BM from MCH1 where // Выбрать ссылку на партию и материал
    MATNR = MCHB-MATNR and
    CHARG = MCHB-CHARG

  Select ATWRT from AUSP where // Выбрать значение по коду признака и ссылке
    ATINN = CABN-ATINN and
    OBJEK = СЛидирующимиНулями(MCH1-CUOBJ_BM) and
    KLART = ‘023’

1 WERKS Plant/Завод = MCHB-WERKS
2 LGORT Storage location/Склад = MCHB-LGORT
3 MATKL Material group/Группа материалов = MARA-MATKL
4 WGBEZ60 Material group name/ Наименование группы материалов = T023-WGBEZ60
5 MATNR Material/Материал = MCHB-MATNR
6 MAKTX Material name/ Наименование материала = MAKT-MAKTX
7 CHARG Batch/Партия = MCHB-CHARG
8 CLABS Valuated stock/ Оцененный запас = MCHB-CLABS
9 MEINS Base unit of measure/БЕИ = MARA-MEINS
10 GTD_1 GTD part 1/ГТД часть 1 = AUSP-ATWRT для признака ‘GTD_1’
11 GTD_2 GTD part 2/ГТД часть 2 = AUSP-ATWRT для признака ‘GTD_2’
12 GTD_3 GTD part 3/ГТД часть 3 = AUSP-ATWRT для признака ‘GTD_3’
13 GTD_4 GTD part 4/ГТД часть 4 = AUSP-ATWRT для признака ‘GTD_4’
14 GTD GTD/ГТД = GTD_1 + “” + GTD_2 +
GTD_3 + “” + GTD_4 (поля ALV-Grid)
 

7. Алгоритм постобработки позиции для группы материалов селекционного экрана
If MATKL <> «Группа материалов» селекционного экрана (если заполнено), then
      Удалить запись из ALV-Grid

 

8. Алгоритм постобработки позиции для ГТД селекционного экрана
If GTD <> «ГТД» селекционного экрана (если заполнено), then
     Удалить запись из ALV-Grid

2.6. Роли и полномочия

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

Таблица 2.6.1. Алгоритм проверки авторизации пользователя
Описание
шага
Алгоритм
1 Проверка объекта полномочий M_MSEG_MWB Проверить объект авторизации M_MSEG_MWB с параметрами
   ACTVT = ‘03’ and
   WERKS = «Завод» селекционного экрана
Если проверка прошла успешно, то перейти к 4.5
Иначе выдать сообщение об ошибке авторизации

2.7. Тестовые данные

Функционально-модульные испытания программы будут вестись согласно тестовых сценариев, приведенных в таблице ниже как для позитивных, так и негативных случаев (табл. 2.7.1).

Таблица 2.7.1. Сценарии функционально-модульного тестирования
 № Сценарий Входные данные Ожидаемый результат Тип тестирования
1 Проверка полномочий Пользователь с полномочиями на запуск отчета для завода RU01 Выведены данные по запасам завода RU01 Позитивный
2 Выборка данных на основе селекционных ограничений Ограничение на основе завода RU01 и склада 1000 Выведены данные по запасам, ограниченные заводом RU01 и складом 1000 Позитивный
3 Выборка данных на основе селекционных ограничений Введение несуществующего номера ГТД Пустой экран выбранных данных Негативный

2.8. Допущения

Спецификация на разработку требует введения следующих допущений, для исключения неоднозначностей и разночтения:

  • данные ГТД хранятся в признаках классификации партии ‘GTD_1’, ‘GTD_2’, ‘GTD_3’, ‘GTD_4’ для типа класса ‘023’.

3. Комментарии к рассмотренному примеру

Обсудим ключевые особенности подготовленной спецификации:

  • грамотно оформленная спецификация позволяет увидеть структуру программы, уже в оглавлении, что наглядно продемонстрировано в разделе 2.1. Обычно селекционный экран описывается отдельно от всех прочих экранов, что видно из оглавления;
  • приводить структуру программы имеет смысл, если число пользовательских экранов более трех. Поэтому рисунок 2.3.1 в данном случае не является обязательным;
  • ссылочный элемент данных приводится в формате <Таблица>-<Поле> (табл. 2.5.1). Если указан ссылочный элемент, нет необходимости указывать тип и размерность данных, так как вся информация будет копировать из ссылки;
  • алгоритмы заполнения полей для строчек 1-14 таблицы 2.5.2, описаны в начале таблицы. Таким образом, для каждого поля есть значение <Таблица>-<Поле>, найденное с использованием SQL-запросов (алгоритмы 1-6). В случае наличия динамически заполняемых полей, для которых значения вычисляются по результатам обработки данных из таблиц, алгоритм их постобработки дан внизу таблицы (алгоритмы 7-8);
  • допущение из раздела 2.8 задано как утверждение, т.е. на момент подготовки функциональной спецификации не было подтвержденного ответа.

Заключение

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

  • понятность документа для бизнес-пользователей;
  • наличие технических деталей предлагаемого решения;
  • обработка неопределенностей.

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

Литература 

  1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
  2. D. Y. Stepanov. Using Agile Methodology in ERP-system Implementation Projects // 2021 International Conference on Information Technologies (InfoTech), 2021, pp. 1-4, doi: 10.1109/InfoTech52438.2021.9548342.
  3. Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 2) // Корпоративные информационные системы. – 2019. – №4(8). – С. 1-18. – URL: https://corpinfosys.ru/archive/issue-8/69-2019-8-functionalspec.
  4. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2014. – 330 с.
  5. Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. – 2019. – №3(7). – С. 29-52. – URL: https://corpinfosys.ru/29-archive/2019-7/66-2019-7-functionalspec.

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

Степанов Д.Ю. Подготовка функциональных спецификаций для доработки корпоративной информационной системы на примере ABAP-отчета в SAP ERP // Корпоративные информационные системы. – 2021. – №1 (13). – С. 93-107. – URL: https://corpinfosys.ru/archive/issue-13/145-2021-13-functionalspecification.

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

Об авторе

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

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

  1. Автоматизация работы стоматологической клиники (часть 1);
  2. Применение спиралевидной модели внедрения для роботизации больницы;
  3. Банкротство юридического лица. Ликвидационный баланс (часть 1);
  4. Автоматизация городской больницы (часть 2);
  5. Подготовка функциональных спецификаций на примере ABAP-отчета в SAP ERP.