Принципы проектирования программ и их отражение в спецификации на доработку ERP-системы
Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [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 большая часть программ разработана и разделена на операции: создание, изменение, удаление и отображение в виде списка …
Литературный источник:
Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. — 2019. — №3(7). — С. 29–52. — URL: https://corpinfosys.ru/29-archive/2019–7/66–2019–7-functionalspec.
