Изображения

Обычная версия

Концептуальная модель КИСУ

19 января 2012, 17:49

Перечень сокращений и условных обозначений

АБДД

Автоматизированный банк дорожных данных

АПК

Аппаратно-программный комплекс

АРМ

Автоматизированное рабочее место

АС

Автоматизированная система

АСОУП

Автоматизированные системы оперативного управления производством

АСУП

Автоматизированная система управления предприятием

АТС

Автоматическая телефонная станция

БД

База данных

ВК

Ведомственные классификаторы

ВКС

Видеоконференцсвязь

ВСС

Ведомственная сеть связи

ГИС

Геоинформационная система

ГРЩ

Главный распределительный щит

ГСДХ

Государственная служба дорожного хозяйства Министерства транспорта Российской Федерации

ГУ

Государственное учреждение

ГУП

Государственное унитарное предприятие

ДГУ

Дизель-генераторная установка

ДРСУ

Дорожное ремонтно-строительное управление

ДСД

Дирекция строящейся дороги

ДТП

Дорожно-транспортные происшествия

ДХ

Дорожное хозяйство

ДЭП

Дорожно-эксплуатационное предприятие

ЕСКК

Единая система классификации и кодирования

ИАС

Информационно-аналитическая система

ИБД

Интегрированный банк данных

ИБП

Источник бесперебойного питания

ИО

Информационное обеспечение

ИОС

Информационная офисная система

ИС

Информационная система

ИССО

Искусственные сооружения

КВС

Корпоративная вычислительная система

КИСУ

Корпоративная информационная система управления

КРУ

Контрольно-ревизионное управление

КСА

Комплекс средств автоматизации

КСЭП

Корпоративная система электронной почты

ЛБД

Локальная база данных

ЛВС

Локальная вычислительная сеть

ЛК

Локальные классификаторы

НИОКР

Научно-исследовательские и опытно-конструкторские работы

НСД

Несанкционированный доступ

НСИ

Нормативно-справочная информация

НТС

Научно-технический совет

ОАСУ

Отраслевая автоматизированная система управления

ОБД

Отраслевой банк данных

ОК

Общероссийские классификаторы

ОС

Обеспечивающая система

ОУДХ

Орган(ы) управления дорожным хозяйством

ПВК

Пункт видеоконтроля

ПИР

Проектно-изыскательские работы

ПО

Программное обеспечение

ПОВА

Система обнаружения вирусной активности

ППО

Прикладное программное обеспечение

ПС

Прикладная система

ПСД

Проектно-сметная документация

ПУИД

Пункт учета интенсивности движения

ПУЭ

Правила устройства электроустановок

ПЭД

Программно-эксплуатационные документы

ПЭКД

Система электронно-цифровой подписи и кодирования данных

Росавтодор

Государственная служба дорожного хозяйства Министерства транспорта Российской Федерации

РП

Рабочее помещение

СБД

Служебные базы данных

СБЭ

Система бесперебойного электроснабжения

СВТ

Средства вычислительной техники

СГДС

Система гарантированной доставки сообщений

СГЭ

Система гарантированного электроснабжения

Синхрони­зация данных

Механизм обеспечения целостности данных при их интеграции из баз данных различной структуры и формата

СКЗИ

Система сертификации средств криптографической защиты информации

СКК

Система классификации и кодирования

СКС

Структурированная кабельная система

СНиП

Строительные нормы и правила

СОИБ

Система обеспечения информационной безопасности

ССУЗ

Средне-специальное учебное заведение

СУБД

Система управления базами данных

СЭ АРМ и ЛВС

Система электроснабжения АРМ и ЛВС

СЭДД

Система электронного документооборота и делопроизводства

ТДФ

Территориальный дорожный фонд

ТЗ

Техническое задание

ТОУ

Территориальный орган управления

УАМ

Управление автомагистрали

УСД

Унифицированная система форм документов

ФГУП

Федеральное государственное учреждение

ФУАД

Федеральное управление автомобильных дорог

Центрдор­контроль

Центр лабораторного контроля, диагностики и сертификации

ЦОИ

Центр обработки информации

ЦУП

Центры управления производством

ЧТЗ

Частное техническое задание

ЭЦП

Электронно-цифровая подпись

Глоссарий

Авторизация пользователей – процесс предоставления доступа пользователям на основе их идентификационных данных.

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

Аутентификация – проверка принадлежности пользователю предъявленного им идентификатора. Аутентификация наряду с авторизацией представляют собой средства защиты от несанкционированного доступа.

Дублинское ядро (Dublin Core, DC) – принятый в качестве международного стандарта базовый набор элементов метаданных для описания семантики XML-документов с целью обеспечения универсального доступа к ним и поиска в архивах.

Единая точка входа – понятие «единая точка входа в систему» позволяет говорить о следующих возможностях:

- однократную централизованную регистрацию пользователей при входе в систему;

- возможность организации индивидуальных рабочих мест пользователей с предоставлением доступа ко всем необходимым прикладным системам;

- общий интерфейс множественных вызовов прикладных систем.

Идентификация пользователей – проверка наличия предъявляемого идентификатора в списке зарегистрированных.

Межсетевой экран (firewall) – аппаратно-программный комплекс, который защищает ресурсы частной сети от пользователей других сетей.

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

- возможность переноса прикладных систем, с минимальными изменениями на широкий диапазон систем;

- совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах;

- взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей);

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

Тег – семантическая единица языка разметки текста, состоящая из заголовка, содержимого и завершающей конструкции.

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

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

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

BPM (BusinessProcessManagement) – технологии управления технологическими процессами.

BizTalk  – технология интеграции приложений, предложенная Microsoft.

DOM-Parser – программа-анализатор для проверки структурной и синтаксической корректности XML-документов.

DNS (domain name system) – служба доменных имен.

DHCP (Dynamic Host Configuration Protocol) – сервис, используемый для автоматического назначения IP-адресов хостам.

EAI (EnterpriseApplicationsIntegration, EAI) – системы интеграции корпоративных приложений. Технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации.

IDEF0 – Международный и российский стандарт (РД IDEF 0 – 2000) и технология моделирования производственных и организационных процессов в организациях. IDEF0 (Icam DEFinition-0) был принят как стандарт моделирования в 1993 году Национальным Институтом Стандартов и Технологий (www.nist.gov). Согласно этой технологии анализируемый процесс представляется в виде совокупности множества взаимосвязанных действий, которые взаимодействуют между собой на основе определенных правил, с учетом потребляемых информационных, человеческих и производственных ресурсов. Поддерживается рядом программных продуктов (в том числе BPwin), используемых для автоматизированного моделирования бизнес-процессов.

GUI (graphicuserinterface) – графический пользовательский интерфейс.

HTTP (HypertextTransferProtocol) – протокол передачи гипертекста.

MS DOS – Microsoft Disk Operation System.

On-line – режим реального времени.

RDF-спецификация – явное описание семантики XML-документов основанное на использовании средств, предложенных в стандарте Resource Definition Framework (RDF).

RDF (Resource Definition Framework) – шаблонописанияресурсов.

SMTP (Simple Mail Transfer Protocol) – протоколпередачиэлектроннойпочты.

SOAP (Simple Object Access Protocol) – простой протокол доступа к объекту. Этот стандарт описывает протокол вызова веб-службы (удаленный процесс доступа к услугам/информации некоторой прикладной системы).

TCP/IP (Transmission Control Protocol/Internet Protocol) – полный комплект протоколов сети интернет.

UDDI (Universal Description, Discovery, and Integration) – универсальный метод описания, обнаружения и интеграции веб-служб. Технология UDDI предоставляет средства, с помощью которых любые приложения или услуги, описанные в терминах веб-служб, могут быть распознаны другими приложениями.

URI (UniformResourceIdentifier) – единый идентификатор ресурсов.

URL (UniformResourceLocater) – ссылка на ресурсы глобальной информационной сети.

VPN(VirtualPrivateNetwork) – виртуальная частная сеть. Это технология виртуальных каналов, обеспечивающая защищенную передачу данных по открытым сетям.

WSDL (Web Services Description Language) – языкописаниявеб-служб. Это основанный на стандарте XML язык, который определяет способ доступа к веб-службам. Он описывает функциональные возможности веб-служб и группирует операции взаимодействия в определенные интерфейсы, задающие способы выполнения операций и те параметры, которые должны быть на входе и выходе.

Web-обозреватель – программа для просмотра Web-страниц.

Web-сервис –программируемый ресурс, доступный по определенной ссылке, который программным образом возвращает определенную информацию.

WINS (Windows Internet Name Service) – служба, поддерживающая распределенную, динамически обновляемую базу имен хостов и соответствующих им адресов IP

XML-документ – документ написанный на языке XML.

XML (Extensible Markup Language) – расширяемый язык разметки информации.

XMLParser – программа-анализатор которая анализирует (разбирает) XML-документ, чтобы с ним могла продолжить работу некоторая программа.

XQL (XML Query Language) – язык запросов для XML.

XSLT (XSLTransformation) – механизм трансформации XML-документов.

Введение

Автомобильные дороги являются важнейшей составляющей транспортной инфраструктуры Российской Федерации. Создание и внедрение Корпоративной информационной системы управления Государственной службы дорожного хозяйства Министерства транспорта Российской Федерации (далее – КИСУ Росавтодора) призвано способствовать эффективному функционированию и устойчивому развитию сети автомобильных дорог, что является необходимыми условиями увеличения экономического роста, обеспечения целостности и национальной безопасности страны, повышения уровня и улучшения условий жизни населения.

При разработке концептуальной модели КИСУ Росавтодора учитывались основные положения «Концепции использования информационных технологий в деятельности федеральных органов государственной власти до 2010 года», разработанной Минсвязи России совместно с Минэкономразвития России, Минпромнауки России, Минобразования России, ФСБ России, ФСО России, Росархивом, РАСУ, Гостехкомиссией России и Госстандартом России с участием Российской академии наук.

Целью создания и внедрения КИСУ Росавтодора, также как и основной целью применения информационных технологий в деятельности федеральных органов государственной власти, изложенной в Концепции, является «повышение эффективности, информационной открытости и прозрачности механизмов государственного управления».

В свете основных положений «Концепции использования информационных технологий в деятельности федеральных органов государственной власти до 2010 года» построение КИСУ Росавтодора ведется с целью:

1) повышения  уровня  взаимодействия и коллективной работы сотрудников федеральных органов государственной власти;

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

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

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

5) повышения эффективности координации развития и модернизации транспортной инфраструктуры, обеспечения мониторинга импортных, экспортных и транзитных грузопотоков и координация развития международных транспортных коридоров;

6) совершенствование механизмов документационного обеспечения деятельности федеральных органов государственной власти на базе электронного документооборота и электронных административных регламентов;

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

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

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

Использование типовых, по своей организации, банков данных, а также применение стандартизованных протоколов обмена информацией и максимальная открытость прикладных систем, позволит адаптировать КИСУ Росавтодора в ходе ее эксплуатации в соответствии с изменяющимися потребностями Росавтодора. Это также позволит интегрировать ее с другими комплексами автоматизации как внутри Министерства транспорта Российской Федерации, так и других министерств и ведомств.

1. Описание объекта автоматизации

1.1. Цели и задачи Государственной службы дорожного хозяйства

