Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства»


НазваниеОтчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства»
страница17/26
ТипОтчет
1   ...   13   14   15   16   17   18   19   20   ...   26

3.4Разработка предложений по структуре и содержанию стандартов моделирования процессов, проектирования систем, моделирования и описания информации и метаданных, архитектуры прикладных систем, информационных технологий, сетей и коммуникаций, межведомственного обмена информацией, защиты информации, иных стандартов, необходимых для разработки информационных систем и технологий в составе «электронного правительства» Ленинградской области

Стандарты моделирования процессов


Необходимо создание единого подхода к формализованному описанию деятельности органов исполнительной власти Ленинградской области.

Данная цель обусловлена целым рядом мероприятий в области реформы государственного управления в РФ. С точки зрения мероприятий второго этапа административной реформы описание административных процессов и деятельности органов власти в целом технологически необходимо для создания административных регламентов и стандартов услуг. В рамках реформы государственной гражданской службы требуется создание должностных регламентов. Таким образом, формализованное описание административных процессов требуется различным группам потребителей информации, для решения различных задач.

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

  • Методология описания процессов должна позволить получить информацию в специфическом для каждой группе пользователей виде;

  • Процедура описания должна быть относительно простой, тиражируемой, понятной;

  • Электронные средства, поддерживающие реализацию методологии, должны быть открыты для изменений;

Это позволит решить следующие задачи стандартизации формального представления административных процессов:

  1. Оптимизация (реинжиниринг) административных процессов, в том числе носящих межведомственный характер;

  2. Повышение исполнительской дисциплины через четкое закрепление ответственности государственных служащих, участвующих в административных процессах, а также возможность контроля со стороны вышестоящего звена

  3. Повышение прозрачности административных процессов для граждан и организаций, вступающих во взаимодействие с государством, через создание простого для понимания формата представления информации о процессе;

  4. Постановка задач для ИТ-решений в рамках подготовки создания электронных административных регламентов


Решение каждой из поставленных задач ориентировано на определенный тип потребителей информации о деятельности органа власти, поэтому формат представления информации должен быть адекватен типу потребителя. Кто является основным потребителем информации?

Проводимая в данный момент административной реформы предусматривает оптимизацию функций и полномочий федеральных органов исполнительной власти, создание системы регламентации деятельности государственных служащих на основе административных и должностных регламентов, создание унифицированных требований (стандартов) взаимодействия государственных органов с гражданами и организациями. Данные направления должны обеспечить большую прозрачность деятельности государственных служащих, исполнительской дисциплины, снижения транзакционных издержек взаимодействия государства и общества в целом. Для успешной реализации данных направлений необходимы новые инструменты организационного моделирования и анализа. Прежде всего, это связано с тем, что существующая регламентирующая деятельность государственных служащих база излишне бюрократизирована, избыточна, но не обеспечивает персонализацию ответственности за принимаемые решения; не позволяет алгоритмически выстроить деятельность служащих и обеспечить необходимый уровень контроля. Текущая рутинная деятельность государственных служащих практически не документирована. Положения об органах власти, подразделениях и отделах определяют только функциональные области, но не административные процессы. Должностные инструкции не актуализируются при изменении функций и полномочий органов и поэтому практически не используются ни при найме на государственную службу, ни для передачи «знаний» о деятельности на данной должности, ни для оценки и планирования деятельности сотрудников.

Новые регламентирующие механизмы, предлагаемые в рамках административной реформы и реформы государственной службы, такие как административные, должностные и электронные регламенты, стандарты государственных услуг, могут быть созданы при реализации следующей последовательности работ:

  • Описание процессов в режиме «как есть», включая анализ текущей регламентирующей базы и административной практики; Формирование предложений по оптимизации процессов (в том числе, с учетом представлений потребителей услуг);

  • Формирование моделей процесса в режиме «как должно быть»

  • Формирование административного регламента процесса, должностных регламентов служащих, стандарта государственной услуги и их правовое закрепление;

  • Формирование технических требований (технических заданий) на создание электронных регламентов.

