ОПИСАНИЕ  МЕТОДИКИ  ПРОЕКТИРОВАНИЯ  АЛГОРИТМОВ  СБОРКИ  И  ОБРАБОТКИ  ДАННЫХ  В  ОБЪЕКТНО-ПРОЦЕССНОМ  ПРОГРАММНОМ  КОМПЛЕКСЕ  «COBRA ++»

Постников  Алексей  Максимович

аспирант  Международной  Академии  бизнеса  и  новых  технологий  (МУБиНТ),

РФ,  г.  Ярославль

E -mail: 

Шведенко  Петр  Владимирович

магистрант  Санкт-Петербургского  университета  точной  механики  и  оптики  (ИТМО),  РФ,  г.  Санкт- Петербург

DESCRIPTION  OF  THE  METHODOLOGY  FOR  THE  DESIGN  OF  ASSEMBLY  ALGORITHMS  AND  DATA  PROCESSING  IN  AN  OBJECT-PROCESS-BASED  SOFTWARE  PACKAGE  «COBRA++»

Postnikov  Alecsey

graduate  of  the  International  Academy  of  business  and  new  technologies  (Mount),  Russia.  Yaroslavl

Shvedenko  Peter

graduate  student  of  the  St.  Petersburg  Institute  of  fine  mechanics  and  optics  (ITMO),  system  administrator,  LLC  "REGUL++",  Russia,  St.  Petersburg

АННОТАЦИЯ

В  статье  описывается  пошаговая  процедура  проектирования  алгоритма  сборки  и  обработки  данных  для  последующей  оценки  эффективности  выполняемых  работ  в  соответствии  с  деревом  целей  и  исполняемыми  бизнес-процессами  предприятия.

ABSTRACT

This  article  describes  a  step-by-step  design  procedure  of  the  Assembly  algorithm  and  processing  data  for  subsequent  evaluation  of  the  effectiveness  of  work  performed  in  accordance  with  the  objectives  tree  and  executable  business  processes  of  the  enterprise.

Ключевые  слова :  информационно-управляющая  система;  объектно-процессное  проектирование;  сбор  и  обработка  информации.

Keywords :  management  information  system;  object-process  design;  collection  and  processing  of  information.

Объектно-процессный  программный  комплекс  (ОО  ПК)  «COBRA++»  (разработка  Санкт-Петербургской  компании  —  ООО  «РЕГУЛ  +»  —  резидента  Инновационного  центра  «Сколково»)  ориентирован  на  создание  пользовательских  приложений  для  описания  объектов  предметной  области,  их  структуры,  регламентов  воздействия  на  объекты  предметной  области  и  разработку  метрической  системы  оценки  результатов  достигаемых  воздействий.  Проектирование  модели  описания  среды  предметной  области  и  настройка  ее  нормативно-корректирующих  параметров  осуществляется  непосредственно  специалистами  предметной  области,  при  этом  обеспечивается  сохранение  всех  ее  предшествующих  модификаций.  ОО  ПК  «COBRA++»  представляет  собой  универсальный  инструмент  построителя  информационно-управляющих  систем  (ИУС)  предприятия/  организации  любой  отраслевой  направленности  и  уровня  сложности,  в  котором  отсутствует  жесткая  и  единообразная  схема  проектирования  задач  управления  объектами  предметной  области.  Один  и  тоже  результат  может  быть  получен  несколькими  способами.  Функциональные  возможности  инструмента  раскрыты  в  статье  [1].

В  работе  предложен  вариант  последовательности  проектирования  задачи  управления  объектами  предметной  области  согласно  следующему  алгоритму: 

Шаг  1.  Формирование  или  выбор  из  имеющейся  библиотеки  ИУС  объектов  управления.   Каждый  объект  описывается  набором  характеристик,  однозначно  отражающих  сущность  предметной  области,  которая  представляется  в  виде  древовидной  структуры,  состоящей  из  объектов  и  его  свойств  (см.  рис.  1)

Рисунок  1.  Примеры  представления  структуры  информационных  объектов

Глубина  детализации  объекта  управления  также  определяется  самим  пользователем  системы,  и  может  меняться  в  зависимости  от  типа  решаемой  им  задачи.

Шаг  2.  Установление  связей  между  объектами  управления.   Построение  графической  схемы  иерархии  объектов  управления  (см.  рис.  2)

Рисунок  2.  Пример  построения  иерархии  связей  объектов  управления  (детализация:  производство  —  …  —  исполнитель  производственной  операции)

Объекты  управления  выбираются  и  структурируются  по  разным  классификационным  признакам  предметной  области  таким  как,  например,  «производственная  программа  предприятия-производственный  заказ-тип  продукции-модель-материал  и  фурнитура»  или  «производственная  подсистема  предприятия-цеха-участки-оборудование-производимые  операции-рабочие,  их  осуществляющие».  Количество  одновременно  используемых  структурных  классификаций  объектов  управления  системой  не  ограничен.  В  зависимости  от  решаемой  задачи  при  сборке  данных  пользователь  в  дальнейшем  подключает  ту  или  иную  сформированную  структуру,  по  которой  будет  осуществляться  агрегация  и/или  выборка  данных.