Государственная служба дорожного хозяйства – отраслевой блок Министерства транспорта Российской Федерации (Минтранс России), федерального органа исполнительной власти, проводящего государственную политику и осуществляющего управление в области транспортного комплекса. В соответствии с законодательством Российской Федерации Росавтодор осуществляет функции по управлению федеральными автомобильными дорогами (автодорогами) общего пользования и федеральным имуществом, необходимым для их функционирования. Основными задачами Росавтодора являются:

1) реализация государственной политики в дорожном хозяйстве (ДХ), развитие сети федеральных автодорог общего пользования, улучшение транспортно-эксплуатационного состояния автодорог общего пользования;

2) организация и контроль исполнения федерального бюджета в части финансирования ДХ, управление средствами федерального бюджета, направляемыми на финансирование ДХ;

3) разработка в установленном порядке стратегии развития ДХ в Российской Федерации;

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

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

6) проведение единой экономической, научно-технической, инновационной, инвестиционной, кадровой, социальной и внешнеэкономической политики в ДХ;

7) координация развития сети автодорог общего пользования Российской Федерации во взаимодействии с федеральными органами исполнительной власти и органами законодательной и исполнительной власти субъектов Российской Федерации;

8) формирование и совершенствование нормативной правовой базы, форм и методов управления и регулирования деятельности ДХ;

9) регулирование деятельности подведомственных организаций, обеспечение проведения структурной перестройки в ДХ;

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

Описание существующих управленческих процессов в виде IDEF диаграмм приведено в Приложении 2.

1.2. Структура Государственной службы дорожного хозяйства

Структура Росавтодора (здесь и далее сведения об объекте автоматизации приводятся на момент окончания обследования – декабрь 2003 г.) представлена на рис. 1.

Рис. 1. Структура Росавтодора

Имущественный комплекс дорожного хозяйства включает в себя:

­ автомобильные дороги общего пользования;

­ искусственные сооружения на автомобильных дорогах общего пользования;

­ государственное имущество, необходимое для ремонта и содержания дорог.

В состав Росавтодора входят следующие организации:

­ Центральный аппарат Росавтодора, в который входят структурные подразделения Центрального аппарата Минтранса России, осуществляющие функции управления ДХ;

­ органы управления дорожным хозяйством (ОУДХ) – государственные учреждения (ГУ), реализующие функции государственных заказчиков по эксплуатации и строительству федеральных автодорог и объектов ДХ (табл. 1);

­ центры и дирекции, реализующие вспомогательные функции управления ДХ (Приложение 1).

Росавтодор имеет трехуровневую иерархическую структуру, верхний уровень которой составляет Центральный аппарат, второй уровень – 41 ГУ (ОУДХ, центры и дирекции), третий уровень – 396 ФГУП (ДРСУ, ДЭУ и др.). Характер информационного обмена между основными организациями (в качестве основных организаций второго уровня выступают ОУДХ, третьего уровня – ДРСУ, ДЭУ) показан на рис. 2. На уровне ОУДХ и ДРСУ формируется информация о финансово-экономической деятельности организаций, о состоянии дорог и сопутствующих объектов, об обстановке на дорогах и т. д. Собранная информация передается в Центральный аппарат для формирования консолидированной отчетности и ключевых показателей для принятия управленческих решений. Из Центрального аппарата в ОУДХ и ДРСУ передаются планы и бюджеты, распоряжения, справочная информация общего пользования.

Рис. 2. Характер информационного обмена между структурными уровнями Росавтодора

Центральный аппарат Росавтодора также имеет внутреннюю трехуровневую иерархическую структуру, элементами верхнего уровня которой является руководство Центрального аппарата, второй уровень составляют 5 департаментов и 6 управлений, а третий, нижний уровень иерархии образуют 48 отделов (рис. 3).

Рис. 3. Структура Центрального аппарата Росавтодора

Росавтодор обеспечивает руководство деятельностью 396 федеральных государственных унитарных предприятий (ФГУП), выполняющих:

­ строительство, ремонт и содержание федеральных автомобильных дорог;

­ научно-исследовательские и проектно-изыскательские работы;

­ развитие дорожной инфраструктуры и сервиса;

­ материально-техническое обеспечение и лизинг;

­ санаторно-курортные и лечебно-оздоровительные услуги;

­ подготовку и переподготовку кадров и другие виды деятельности.

2. Общие положения КИСУ

2.1. Предпосылки создания КИСУ

Успешная реализация государственной политики в области дорожного хозяйства зависит от эффективности управления отраслью – использования имеющихся мощностей и ресурсов, но в особенности – от оперативности и эффективности использования новых знаний и технологий. На сегодняшний день в Росавтодоре ведутся работы по автоматизации управления отраслью и некоторые задачи частично автоматизированы. Так, например, используется банк дорожных данных (АБДД «Дорога») и ведутся реестры сведений о земельных участках, закрепленных за государственными унитарными предприятиями и государственными учреждениями («Реестр-2»). Но многие задачи не автоматизированы, и существующее программное обеспечение не в состоянии обеспечить автоматизацию деятельности Росавтодора в полном объеме и на современном уровне.

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

­ создание условий для улучшения социально-экономического положения страны и освоения новых территорий;

­ укрепление обороноспособности и экономической безопасности государства;

­ повышение конкурентоспособности отечественных товаров за счет снижения транспортных издержек при перевозках автомобильным транспортом;

­ развитие автомобильных дорог в соответствии с темпами автомобилизации страны.

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

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

На всех этапах формирования решений необходима разнообразная внешняя и внутренняя информация.

Внешняя – это информация, которая поступает в данный орган управления извне. Например:

­ информация о функционировании дорожной сети;

­ информация о сроках ремонтов автомобильных дорог;

­ сведения о техническом уровне автомобильных дорог и их пропускной способности;

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

Внутренняя – это информация, которая формируется в самом органе управления в процессе подготовки и принятия решения, а также контроля его исполнения. Например:

­ распоряжения;

­ методические и нормативные материалы;

­ отчеты.

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

­ нарушение традиционно сложившихся связей между заказчиками, подрядчиками и поставщиками оборудования и материалов;

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

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

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

­ практическая невозможность или затрудненность получения оперативных консультаций ведущих специалистов по текущим вопросам деятельности;

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

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

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

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

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

2.2. Цели и задачи КИСУ

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

Основными целями создания КИСУ являются:

1) повышение качества и эффективности управления дорожным хозяйством РФ;

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

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

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

5) создание электронного кадастра землеустроительной документации, совершенствование системы государственной регистрации прав на недвижимое имущество и сделок с ним, повышение эффективности контроля охраны и использования земельных ресурсов;

6 повышение эффективности координации развития и модернизации транспортной инфраструктуры, мониторинга импортных, экспортных и транзитных грузопотоков и координация развития международных транспортных коридоров;

7) анализ экономической эффективности деятельности федеральных государственных унитарных предприятий;

8) управление финансовыми, материально-техническими, кадровыми ресурсами;

9) совершенствование механизмов документационного обеспечения деятельности Росавтодора на базе электронного документооборота и электронных административных регламентов;

10) обеспечение информационной безопасности Росавтодора.

Поставленные перед КИСУ Росавтодора цели реализуются за счет:

1) увеличения производительности труда работников Росавтодора благодаря автоматизации трудоемких функций по получению и обработке информации;

2) сокращения объемов трудоемких рутинных операций, связанных с обменом информацией, выполняемых на всех этапах управленческих процессов и производственно-хо­зя­йст­вен­ной деятельности Росавтодора;

3) повышения достоверности получаемой, обрабатываемой и хранимой информации, используемой в процессе деятельности Росавтодора;

4) повышения оперативности контроля над деятельностью Росавтодора;

5) сокращения сроков и повышение качества проведения управленческих процессов, а также подготовки и оформления документов;

6) улучшения координации деятельности работников Росавтодора в рамках совместной деятельности;

7) формирования для руководства Росавтодора консолидированной отчетности, включающей в себя все основные финансово-экономические показатели дея­тельности Росавтодора;

8) сбора информации о финансово-хозяйственной и производственной деятельности Росавтодора;

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

Для достижения указанных целей КИСУ решает следующие основные задачи:

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

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

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

4) интеграция используемого в настоящее время и вновь создаваемого программного и информационного обеспечения и организация их взаимодействия и совместного функционирования при реализации управленческих процессов Росавтодора;

5) обеспечение удобного, единообразного и безопасного доступа различных категорий пользователей к системе с использованием различных каналов связи и различных устройств.

Критерием достижения поставленных целей является создание корпоративной информационной системы управления в установленные сроки и позволяющей обеспечить достижение поставленных перед КИСУ целей.

2.3. Общие принципы построения КИСУ

При создании КИСУ должны быть использованы следующие основные принципы:

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

2) принцип максимально достижимой автоматизации – система должна охватывать как можно большее количество подразделений, направлений деятельности и управленческих процессов Росавтодора;

3) принципы унификации и стандартизации – в основу архитектуры КИСУ должен быть заложен единый методологический подход, должна использоваться единая система классификации и кодирования объектов, единые принципы организации и обмена данных;

4) а также перечисленные ниже условия:

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

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

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

- быстрая отдача – выбираемые решения, должны приносить конкретную пользу деятельности Росавтодора практически с момента внедрения;

- постоянное совершенствование – решения, заложенные в основу КИСУ, должны обеспечить возможность дальнейшего развития КИСУ Росавтодора, для получения оптимальных значений производительности, надежности и удобства использования;

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

2.4. Основные требования к КИСУ

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

Открытость. При создании КИСУ должны использоваться открытые спецификации и стандарты (TCP/IP, XML, SOAP и др.), что обеспечит возможность использования различных программных продуктов (компонент КИСУ), общесистемных, инструментальных и прикладных программных средств, выполненных разными разработчиками. Открытая архитектура позволяет обеспечить:

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

­ согласование КИСУ с информационными системами, использующимися в настоящее время в Росавтодоре;

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

При создании КИСУ будет обеспечена совместимость КИСУ с продуктами Microsoft:

­ прикладные системы КИСУ работают под управлением операционной системы Windows, не ниже Windows 2000;

­ подготовка документации и отчетов выполняется с использованием средств MS Office;

­ для хранения данных прикладных систем используется СУБД MSSQL Server 2000 и выше (в отдельных случаях при согласовании с заказчиком используется СУБД Oracle версии не ниже 8i);

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

Целостность (интегративность). Компоненты КИСУ должны быть объединены в единую целостную систему, которая охватывает как функциональные, так и информационные ресурсы Росавтодора. Интеграция информационных ресурсов должна позволять использовать информацию из различных баз данных (в том числе территориально удаленных), а интеграция функциональных ресурсов должна обеспечивать единый унифицированные доступ к функциональным модулям системы через портал прикладных систем. В качестве основной технологии интеграции используется XML-технология, включающая в себя XML-формат для передачи данных; XSL – для преобразования данных; XSD-схемы для структурирования и интерпретации данных.

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

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

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

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

Кроме того, к КИСУ и ее компонентам предъявляются следующие отдельные требования:

­ система должна решать задачу оперативного и достоверного информирования руководства Росавтодора и его подразделений о текущем положении дел;

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

­ должна храниться картографическая информация с максимальной привязкой к ней объектов и субъектов ДХ;

­ должна быть обеспечена возможность определять источник происхождения данных (определять адресность данных);

­ детальные требования к прикладным системам должны оформляться соответствующими частными техническими заданиями;

­ прикладные системы КИСУ и другие ее компоненты должны проектироваться в соответствии с принципами трехзвенной архитектуры с «тонким» клиентом (описывается далее);