Очевидно, что на каждом этапе возникает проблема представления информации, необходим ответ на вопросы: что означает модель процесса, в каком виде информация о процессе проходит этап оптимизации, как сохранить единый источник изменений информации и непротиворечивость различных форм представления о процессе при прохождении всех этапов. Причем все эти процедуры должны учитывать закрепленные законодательно имеющиеся стандарты представления – например, к имеющимся можно отнести положения об органе, его структурных подразделениях, из возникающих в данный момент – административный регламент исполнения государственных функций, административный регламент предоставления государственных услуг, должностной регламент. Следует отметить, что последние нормативные правовые акты в области регламентации позволяют во многом приблизится к процессному подходу, прежде всего на уровне детализации описания процессов (до уровня действий, документов и т.д.). Также осознана и зафиксирована связь между административным регламентом исполнения функций (по сути – процессов) и должностными регламентами государственных служащих. Стандарты государственных услуг выступают как одна из проекций представления административного процесса, направленная на потребителя услуги и содержащая только информацию о точках взаимодействия с государственным органом в ходе процесса. Должностной регламент (в переменной, операционной части) строится на основе административных регламентов процессов, с точки зрения должности. С точки зрения специалистов по информационным решениям также существует набор стандартных форм представления информации, как в виде графических нотаций, так и в виде языков описания процессов.

Тем самым, можно предварительно выделить несколько типов потребителей информации о деятельности органов власти:

  • группа 1 - граждане и организации, пользующиеся услугами ОИВ;

  • группа 2 - вышестоящие органы ОИВ;

  • группа 3 - аудиторы ОИВ;

  • группа 4 - персонал (служащие) ОИВ;

  • группа 5 - руководство ОИВ;

  • группа 6 - эксперты-консультанты, занятые построением моделей деятельности ОИВ, реинжинирингом процессов и структур ОИВ;

  • группа 7 - специалисты по созданию информационных систем, поддерживающих деятельность ОИВ.

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

Можно ли решать поставленные задачи (регламентация, стандартизация услуг, информатизация отдельных процессов, реинжиниринг) автономно, без единого формата описания процессов? Как показывает практика, разработать регламент процесса как описание последовательности административных действий, системе предписаний к очередности работ, содержанию работ исполнителя на каждом шаге процесса исключительно на основе правовой базы невозможно. Регламент по уровню детализации существенно отличается даже от наиболее подробных инструкций, порядков и иных регламентирующих исполнение государственных функций документов. Неизбежно требуется описание текущей административной практики, что является исходной точкой для последующей оптимизации и фиксации желаемого состояния в виде регламента (бумажного или электронного). Можно ли изначально формировать технические решения, на уровне распространенных стандартов моделирования бизнес-процессов, например, в BPML, в UML? Да, но для ограниченной задачи информатизации конкретного процесса, причем такие варианты не позволяют на их основе написать, например, административный регламент, что резко снижает общность решений. Необходимо, чтобы в результате описания (за счет четкого определения необходимой входящей информации) появлялась возможность ее выражения в стандартах бизнес-моделирования, но не наоборот. Обратная ситуация уже невозможна, так как данные стандарты находятся вне контроля российских разработчиков административной реформы. Это приводит еще к одному частному выводу – так как на задаче описания соединяются требования со стороны различных направлений (административное, информационное и т.д.) использование международных стандартов ограничивает, а не способствует решению задачи (ситуация обратная применению стандартов, например, в архитектуре программного обеспечения, где есть зависимость от мейнстрима велика и стандартизация действительно эффективна). В силу того, что ситуация в части регламентации, изменения функционирования органов власти постоянно изменяется, должна быть возможность самостоятельного расширения решения, в частности – состава «входящей» информации и форматов представления информации (отчетов).

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

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

К лидерам функциональности и возможностям полноты описания представленных на российском рынке программного обеспечения можно отнести продукты компаний IDS Scheer и Casewise. Помимо этих продуктов можно выделить так же менее мощные по своим функциональным характеристикам и возможностям полноты описания, но хорошо известные и пользующиеся популярностью инструменты компаний Computer Associates и Microsoft, такие как MS Visio и IBM WORKBENCH. Ввиду того, что инструмент MS Visio компании Microsoft является чисто графическим инструментом, не имеющим методологии, он не рассматривается далее.

В части применяемых методологий продукты Computer Associates поддерживают методологии и стандарты семейства IDEF, компания IDS Scheer предлагает собственную методологию описания – методологию EPC, Corporate Modeler компании Casewise использует известную методологию Захмана.

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

