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

Подробности

Опубликовано: 05.01.2021 09:00

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

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

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

Введение

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

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. Детали разрабатываемой программы

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

Таблица 2.4.2. Селекционный экран программы

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

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

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

Рис. 2.5.1. Стандартные кнопки редактирования данных

Таблица 2.5.1. Поля ALV-списка выбранных данных

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

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

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

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

Таблица 2.6.1. Алгоритм проверки авторизации пользователя

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

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

Таблица 2.7.1. Сценарии функционально-модульного тестирования

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.

Об авторе

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

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

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