­ разработчики прикладных систем должны использовать общие архитектурные принципы и принципы взаимодействия компонентов КИСУ при описании своих собственных архитектур;

­ все информационные ресурсы КИСУ должны снабжаться метаданными, состав которых определяется «Дублинским ядром» (Приложение 7.4.2);

­ должна быть обеспечена подробная документации на КИСУ и ее составные части для специалистов, обеспечивающих их адаптацию и развитие в соответствии с потребностями Росавтодора.

3. Структура КИСУ

3.1. Структурные элементы КИСУ

Рис. 4. Основные структурные элементы и иерархия КСА КИСУ

КИСУ является системой, обладающей сложной многоуровневой и неоднородной стру­ктурой. Ее основными структурными элементами являются подсистемы следующих типов:

­ прикладная система (ПС) – это подсистема КИСУ, предназначенная для решения определенного класса задач, связанных с функциями управления дорожным хозяйством;

­ система, входящая в состав ядра – это подсистема, реализующая функции интеграции и централизованного управления КИСУ. Совокупность подсистем данного типа образуют ядро КИСУ;

­ обеспечивающая система (ОС) – это подсистема КИСУ, обеспечивающая функционирование системы в целом и отдельных ее прикладных систем.

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

С точки зрения автоматизации Росавтодор представляет собой иерархически организованную совокупность объектов автоматизации, таких как Центральный аппарат, различные конкретные ОУДХ и др. Назовем совокупность компонентов КИСУ, а также технических и программных средств, функционирующих в рамках одного объекта автоматизации, комплексом средств автоматизации (КСА). По существу, каждый КСА является самостоятельной системой, которую можно отнести к классу автоматизированных систем управления предприятием (АСУП), функционирующей в составе отраслевой КИСУ.

Если рассматривать КИСУ как совокупность КСА (количество КСА равно числу объектов автоматизации), то она представляет собой двухуровневую функционально централизованную систему, обобщенная структура которой пред­ставлена на рис. 4. Здесь же показаны структурные элементы КИСУ на примере КСА Центрального аппарата. Необходимо отметить, что структура КСА большинства объектов автоматизации одинакова. В структуре КСА отдельных объектов автоматизации, например ГУ «Центр международных перевозок», могут отсутствовать некоторые компоненты КИСУ.

3.2. Структура вычислительной среды КИСУ

Вычислительная среда, в которой функционирует КИСУ, организована следующим образом (рис. 5). Вычислительная среда каждого КСА представляет собой так называемый «корпоративный Интранет». Это означает, что все подсистемы и элементы внутри одного КСА связаны локальной сетью и взаимодействуют между собой через защищенную среду передачи данных с помощью IP-протокола.

Рис. 5. Структура вычислительной среды КИСУ

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

3.3. Функциональная структура КИСУ

Функциональная структура КИСУ отражает совокупность компонентов и информационные связи между ними. Функциональная структура показана на Рис. 6.

Рис. 6. Функциональная структура КИСУ

С точки зрения уровня решаемых задач, ПС КИСУ образуют трехуровневую иерархию, нижний уровень которой составляют 12 ПС автоматизации оперативной деятельности, средний – 4 ПС мониторинга, анализа и прогнозирования, верхний – 2 ПС информационной поддержки принятия управленческих решений. Нижний уровень, в свою очередь, разбит на 5 функциональных блоков финансового, кадрового, имущественного, производственного учета и учета договорных отношений.

Кроме того, в рамках КИСУ функционирует ПС электронного документооборота и делопроизводства и две ПС, предназначенные для сопровождения информационных хранилищ: ИБД, в котором собираются все данные для общего пользования, и ОБД, в котором хранится отраслевая справочная информация и ведется единая система классификации и кодирования Росавтодора.

Каждая ПС тиражируется и может, в случае необходимости, войти в состав любого КСА.

3.4. Схемы автоматизации структурных подразделений и подведомственных учреждений Росавтодора «как есть» и «как будет»

Схемы автоматизации «как есть» и рекомендуемые схемы автоматизации структурных подразделений Росавтодора приведены в документе «Концептуальная модель КИСУ, Том 2, Альбом схем». Взаимодействие всех пользователей структурных подразделений Росавтодора происходит по схеме, приведенной на Рис. 7. На рекомендуемых схемах автоматизации не показаны некоторые части КИСУ, такие как корпоративный портал, ядро КИСУ, ИБД, и акцентировано внимание на автоматизируемые информационные потоки между компонентами системы и деятельность подразделений.

3.5. Структура КСА

Как уже отмечалось, большинство КСА КИСУ имеют одинаковую внутреннюю организацию (Рис. 7) и включают в свой состав следующие структурные элементы (компоненты):

1. Прикладные системы, предназначенные для решения задач управления дорожным хозяйством, имеющие в своем составе локальные базы данных (ЛБД) и web-службы.

2. Ядро системы, в составе:

2.1. Система безопасности, осуществляющая идентификацию и аутентификацию пользователей и обеспечение их прав доступа к ПС КИСУ. Система безопасности включает в себя модуль контроля сессии, реестр пользователей, систему криптозащиты информации, межсетевые экраны и аппаратные средства защиты на транспортном уровне, а также подсистемы безопасности, входящие в состав отдельных ПС.

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

2.1.2. Реестр пользователей – служебная база данных, содержащая перечень и профили пользователей КИСУ.

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

2.2.1. Навигатор предназначен для диспетчеризации запросов пользователей к web-служ­бам функциональных модулей КИСУ.

2.2.2. Репозитарий функциональных модулей – служебная база данных, содержащая перечень функциональных модулей КИСУ, доступных для каждого профиля пользователя.

2.2.3. Журнал – служебная база данных, предназначенная для ведения аудита работы пользователя в системе на уровне начала-окончания работы с прикладными системами. При необходимости ведения более детального аудита действий пользователя в ПС,  требования будут определены в ЧТЗ на ПС.

2.3. Web-службы – общие для ПС и доступные по определенной ссылке программы, выполняющие некоторые действия и взаимодействующие друг с другом и с другими компонентами КИСУ с помощью стандартов и протоколов XML, SOAP, HTTP.

3. Обеспечивающие системы, а именно:

3.1. Портал прикладных систем, обеспечивающий для всех пользователей КИСУ, нахо­дя­щихся в любом месте и в любое время, единую точку входа в систему и доступ ко всем ее ПС;

3.2. Электронная почта, обеспечивающая транспортировку данных внутри и вне КСА

4. Интегрированный банк данных, предназначенный для сбора, формирования и хранения аналитической информации.

5. Отраслевой банк данных, предназначенный для хранения отраслевой, нормативной и справочной информации и ведения единой системы классификации и кодирования Росавтодора.

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

Рис. 7. Структура КСА

3.6. Архитектура КСА

По типу архитектуры КСА можно отнести к системе, имеющей многозвенную архитектуру с «тонким» клиентом. Такая архитектура предполагает, что система состоит из относительно независимых звеньев – сервера данных, сервера приложений, web-сервера и клиентских приложений (рис. 8):

Рис. 8. Многозвенная архитектура

1) сервер данных осуществляет централизованное хранение, обслуживание и обеспечение целостности данных, предоставляя их по запросу различным приложениям и тем самым реализуя единое информационное пространство для их функционирования;

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

3) web-сервер обеспечивает доступ пользователей к системе и обращается к серверу приложений с запросами на выполнение определенной функции; web-сервер также формирует пользовательский интерфейс, который кодируется и по Интернет-протоколам пересылается в пользовательский компьютер;

4) клиентское приложение с помощью стандартного web-обозревателя отображает элементы пользовательского интерфейса и ведет диалог с пользователем.

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

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

­ многозвенная архитектура менее требовательна к скорости линий связи между приложением-клиентом и сервером приложений, вследствие чего возможна нормальная работа для удаленных клиентов даже по коммутируемым линиям;

­ аппаратные требования для клиентского компьютера минимальны.

В КСА КИСУ многозвенная архитектура реализуется следующим образом:

­ первое звено – сервер данных составляют серверы ЛБД ПС, серверы ИБД и ОБД;

­ второе звено – сервер приложений составляют серверы приложений ПС и соответствующие web-службы, обеспечивающие доступ к функциональным возможностям ПС;

­ третье звено составляет ядро КСА и портал прикладных систем;

­ четвертое звено составляют пользовательские компьютеры с установленным на них web-обозревателем.

4. Компоненты КИСУ

4.1. Прикладные системы

Как уже упоминалось в разделе 3, основными структурными элементами КСА КИСУ являются прикладные и обеспечивающие системы КИСУ. Описание ПС согласно госконтракту приведены в Приложении 4.

4.2. Интеграция ПС

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

Таким образом, в зависимости от своего происхождения, ПС можно разделить на «типовые», «старые» и «новые» системы:

1) типовые ПС – ПС, построенные на базе готовых стандартных тиражируемых решений от независимых разработчиков (например, «1С Бухгалтерия»), которые после определенной настройки и доработки интегрируются в состав КИСУ;

2) старые ПС – ранее созданные (заказные) и эксплуатировавшиеся в Росавтодоре си­с­темы, которые наследуются и после определенной доработки интегрируются в состав КИСУ (уровень необходимой доработки определяется частными техническими заданиями на ПС. Доработка включает в себя синхронизацию словарей и справочников, доработку для интеграции в систему безопасности КИСУ, разработку web-интерфейса и/или web-служб для отображения информации, разработку дополнительных функциональных возможностей);

3) новые ПС – вновь разрабатываемые системы, изначально проектируемые с учетом требований к интеграции в состав КИСУ.

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

1) функциональная интеграция – централизация доступа и унификация процедуры использования всех функциональных возможностей КИСУ;

2) информационная интеграция – обеспечение совместимости всех компонентов КИСУ на уровне информационного обмена.

В мировой практике известны следующие основные технологии интеграции:

1) интеграция корпоративных приложений;

2) межведомственная интеграция;

3) управление технологическими процессами.

Системы интеграции корпоративных приложений (Enterprise Applications Integration, EAI) – технологии, ориентированные на интеграцию различных систем, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application – приложение-приложение).

Системы межведомственной интеграции (Business-to-Business Integration, B2Bi) – технологии, ориентированные на обеспечение надежного и безопасного информационного обмена между различными организациями и их информационными системами по различным каналам связи, в том числе с помощью глобальной информационной сети. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов и дают возможность автоматизировать технологические процессы в рамках «расширенных организаций», включая поставщиков, партнеров, потребителей продуктов и услуг.

Технологии управления технологическими процессами (Business Process Management, BPM), интегрирующие данные, приложения и людей с помощью единых технологических процессов, поскольку технологические процессы организации «пересекают» границы различных приложений, департаментов и организаций. Технологии этого типа являются развитием систем документооборота и систем EAI, ориентированных на пересылку информации между людьми и системами, выполняющими определенные действия внутри одной организации, и технологий B2Bi, ориентированных на интеграцию данных в межведомственной среде.

Для интеграции ПС и других компонентов КИСУ используется подход, сочетающий в себе технологии второго (B2Bi) и третьего (BPM) типов. При этом функциональная интеграция реализуется преимущественно с помощью портала прикладных систем и системы безопасности, а информационная интеграция – с помощью системы гарантированной доставки сообщений, управления технологическими процессами, ИБД и ОБД.