Одна из наиболее популярных методологий – IDEF0. Методология весьма подробно описана, доведена до стандартов, в приемлемое время становится вполне понятной пользователю после объяснения принципов лежащих в её основе. Ограничение на сферу применения методологии определяется тем, что методология IDEF0 сфокусирована на представлении структурной модели процесса с показом управляющих воздействий, используемых ресурсов, процессов обмена данными и не позволяет донести информацию о происходящих процессах с учетом именно временного аспекта и алгоритмической логики.

Одним из главных назначений модели административных процессов служит последующая оценка и анализ порядка их исполнения. Модель изучается специалистами, либо консультантами с целью выявления источников ошибок планирования и источников операционных рисков. Для обеспечения такой возможности модель должна быть понятной тому, кто ее анализирует, а представление должно максимально способствовать облегчению работы по выявлению и устранению недостатков. Методология в этом случае должна обеспечивать предоставление сведений о процессах, их исполнителях, сведений об ответственных за процесс, используемых ресурсах и потоках данных, а также последовательности выполнения подпроцессов и возможных сценариях протекания процесса, однако IDEF0 не отображает динамику процессов. То есть ещё одним существенным ограничением сферы применения методологии IDEF0 является отсутствие возможности учёта и отображения динамики процессов.

Другой хорошо известной методологией является EPC-моделирование процессов посредством ARIS. В отличие от семейства IDEF, методология EPC представляет собой способ описания всех сторон деятельности организации. В ARIS предоставляется возможность очень подробного описания процессов, которое включает в себя потоки документов, материалов, показывает исполнителей той или иной функции и их степень ответственности за нее, отображает инициирующие события. Диаграммы процессов в нотации EPC ARIS содержат большое количество информации, а правила построения диаграммы жестко регламентированы. С одной стороны, строгость правил построения диаграммы дает определенные преимущества, но с другой стороны, требуются значительные затраты на обучение, а в ряде случаев сама возможность и даже необходимость обучить всех просто отсутствует, как например в случае, когда конечными пользователями модели могут выступать рядовые потребители. Еще одним пользовательским ограничением сферы применения диаграмм ARIS можно считать большое количество отображаемой на диаграммах информации. В тех случаях, когда приходится иметь дело с широким кругом пользователей, листы, представляющие диаграммы процесса с применением большого числа специальных пиктограмм, могут оцениваться как излишне перегруженные.

Решения Casewise Framework опираются на подходы Захмана, где методология предоставляет всеобъемлющую структуру, с помощью которой можно отобразить архитектуру организации. Для каждой ячейки собрана подробная информация, описывающая диаграммы ячейки, методы сбора данных, ее взаимосвязи с другими ячейками структуры («framework»). Использование данной методологии представляется особенно удобным в сложных проектах направленных на моделирование сильносвязанных организационных систем. Благодаря гибкости правил построения диаграммы с ее помощью можно легко отображать те аспекты, которые трудно отобразить посредством ARIS и IDEF0. Преимущество этой системы моделирования заключается в продвинутых и развитых возможностях настройки способов отображения объектов и их взаимосвязей. Дело в том, что методология Захмана регламентирует в основном правила построения модели в целом, а что касается правил построения отдельных диаграмм, здесь пользователю представляется большая свобода выбора, что позволяет изображать диаграммы в удобном в каждом случае виде. В данной методологии есть возможность создания временных диаграмм (диаграмм Гантта), которые помогают планировать и управлять ходом процесса, разбивать процесс на подпроцессы, расписывая его на управляемые и контролируемые активности. Таким образом, одним из главных преимуществ данной структуры состоит в том, что регламентируются не только правила создания самой модели, а описывается целостный подход к созданию модели.

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

Важным аспектом любого проекта по автоматизации деятельности является управление требованиями к автоматизации. Цель управления требованиями состоит в том, чтобы заказчик и исполнитель смогли полностью согласовать требования. Поэтому Casewise и ARIS имеют средства интеграции с системами управления требованиями, такими как Rational Requisite Pro, Telelogic DOORS. Стоит также отметить, что инструментальные среды ARIS (IDS Scheer) и Corporate Modeler (Casewise) поддерживают возможность создания диаграмм в соответствии с нотацией UML (Unified Modeling Language). Это унифицированный язык моделирования, явившийся развитием принципов объектно-ориентированного подхода. Может использоваться для представления бизнес-процессов, структур, деревьев функций событий и для проектирования информационных систем. Имеет восемь типов диаграмм (вариантов использования, классов, состояний, активностей, последовательностей, кооперации, компонентов развертывания). Преимущество этого языка заключается в его универсальности - он представляет собой мощное универсальное средство описания моделей различных типов, однако, он достаточно сложен для его применения не профессионалами в области информационных технологий и это является его существенным ограничением по сфере применения. Этот язык широко используется программистами, однако, в государственной организации, где насчитывается множество различающихся по компетенции групп пользователей, использование и понимание этого языка другими группами пользователей затруднено.

