Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [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.