Одним из основных инструментов, обеспечивающих реализацию этих технологий, являются web-службы, которыми снабжаются все ПС КИСУ. Так, при доработке типовых и унаследованных старых ПС необходимо написание web-служб, обеспечивающих получение необходимой информации из их ЛБД. При разработке новой ПС в ее составе изначально должны присутствовать web-службы, интегрирующие ее в КИСУ и обеспечивающие на основе стандартных Интернет-протоколов доступ к функциональным возможностям данной ПС со стороны пользователей и других ПС по локальной или глобальной сетям.

4.3. Признаки прикладной системы в составе КИСУ

Создание КИСУ предполагает комплексную автоматизацию деятельности Росавтодора. Наряду с прикладными системами КИСУ в Росавтодоре могут использоваться и автоматизированные системы, не входящие в состав КИСУ. Прикладные системы КИСУ имеют следующие основные признаки:

­ унифицированный интерфейс;

­ единую точку входа через портал прикладных систем;

­ общие словари и справочники;

­ единая система безопасности;

­ стандартизованные форматы и протоколы обмена информацией между прикладными системами в рамках КИСУ.

4.4. Портал прикладных систем

Портал прикладных систем является основным средством функциональной интеграции КИСУ и предназначен для обеспечения работы пользователей с ПС КИСУ через единую централизованную точку входа в систему. Создание единой точки входа в систему позволяет обеспечить:

1) однократную централизованную регистрацию пользователей при входе в КИСУ;

2) возможность организации индивидуальных рабочих мест пользователей с предоставлением доступа ко всем необходимым ПС;

3) общий интерфейс множественных вызовов ПС.

Как уже отмечалось, портал является средством интеграции ПС, имеющих в своем составе web-службы, обеспечивающие на основе стандартных Интернет-протоколов доступ к их информации и функциональным возможностям. Использование портала прикладных систем совместно с системой безопасности дает возможность аутентификации пользователей, с помощью которой можно не только идентифицировать пользователя, но и строго определить его права по доступу к различной информации и ПС. Благодаря порталу прикладных систем пользователь может работать с ПС с помощью любого устройства, в любом месте и в любое время в защищенном режиме, используя единый интерфейс.

4.5. Описание пользовательского интерфейса

4.5.1. Требования к пользовательскому интерфейсу

Интерфейс всех ПС прикладных систем, разрабатываемых в рамках проекта по созданию КИСУ Росавтодора, должен отвечать принципу единообразия. Построение интерфейса ПС должно базироваться на следующих общих принципах:

­ единообразие внешнего вида ПС;

­ общая логика взаимодействия пользователей с ПС;

­ соблюдение стандартов графического пользовательского интерфейса (GUI);

­ единая эргономика организации рабочего места пользователя;

­ интуитивно понятный и узнаваемый по отношению к внешней среде интерфейс.

Цветовая схема интерфейса прикладной системы должна соответствовать текущим настройкам цветовой схемы операционной системы. Изменение настроек цветовой схемы операционной системы должно динамически отражаться на настройках цветовой схемы интерфейса прикладной системы.

Используемые в интерфейсе прикладной системы для обозначения операций пиктограммы должны быть максимально приближены к пиктограммам, используемым для обозначения аналогичных операций в продуктах Microsoft (Windows, Office, InternetExplorer).

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

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

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

4.5.2. Шаблон главного окна прикладной системы

ПС, работающие в рамках портала прикладных систем, должны взаимодействовать с пользователем посредством стандартных web-обозревателей (MS Internet Explorer версии 5.5 и выше). Таким образом, верхним уровнем интерфейсной оболочки главного окна ПС должно быть окно web-обозревателя, в заголовке которого должно отображаться название ПС. Примерный вид главного окна приведен на Рис. 9.

В отдельных случаях, при согласовании с Заказчиком, допускается использовать обычный Windows интерфейс без применения web-обозревателя.

Главное окно ПС, разрабатываемой в рамках КИСУ, должно располагаться в рабочей области web-обозревателя, соответствовать стандартам интерфейса продуктов линейки XP и может иметь следующие области:

1) главное меню ПС;

2) панель инструментов;

3) строка состояния;

4) рабочая область ПС.

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

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

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

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

Рис. 9.Примерный вид главного окна ПС КИСУ.

4.5.3. Шаблон страницы (диалогового окна)

Структура страницы (диалогового окна), отвечающей за отдельную операцию прикладной системы должна соответствовать стандартной структуре диалогового окна продуктов Microsoft. Структура страницы представлена на Рис. 10. Страница разбивается на три области:

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

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

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

Рис. 10. Структура страницы (диалогового окна) ПС КИСУ.

4.6. Web-службы

Web-служба – это приложение (программируемый ресурс), выполняющее заданные функции и возвращающее определенную информацию в ответ на запрос (вызов). Получение информации от web-службы и доступ к ней осуществляется по определенной ссылке с использованием стандартных протоколов и технологий Интернет, таких как TCP/IP, HTTP, XML, SOAP, WSDL и UDDI (более подробно эти стандарты обсуждаются при рассмотрении технологии информационного обмена между компонентами КИСУ). Благодаря такой унификации пользователю или прикладной системе не надо знать, как реализована и внутренне организована та или иная служба для того, чтобы ее использовать.

Любой компонент КИСУ может быть реализован и/или описан в виде web-службы и быть доступным по Интернет-протоколам.

Одними из наиболее важных в КИСУ являются web-службы, предназначенные для фор­ми­рования XML-документов с данными для передачи и приема XML-документов и загрузки содержащейся в них информации в базу данных.

4.7. Система безопасности

4.7.1. Основные понятия информационной безопасности

Механизмы безопасности в КИСУ должны быть реализованы в форме широко известных в России и в мире, опробованных и одобренных стандартов и протоколов. Основные термины в области обеспечения информационной безопасности, определяемые указанными стандартами:

­ политика – набор формальных (официально утвержденных либо традиционно сложившихся) правил, которые регламентируют функционирование механизмов информационной безопасности;

­ идентификация – определение (распознавание) каждого участника процесса информационного взаимодействия перед тем, как к нему будут применены какие бы то ни было понятия информационной безопасности;

­ аутентификация – обеспечение уверенности в том, что участник процесса обмена информацией идентифицирован верно, то есть действительно является тем, чей идентификатор он предъявил;

­ контроль доступа – создание и поддержание набора правил, определяющих каждому участнику процесса информационного обмена разрешения на доступ к ресурсам и уровень этого доступа;

­ авторизация – формирование профиля прав для конкретного участника процесса информационного обмена (аутентифицированного или анонимного) из набора правил контроля доступа;

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

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

4.7.2. Основные принципы построения системы безопасности Росавтодора

Основные принципы, положенные в основу разработки системы обеспечения информационной безопасности (СОИБ) КИСУ:

4.7.2.1. Законность

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

4.7.2.2. Системность

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

При создании СОИБ должны учитываться все слабые и наиболее уязвимые места информационно-телекоммуникационных систем Росавтодора, возможности появления принципиально новых путей реализации угроз безопасности.

4.7.2.3. Комплексность

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

4.7.2.4. Непрерывность защиты

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

4.7.2.5. Своевременность

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

Разработка подсистем защиты должна вестись параллельно с разработкой и развитием самой защищаемой системы.

4.7.2.6. Преемственность и совершенствование

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

4.7.2.7. Разумная достаточность (экономическая целесообразность, сопоставимость возможного ущерба и затрат)

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

4.7.2.8. Персональная ответственность

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

4.7.2.9. Принцип минимизации полномочий

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

4.7.2.10. Взаимодействие и сотрудничество

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

4.7.2.11. Гибкость подсистемы защиты

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

4.7.2.12. Открытость алгоритмов и механизмов защиты

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

4.7.2.13. Простота применения средств защиты

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

4.7.2.14. Научная обоснованность и техническая реализуемость

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

4.7.2.15. Специализация и профессионализм

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

4.7.2.16. Взаимодействие и координация

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

4.7.2.17. Обязательность контроля

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

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

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

- разграничение доступа;

- антивирусная защита;

- резервное копирование;

- защита от несанкционированного доступа на уровне сети;

- шифрование;

- электронная цифровая подпись;

- контроль целостности;

- обнаружение уязвимостей;

- обнаружение вторжений;

- фильтрация контента.

К основным сервисам, обеспечивающим базовый (минимально необходимый) уровень защищенности, относятся:

- разграничение доступа;

- антивирусная защита;

- резервное копирование;

- защита от несанкционированного доступа на уровне сети.

К дополнительным сервисам, обеспечивающим повышенный уровень защищенности, относятся:

- шифрование;

- электронная цифровая подпись;

- контроль целостности;

- обнаружение уязвимостей;

- обнаружение вторжений;

- фильтрация контента.

4.7.2.18. Разграничение доступа

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

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

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

4.7.2.19. Антивирусная защита

Цель антивирусной защиты – предотвратить проникновение в информационно-телекоммуникационные системы Росавтодора вредоносного программного обеспечения (вирусы, «троянские кони»). Последствия воздействия вредоносного программного обеспечения могут выражаться в утечке конфиденциальной информации или блокировании работы критичного оборудования. По статистике, приводимой группой реагирования на инциденты CERT, вирусные атаки являются наиболее распространенными и часто реализуемыми.

Сервис антивирусной защиты обеспечивает базовый уровень защищенности и должен быть реализован в каждой из информационно-телекоммуникационных систем Росавтодора.

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

4.7.2.20. Резервное копирование

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

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

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

4.7.2.21. Защита от НСД на уровне сети

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

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

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

4.7.2.22. Шифрование

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

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

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

4.7.2.23. Электронная цифровая подпись

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

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

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

4.7.2.24. Контроль целостности

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

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

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

4.7.2.25. Обнаружение уязвимостей

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

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

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

4.7.2.26. Обнаружение вторжений

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

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

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

4.7.2.27. Фильтрация контента

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

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

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

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

4.7.3. Основные положения системы безопасности

Система безопасности КИСУ представляет собой комплекс программно-технических средств и административных (нормативных и организационных) мер, направленных на реализацию политики Росавтодора в области защиты информации и информационной безопасности. Основными составляющими этой политики являются:

1) обеспечение конфиденциальности информации – ознакомиться с информацией может только тот субъект (пользователь или процесс), который уполномочен для этого;

2) обеспечение целостности данных – модифицировать те или иные данные может только тот субъект, который уполномочен для этого;

3) обеспечение доступности информации – информационные ресурсы должны быть доступны для уполномоченного субъекта в необходимое для него время.

Система безопасности КИСУ является частью общей системы информационной безопасности Росавтодора. Предполагается, что для организации и поддержания такой системы в Росавтодор функционирует или будет создано подразделение по обеспечению информационной безопасности, которое возьмет на себя настройку механизмов работы системы в зависимости от текущих требований организации, а также контроль использования информационных ресурсов системы пользователями. При этом указанное подразделение функционирует в рамках соответствующего нормативно-правового пространства, то есть, снабжено соответствующими положениями, утвержденными функциональными и должностными обязанностями, политиками и т.д.

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

Основными задачами системы безопасности КИСУ является обеспечение сохранения данных, связанных с Системой (собственно модулей системы, системных и прикладных данных) таким образом, чтобы:

­ невозможно было получить логический доступ к указанным данным вне рамок работы с компонентами КИСУ;

­ любые перемещения данных из или в КИСУ происходили под контролем системы безопасности.