Помимо UML целесообразно обратить внимание на еще один известный стандарт - BPML, предназначенный для определения формальной модели, выражающей выполнимые процессы, с описанием основных аспектов порядка исполнения корпоративных бизнес-процессов. Разработки группы BPMI, в частности язык BPML, представляют несомненный интерес с точки зрения создания формализованных средств для описания схем бизнес-процессов. Их можно рассматривать как некоторые обобщения возможностей нотаций и средств моделирования от различных производителей (ARIS, BPWIN, CASEWISE). Однако, надо признать, что идеология построения моделей органов исполнительной власти исходит из более общего подхода и преследует более широкие цели, чем моделирование исключительно последовательности действий.

Таким образом, на основе анализа основных систем моделирования
и практики применения этих систем в государственном и бизнес-секторе, напрашивается вывод о том, что невозможно с помощью одной графической нотации во всей полноте представить все аспекты деятельности организации, интересующие различные группы пользователей. Для органов исполнительной власти пользователи – это граждане и организации, вступающие во взаимодействие с государством, чиновники – исполнители, руководители вышестоящих организаций, разработчики ИТ-систем, и аналитики – эксперты по оптимизации процессов.

Оглядываясь на опыт разных стран по созданию электронного правительства, надо отметить, что каждая страна избирала свой путь моделирования и проектирования. В Канаде, например, пошли по пути перенесения опыта, полученного в бизнесе в область государственного управления. Сегодня там для создания желаемого государственного аппарата реализуется программа по обеспечению трансформации бизнеса /The Business Transformation Enablement Program (BTEP), в рамках данной программы создается и внедряется интегрированный набор инструментов для планирования, проектирования и внедрения трансформаций с использованием лучших практик бизнес проектирования и моделей, соответствующих государственному сектору. В Англии инициатива по созданию электронного правительства реализуется с помощью создания и внедрения Схемы развития электронных сервисов e-Service Development Framework (eSDF). Такая схема обеспечивает структуру для создания спецификаций для совместной работы и стандарты для е-Сервисов, которые будут использоваться в государственном секторе. Однако в целом Схема развития электронных сервисов Английского правительства направлена в первую очередь на согласования форматов представления информации и не затрагивает перестройки административных процессов.
Исходя из приведенного рассмотрения можно сделать вывод о том, что в России сегодня трудно решить проблему моделирования, использую конкретную графическую нотацию моделирования, или конкретную существующую методологию, поскольку требования различных групп пользователей сильно отличаются друг от друга, а каждая конкретная методология имеет свою сферу эффективного применения.

Надо также признать, что конечные требования к электронным регламентам со стороны административной реформы на настоящий момент не доопределены и в ходе проведения работ эти требования будут безусловно развиваться и уточняться.

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

  • Вместо конкретной методологии ориентироваться на применение открытой развивающейся методологии, включающей в качестве минимального ядра уже очевидные решения по построению моделей деятельности органа власти, эффективность и необходимость которых признается на настоящий момент и на перспективу, а также систему работы (метаметодологию) по развитию методологии моделирования.

  • Системное накопление требований со стороны разработчиков административной реформы.

  • Системное накопление требований по выводу информации о регламентах для разных групп пользователей, вводу информации о регламентах от разных групп специалистов, необходимых способах представления, анализа и проектирования моделей регламентов администраторами моделей.

  • Системное накопление требований по сопряжению решений с ИТ –стандартами и «универсальными» языками моделирования, а также известными эффективными системами моделирования.

  • Отбор приоритетных требований, развитие системы моделирования под приоритетные требования.

  • Создание и пошаговое развитие программного ядра системы моделирования административных регламентов.

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

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

