BC/NW 2014 №2 (25):11.2
ИНФОРМАЦИОННО-АНАЛИТИЧЕСКАЯ СИСТЕМА СБОРА И ОБРАБОТКИ ПЛАНОВОЙ И ОТЧЕТНОЙ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ ОТ ПОДВЕДОМСТВЕННЫХ МИНОБРНАУКИ РОССИИ ОРГАНИЗАЦИЙ
Богомолова А.С., Куликова А.В., Полотнов М.М., Щербаков Д.А., Юрченко И.И.
(ФГБОУ ВПО «Национальный исследовательский университет «МЭИ», Москва, Россия)
Эффективное решение задач бюджетного планирования и расчетов финансового обеспечения выполнения государственных заданий на оказание услуг (выполнение работ) и иные цели требует наличия плановых и отчетных показателей финансовой деятельности подведомственных Минобрнауки России организаций. В ходе реализации цикла планирования указанные показатели собираются с подведомственных организаций, верифицируются, агрегируются, при необходимости уточняются, и затем применяются в качестве исходных данных для проведения расчетов, а также в аналитических целях при анализе показателей бюджета и формировании отчетности.
В процессе эксплуатации разработанных ранее и эксплуатируемых в настоящее время в Минобрнауки России программных средств [1] выявлены существенные недостатки, среди которых основными являются:
- неоднородность технологической платформы сбора и обработки данных по отдельным направлениям, широкая номенклатура приложений для работы с данными различных предметных задач и исторических периодов;
- пакетно-ориентированные модели и алгоритмы агрегации данных, затрудняющие формирование сводов и точечную актуализацию сведений по отдельным организациям;
- жесткая интеграция логики обработки данных в код приложений – изменение перечня собираемых показателей и (или) состава форм требуют переработки и замены версий программного обеспечения (ПО), расширение номенклатуры приложений.
Описанные недостатки определили основные направления модернизации баз данных и ПО:
- унификация технологической платформы, форматов хранения данных и средств их обработки;
- обеспечение единообразного интерфейса и единый принцип работы с данными;
- обеспечение единой точки входа для работы с данными всех предметных задач и исторических периодов;
- разделение данных и логики их обработки, обеспечение максимальной независимости централизованных баз данных и ПО их обработки от состава и структуры собираемых и обрабатываемых показателей;
- обеспечение автоматического контроля и развертывания новых версий ПО, реализацию схемы автоматической конвертации пользовательских данных при переходе на новые версии.
В процессе модернизации разработаны и реализованы:
- качественно новая модель данных формирования и ведения информационных массивов для расчетов бюджетных ассигнований в разрезе государственных услуг, позволяющая осуществлять хранение сведений в одном физическом хранилище, независимо от состава и структуры показателей в рамках отдельных предметных задач, реализованная в виде реляционной базы данных и формата обмена сведениями;
- алгоритмы агрегации данных, обеспечивающие детализированный доступ к отдельным сведениям по отдельным организациям в режиме реального времени и к заданным историческим периодам; алгоритмы реализованы в виде модулей агрегации модернизированных программных средств;
- унифицированные программные средства, реализующие однородную технологическую платформу доступа к отдельным направлениям и данным различных предметных задач и исторических периодов.
Модернизированные модели формирования и ведения информационных массивов для расчетов бюджетных ассигнований реализованы в виде реляционной базы данных сбора и обработки первичной плановой и отчетной информации, поступающей от подведомственных Минобрнауки России организаций и внешних информационных систем, и формата обмена данными.
Логическая структура основного блока модели данных изображена на рисунке 1. На рисунке отображены основные сущности базы данных, описание которых приведено в таблице 1. Для наглядности на схеме не представлены сущности метаданных и служебной информации.
Рисунок 1. Логическая структура модернизированного блока сведений модели формирования и ведения информационных массивов
Таблица 1 - Основные сущности информационного хранилища сбора сведений
|
Сущность БД |
Описание |
|
Организации |
Общий реестр организаций, участвующих в решении задач сбора, а также частные реестры для отдельных задач сбора. Допускается включение в общий и частный реестры организаций, не подведомственных Минобрнауки России, но участвующих в задачах сбора, а также дополнительная детализация реестров путем включения в них филиалов учреждений. |
|
Задачи сбора |
Задача сбора определяет предметную область, для которой используются общие документы (например, штатные расписания, информация для формирования бюджетных ассигнований и т.д.). Задача определяет комплект (либо набор комплектов) форм сбора и перечень организаций, участвующих в задаче. |
|
Задачи_ Организации |
Реализует связь многие-ко-многим между задачами сбора и организациями |
|
Документы |
Основная структурная сущность оперативного хранилища данных подсистемы сбора. Документ агрегирует сведения, сформированные подведомственной организацией. Документ является агрегатом форм в пределах задачи сбора. |
|
Формы |
Форма является промежуточным агрегатом параметров. Форма описывается визуальной таблицей, в которой на пересечении строк и столбцов находятся параметры (вводимые пользователем данные). |
|
Параметры |
Параметр является элементарным элементом данных системы и соответствует значению конкретной ячейки конкретной формы сбора. Все параметры поименованы и имеют уникальный идентификатор в пределах задачи сбора. Идентификатор параметра обеспечивает единство элемента предметной области в любом документе системы в контексте задачи сбора. |
|
Значения |
Значения параметров с учетом форматирования и установленной точности. |
Разработанная модель обеспечивает независимость модели хранения данных от состава и структуры показателей, обеспечивая иерархичность данных, что позволяет создать унифицированную платформу доступа к сведениям и реализовать единый алгоритм агрегации данных.
Модернизация алгоритмов агрегации данных осуществляется с учетом внесенных изменений в модель формирования и ведения информационных массивов для расчетов бюджетных ассигнований. При работе с документами организации используется структура сведений в виде «Задача сбора»-«Параметр»-«Значение», что позволяет осуществлять агрегацию и консолидацию данных с требуемой детализацией. Реализованный алгоритм агрегации может быть описан в виде следующей последовательности операций:
1) приём документов, предоставляемых зарегистрированными пользователями подведомственных организаций через единый интерфейс или Web-сервисы портала сбора сведений;
2) разархивирование файла документа, первичная XML-валидация, проверка целостности данных;
3) XML-парсинг документа;
4) пересчет и сверка контрольной суммы с указанной в документе;
5) проверка соответствия задаче сбора;
6) проверка соответствия организации пользователю;
7) проверка актуальности версии схемы документа, импорт первичного документа в информационное хранилище;
8) импорт сведений в формате параметр-значение в информационное хранилище с применением соответствующей карты документов;
9) проверка сведений импортированных документов кураторами при помощи унифицированных программных средств доступа к сведениям;
10) предоставление результатов проверки сведений доступны пользователям организаций;
11) корректировка сведений пользователями при необходимости;
12) использование данных проверенных документов, корректных достоверных сведений для построения аналитических отчетов.
При разработке унифицированных программных средств, реализующих однородную технологическую платформу доступа к отдельным направлениям и данным различных предметных задач и исторических периодов, использовалась компонентная технология и концепция «Модель-представление-контроллер» (MVC). В рамках данной концепции модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.
Паттерн «Модель-представление-контроллер» позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента. Модель (Model) предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя свое состояние. Представление (View) отвечает за отображение информации (пользовательский интерфейс). Поведение (Controller) интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции. Представление и поведение зависят от модели. В свою очередь модель не зависит от представления и поведения (рисунок 2). Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.
Применение указанной технологии вместе с широкими функциональными возможностями по настройке модели данных позволяет обеспечить адаптацию программных средств к появлению новых задач сбора, возможным изменениям нормативно-методической базы, обеспечивая независимость баз данных и ПО от состава и структуры собираемых и обрабатываемых показателей.
Рисунок 2 – MVC паттерн проектирования
Реализация программных средств осуществляется на единой для всех клиентских мест платформе .NET. ПО представляет собой настольное приложение. Приложение является «толстым» клиентом, использующим централизованное единое для всех задач и направлений сбора сведений хранилище, реализованное по модернизированной модели данных. При запуске исполняемого файла осуществляется автоматическая проверка и обновление при необходимости ПО пользователя при помощи технологии ClickOnce. Доступ пользователей к ПО, данным и сервисам регламентируется настройками сети и именами пользователей в доменной сети. При необходимости ПО может быть настроено на использование диалога ввода логина и пароля для идентификации пользователя. В результате запуска программы пользователю предоставляется единый интерфейс, обеспечивающий доступ ко всем задачам и направлениям сбора сведений. На рисунке 3 представлена экранная форма выбора предметной задачи в рамках унифицированной программной платформы. Программа обеспечивает единый принцип работы с данными всех направлений.
Для перехода к задаче сбора используется древовидное меню, расположенное в левой части формы. Для перехода к сведениям конкретной организации используются дочерние задачи сбора. Для удобства навигации организации разделены на группы в соответствии с реестром.
Рисунок 3 – Интерфейс выбора предметной задачи в рамках унифицированной программной платформы
На рисунке 4 представлен интерфейс проверки сведений организации. В правой части экранной формы расположены таблицы сведений (формы документов). Для перехода между формами используются именованные закладки в нижней части экрана. В верхней части расположены элементы ввода результатов проверки и ввода комментария.
Используя древовидное меню, навигацию между формами, пользователь может осуществить переход к любой предметной задаче всех исторических периодов в рамках единого программного средства.
Программные средства и базы данных ориентированы на применение в задачах, решаемых Департаментом бюджетного процесса, учета и отчетности для реализации бюджетного планирования и определения бюджетных ассигнований, при управлении экономикой отрасли, а также в подведомственных Минобрнауке России учреждениях при подготовке плановой и отчетной информации.
Рисунок 4 – Интерфейс проверки сведений учреждения
Литература
1. Подход к модернизации баз данных и программного обеспечения сбора и обработки плановой и отчетной экономической информации от учреждений, подведомственных Минобрнауки России / А.Г. Стефанцов, А.В. Бобряков, М.М. Полотнов, Е.В. Трофимова, И.И. Юрченко // Естественные и технические науки. – 2013. – №6. – С. 324-328
2. Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения — ПИТЕР, 2012