Эти задачи решаются благодаря встраиванию системы безопасности в ядро КСА, без участия которого не должно осуществляться ни одно значимое действие в рамках КИСУ – будь то действие пользователя или процесса. Можно выделить четыре уровня обеспечения защиты информации и информационной безопасности в КИСУ:

1) системно-административный уровень;

2) аппаратно-технический уровень (или уровень передачи данных);

3) компонентный уровень;

4) функциональный уровень.

4.7.3.1. Системно-административный уровень

Системно-административный уровень предполагает наличие централизованного управления пользователями на уровне доступа к операционной системе. Ядром системы управления доступом является инфраструктура открытого ключа Windows 2000 на базе службы единого каталога Active Directory или центра сертификации ключей. Для управления правами пользователей и настройками рабочих станций используются групповые политики Windows 2000. Инфраструктура открытого ключа не заменяет существующие механизмы доверия и аутентификации домена Windows 2000, в основе которых лежат контроллер домена и центр распределения ключей, а взаимодействует с этими службами и обеспечивает распределенную аутентификацию и механизм однократной аутентификации для доступа к различным ресурсам и компонентам КИСУ.

4.7.3.2. Аппаратно-технический уровень

Аппаратно-технический уровень включает в себя аппаратно-технические средства обеспечения безопасности, необходимые для:

­ организации защищенных каналов передачи данных (VPN, межсетевые экраны и др.);

­ обеспечения конфиденциальности и контроля целостности информации посредством ее шифрования и имитозащиты в соответствии с ГОСТ 28147-89.

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

Требования к аппаратному и сетевому обеспечению КИСУ выражаются в необходимости подержания требуемого (определяемого ниже) уровня безопасности и не снижения его при использовании каких-либо специальных аппаратных устройств.

4.7.3.3. Компонентный уровень

Разграничение доступа пользователей как на компонентном, так и на функциональном уровне осуществляется с помощью процедур идентификации, аутентификации и авторизации. При этом каждому пользователю, в зависимости от исполняемых им функций, назначаются разные права доступа к различным типам данных. Компонентный уровень или уровень разграничения доступа к компонентам КИСУ обеспечивается репозитарием функци­ональ­ных модулей (составная часть ядра КСА), в котором для каждого пользователя системы определяется возможность доступа к тому или иному функциональному модулю КИСУ.

4.7.3.4. Функциональный уровень

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

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

4.8. Система гарантированной доставки сообщений

Для централизации и унификации процедур информационного обмена между компонентами КИСУ вводится промежуточное звено – СГДС как составная часть ядра каждого КСА. В этом случае все ПС должны напрямую взаимодействовать только с СГДС, формируя информационные XML-пакеты и указывая в их теле адресата (адресатов).

СГДС разрабатывается на базе стандартных интернет-протоколов и на базе технологии BizTalk. В функции СГДС входит:

­ формализованное описание и реализация информационного обмена для управления технологическими процессами;

­ поддержка работы с XML-документами и пакетами, обеспечение приема XML-пакетов, их маршрутизация и гарантированная передача адресатам по стандартным протоколам HTTP, SMTP, FTP;

­ поддержка синхронной и асинхронной связи;

­ отслеживание движения документов;

­ отслеживание периодических операций;

­ при необходимости протоколирование совершаемых транзакций;

­ при необходимости сохранение передаваемой информации в ИБД.

4.9. Информационные хранилища

Информация в КИСУ хранится в базах и банках данных четырех типов:

1) в локальных базах данных, предназначенных для хранения информации ПС;

2) в отраслевом банке данных, предназначенном для хранения общесистемных справочников и классификаторов;

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

4) в служебных базах данных, предназначенных для хранения информации о конфигурации КИСУ.

4.9.1. Локальные базы данных

В ЛБД хранятся данные прикладных систем КИСУ. В каждой ПС по мере необходимости может создаваться своя ЛБД, структура и содержание которой полностью определяются требованиями и спецификой соответствующей ПС. Основной задачей ЛБД является накопление и хранение информации об объектах предметной области данной ПС. Наряду с этой информацией, ЛБД могут содержать специализированные файлы, такие как:

­ электронные цифровые карты, используемые геоинформационными модулями ПС;

­ фотографические изображения, видео- и аудиоинформация, чертежи и другая информация с привязкой к конкретным дорожным объектам,

Информация, хранящаяся в ЛБД одной ПС, может быть использована и другими ПС с помощью технологии информационного обмена (п. 5.1). Для повышения быстродействия работы со специализированными файлами возможно их тиражирование на клиентские рабочие места. За тиражирование, репликацию и поддержание специализированных файлов в актуальном состоянии отвечает ядро КСА. При передаче специализированных файлов между различными КСА, если их размеры не позволяют использовать электронную почту, файлы передаются на твердых носителях.

4.9.2. Отраслевой банк данных

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

1) общероссийские и ведомственные словари и классификаторы;

2) ведомственные справочники, включающие в себя: нормативные акты, формы документов, регламентирующие документы и другую информацию.

4.9.2.1. Общероссийские и ведомственные словари и классификаторы

Ведение общероссийских и ведомственных словарей и классификаторов осуществляется централизованно с помощью ПС «Отраслевой банк данных», обладающей исключительным правом добавления новых, редактирования и удаления существующих элементов словарей и классификаторов. Все классификаторы ведутся на основании единой системы классификации и кодирования (ЕСКК). Общероссийские и ведомственные словари и классификаторы реплицируются в ИБД, а все вносимые в них изменения должны оперативно передаваться в ИБД. Все ПС (за исключением ПС «Отраслевой банк данных) должны обращаться за данными общероссийских и ведомственных словарей и классификаторов в ИБД. Описание ЕСКК приведено в  Приложении 6.

4.9.2.2. Ведомственные справочники

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

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

4.9.3. Служебная информация

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

4.9.4. Интегрированный банк данных

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

ИБД создается как на уровне Центрального аппарата Росавтодора, так и на уровне ОУДХ. ИБД уровня Центрального аппарата консолидирует данные из ИБД всех ОУДХ (например, информацию по тендерным торгам, договорам, подрядчикам, объектам имущества дорог, плановым и фактическим объемам работ и т.д.).

4.9.4.1. Семантическая модель ИБД

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

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

Объекты, имеющие идентичную структуру и смысловое наполнение, объединены в классы (понятие класса в концептуальной модели данных соответствует понятию сущности). Каждый класс имеет некоторую внутреннюю структуру, хранящуюся в ИБД отдельно – виде набора атрибутов, связанных с данным классом (например, для класса ДОГОВОР это атрибуты НОМЕР, ПРЕДМЕТ, СТОРОНЫ, СРОКИ и др.). Эта структура наследуется всеми объектами, принадлежащими данному классу. Таким образом, не только данные об объекте, но и структура любого объекта является предметом хранения в ИБД. Благодаря такому подходу, информация о любых объектах предметной области хранится в универсальной форме: класс, объект, атрибут, реквизит, а изменение структуры любого класса и/или объекта вызовет лишь изменение содержимого ИБД, не изменяя при этом структуру ИБД.

На Рис. 11 представлена семантическая модель ИБД, являющаяся метаописанием информации, хранящейся и используемой в КИСУ. Семантическая модель представляется в виде семантической сети (помеченного графа). В узлах этой сети представлены семантические единицы; дуги отражают связи между ними. Дуги содержат метки на концах, обозначающие мощность и полноту этих связей. Каждая семантическая единица имеет:

­ название, отражающее ее роль в описании объектов предметной области;

­ атрибуты, отражающие характеристики и структуру данной семантической единицы;

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

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

Модель ИБД включает в себя следующие семантические единицы:

1) КЛАСС – для хранения описаний объектов предметной области;

2) ОБЪЕКТ – для хранения экземпляров объектов предметной области;

3) АТРИБУТ КЛАССА – для хранения атрибутов объектов предметной области, ассоциированных с классом;

4) ТИП ДАННЫХ –  для хранения перечня допустимых в ИБД типов данных;

5) ДОМЕН АТРИБУТА – для типизации областей значения атрибутов;

6) РЕКВИЗИТ ОБЪЕКТА – для хранения значений атрибутов;

7) ИСТОЧНИК ИНФОРМАЦИИ – для хранения перечня прикладных систем, из которых поступает информация в ИБД;

8) КЛАССИФИКАТОР ОБЪЕКТОВ – для классификации (рубрикации) объектов одного или нескольких классов;

9) ПРОТОКОЛ СЕАНСОВ ПРИЕМА ИНФОРМАЦИИ – для хранения статистических и временных характеристик сеансов приема информации, а также детальной пообъектной информации о сеансах приема информации.

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

1) АНАЛИТИЧЕСКИЙ ПОКАЗАТЕЛЬ –  для хранения значений и описаний аналитических показателей для ИАС;

2) СТРАТЕГИЧЕСКИЙ ПОКАЗАТЕЛЬ – для хранения описаний стратегических показателей для ИАС;

3) СТРАТЕГИЧЕСКАЯ ЦЕЛЬ – для хранения описаний стратегических целей для ИАС;

4) АНАЛИТИЧЕСКИЙ ОТЧЕТ – для хранения описаний отчетов в ИАС.

Рис. 11. Семантическая модель ИБД

5. Взаимодействие компонентов КИСУ

5.1. Участники и процессы взаимодействия

Взаимодействие компонентов КИСУ сводится к информационному обмену между ними. Участниками информационного обмена являются: ИБД уровня Центрального аппарата; ИБД уровня ОУДХ; ПС уровня Центрального аппарата; ПС уровня ОУДХ; ОБД. Взаимодействие компонентов складывается из следующих процессов:

1) взаимодействие ИБД с ПС;

2) взаимодействие ИБД с ИБД;

3) взаимодействие ИБД с ОБД;

4) взаимодействие ПС с ПС.

На Рис. 12 приведена информационная структура КИСУ, отражающая перечисленные информационные потоки и их характер. Информационный обмен инициируется, как правило, одним из следующих факторов:

1) запрос;

2) событие;

3) регламент.

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

Некоторый компонент КИСУ может по своей инициативе направлять информацию одному или нескольким другим компонентам, если при работе этого компонента наступило определенное событие. Таким событием может быть выполнение какой-либо операции в рамках данного компонента или явная инициатива пользователя о передаче информации, достижение каким-либо показателем определенного значения и т.п. Например:

­ после создания документа в ПС он отправляется целиком или частично;

­ после создания, изменения или удаления объекта в ИБД нижнего уровня, должна быть выполнена синхронизация информации в ИБД верхнего уровня.

Согласно установленному регламенту некоторый компонент КИСУ должен с заданной периодичностью (например, каждый день или месяц) пересылать накопленную за этот период времени информацию (детальную или сводную) одному или нескольким другим компонентам. При этом регламент со временем может изменяться.

Основной единицей информационного обмена в КИСУ является объект, информация о котором для передачи представляется в форме XML-документа. В одном XML-документе может содержаться информация о нескольких объектах. Состав информации по каждому объекту определяется структурой класса, к которому относится данный объект.

Рис. 12.  Информационная структура КИСУ

5.1.1. Функциональная схема взаимодействия ПС

Рис. 13. Функциональная схема взаимодействия в рамках одного КСА

Существует три наиболее распространенные схемы обмена данных между ПС в рамках одного КСА (Рис. 13).