Единая модель также позволяет расширить набор способов оптимизации отдельных процессов с учетом их связей с другими видами деятельности, распределения ресурсов. Это не означает необходимости детального описания органа в целом для решения частной задачи описания одного административного процесса, но позволяет увидеть процесс в общей системе деятельности органа власти.

Стандарт моделирования процессов, основанный на данной парадигме, приведен в приложении 2 к настоящей работе. Он не предусматривает использование определенного электронного средства моделирования процессов, но лишь определяет систему требований к любым электронным средствам моделирования процессов.

Стандарты проектирования систем

Ключевым фактором успеха в реализации компонентной технологии становятся методология и средства анализа и проектирования многокомпонентных информационных систем. Методология создания информационных систем с компонентной архитектурой "выросла" из объектно-ориентированной методологии проектирования распределенных систем.

Наиболее распространенной является методология, основанная на использовании унифицированного языка моделирования (UML - Unified Modeling Language в настоящее время принят OMG в качестве стандарта смысл фразу не понятен), поддержана целым спектром инструментальных программных средств визуального моделирования, совместной разработки (поддерживаются основные языки программирования С++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder), автоматизированного тестирования и документирования, охватывающих жизненный цикл создания программных систем.

Стандарты описания информации и метаданных

В качестве основного стандарта описания информации должны использоваться ER-диаграммы.

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или entity-relationship diagram ) — это модель данных, позволяющая описывать концептуальные схемы. Она предоставляет графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

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

ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).

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

Существует несколько графических нотаций описания ER-диаграм (несколько похожих ER-моделей данных). Классический вариант описывается во второй части данной статьи. Есть несколько типичных примеров использования ER-модели данных: IDEF1x (ICAM DEFinition Language) и dimensional modelling.

В качестве графической нотации для ER-диаграммы рекомендуется использовать UML (сокр. От англ Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

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

  1. Диаграмму классов

Диаграмма классов, Class diagram — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты и зависимости между классами.

  1. Диаграмму компонентов, Component diagram — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

  2. Диаграмму пакетов, Package diagram — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Диаграмму деятельности, Activity diagram — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого. Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

Метаданные могут либо описывать сам ресурс (например, название и размер файла), либо содержимое ресурса. По отношению к ресурсу в целом. Метаданные могут относиться к ресурсу в целом или к его частям. По возможности логического вывода. Метаданные можно подразделить на три слоя: нижний слой — это «сырые» данные сами по себе; средний слой — метаданные, описывающие эти данные; и верхний слой — метаданные, которые позволяют делать логический вывод, используя второй слой.
1   ...   13   14   15   16   17   18   19   20   ...   26

Похожие:

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о выполнении научно-исследовательской работы по теме: «Разработка...
«Разработка конкретных предложений по повышению эффективности морского законодательства»

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о научно-исследовательской работе «Оценка места России в рейтинге...
«Оценка места России в рейтинге по уровню развития «электронного правительства» в рамках создания единой информационной системы мониторинга...

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconТехническое задание выполнение работ по модернизации и оказание услуг...
Выполнение работ по модернизации и оказание услуг по технической поддержке автоматизированной информационной системы «Реформа жкх»...

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о выполнении научно-исследовательской работы
«Разработка концепции оценки регулирующего воздействия при подготовке проектов нормативно-правовых актов»

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о выполнении работ по Государственному контракту № гк-171-оф/Д01...
Директор Департамента государственного регулирования в экономике Минэкономразвития России

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о выполнении работ по Государственному контракту № гк-171-оф/Д01...
Директор Департамента государственного регулирования в экономике Минэкономразвития России

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconФункциональная модель комбайна
Задачи построения функциональной модели комбайна «Нива» состоят в проведении анализа взаимодействия его подсистем, взаимодействие...

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconПояснительная записка Методическая разработка по теме: «Прием и оформление...
Методическая разработка по теме: «Прием и оформление периодической подписки» подготовлено для обучающихся по специальности «Почтовая...

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconРазработка и внедрение информационной системы
Федеральным законом от 18 июля 2011 г. №223фз «О закупках товаров, работ, услуг отдельными видами юридических лиц» и Положением...

Отчет о выполнении работ по теме: «Разработка концептуальной, функциональной, информационной и технической структуры «электронного правительства» iconОтчет о выполнении нир «Техническое проектирование, разработка нормативного...
Межрегиональная общественная организация содействия развитию рынка геоинформационных технологий и услуг

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск