Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1].
Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].
Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:
формирование требований к АС;
разработка концепции АС;
техническое задание;
эскизный проект;
технический проект;
рабочая документация;
ввод в действие;
сопровождение АС.
Проводя аналогию между практикой внедрения ERP-систем и действующими ГОСТами, можно отметить, что функциональная спецификация представляет собой совокупность технического проекта и технического задания, где первый описывает, как будет реализована система, второй – что она должна делать.
Не смотря на обилие литературных источников, посвященных проектированию информационных систем [1, 3-4], попыток формализации и примеров подготовки функциональных спецификаций достаточно немного, что порождает изобретение все новых и новых велосипедов при решении типовых проектных задач по разработке корпоративных информационных систем.
Основной целью данной работы является детальное рассмотрение содержания функциональной спецификации на разработку ERP-системы, что позволит реализовать информационную систему в срок и с высоким качеством. Достижение казанной цели требует решения следующих задач:
обзор типовой структуры функциональной спецификации на разработку;
рассмотрение примера спецификации для разработки отчета в SAP ERP;
анализ ключевых особенностей в рассмотренной спецификации.
1. Типовая структура спецификации на разработку
Достаточно часто в проекте внедрения АС предлагается уникальная структура спецификации, подходящая или для всех видов разработок согласно классификации RICEFW или отдельно для каждой [5]. Практика показывает, попытка выделить отдельный шаблон для каждого вида разработок RICEFW не упрощает, а лишь усложняет процесс подготовки спецификации. Поэтому сосредоточим внимание на едином документе спецификации.
Рассмотрим типовую структуру документа функциональной спецификации на разработку, предложенную в [3]. Плюс этой структуры состоит в том, что описание хода реализации ведется сверху вниз, кроме того, сохранена логическая последовательность отображения экранов программы, что упрощает понимание программы. Документ спецификации разделяется на 6-ть разделов (рис. 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.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. Поля 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 | |||
| 2. Алгоритм выбора группы материалов Loop at MCHB (step 1) | |||
| 3. Алгоритм выбора названия группы материалов Loop at MARA (step 2) | |||
| 4. Алгоритм выбора названия материала Loop at MCHB (step 1) | |||
| 5. Алгоритм выбора базовой ЕИ материала Loop at MCHB (step 1) | |||
| 6. Алгоритм выбора признака ГТД_1 Loop at MCHB (step 1) Select CUOBJ_BM from MCH1 where // Выбрать ссылку на партию и материал Select ATWRT from AUSP where // Выбрать значение по коду признака и ссылке | |||
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. Алгоритм постобработки позиции для группы материалов селекционного экрана | |||
| 8. Алгоритм постобработки позиции для ГТД селекционного экрана | |||
Литературный источник
Степанов Д.Ю. Подготовка функциональных спецификаций для доработки корпоративной информационной системы на примере ABAP-отчета в SAP ERP // Корпоративные информационные системы. – 2021. – №1 (13). – С. 93-107. – URL: https://corpinfosys.ru/archive/issue-13/145-2021-13-functionalspecification.