В первом варианте (Рис. 13, а), каждая ПС имеет свою собственную локальную базу данных. ЛБД содержит данные непосредственно обрабатываемые отдельно взятой ПС. В случае, когда пользователь ПС запрашивает данные, обрабатываемые другими системами, формируется в установленном формате запрос, в виде XML-пакета. Данный запрос отправляется одной или нескольким ПС,  в которых содержится необходимая информация, через вызов метода соответствующей прикладной системы. Прикладная система, получившая запрос, на основании содержащихся в ее ЛБД данных, формирует  ответ и аналогичным образом направляет его запрашивающей системе. Недостаток этого варианта – при большом количестве запрашиваемой информации, прикладная система (ПС1) может не справиться с обработкой запросов.

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

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

5.1.2. Взаимодействие ИБД с ПС

Взаимодействие ИБД с ПС осуществляется как на уровне Центрального аппарата, так и на уровне ОУДХ. Целями взаимодействия ИБД с ПС является:

1) накопление и обновление в ИБД информации об объектах, для чего ПС уровня ОУДХ должны обеспечить передачу формируемой в них первичной информации в ИБД уровня ОУДХ;

2) описание и поддержание в актуальном состоянии структур классов в ИБД, для чего каждая ПС должна обеспечить передачу в ИБД информации о составе и структуре классов, объекты которых формируются в данной ПС;

3) получение ПС от ИБД необходимой им информации об объектах и классах по запросу.

Таким образом, в процессе взаимодействия каждая ПС должна обеспечить передачу в ИБД информации о:

1) составе и структуре классов, объекты которых формируются в данной ПС;

2) объектах в объеме, соответствующем структуре класса.

ИБД должен обеспечивать:

1) прием, загрузку и обновление описаний классов, полученных от систем;

2) прием информации об объектах,

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

Кроме того, ИБД предоставляет ПС нормативно-справочную информацию и отвечает за ее корректность.

Информационный обмен между ИБД и ПС осуществляется через ядро КИСУ с участием подсистем безопасности и гарантированной доставки сообщений в соответствии с определенным регламентом.

Информация может поступать в ИБД как в автоматизированном (автоматическом) режиме с использованием технологии информационного обмена между компонентами КИСУ, так и в ручном (интерактивном) режиме. В первом случае соответствующая web-служба обрабатывает XML-документ, во втором случае администратор ИБД в интерактивном режиме на основании поступившего и согласованного с заинтересованными сторонами документа.

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

Взаимодействие между ПС и ИБД инициируется запросами со стороны ПС, событиями и регламентом.

5.1.2.1. Прием и загрузка в базу данных описаний классов

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

1) если описание класса передается из ПС в соответствии с общими принципами обмена, то прием и загрузка в ИБД осуществляются автоматически – вызовом специальной web-службы, принимающей и анализирующей XML-документ с описанием класса и выполняющей соответствующую настройку структуры класса в ИБД;

2) если описание класса передается из ПС оформлением согласованного заинтересованными сторонами документа с описанием структуры класса, то прием и загрузка в ИБД осуществляются в ручном режиме – выполнением администратором ИБД настройки структуры класса в интерактивном режиме.

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

1) автоматизировано – ПС должны быть извещены посылкой им XML-документа с новым описанием класса, после чего ИБД должен получить от них подтверждение о принятии новой структуры (с участием администратора системы);

2) оформлением согласованного заинтересованными сторонами документа с описанием новой структуры класса, достаточным для того, чтобы администратор ИБД мог актуализировать структуру класса в базе данных.

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

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

5.1.2.2. Прием информации об объектах и загрузка их в базу данных

В зависимости от регламента, передача информации об объектах происходит либо с зада­нной периодичностью, либо при наступлении различных событий, например при вводе в ЛБД ПС нового объекта, изменении характеристик существующего объекта, удалении объекта.

5.1.3. Взаимодействие ИБД с ИБД

1) передача информации из ИБД уровня ОУДХ в ИБД уровня Центрального аппарата;

2) передача необходимой информации из ИБД уровня Центрального аппарата в ИБД уровня ОУДХ.

ИБД используются на всех уровнях КИСУ – как на уровне Центрального аппарата Росавтодора, так и на уровне ОУДХ. ИБД Центрального аппарата по своему назначению исполняет роль информационного хранилища аналитической информации КИСУ. Для этого между ним и ИБД нижнего уровня должен осуществляться информационный обмен, направленный на обеспечение полноты информации в ИБД верхнего уровня и синхронизацию информации в ИБД нижнего уровня. Таким образом, целями информационного обмена между ИБД разных уровней являются:

1) интеграция в ИБД Центрального аппарата данных из ИБД всех ОУДХ;

2) передача из Центрального аппарата в ОУДХ изменений в нормативно-справочной информации.

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

1) данные из ИБД уровня ОУДХ отправляются в ИБД Центрального аппарата;

2) из ИБД уровня ОУДХ посылается запрос в ИБД Центрального аппарата, в ответ на который в ИБД уровня ОУДХ присылаются данные.

В автоматическом режиме информационный обмен инициируется:

1) по регламенту с заданной периодичностью (например, каждый день или месяц), при этом регламент может задаваться и меняться;

2) по совершении какого-нибудь события  (например, при создании, изменении или удалении объекта).

5.1.4. Взаимодействие ИБД с ОБД

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

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

Таким образом, целями информационного обмена между ИБД и ОБД являются:

1) синхронизация нормативно-справочной информации в ИБД всех уровней с нормативно-справочной информацией, содержащейся в ОБД;

2) передача в ОБД изменений в нормативно-справочной информации.

5.1.5. Взаимодействие между ПС

Взаимодействие между прикладными системами КИСУ осуществляются согласно схемам, описанным в п. 5.1.1. Детальные требования к взаимодействию ПС и объемам передаваемой ими информации будут определены в ЧТЗ на ПС.

5.2. Технологии взаимодействия

Детальное описание технологий информационного взаимодействия между компонентами КИСУ приведено в  Приложении 7.

6. Обеспечивающие системы КИСУ

6.1. Корпоративная система электронной почты

Целью создания корпоративной системы электронной почты (КСЭП) Росавтодора является разработка управляемой централизованно почтовой системы для всех подразделений Росавтодора. Решение основано на использовании программных продуктов Microsoft Windows 2000 и Microsoft Exchange 2000 и внедряется на всех уровнях вертикальной структуры Росавтодора (Центральный аппарат, ОУДХ).

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

Каждая маршрутная группа регионального подразделения Росавтодора включает в себя коннектор, соединяющий ее с маршрутной группой Центральный аппарат (Рис. 14), и SMTP-коннектор, позволяющий пересылать почту через локального провайдера Интернет при отсутствии каналов связи с Центральным аппаратом в результате сбоя или аварии.

Рис. 14. Схема подключения маршрутных групп объектов Росавтодора

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

Функциональная схема КСЭП представлена на Рис. 15.

Система построена по технологии «клиент-сервер». Серверная часть обеспечивает управление БД сообщений, управление соединениями почтовых серверов друг с другом и с внешними почтовыми системами. Клиентская часть позволяет принимать и отсылать сообщения. Пользователь получает доступ к своему почтовому ящику и возможность обмениваться сообщениями, как в пределах Росавтодора, так и с внешними получателями.

Рис. 15. Функциональная схема КПС

КСЭП, являясь одной из обеспечивающих систем КИСУ, взаимодействует с другими обеспечивающими системами КИСУ так, как представлено на Рис. 16.

Рис. 16. Взаимодействие КСЭП с другими системами КИСУ

Служба единого каталога

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

Сетевые сервисы

КСЭП использует службы DNS для поиска IP-адресов как внутренних серверов, так и серверов внешних почтовых систем.

Централизованная система администрирования и мониторинга

Система решает задачу контроля работоспособности основных сервисов КИСУ. К таким сервисам относится и служба электронной почты. Для наблюдения используется специальный модуль Exchange SPI (Smart-Plug-In), который уведомляет обслуживающий персонал о возникновении проблем.

Служба резервного копирования и восстановления

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

Корпоративный портал

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

Система обеспечения информационной безопасности

В рамках КСЭП используются следующие функциональные возможности системы обеспечения информационной безопасности:

­ разграничение доступа к данным, хранящимся в почтовой системе;

­ электронно-цифровая подпись;

­ контроль целостности информации и кодирование данных на базе электронных сертификатов X.509;

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

­ оперативное оповещение администратора системы о возникновении инцидентов, сбор статистики и постоянный мониторинг;

­ защищенный удаленный доступ к почтовым ящикам пользователей и групповым папкам Exchange;

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

Документооборот

СЭДД использует функцию пересылки сообщений системы КСЭП для организации передачи документов между подразделениями Росавтодора.

6.2. Корпоративный портал

Система «Корпоративный портал» представляет собой интегрирующий инструмент доступа пользователей Центрального аппарата, пользователей подразделений Росавтодора и мобильных пользователей к системам КИСУ и хранилищам данных.

Структурная схема системы «Корпоративный портал» на базе программного обеспечения Microsoft SharePoint Portal Server 2001 представлена на рисунке Рис. 17.

Рис. 17. Структурная схема системы «Корпоративный портал»

Для системы «Корпоративный портал» на базе Microsoft SharePoint Portal Server 2001 в КИСУ Росавтодора выбрана односерверная конфигурация, предоставляющая поисковый сервис и средства для настройки и оформления публикуемой информации. Данная конфигурация при взаимодействии с реализуемыми в рамках КИСУ системами предоставляет пользователям единую точку доступа к информационным ресурсам КИСУ и возможность осуществления эффективного поиска и управления данными. Функциональная схема системы «Корпоративный портал» представлена на рисунке Рис. 18.

Рис. 18. Функциональная схема системы «Корпоративный портал» (односерверная конфигурация)

Для доступа к серверу SharePoint Portal Server с помощью узла электронных инструментальных панелей в Операционной системе Windows можно использовать следующие веб-обозреватели:

6.3. Программно-техническая инфраструктура

Программно-техническая инфраструктура предназначена для создания информационной среды функционирования прикладных систем.

Программно-техническая инфраструктура состоит из следующих систем:

­ система обеспечение базовых системных сервисов;

­ информационная офисная система;

­ система управления базами данных;

­ геоинформационная система;

­ система автоматизированного проектирования;

­ система обработки факсимильных сообщений;

­ система резервного копирования и архивирования информационных ресурсов;

­ система HelpDesk;

­ система централизованного администрирования, мониторинга и управления;

­ компьютерное и периферийное оборудование;

­ система бесперебойного электроснабжения;

­ система кондиционирования технологических помещений.

6.3.1. Система обеспечения базовых системных сервисов

6.3.1.1. Архитектура

Основные системные сервисы КИСУ строятся на базе программного продукта Microsoft Windows 2000 Server. При этом реализуется весь необходимый функционал, а именно:

­ служба единого каталога;

­ сетевые службы (WINS, DNS, DHCP);

­ файловые службы;

­ службы сетевой печати.

Структурная схема базовых системных сервисов представлена на Рис. 19.

Рис. 19. Структурная схема взаимодействия базовых системных сервисов

6.3.1.2. Служба единого каталога

Строится на базе службы единого каталога Active Directory, входящей в состав Microsoft Windows 2000 Server. Основными характеристиками службы являются:

­ интеграция групповой политики;

­ публикация служб;

­ расширение объектов справочника;

­ модель расширения интерфейса ADSI.

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

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

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

Интерфейс ADSI (ActiveDirectoryServicesInterface) предоставляет модель программирования ADSIExtensionModel. С ее помощью разработчикам и администраторам предоставляется простой и логичный способ работы с приложениями и их объектами. Модель расширения также облегчает применение методов к группам объектов (например, группе «все пользователи в Бухгалтерии»).

Доменная структура Росавтодора содержит одно дерево доменов, состоящее из двух уровней.

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

Второй уровень - домены, соответствующие Центральному аппарату Росавтодора (center.fad.ru) и региональным подразделениям (ОУДХ, ДСД и т.п.).

Доменная структура Росавтодора показана на Рис. 20.

Рис. 20. Логическая структура службы каталога AD

Каждый из доменов Росавтодора поддерживается двумя серверами под управлением Microsoft Windows 2000 (контроллеры доменов). Контроллеры доменов подразделений Росавтодора располагаются в соответствующих подразделениях. Контроллеры домена fad.ru располагаются в Центральном аппарате Росавтодора. Наличие высокоскоростных линий связи (от 10 Мб/сек) между всеми частями ЛВС в Центральном аппарате позволяет объединить домены fad.ru и center.fad.ru в один сайт, что обеспечивает проведение репликации между контроллерами доменов в масштабе времени, близком к реальному. Топология репликации внутри сайта создается автоматически.

Контроллеры доменов региональных подразделений располагаются каждый в своем собственном сайте. Исключением являются региональные подразделения, связанные высокоскоростными линиями связи. Такие контроллеры доменов располагаются в одном сайте.

Физическая структура службы каталога Active Directory Росавтодора представлена на Рис. 21.

Рис. 21. Физическая структура службы каталога AD

Данная структура обеспечивает:

­ единое пространство имен;

­ соответствие доменной структуры существующей организационной структуре Росавтодора;

­ возможность автономной работы региональных доменов в случае плохой связи с центром;

­ возможность централизованного администрирования с разграничением полномочий;

­ возможность модификации структуры при изменении административной структуры организации;

­ наличие границ безопасности между Центральным аппаратом и подведомственными подразделениями Росавтодора;

­ возможность подключения и отключения новых региональных организаций;

­ возможность объединения с другими организациями и партнерами.

Домены Windows 2000 связываются с явным пространством имен DNS. Пространство имен доменов Windows 2000 в Росавтодоре берет свое начало от домена fad.ru, который считается корневым доменом. Дочерними доменами являются center.fad.ru, tver.fad.ru и т.д. Имена дочерних доменов назначаются в зависимости от географического расположения подразделений путем добавления сокращенного названия города (на английском языке). Все имена доменов уникальны и не подлежат изменению. В целях стандартизации предлагается использовать названия доменов, состоящие не более чем из шести букв.

6.3.1.3. Сетевые службы

Сетевые службы реализованы на базе сетевых служб операционной системы Microsoft Windows 2000 Server.

Ключевыми сетевыми службами являются службы имен DNS, WINS и DHCP.

В качестве серверов DNS могут быть использованы любые приложения, которые соответствуют BIND 8.2 или выше. Основными требованиями является поддержка динамических обновлений и записей типа SRV. Важным является возможность интегрировать службу DNS и службу единого каталога.

Учитывая, что расположение серверов DNS оказывает влияние на скорость аутентификации пользователей, в подразделениях Росавтодора придерживаются принципа размещения серверов: «в каждом сайте - один сервер DNS».

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

Служба имен WINS используется для разрешения NetBIOS-имен.

Сервис DHCP предназначен для автоматического назначения IP-адресов клиентским компьютерам в сети. Интеграция данного сервиса со службой каталога позволяет работать в сети только авторизованным серверам DHCP.

6.3.1.4. Служба DNS

Служба DNS является основной службой для функционирования единого каталога Active Directory и является каталогом для него. Она хранит информацию о местонахождении серверов глобального каталога, контроллеров доменов и сетевых устройств.

Служба спроектирована в соответствии со следующими требованиями:

­ для каждой доменной зоны должно быть не менее двух серверов DNS, хранящих реплику данной зоны.

­ сервера DNS располагаются на серверах контроллерах доменов и являются интегрированными в Active Directory зонами. В случае невозможности функционирования данной службы на контроллере домена допускается развертывание службы DNS на другом сервере Windows 2000 Server.

­ в каждом сайте служба единого каталога Active Directory должна иметь вторичную копию зоны _msdcs.fad.ru.

Схема передачи зон DNS на примере доменов fad.ru, center.fad.ru, vornzh.fad.ru представлена на Рис. 22. Передача зон в другие домены производится аналогичным образом.

Рис. 22. Пример схемы передачи зон DNS

6.3.1.5. Служба DHCP

Служба DHCP отвечает за автоматическое конфигурирования протокола TCP/IP на рабочих местах пользователей КИСУ Росавтодора. Служба DHCP КИСУ Росавтодора реализуется на базе службы из состава Microsoft Windows 2000 Server. Сервер DHCP устанавливается в каждой подсети Росавтодора. В случае невозможности установки отдельного сервера DHCP в подсети должна функционировать служба DHCP Relay, осуществляющая перенаправление запросов DHCP на сервер в другой подсети. Служба DHCP отвечает за назначение следующих параметров протокола TCP/IP:

­ адрес TCP/IP клиентской машины;

­ адрес подсети TCP/IP, в которой располагается клиентская машина;

­ адрес маршрутизатора по умолчанию;

­ адрес первичного сервера DNS;

­ адрес вторичного сервера DNS;

­ адрес сервера WINS.

Адреса, выдаваемые сервером DHCP клиентским машинам, определяются на этапе разработки ЧТЗ.

6.3.1.6. Служба WINS

Служба WINS является службой поддержки имен NetBIOS. Данная служба внедряется для поддержки работы КИСУ с клиентскими операционными системами ниже Windows 2000 (Windows NT 4.0 Workstation, Windows 95/98/Me).

Адрес службы WINS выдается клиентским рабочим машинам в процессе получения ими IP-адреса от сервера DHCP. На компьютерах со статически настраиваемым протоколом TCP/IP необходимо указывать адрес сервера WINS вручную. Проектирование службы WINS осуществляется в ходе разработки ЧТЗ на систему.

6.3.1.7. Файловая служба

Файловая служба реализуется на базе службы хранения файлов, включенной в состав Microsoft Windows 2000 Server. Служба поддерживает файловую систему NTFS 5.0 и используется для централизованного хранения следующих данных:

­ каталоги профилей пользователей;

­ домашние каталоги пользователей;

­ каталоги приложений.

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

6.3.1.8. Служба сетевой печати

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

PRN – R<номер комнаты>N<номер принтера>,

где <номер комнаты> - номер комнаты внутри здания, включающий в себя номер этажа и номер комнаты на этаже;

<номер принтера> – номер принтера в комнате.

6.3.1.8.1. Управление доступом к принтерам

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

Система Windows 2000 не требует устанавливать однозначную связь между принтерами (программным обеспечением) и устройствами печати (физическим оборудованием). Система позволяет соединять принтеры и устройства печати различными способами. Таким образом, предоставляется возможность гибко настроить возможности печати.

6.3.1.8.2. Удаленная печать в Windows 2000

При подключении клиентов Windows NT/2000 и Windows 95/98 к настроенному серверу печати Windows 2000 (Рис. 23), драйвер принтера автоматически устанавливается на клиентском компьютере. Клиенты Windows NT 4.0 и 2000 выполняют обновление драйвера принтера автоматически.

Рис. 23. Удаленная печать в Windows 2000

6.3.1.8.3. Срочность печати и уровни приоритета

Служба печати Windows 2000 позволяет устанавливать различные приоритеты для различных групп пользователей. При связывании двух принтеров с одним устройством печати, первыми будут печататься документы, направленные на принтер с самым высоким уровнем приоритета (самый большой номер) (Рис. 24).

Рис. 24. Установка уровней приоритетов печати

6.3.2. Информационная офисная система

Информационная офисная система (ИОС), состоит из следующих компонент:

­ комплект офисных приложений;

­ средства оптического сканирования и распознавания документов;

­ набор электронных словарей централизованного общего пользования;

­ средства машинного перевода текста с иностранных языков централизованного общего пользования;

­ комплект утилит;

­ комплект архиваторов основных форматов.

Для обеспечения требуемой функциональности используется пакет Microsoft Office XP (русская версия) в составе:

­ текстовый процессор Microsoft Word XP (русская версия);

­ электронные таблицы Microsoft Excel XP (русская версия);

­ клиент электронной почты Microsoft Outlook XP (русская версия);

­ средства проверки орфографии;

­ графический редактор Microsoft Photo Editor XP (русская версия);

­ клиентские средства коллективной работы всех сотрудников Росавтодора Microsoft SharePoint Support;

­ клиентские средства электронного документооборота для выделенных групп пользователей Microsoft Office Document Routing;

­ поддержка платформы разработки офисных приложений Visual Basic for Applications.

Для сканирования и распознавания отсканированных документов используется продукт ABBYY FineReader 6.0 Corporate Edition.

В качестве набора словарей централизованного общего пользования используется продукт PROMT Net XT в комплектации «Гигант», включающий электронные словари централизованного общего пользования.

В качестве средств машинного перевода текста с иностранных языков централизованного пользования используется продукт PROMT Net XT.

Для поддержки основных форматов архивирования на АРМ пользователей устанавливается архиватор WinRar версии 3. Архиватор WinRar поддерживает большинство форматов архивов, включая собственный RAR, а также ZIP, ARJ, GZIP, TAR и др.

Выбор пакета Microsoft Office XP в качестве офисного комплекта приложений обусловлен тем, что данный пакет программ является в настоящий момент стандартом де-факто для офисных приложений, функционирующих на платформе Microsoft Windows 2000 и выше.

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

7. Общие требования к прикладным системам КИСУ

В разделе приведены общие требования к прикладным системам КИСУ. Требования должны включаться в соответствующие разделы ЧТЗ на прикладные системы.

7.1. Требования к структуре и режимам функционирования ПС

7.1.1. Требования к архитектуре ПС

В основу архитектуры прикладной системы должен быть заложен единый методологический подход, применяемый при построении КИСУ.

Система должна быть построена с использованием трехзвенной архитектуры с применением Интранет технологий. Допускается разработка, после согласования с заказчиком, первоначального варианта системы с использованием архитектуры «клиент-сервер» с обязательным последующим переходом к трехзвенной архитектуре.

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

7.1.2. Требования к способам и средствам связи для информационного обмена между ПС

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

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

7.1.3. Требования к характеристикам взаимосвязей ПС со смежными системами, требования к совместимости

Должна быть обеспечена возможность единого доступа к системе по глобальной и локальной сети.

Взаимодействие системы со смежными системами должно осуществляться с использованием общедоступных служб ядра КИСУ. Система должна предоставлять возможность интеграции с ядром КИСУ.

Протоколы обмена данными и методы взаимодействия со смежными системами будут уточняться в ЧТЗ на прикладные системы.

7.1.4. Требования к режимам функционирования ПС

Прикладная система должна соответствовать двухуровневой организационной структуре Росавтодора:

1) Центральный аппарат Росавтодора;

2) органы управления дорожным хозяйством.

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

Должна обеспечиваться работа системы в двух режимах:

1) «распределенный», при нормальном функционировании каналов связи между ОУДХ и Центральным Аппаратом система взаимодействует с компонентами системы КИСУ, установленными на разных объектах автоматизации;