Шаг  3.  Прикрепление  к  объектам  управления  бизнес-процессов,  через  них  циркулирующих.   Прикрепление  производится  автоматически  или  выборочно  (через  таблицу  решений)  в  соответствии  с  имеющейся  в  ИУС  библиотекой  связей  «Объект  управления»  —  «Этап  i-й  бизнес-процесса  j-го».  При  этом  соблюдается  следующее  правило:  «Через  каждый  объект  управления  в  ИУС  может  проходить  один  или  более  бизнес-процессов.  Объект,  через  который  не  проходит  ни  один  бизнес-процесс,  объектом  управления  не  является».  Узлом  связи  выступает  конкретный  этап  бизнес-процесса.

Шаг  4.  Назначение  объектов  контроля.   Состояние  каждого  объекта  управления  может  быть  рассмотрено  через  различные  его  ракурсы.  Каждый  ракурс  объекта  управления  описывается  своей  системой  контроля.  Например,  при  анализе:  соблюдения  сроков  выполнения  заказов  предприятия,  заказы  —  объект  управления,  сроки  выполнения  —  объект  контроля;  загрузки  производственной  мощности  предприятия,  оборудование  —  объект  управления,  продолжительность  работы  оборудования  —  объект  контроля;  себестоимости  выпуска  единицы  модели  Х,  модель  Х  —  объект  управления,  структура  себестоимости  и  сырьевого  списка  модели  Х  —  объект  контроля;  использования  стали  определенной  марки  за  1  квартал  20хх  года,  объект  управления  —  сталь  определенной  марки,  объем  использования  всего  по  предприятию  и  в  разрезе  ассортимента  выпускаемой  продукции,  в  том  числе  списанной  в  брак  и  реализованной  на  сторону  —  объекты  контроля.  В  системе  ИУС  производится  присвоение  каждому  объекту  управления  один  и  более  объектов  контроля. 

Шаг  5.  Назначение  показателей,  оценивающих  состояние  объекта  контроля.   Каждому  объекту  контроля  может  соответствовать  один  и  более  показателей,  измеряющий  его  состояние.  Например,  объект  управления  —  оборудование,  объект  контроля  –  продолжительность  работы,  показатели  —  время  начала  и  завершения  в  разрезе  каждой  смены,  количество  и  продолжительность  остановов  оборудования  в  разрезе  каждой  смены,  количество  произведенных  операций  по  отношению  к  отработанному  времени  за  смену  и  т.  д.

Шаг  6.  Присвоение  нормативных  параметров  каждому  показателю,  оценивающему  состояние  объекта  контроля.  Назначение  диапазона  коридоров  отклонений   (разрешенное,  допустимое,  предельное),  их  верхнее  и  нижнее  значение.  Назначение  схемы  адресации  сообщений  о  возникающих  отклонениях  (передача  сигналов  на  операционно-функциональный,  тактический  и  стратегический  уровни  принятия  управленческих  решений).

Шаг  7.  Формирование  схемы  агрегирования  данных.   Различают  первичную  горизонтальную  агрегацию  –  укрупнение  данных  исполнения  этапов  бизнес-процессов  предприятия  по  периодам  сбора  информации  (смена,  сутки,  неделя,  декада,  месяц  и  т.  д.)  и  три  вида  вторичной  вертикальной  агрегации  данных  (по  функциональным,  целевым  и  объектным  иерархическим  срезам  структурируемых  данных).  (см.  рис.  3).

Как  следует  из  рис.  3,  функциональная  агрегация  предполагает  укрупнение  данных  по  функциональным  признакам  решаемой  задачи  (принадлежность  к  функциональному  направлению  деятельности  предприятия).  Целевая  агрегация  данных  производится  в  соответствии  с  обозначенным  деревом  исполнения  задач  предприятия.  Объектная  агрегация  выполняется  в  соответствии  с  установленной  предметной  иерархией  анализируемых  объектов  управления.  Проектирование  схем  агрегации  данных  производятся  в  графическом  и  табличном  формате.  Механизм  агрегирования  данных  описан  в  работах  [2;  3].

Рисунок  3.  Схема  первичной  и  вторичной  агрегации  данных

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

Список  литературы:

1.Шведенко  В.Н.,  Веселова  Н.С.  Методика  проектирования  объектно-процессных  систем  управления  предприятием  на  платформе  ОО  СУБД  «COBRA++»  //  Научно-практический  журнал  «Интеграл»,  —  №  5—6  (79—80),  —  2014  г.,  —  с.  115.

2.Шведенко  В.Н.,  Шведенко  В.В.,  Постников  А.М.  Модель  агрегированных  значений  плановых  и  фактических  показателей  в  объектно-ориентированных  СУБД  //  Научно-практический  журнал  «Интеграл»,  —  №  1,  —  2014  г.,  —  с.  78—80 

3.Шведенко  В.В.,  Шведенко  П.В.  Агрегирование  данных  в  ОО  СУБД  «COBRA++»  //  Научно-практический  журнал  «Интеграл»,  —  №  5—6  (79—80),  —  2014  г.,  —  с.  31.