2) «автономный», при нарушении или отсутствии связи между ОУДХ и Центральным Аппаратом система взаимодействует с компонентами системы КИСУ, установленными на одном объекте автоматизации.

7.1.5. Перспективы развития и модернизации ПС

Прикладная система должна быть открытой и допускать наращивание функциональных возможностей.

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

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

7.2. Требования к численности и квалификации персонала системы и режиму его работы

7.2.1. Требования к количеству пользователей системы

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

В Центральном аппарате и каждом ОУДХ должно быть не менее одного администратора системы.

7.2.2. Требования к квалификации персонала

Пользователи системы должны иметь базовые навыки работы с операционными системами Microsoft (одна из списка MS Windows 95, 98, ME, NT 4.0, 2000, XP), офисным программным обеспечением MS Office.

Все администраторы системы должны иметь навыки администрирования сети на основе операционной системы Windows 2000 и применяемых серверов баз данных Oracle или MicrosoftSQLServer.

Все пользователи и администраторы системы должны пройти обучение работе с прикладной системой.

7.3. Требования к надежности

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

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

­ регулярное резервное копирование базы данных;

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

­ после восстановления системы с резервной копии необходимо обеспечить синхронизацию данных между экземплярами системы в ОУДХ и Центрального аппарата.

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

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

7.4. Требования к эргономике и технической эстетике

7.4.1. Требования к внешнему оформлению

Интерфейс системы должен быть максимально приближен к интерфейсу продуктов Microsoft (Windows, Office, InternetExplorer). Цветовая схема интерфейса прикладной системы должна соответствовать текущим настройкам цветовой схемы операционной системы. Изменение настроек цветовой схемы операционной системы должно динамически отражаться на настройках цветовой схемы интерфейса прикладной системы.

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

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

Система должна взаимодействовать с пользователем посредством стандартных web-обозревателя (MS Internet Explorer версии 5.5 и выше). В отдельных случаях, при согласовании с Заказчиком, допускается использовать обычный Windows интерфейс без применения web-обозревателя.

7.4.2. Требования к диалогу с пользователем

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

Система должна иметь контекстно-зависимую справочную систему.

7.5. Требования к эксплуатации и техническому обслуживанию

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

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

Основным компонентом системы, требующим технического обслуживания, является  СУБД (MSSQLServer и/или Oracle), в которой хранятся данные системы.

Обслуживание СУБД должны проводить сертифицированные или специально обученные специалисты.           

Регламент выполнения работ должен соответствовать требованиями и рекомендациями поставщика данной СУБД.

7.6. Требования к патентной чистоте

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

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

7.7. Требования по стандартизации и унификации

Прикладная система должна взаимодействовать с другими прикладными системами КИСУ и ядром системы. Порядок взаимодействия с прикладными системами и ядром системы определяется разделе 5. Информационный обмен осуществляется с помощью XML пакетов и с использованием Интернет протоколов (HTTP, SOAP).

Система должна использовать общие для КИСУ словари и справочники.

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

Содержание и оформление передаваемой документации на систему должно соответствовать требованиям следующих стандартов и нормативных документов:

1)Комплекс стандартов на автоматизированные системы: ГОСТ РД 50-34.698, ГОСТ 34.201, ГОСТ 34.602, ГОСТ 34.603;

2) Единая система программной документации: ГОСТ 19.101, ГОСТ 19.105, ГОСТ 19.201, ГОСТ 19.301, ГОСТ 19.401.

8. Разработка и внедрение КИСУ

8.1. Рекомендуемый план разработки, внедрения, развития и сопровождения КИСУ

Этап 1.  Создание пилотной зоны КИСУ в составе прикладных систем 1-ой очереди на объектах: Центральный аппарат, УПРДОР «Россия».

Этап 2. Проектно-изыскательские работы (ПИР) по прикладным системам КИСУ и разработка концептуальной модели КИСУ.

Этап 3. Разработка и внедрение информационно-аналитической системы. Разработка прикладных систем 2-й очереди в рамках ПИР.

Этап 4. Разработка прикладных систем 3-й очереди в рамках ПИР.

Этап 5. Доработка прикладных систем 1-ой очереди. Ввод в действие прикладных систем 1-ой очереди за исключением СЭДД в составе 14 ОУДХ. Проектирование и разработка прикладных систем 2-й и 3-й очереди. Опытная эксплуатация прикладных систем 2-й очереди на объектах пилотной зоны.

Этап 6.  Ввод в действие прикладных систем 1-ой очереди, за исключением СЭДД, в 14 ОУДХ (определение объектов выполняется на этапе ПИР и предпроектного обследования).

Этап 7. Ввод в действие прикладных систем 2-й и 3-й очереди в 17 ОУДХ.

Этап 8. Гарантийное и техническое сопровождение КИСУ.

Рекомендуемый план разработки, внедрения и сопровождения прикладных систем КИСУ приведен в Таблице 2 (согласно ГОСТ 34.601 на автоматизированные системы).

Таблица 2. Рекомендуемый план разработки, внедрения и сопровождения прикладных систем  КИСУ

1

Формирование требований к Системе

 

1.1

Обследование объекта и обоснование необходимости создания КИСУ

 

1.2

Формирование требований к Системе

 

1.3

Оформление отчёта о выполненной работе и заявки на разработку КИСУ (технического задания)

2.

Разработка концепции КИСУ

 

2.1

Проведение проектно-изыскательских работ

 

2.3

Разработка концептуальной модели КИСУ

3.

Техническое задание

 

3.1

Разработка и утверждение технического задания на создание КИСУ или ее частей

4.

Технический проект

 

4.1

Разработка проектных решений по системе и её частям

 

4.2

Разработка документации на КИСУ и её части

 

4.3

Разработка и оформление документации на поставку изделий для комплектования КИСУ

 

4.4

Разработка заданий на проектирование в смежных частях проекта объекта автоматизации

5.

Рабочая документация

 

5.1

Разработка рабочей документации на систему и её части

 

5.2

Разработка и адаптация прикладных систем

6.

Ввод в действие

 

6.1

Подготовка объекта автоматизации к вводу КИСУ в действие

 

6.2

Подготовка персонала

 

6.3

Комплектация КИСУ поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

 

6.4

Проведение предварительных испытаний

 

6.5

Проведение опытной эксплуатации

 

6.6

Проведение приёмочных испытаний

7.

Сопровождение КИСУ

 

7.1

Выполнение работ в соответствии с гарантийными обязательствами

 

7.2

Послегарантийное обслуживание

8.2. Порядок внедрения КИСУ

Для обеспечения непрерывной работы подразделений Росавтодора разработка и внедрение КИСУ осуществляется поэтапно. В соответствии с госконтрактом на разработку КИСУ, прикладные системы КИСУ разрабатываются в три этапа. Разработка и внедрение прикладных систем осуществляется в следующей последовательности:

­ разработка (доработка) прикладной системы;

­ опытная эксплуатация;

­ обучение пользователей;

­ внедрение прикладной системы.

На этапе разработки прикладной системы разрабатывается или дорабатывается существующая автоматизированная система на основании технического задания. Дорабатываемая система для включения в КИСУ должна соответствовать требованиям п. 4.3.

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

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

8.3. Сопровождение КИСУ

Гарантийное обслуживание ПС КИСУ осуществляется в течение 1 года с момента ввода ПС в промышленную эксплуатацию. Техническое сопровождение КИСУ осуществляется после завершения гарантийного срока обслуживания и осуществляется по дополнительному соглашению. Сопровождение КИСУ включает в себя:

1) обновление версий покупного ПО;

2) исправление выявленных несоответствий Техническому заданию;

3) внесение согласованных между Генподрядчиком и Подрядчиком изменений с целью доработки прикладных систем КИСУ по требованию пользователей;

4) информационную поддержку пользователей КИСУ в режиме «горячая линия».

8.4. Интеграция существующих автоматизированных систем

В Росавтодоре в настоящее время для автоматизации управленческих процессов используется большое количество различных автоматизированных систем. Некоторые из них после необходимой доработки пригодны для включения в КИСУ.

Доработка существующих систем будет осуществляться в следующей последовательности:

­ синхронизация словарей и справочников;

­ доработка для интеграции в систему безопасности КИСУ;

­ разработка веб-интерфейса и/или веб-служб для отображения информации;

­ разработка дополнительного функционала.

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

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

8.5. Рекомендуемый план развития КИСУ

Так как деятельность любой организации изменяется с течением времени, ее система автоматизации должна модернизироваться, чтобы отвечать изменяющимся требованиям пользователей. КИСУ Росавтодора строится как открытая система, которая предполагает внесение изменений после создания системы.

Этап 1. Разработка и включение в состав КИСУ программно-технических средств дорожных ремонтно-строительных управлений (ДРСУ).

Этап 2. Доработка КИСУ Росавтодора для предоставления информационных услуг населению.

Этап 3. Интеграция с Информационными системами государственных органов власти на уровне информационного обмена.

Этап 4. Полная интеграция КИСУ Росавтодор с Информационными системами государственных органов власти (построение «электронного правительства»).

Список использованных источников

1. Государственная транспортная политика Российской Федерации. Концепция. Одобрена Постановлением Правительства Российской Федерации от 8 сентября 1997 г. № 1143.

2. Положение о Государственной службе дорожного хозяйства Министерства транспорта Российской Федерации, утвержденная Приказом Министерства транспорта Российской Федерации от 8 ноября 2001 г. № 161.

3. Государственная концепция создания и развития сети автомобильных дорог в Российской Федерации, утв. Постановлением Правительства Российской Федерации от 17 апреля 1999 года № 438;

4. Подпрограмма «Автомобильные дороги» в составе федеральной целевой программы «Модернизация транспортной системы России (2002–2010 годы)», разработанная на основании Распоряжения Правительства Российской Федерации от 16 февраля 2001 года № 232;

5. Приказ Министерства транспорта Российской Федерации от 29 марта 2001 г. № 57 «О задачах Министерства транспорта Российской Федерации на 2001 год, вытекающих из Плана действий Правительства Российской Федерации в области социальной политики и модернизации экономики на 2000–2001 годы, утв. распоряжением Правительства Российской Федерации от 26 июля 2000 г. № 1072-p»;

6. Распоряжение Министерства транспорта Российской Федерации от 31 декабря 2002 г. № ИС-1185-р «Об утверждении новой редакции Временного регламента создания и функционирования электронного архива справочно-информационных и аналитических материалов»;

7. Концепция научно-технической политики в дорожном хозяйстве России на период 1998–2005гг., утвержденная Распоряжением Росавтодора от 16 октября 2003 г.;

8. Конкурсная документация Открытого конкурса на создание «Корпоративной информационной системы управления Государственной службы дорожного хозяйства Министерства транспорта Российской Федерации»;

9. Концепция создания автоматизированной системы информационного обеспечения дорожной отрасли, разработанная научно-производственной и учебно-инженерной фирмой «МАДИ-путь» совместно с фирмой «Компьютерные системы менеджмента» («КСиМ») по заказу Росавтодора – М. 1993;

10. Порядок разработки и реализации федеральных целевых программ, утв. Постановлением Правительства Российской Федерации от 26 июня 1996 года № 594 (с последующими доп. и изм.);

11. ГОСТ 6.01.1-87 Единая система классификации и кодирования технико-экономической информации. Основные положения.- М.: Изд. стандартов, 1987;

12. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.- М.: Изд. стандартов, 1990.