Akka или эквивалент. 2. Сервер приложений. Akka или эквивалент, Крипто Про.


Технические требования на выполнение работ по Развитию региональной Системы межведомственного электронного взаимодействия Московской области
версия 14
Красногорск, 2014
Оглавление
TOC \o "1-3" \h \z \u 1ОБЩИЕ СВЕДЕНИЯ PAGEREF _Toc401402118 \h 41.1Наименование работ PAGEREF _Toc401402119 \h 41.2Источник финансирования PAGEREF _Toc401402120 \h 41.3Заказчик PAGEREF _Toc401402121 \h 41.4Исполнитель PAGEREF _Toc401402122 \h 51.5Срок выполнения работ PAGEREF _Toc401402123 \h 51.6Правовые основания для развития Системы PAGEREF _Toc401402124 \h 51.7Особые условия PAGEREF _Toc401402125 \h 61.8Перечень используемых терминов и сокращений PAGEREF _Toc401402126 \h 72НАЗНАЧЕНИЕ И ЦЕЛИ РАЗВИТИЯ СИСТЕМЫ PAGEREF _Toc401402127 \h 122.1Назначение и цели развития Системы PAGEREF _Toc401402140 \h 122.2Цели выполнения работ PAGEREF _Toc401402141 \h 133ТРЕБОВАНИЯ К СПЕЦИАЛЬНОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СИСТЕМЫ PAGEREF _Toc401402142 \h 143.1Процессы и процедуры, выполняемые с использованием Системы PAGEREF _Toc401402143 \h 143.2Целевое обеспечение Системы PAGEREF _Toc401402144 \h 183.2.1Обязанности по предоставлению аппаратного и программного обеспечения PAGEREF _Toc401402145 \h 193.3Перечень подсистем Системы PAGEREF _Toc401402146 \h 193.4Сведения о текущем состоянии Системы PAGEREF _Toc401402147 \h 213.4.1Наименование работ, выполненных в рамках развития Системы PAGEREF _Toc401402148 \h 213.5Пользовательские требования к Системе PAGEREF _Toc401402232 \h 283.5.1Общие требования к Системе PAGEREF _Toc401402233 \h 283.5.2Требования к организации взаимодействия с внешними информационными системами PAGEREF _Toc401402234 \h 293.5.3Требования к надежности и производительности (потребительские характеристики) PAGEREF _Toc401402235 \h 313.5.4Функциональные требования к подсистемам PAGEREF _Toc401402236 \h 323.5.5Требования к проектированию подсистемы информационной безопасности PAGEREF _Toc401402237 \h 453.5.6Дополнительные требования к развиваемой системе PAGEREF _Toc401402238 \h 504СОСТАВ, СОДЕРЖАНИЕ И РЕЗУЛЬТАТЫ РАБОТ PAGEREF _Toc401402239 \h 545ТРЕБОВАНИЯ К РАБОТАМ PAGEREF _Toc401402240 \h 585.1Общие требования PAGEREF _Toc401402241 \h 585.1.1Требования к качеству и результатам выполнения работ PAGEREF _Toc401402251 \h 585.2Формирование требований к ЧТЗ PAGEREF _Toc401402252 \h 595.2.1Требования к ЧТЗ PAGEREF _Toc401402253 \h 595.2.2Требования к развертыванию тестового контура СПО PAGEREF _Toc401402254 \h 625.3Требования к техно-рабочему проекту PAGEREF _Toc401402255 \h 655.3.1Требования к модели угроз и нарушителя информационной безопасности Системы PAGEREF _Toc401402256 \h 655.4Требования к вводу Системы в действие PAGEREF _Toc401402257 \h 675.4.1Работы по развертыванию и конфигурированию Системы PAGEREF _Toc401402285 \h 675.4.2Требования к проведению мероприятий по подготовке пользователей PAGEREF _Toc401402286 \h 675.4.3Требования к сопровождению системы в период опытной эксплуатации PAGEREF _Toc401402287 \h 686ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ PAGEREF _Toc401402288 \h 716.1Общие требования к приемке работ по этапам PAGEREF _Toc401402289 \h 716.2Виды, состав, объем и методы испытаний Системы PAGEREF _Toc401402290 \h 726.3Сведения о гарантийном обслуживании системы PAGEREF _Toc401402293 \h 766.4Порядок выполнения доработок и устранения допущенных исполнителем ошибок, выявленных на стадии приемки PAGEREF _Toc401402294 \h 776.5Порядок проведения экспертизы документации PAGEREF _Toc401402295 \h 777ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ PAGEREF _Toc401402296 \h 818ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ PAGEREF _Toc401402300 \h 86ПРИЛОЖЕНИЕ А PAGEREF _Toc401402301 \h 87ПРИЛОЖЕНИЕ Б PAGEREF _Toc401402302 \h 91ПРИЛОЖЕНИЕ В PAGEREF _Toc401402303 \h 102ПРИЛОЖЕНИЕ Г PAGEREF _Toc401402304 \h 103ПРИЛОЖЕНИЕ Д PAGEREF _Toc401402305 \h 1071ОБЪЕКТ ИСПЫТАНИЙ PAGEREF _Toc401402306 \h 1102ЦЕЛЬ ИСПЫТАНИЙ PAGEREF _Toc401402307 \h 1113ОБЪЕМ ИСПЫТАНИЙ PAGEREF _Toc401402308 \h 1123.1 Проверка выбранных технологий на соответствие техническим требованиям PAGEREF _Toc401402309 \h 1123.2 Перечень этапов испытаний PAGEREF _Toc401402310 \h 1123.3 Последовательность проведения и режим испытаний PAGEREF _Toc401402311 \h 1134УСЛОВИЯ И ПОРЯДОК ПРОВЕДЕНИЯ ИСПЫТАНИЙ PAGEREF _Toc401402312 \h 1144.1 Требования к составу технических средств PAGEREF _Toc401402313 \h 1144.2 Требования к персоналу, проводящему испытание, порядок допуска к испытаниям PAGEREF _Toc401402314 \h 1145МЕТОДИКА ПРОВЕРКИ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ТЕСТОВОГО КОНТУРА СПО СИСТЕМЫ PAGEREF _Toc401402315 \h 1155.1 Обеспечение работоспособности подсистемы распределения задач РСМЭВ МО PAGEREF _Toc401402316 \h 1155.1.1 Обеспечение возможности предоставления внешним ИС WSDL и XSD описаний электронного сервиса PAGEREF _Toc401402317 \h 1155.1.2 Обеспечение возможности оповещения ИС участника информационного взаимодействия о статусе доставки сообщения PAGEREF _Toc401402318 \h 1155.1.3 Обеспечение синхронного взаимодействия PAGEREF _Toc401402319 \h 1165.1.4 Обеспечение асинхронного взаимодействия PAGEREF _Toc401402320 \h 1165.2 Обеспечение работоспособности реестра электронных сервисов PAGEREF _Toc401402321 \h 1175.2.1 Осуществление возможности получения основной информации по электронным сервисам (владелец, идентификатор, наименование электронного сервиса, назначение, режим доступности, режим работы, область применения) PAGEREF _Toc401402322 \h 1175.2.2 Осуществление возможности регистрации нового сервиса PAGEREF _Toc401402323 \h 1185.2.3 Осуществление возможности изменения атрибутов зарегистрированных сервисов PAGEREF _Toc401402324 \h 1195.2.4 Осуществление возможности редактирование сведений в матрице доступа PAGEREF _Toc401402325 \h 1195.2.5 Осуществление возможности получения руководства пользователя по сервису PAGEREF _Toc401402326 \h 1205.2.6 Осуществление возможности получения контрольных примеров в соответствии с операциями (методами) электронного сервиса PAGEREF _Toc401402327 \h 1205.2.7 Осуществление возможности получения основной информации, содержащейся в форме паспорта электронного сервиса (детальная информация по характеристикам, возможным операциям и реестру прав доступа) PAGEREF _Toc401402328 \h 1215.2.8 Осуществление возможности поиска/фильтрации зарегистрированных электронных сервисов по ключевым словам и категориям PAGEREF _Toc401402329 \h 1215.3 Обеспечение прочих функций и требований PAGEREF _Toc401402330 \h 1225.3.1 Обеспечение работоспособности подсистемы протоколирования PAGEREF _Toc401402331 \h 1225.3.2 Осуществление возможности получение статистики межведомственного взаимодействия в различных разрезах PAGEREF _Toc401402332 \h 1226РЕЗУЛЬТАТ ИСПЫТАНИЙ ТЕСТОВОГО КОНТУРА СПО СИСТЕМЫ PAGEREF _Toc401402333 \h 123
ОБЩИЕ СВЕДЕНИЯНаименование работПолное наименование системы: Региональная система межведомственного электронного взаимодействия Московской области (далее - Система).
Полное наименование работ: Работы по развитию Системы (далее Работы).
Источник финансированияИсточники финансирования
Бюджет
Наименование программы и подпрограммы Номер мероприятия в подпрограмме Код бюджетной классификации
Бюджет Московской области на 2014 год
Программа «Эффективная власть»
Подпрограмма 2 «Развитие информационно-коммуникационных технологий для повышения эффективности процессов управления и создания благоприятных условий жизни и ведения бизнеса в Московской области» 8.3. «Развитие и техническое сопровождение специального программного обеспечения региональной системы межведомственного электронного взаимодействия Московской области и интеграцию на ее базе региональных и ведомственных информационных систем Московской области для обеспечения возможности автоматизированного взаимодействия между собой» 015 0410 12 2 0061 242 320
ЗаказчикГосударственный заказчик: Министерство государственного управления, информационных технологий и связи Московской области (далее - Заказчик).
Место нахождения: 143405, Московская обл., г. Красногорск, Ильинское шоссе, д. 4
Почтовый адрес: 143407, Московская область, г. Красногорск, б-р Строителей, д. 1 (Дом Правительства Московской области).
Функциональные заказчики: Центральные исполнительные органы государственной власти Московской области, территориальные исполнительные органы Московской области, государственные казенные учреждения Московской области согласно Приложению А.
Органы местного самоуправления муниципальных образований Московской области согласно Приложению А.
ИсполнительИсполнитель определяется по итогам проведения открытого конкурса в соответствии с Федеральным законом от 05.04.2013 г. №44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее - Исполнитель).
Срок выполнения работНачало выполнения работ с даты заключения Государственного контракта.
Сроки окончания работ – 30 марта 2015 года.
Этапы Работ определены в п. 4 настоящего документа.
Правовые основания для развития СистемыОснования для развития Системы
№ Вид документа Наименование документа Реквизиты документа
Указ Президента РФ «Об основных направлениях совершенствования системы государственного управления» 01.05.2012 г. № 601
Федеральный закон «Об организации предоставления государственных и муниципальных услуг» 27.07.2010 г. № 210-ФЗ
Федеральный закон «Об электронной подписи»
06.04.2011 г. № 63-ФЗ
Постановление Правительства РФ «О единой системе межведомственного электронного взаимодействия» 08.09.2010 г. № 697
Постановление Правительства РФ «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме» 08.06.2011 г. № 451
Постановление правительства РФ «Об Электронной подписи, используемой органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также  об установлении требований к обеспечению совместимости средств электронной подписи» 09.02.2012 г. № 111
Приказ Министерства связи и массовых коммуникаций РФ «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» 27.12.2010 г. № 190
Постановление Правительства Московской области «Об утверждении государственной программы Московской области «Эффективная власть» на 2014-2018 годы» 23.08.2013 г. № 660/37
Особые условияДо начала работ Заказчик предоставляет Исполнителю в электронном виде техническую и эксплуатационную документацию на Систему и исходные коды ПО, разработанные в рамках:
Государственного контракта от 15.08.2012 г. № 0148200002412000078-0153034-03 на оказание услуг по настройке и вводу в эксплуатацию программно-технического решения, обеспечивающего процессы межведомственного электронного взаимодействия между Поставщиками и Потребителями данных при предоставлении услуг Московской области;
Государственного контракта от 17.12.2013 г. № 0148200000613000292 на выполнение технологических работ по развитию комплекса программно-технических решений, обеспечивающего процессы межведомственного электронного взаимодействия между Поставщиками и Потребителями данных при предоставлении государственных и муниципальных услуг Московской области в электронном виде.
Реализация развиваемых функций Системы должна соответствовать требованиям, которые определены для Системы в рамках указанных Государственных контрактов. Дополнительные требования к Системе определены ниже.
Результаты работ по ТТ должны быть совместимы на уровне программного, технического, информационного и других видов обеспечения с результатами работ, уже реализованными в рамках указанных Государственных контрактов. При этом не должно нарушаться установленное соответствие реализованной Системы требованиям, которые определены в ЧТЗ на развитие Системы, в соответствии с технической документацией на Систему, разработанную в рамках Государственных контрактов.
Патентная чистота Системы и его частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации.
При использовании программного обеспечения (или его компонентов), разработанного третьими лицами, для обеспечения работы Системы, условия, на которых передается право на использование (исполнение) этого программного обеспечения, не должны накладывать ограничений, препятствующих эксплуатации Системы.
На все программное обеспечение (или его компоненты), разработанное третьими лицами, используемое для обеспечения работы Системы, должно быть получено разрешение разработчика на «раскрытие кода» для Заказчика (если таковое не оговорено в стандартном лицензионном соглашении).
Исключительные права на объекты интеллектуальной собственности, возникшие в связи с выполнением работ по развитию Системы, должны быть переданы Заказчику.
Перечень используемых терминов и сокращенийТаблица сокращений
Сокращение Описание
3-НДФЛ Налоговая декларация по налогу на доходы физических лиц
API Application Programming Interface (Интерфейс программирования приложений)
WSDL Web Services Description Language (Язык описания веб-сервисов и доступа к ним, основанный на языке XML)
XML EXtensible Markup Language (Расширяемый язык разметки, с простым формальным синтаксисом, удобный для создания и обработки документов программами и одновременно удобный для чтения и создания документов человеком)
XSD XML Schema Definition (Язык описания структуры XML документа)
SID Идентификатор электронного сервиса в Системе
БД База данных
ГК Государственный контракт
ГМУ Государственные и муниципальные услуги
ГПН Государственный пожарный надзор
ГПС Государственная пожарная служба
ЕГРЮЛ/ЕГРИП Единый государственный реестр юридических лиц/ Единый государственный реестр индивидуальных предпринимателей
ЕПГУ Единый портал государственных и муниципальных услуг (функций)
ИБ Информационная безопасность
ИНН Идентификационный номер налогоплательщика
ИС Информационная система
МО Московская область
МР Методические рекомендации по разработке электронных сервисов и применению технологий электронной подписи при межведомственном электронном взаимодействии (версии 2.4.5, 2.5.6), утвержденному Протоколом заседания Правительственной комиссии по использованию информационных технологий при предоставлении ГМУ Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 20.04.2012 г. №11
НСД Несанкционированный доступ
ОВД Органы внутренних дел
ОГВ Органы государственной власти
ОМСУ Орган местного самоуправления
ПО Программное обеспечение
ПИБ Подсистема информационной безопасности
ППУ Портал поставщиков услуг
ПТР Программно-техническое решение
РД Руководящая документация
РПГУ Региональный портал государственных и муниципальных услуг (функций)
РС Реестр Сервисов
РСМЭВ МО Региональная система межведомственного электронного взаимодействия Московской области
РФ Российская федерация
СКЗИ Средство криптографической защиты информации
СМЭВ Система межведомственного электронного взаимодействия
СНИЛС Страховой номер индивидуального лицевого счета
СПО Специальное программное обеспечение, программа для ЭВМ, разрабатываемая в рамках развития Системы
СУБД Система управления базами данных
ТП РСМЭВ МО Технологический портал региональной системы межведомственного электронного взаимодействия Московской области
ТТТехнические требования
УЦ Удостоверяющий центр
ФЛ Физические лица
ФЛК Форматно-логический контроль
ФОИВ Федеральный орган исполнительной власти
ФПС Федеральная пожарная служба
ФСБ Федеральная служба безопасности Российской Федерации
ФСТЭК Федеральная служба по техническому и экспортному контролю Российской Федерации
ЧТЗ Частное техническое задание
ЭП Электронная подпись
ЭП-ОВ Электронная подпись, формируемая от имени органа государственной власти, участвующего в межведомственном взаимодействии при оказании государственных услуг
ЭП-СП Электронная подпись, формируемая от имени должностного лица органа власти, участвующего в межведомственном взаимодействии при оказании государственных услуг
ЮЛ Юридические лица
Таблица терминов
Термин Определение
Администратор РСМЭВ МО Уполномоченный представитель Министерства государственного управления, информационных технологий и связи Московской области
Государственная или муниципальная услуга (Услуга) В соответствии со ст. 2 Федерального Закона от 27.07.2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»:
Государственная услуга – это деятельность по реализации функций федерального органа исполнительной власти, государственного внебюджетного фонда, исполнительного органа государственной власти субъекта РФ, а также органа местного самоуправления при осуществлении отдельных государственных полномочий, переданных федеральными законами и законами субъектов РФ (далее – органы, предоставляющие государственные услуги), которая осуществляется по запросам заявителей в пределах установленных нормативными правовыми актами РФ и субъектов РФ полномочий органов, предоставляющих государственные услуги.
Заказчик Министерство государственного управления, информационных технологий и связи Московской области.
Заявитель Юридическое или физическое лицо, обратившееся с запросом о предоставлении Услуги, выраженным в письменной, устной или электронной форме.
Модуль Компонент Системы, предоставляющий один или несколько сервисов для других модулей. Может использовать сервисы, поддерживаемые другими модулями. Модули состоят из ряда других, более простых компонентов.
Общее программное обеспечение Часть программного обеспечения, представляющая собой совокупность программных средств, разработанных вне связи с созданием Системы.
Оператор РСМЭВ МО Министерство государственного управления, информационных технологий и связи Московской области.
Оператор СМЭВ Министерство связи и массовых коммуникаций Российской Федерации
Пользователь Лицо, участвующее в функционировании Системы или использующее результаты её функционирования.
Поставщик В соответствии с документом «Регламент взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия», утвержденным Протоколом заседания Правительственной комиссии по использованию информационных технологий при предоставлении ГМУ Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 09.09.2011 г. №15 под Поставщиком понимается участник информационного взаимодействия, выступающий в роли Поставщика информации.Потребитель В соответствии с документом «Регламент взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия», утвержденным Протоколом заседания Правительственной комиссии по использованию информационных технологий при предоставлении ГМУ Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 09.09.2011 г. №15 под Потребителем понимается участник информационного взаимодействия, выступающий в роли Потребителя информации.Роль В Системе регистрируются роли, с которыми сопоставляется комплект прав, позволяющих выполнять пользователю конкретные функции Системы.
Тестовый контур СПО Программно-аппаратный комплекс, дублирующий функции ин-формационной системы, находящейся в эксплуатации, используемый для разработки и апробации новых функций в рамках развития Системы.
Участники информационного взаимодействия В соответствии с документом «Регламент взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия», утвержденным Протоколом заседания Правительственной комиссии по использованию информационных технологий при предоставлении ГМУ Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 09.09.2011 г. №15 под Участниками информационного взаимодействия понимаются: Участник информационного взаимодействия федерального уровня, Участник информационного взаимодействия регионального уровня, иная организация.
Участник информационного взаимодействия регионального уровня Региональный орган исполнительной власти, орган местного самоуправления.
Участник информационного взаимодействия федерального уровня Федеральный орган исполнительной власти, государственный внебюджетный фонд, и иной орган и организация, участвующий в предоставлении государственных и муниципальных услуг (функций).
Экземпляр модуля «Сервисная шина» Программное обеспечение, установленное на отдельном виртуальном сервере, выполняющее все функции модуля «Сервисной шины» в соответствии с настоящими Техническими требованиями.
Экземпляр модуля «Очередь сообщений» - Программное обеспечение, установленное на отдельном виртуальном сервере, выполняющее все функции модуля «Очередь сообщений» в соответствии с настоящими Техническими требованиями.
НАЗНАЧЕНИЕ И ЦЕЛИ РАЗВИТИЯ СИСТЕМЫНазначение и цели развития СистемыВ соответствии с постановлением Правительства Московской области от 23.10.2012 № 1325/39 РСМЭВ МО предназначена для решения следующих задач:
обеспечение исполнения государственных и муниципальных функций в электронной форме;
обеспечение предоставления государственных и муниципальных услуг в электронной форме, в том числе с использованием универсальной электронной карты, федеральной государственной информационной системы "Единый портал государственных и муниципальных услуг (функций)", а также на базе многофункциональных центров предоставления государственных и муниципальных услуг;
обеспечение информационного взаимодействия в электронной форме при предоставлении государственных и муниципальных услуг и исполнении государственных и муниципальных функций;
обеспечение информационного взаимодействия с единой системой межведомственного электронного взаимодействия (далее - СМЭВ).
Целями развития Системы являются:
Развитие архитектуры межведомственного взаимодействия и обеспечения соответствия РСМЭВ МО документу «Методические рекомендации по разработке электронных сервисов и применению технологий электронной подписи при межведомственном электронном взаимодействии» (версии 2.4.5, 2.5.6), утвержденному Протоколом заседания Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 20.04.2012 г. №11;
Обеспечение возможности идентификации межведомственных запросов и ответов ОГВ, ОМСУ и МФЦ МО по ЭП-ОВ;
Обеспечение автоматизированной проверки наличия ЭП-ОВ в соответствии с требованиями Методических рекомендаций по использованию электронной подписи при межведомственном электронном взаимодействии (версия.4.3);
Обеспечение возможности получения корректных сведений о количестве направленных межведомственных запросов и ответов в разрезе ОГВ, ОМСУ и МФЦ МО;
Обеспечение возможности управления сроками регистрации ИС и сервисов в РСМЭВ МО.
Цели выполнения работ
Целью работ является развитие программного обеспечения РСМЭВ МО для реализации требований нормативно-правовых актов в части формирования единого пространства юридически значимого межведомственного электронного взаимодействия в рамках процессов предоставления государственных и муниципальных услуг в электронном виде.
Для достижения целей работ должны быть решены следующие задачи:
Развитие подсистем входящих в состав РСМЭВ МО, разработанных в рамках Государственных контрактов указанных в п. 1.7:
подсистема «Реестр электронных сервисов»;
подсистема «Шлюз сервисов»;
подсистема протоколирования;
подсистема статистики и отчетности.
Разработка подсистемы распределения задач.
Подготовка пользователей Системы.
Ввод в действие РСМЭВ МО.
ТРЕБОВАНИЯ К СПЕЦИАЛЬНОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СИСТЕМЫПроцессы и процедуры, выполняемые с использованием СистемыИсполнитель должен реализовать в Системе функции, необходимые для выполнения административных, организационных, информационных, обслуживающих и иных процессов и процедур, описание которых приведено в ссылочных регламентирующих документах, указанных в таблице 5, либо представлено в таблице 6.
Регламентирующие документы, описывающие процессы и процедуры, которые должны выполняться с использованием Системы
№ Наименование документа Способ получения документа
Административные регламенты оказания Услуг Доступны на официальных сайтах Московской области и в Реестре государственных и муниципальных услуг«Концепция развития механизмов предоставления государственных и муниципальных услуг в электронном виде», утвержденная Распоряжением Правительства РФ от 25.12.2013 г. № 2516-р Доступна на официальных сайтах Правительства РФ
«Регламент взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия», утвержденный Протоколом заседания Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 09.09.2011 г. №15» Доступен на http://smev.gosuslugi.ru/portal/
«Проект порядка подключения РСМЭВ к СМЭВ» Доступен на http://smev.gosuslugi.ru/portal/
«Проект требований, предъявляемых к РСМЭВ в целях обеспечения подключения к СМЭВ» Доступен на http://smev.gosuslugi.ru/portal/
«Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии» (версии 2.4.5, 2.5.6), утвержденные Протоколом заседания Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 20.04.2012 г. №11 Доступен на http://smev.gosuslugi.ru/portal/
«Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)» Доступен на http://smev.gosuslugi.ru/portal/
Описание процессов, процедур или отдельных действий, осуществляемых администратором Системы
№ Действия Входные данные Выходные данные (результат действия)
Ведение матрицы доступа Предоставление доступа к электронному сервису регионального уровня;
комплект документов в соответствии с регламентирующими документами, описанными в таблице 5; Паспорт электронного сервиса с измененным реестром прав доступа;
уведомление о предоставлении доступа;
опубликованные изменения на ТП РСМЭВ МО.
Предоставление доступа к электронному сервису федерального уровня;
комплект документов в соответствии с регламентирующими документами, описанными в таблице 5;
Паспорт сервиса с обновленным полем SID и адресом сервиса в РСМЭВ МО;
доступ реализован в РСМЭВ МО,
адрес сервиса в РСМЭВ МО;
изменение на ТП РСМЭВ МО.
Ведение реестра электронных сервисов Регистрация электронного сервиса регионального уровня в РСМЭВ МО:
заявка на регистрацию в электронной форме;
комплект документов на сервис в соответствии с регламентирующими документами, описанными в таблице 5;
паспорт электронного сервиса. Сервис зарегистрирован в РСМЭВ МО;
паспорт сервиса опубликован на ТП РСМЭВ МО;
доступ к Потребителям к зарегистрированному электронному сервису предоставлен;
Внесения изменений в электронный сервис РСМЭВ МО:
заявка на внесение изменений с обновленным комплектом документов в соответствии с регламентирующими документами, описанными в таблице 5;
информационные системы зарегистрированы в РСМЭВ МО;
реестр прав доступа в паспорте сервиса. Уведомление об успешной перерегистрации;
Обновленный паспорт сервиса
изменения на ТП РСМЭВ МО.
Подключение функции регламентации доступа без перерегистрации сервиса:
заявка на изменение сервиса с обновленным комплектом документов в соответствии с регламентирующими документами, описанными в таблице 5. Обновленный паспорт сервиса,
Подключение матрицы доступа
Изменения сервиса без перерегистрации:
заявка на изменение сервиса, с обновленным комплектом документов в соответствии с регламентирующими документами, описанными в таблице 5. Обновленный паспорт сервиса
Перерегистрация электронного сервиса доработанного по новой версии методических рекомендаций:
заявка на регистрацию в электронной форме;
комплект документов на сервис в соответствии с регламентирующими документами, описанными в таблице 5;
реестр прав доступа. Регистрация нового сервиса в РСМЭВ МО (новый SID)
Паспорт сервиса;
доступ Потребителям к электронному сервису предоставлен;
изменения на ТП РСМЭВ МО.
Другие изменения сервиса с перерегистрацией и выводом из обращения старой версии сервиса:
комплект документов в соответствии с регламентирующими документами, описанными в таблице 5. Регистрация нового сервиса в РСМЭВ МО (новый SID)
Паспорт сервиса;
доступ Потребителям к электронному сервису предоставлен;
изменения на ТП РСМЭВ МО.
вывод из эксплуатации старой версии сервиса;
информирование о перерегистрации сервиса.
Вывод из эксплуатации устаревшей версии сервиса:
заполненная форма паспорта устаревшего сервиса;
заполненная форма паспорта нового сервиса, доработанного по новой версии методических рекомендаций. Срок вывода из эксплуатации; вывод из эксплуатации старой версии сервиса;
информация на ТП РСМЭВ МО.
Информирование о плановой недоступности электронного сервиса в РСМЭВ МО:
заявка на публикацию информации о недоступности сервиса в РСМЭВ МО;
паспорт электронного сервиса, зарегистрированного в РСМЭВ МО;
информация о ОГВ в интересах, которых разработан сервис. Изменения на ТП РСМЭВ МО.
Отзыв права доступа к электронному сервису и предоставление заявки на отзыв прав доступа. Уведомление об отзыве права доступа к электронному сервису;
публикация новой версии паспорта электронного сервиса Поставщика.
Ведение реестра ИС участников информационного взаимодействия Запрос на подключение информационных систем;
комплект документов в соответствии с регламентирующими документами, описанными в таблице 5. Уведомление Участника информационного взаимодействия о регистрации его информационных систем в РСМЭВ МО;
Положительный результат тестирования / Письмо о необходимости устранения замечаний.
Администрирование ИБ
Управление и настройка комплекса средств защиты информации Открыта возможность для администрирования ИБ;
внедрен и сконфигурирован комплекс средств защиты информации. Корректная работа в соответствии с требованиями по безопасности информации.
Целевое обеспечение СистемыСПО Системы должно функционировать на программно-аппаратном обеспечении, представленном в таблице 7.
Программно-аппаратное обеспечение, предоставляемое Заказчиком для функционирования Системы
№ Наименование виртуального сервера Кол-во
виртуальных
серверов (не более) Кол-во ядер (не более) ОЗУ, ГБ (не более) Объем жесткого диска, Гб. (не более) Общее программное обеспечение
1. Сервер балансировщика нагрузки 2 2 4 20 RHEL или эквивалент,
Akka или эквивалент
2. Сервер приложений 4 2 8 50 RHEL или эквивалент,
Web-контейнер Apache Tomcat или эквивалент
3. Сервер «Интеграционная шина» 6 4 12 50 RHEL или эквивалент,
Apache Camel или эквивалент,
Cxf или эквивалент,
Akka или эквивалент,
Крипто Про
4. Сервер хранилища данных 2 12 36 200 RHEL или эквивалент,
PostgreSQL или эквивалент
5. Web-сервер 2 2 8 50 RHEL или эквивалент,
PostgreSQL или эквивалент,
Web-контейнер Apache Tomcat или эквивалент
Обязанности по предоставлению аппаратного и программного обеспеченияЗаказчик предоставляет аппаратное и общее программное обеспечение Исполнителю на всех этапах развития и эксплуатации Системы.
Перечень подсистем СистемыСистема должна состоять из следующих подсистем:
подсистема распределения задач;
подсистема «Шлюз сервисов»;
подсистема «Реестр электронных сервисов»;
подсистема протоколирования;
подсистема статистики и отчетности.
Целевая функциональная схема Системы приведена на рисунке 1.

Рисунок SEQ Рисунок \* ARABIC 1. Целевая функциональная схема Системы
Сведения о текущем состоянии Системы Наименование работ, выполненных в рамках развития СистемыВыполнение работ на оказание услуг по настройке и вводу в эксплуатацию программно-технического решения, обеспечивающего процессы межведомственного электронного взаимодействия между Поставщиками и Потребителями данных при предоставлении услуг Московской области - Государственный контракт от 15.08.2012 г. № 0148200002412000078-0153034-03.
Выполнение технологических работ по развитию комплекса программно-технических решений, обеспечивающего процессы межведомственного электронного взаимодействия между Поставщиками и Потребителями данных при предоставлении государственных и муниципальных услуг Московской области в электронном виде - Государственный контракт от 17.12.2013 г. № 0148200000613000292.
Перечень функций Системы приведены в таблице 8.
Перечень функций Системы
№ Наименование модуля/подсистемы в текущем состоянии Системы Наименование модуля/подсистемы в целевом состоянии Системы Функции, реализуемые модулем/подсистемой в текущем состоянии Системы
Подсистема «Портал Поставщиков услуг» в составе модуля, обеспечивающего предоставление государственных и муниципальных услуг в электронном виде в условиях стабильных каналов связи, обеспечивающих взаимодействие в режиме реального времени (РСМЭВ МО М1). Функциональная схема модуля - REF _Ref395705357 \* Lower \h \* MERGEFORMAT рисунок 2. Подсистема «Портал Поставщиков услуг» при проведении работ, являющихся предметом ГК, развитию не подлежит. Выполнение процессов предоставления услуг в электронной форме.
Выполнение процессов в рамках межведомственного взаимодействия.
Выполнение процессов в рамках межуровневого взаимодействия, в том числе обмен информаций с федеральными сервисами. Выполнение бизнес-процессов функционирования синхронных электронных сервисов информационных систем участников информационного взаимодействия.
Выполнение бизнес-процессов функционирования синхронных и асинхронных электронных сервисов информационных систем участников взаимодействия.
Разграничение доступа при исполнении процессов предоставления государственных и муниципальных услуг в электронном виде для участников информационного взаимодействия, включенных в систему посредством подсистемы «Портал поставщиков услуг», используя настройки безопасности.
Подсистема «Сервер конфигурации» в составе модуля РСМЭВ МО М1. Подсистема «Реестр электронных сервисов» Управление основными сущностями и каталогом межведомственных запросов.
Управление каталогом поставщиков.
Управление каталогом веб-сервисов.
Конфигурирование подсистемы «Модуль интеграции».
Управление каталогом подсистемы «Модуль интеграции».
Журналирование операций.
Управление регламентами услуг.
Управление документами.
Управление ролями.
Управление справочниками.
Подсистема «Сервисная шина» в составе модуля РСМЭВ МО М1. Подсистема «Шлюз сервисов» Поддержка синхронного и асинхронного способа вызова сервисов.
Гарантированная доставка сообщений, поддерживающая транзакционную модель.
Маршрутизация по контенту и контексту сообщения.
Маршрутизация, основанная на правилах бизнес-процессов.
Обеспечение доступа к данным из внешних информационных систем с помощью готовых или специально разработанных адаптеров.
Обработка и преобразование сообщений, в том числе к формату, определенному в МР.
Подсистема «Модуль интеграции» в составе модуля РСМЭВ МО М1. Подсистема «Шлюз сервисов» и подсистема протоколирования. Обмен электронными сообщениями на основе полученных сведений из файлов конфигурации.
Журналирование операций.
Разграничение прав доступа участников информационного взаимодействия к электронным сервисам РСМЭВ МО.
Формирование подписи ЭП-ОВ в соответствии с документом МР.
Подсистема «Портал мониторинга и статистики» в составе модуля РСМЭВ МО М1. Подсистема статистики и отчетности. Мониторинг сроков действия сертификатов операторов подсистемы «Портал поставщиков услуг».
Получение статистики межведомственного взаимодействия в различных разрезах.
Предоставление информации по запросу оператора подсистемы «Портал поставщиков услуг».
Проверка назначенных прав операторов подсистем «Портал поставщиков услуг».

Рисунок SEQ Рисунок \* ARABIC 2. Функциональная схема модуля РСМЭВ МО М1Текущее программно-аппаратное обеспечение Системы.
№ Наименование виртуального сервера Наименование подсистемы Кол-во виртуальных серверов Общее программное обеспечение
Сервер хранилища данных Подсистема «Портал Поставщиков услуг»,
Подсистема «Сервер конфигурации»,
Подсистема «Сервисная шина». 8 Windows 2008
Snare Server 4.0.0.1Zabbix Agent
СПО СЗИ НСД «Аккорд-Win64»
Microsoft Windows Server 2008
Oracle Database 11gR2
Oracle SQL Developer 3.0
Сервер приложений Подсистема «Модуль интеграции»,
Подсистема «Портал Поставщиков услуг»,
Подсистема «Портал мониторинга и статистики»,
Подсистема «Сервер конфигурации»,
Подсистема «Сервисная шина»,
Сервер РСМЭВ МО М2,
Криптосервис РСМЭВ МО М2. 14 Microsoft Windows Server 2008, Крипто Про CSP 3.6,
Apache Tomcat 6.0.35Java 6.33, Программное обеспечение SiTex – «Портал Поставщиков Услуг»
Сервер «Интеграционная шина» Подсистема «Модуль интеграции»,
Транспортная шина РСМЭВ МО М2. 3 Microsoft Windows Server 2008 Standard Edition SP1, Glassfish 2.2 + OpenESB, IBM WebSphere MQ
Web-сервер Подсистема «Портал Поставщиков услуг»,
Подсистема «Портал мониторинга и статистики»,
Подсистема «Сервер конфигурации». 6 Windows 2008 32-bit Srv, Windows 2008 64-bit, RedHat, Zabbix Server, IBM WebSphere Enterprise Service Bus (6.2.0.3), VMWare vCenter Server 5.x
Рабочая станция АРМ РСМЭВ МО М2,
АРМ администратора РСМЭВ МО М21 Microsoft Windows 2000 SP4 или Microsoft Windows XP SP3 или Microsoft Windows 7 SP1;
Microsoft SQL Server 2005 Express Edition with SP4;
ПК ViPNet Клиент КС3, версия 3.1 (4.8344);
КриптоПро CSP 3.6 R2 КС3 (3.6.6497);
Microsoft XML Core Services (MSXML) версии 4.0;
СЗИ от НСД «Dallas Lock 7.7».
Текущее программное обеспечение Системы
№ Программное обеспечение Назначение и краткое описание программного обеспечения
Операционные системы и средства виртуализации
Windows 2008 64-bit
RedHatПредназначены для работы виртуальных серверов.Уровень хранения и управления данными
Microsoft SQL Server
Oracle Database 11gR2 Предназначены для хранения данных и организации доступа к ним.
Microsoft SQL Server предназначен для поддержки конфигурации системы.
Oracle Database 11gR2 предназначена для хранения полученных и обработанных данных в РСМЭВ МО. На базе данных Oracle проводится генерация отчетов, хранение журнала событий.
Уровень прикладной логики (бизнес-логики)
Сервер приложений Apache Tomcat 6 Предназначен для организации корректного взаимодействия участников информационного взаимодействия.
Уровень представления (пользовательские и технологические интерфейсы Системы)
АРМ-Клиента «СГД BS-eRegion»
КриптоПро CSP
ПК ViPNet Клиент КС3 Предназначены для организации взаимодействия со сторонними приложениями в сервис-ориентированной архитектуре (SOA).Предназначены для организации взаимодействия между браузером и СКЗИ пользователя.
Компоненты визуализации HTML, javascript, CSS, jQuery Предназначены для отображения информации в браузере и организации взаимодействия с пользователем посредством элементов управления.
Документы, содержащие сведения о структуре
и порядке функционирования существующей Системы
№ Наименование документа Способ получения документа
Документация к техническим проектам, разработанная в соответствии с Государственными контрактами, указанными в п.1.7 настоящих Технических требований:
пояснительная записка к техническому проекту
описание автоматизируемых функций
описание программного обеспечения
описание информационного обеспечения
описание комплекса технических средств
общее описание системы
руководство пользователя (оператора, администратора)
руководство системного программиста Предоставляется Заказчиком
Пользовательские требования к СистемеОбщие требования к СистемеСистема должна обеспечивать:
доступ к электронным сервисам внешних информационных систем, подключенных к Системе (в соответствии с п. 3.5.2);
получение, обработку и доставку электронных сообщений органов государственной власти, органов местного самоуправления, многофункциональных центров в рамках информационного взаимодействия при предоставлении государственных и муниципальных услуг (функций) с обеспечением фиксации времени передачи, целостности и подлинности электронных сообщений, указания их авторства и возможности предоставления сведений, позволяющих проследить историю движения электронных сообщений при предоставлении государственных и административных услуг, выполнении функций в электронной форме;защиту передаваемой информации от несанкционированного доступа в соответствии с законодательством РФ в области защиты информации (в соответствии с перечнем, указанным в п. 3.5.5.1);
хранение информации, содержащейся в реестре электронных сервисов информационных систем органов исполнительной власти (далее - реестр электронных сервисов), подключенных к Системе;
широковещательную рассылку информационным системам, подключенным к Системе;
оповещение о сбоях Системы и/или ее компонентов. В автоматическом режиме должен осуществляться регулярный опрос зарегистрированных электронных сервисов, анализ их состояния и формирование автоматической рассылки уведомлений Оператору РСМЭВ МО и поставщику электронного сервиса при диагностировании ошибок;
регистрацию событий, происходящих во внешних информационных системах, подключенных к Системе, а также событий, происходящих в Системе. Передача данной информации о событиях по подписке должна осуществляться заинтересованным пользователям (информационным системам) с поддержкой протоколирования всех уведомлений о возникновении событий и всех фактов рассылки;
предоставление отчетности (в соответствии с п. 3.5.4.5);
автоматизацию процесса регистрации электронных сервисов и ИС в части подачи заявлений участниками информационного взаимодействия и их обработки;
поддержку функционирования всех зарегистрированных электронных сервисов в РСМЭВ МО с 2012 года в соответствии с Приложением Б.
Система должна состоять из следующих подсистем:
подсистема распределения задач;
подсистема «Шлюз сервисов», включающая:
модуль «Сервисная шина», состоящий из:
транспортного модуля;
модуля электронной подписи;
модуля разграничения доступа;
модуля форматно-логического контроля;
модуль «Очередь сообщений»;
подсистема «Реестр электронных сервисов»;
подсистема протоколирования, включающая:
модуль хранения данных;
модуль мониторинга;
подсистема статистики и отчетности.
Целевая функциональная схема Системы представлена в Приложении В.
Требования к организации взаимодействия с внешними информационными системамиИсполнитель обязан реализовать функции, необходимые для взаимодействия Системы с внешними информационными системами.
Внешние информационные системы должны быть подключены к Системе в соответствии с требованиями регламентирующих документов, приведенных в таблице 5.
РСМЭВ МО должна обеспечивать информационное взаимодействие в электронной форме между органами государственной власти (перечень приведен в Приложение А), органами местного самоуправления (перечень приведен в Приложение А), многофункциональными центрами Московской области при предоставлении государственных и муниципальных услуг.
Синхронное взаимодействие Потребителя информации и Поставщика информации должно происходить по следующему обобщенному сценарию:
Информационная система Потребителя информации отправляет электронное сообщение на сервис Поставщика информации в РСМЭВ МО (соответствующий URL в сети);
РСМЭВ МО выполняет обработку электронного сообщения:
проверка электронной подписи сообщения;
выполнение форматно-логического контроля сообщения;
проверка прав доступа Потребителя информации к сервису Поставщика информации.
После выполнения всех проверок РСМЭВ МО передает электронное сообщение информационной системе Поставщика информации;
Информационная система Поставщика информации выполняет обработку запроса Потребителя, отправляет ответ в РСМЭВ МО;
РСМЭВ МО выполняет обработку ответа сервиса Поставщика информации;
РСМЭВ МО отправляет ответ сервиса Поставщика информации в информационную систему Потребителя.
Асинхронное взаимодействие Потребителя информации и Поставщика информации должно происходить по следующему обобщенному сценарию:
Информационная система Потребителя информации отправляет электронное сообщение на сервис Поставщика информации в РСМЭВ МО (соответствующий URL в сети);
РСМЭВ МО выполняет обработку электронного сообщения:
проверка электронной подписи сообщения;
выполнение форматно-логического контроля сообщения;
проверка прав доступа Потребителя информации к сервису Поставщика информации.
После выполнения всех проверок РСМЭВ МО передает электронное сообщение информационной системе Поставщика информации;
Информационная система Поставщика информации выполняет обработку запроса Потребителя и отправляет в РСМЭВ МО сообщение-квиток с уведомлением, что запрос получен;
РСМЭВ МО выполняет обработку ответа сервиса Поставщика информации;
РСМЭВ МО отправляет сообщение-квиток в информационную систему Потребителя;
Потребитель отправляет электронное сообщение с запросом статуса на сервис Поставщика информации в РСМЭВ МО;
РСМЭВ МО выполняет обработку электронного сообщения:
проверка электронной подписи сообщения;
выполнение форматно-логического контроля сообщения;
проверка прав доступа Потребителя информации к сервису Поставщика информации.
После выполнения всех проверок РСМЭВ МО передает электронное сообщение информационной системе Поставщика информации;
Информационная система Поставщика информации выполняет обработку запроса Потребителя и отправляет в РСМЭВ МО сообщение, содержащее статус исполнения запроса или ответ;
РСМЭВ МО выполняет обработку ответа сервиса Поставщика информации;
РСМЭВ МО отправляет ответ сервиса Поставщика информации в информационную систему Потребителя.
Требования к надежности и производительности (потребительские характеристики)Система должна функционировать в соответствии с показателями производительности и надежности, установленными в таблице 12.
Показатели надежности и производительности Системы
Наименование критерия Условие Эталонное значение Единица измерения
Суммарное время недоступности Системы или ее компонентов в течение года не более 5 дни
Максимальная продолжительность недоступности Системы или ее компонента не более 24 час
Минимальное время между периодами недоступности системы не менее 5 дни
Количество участников информационного взаимодействия не ограничено - Шт.
Максимальное число одновременно работающих участников информационного взаимодействия - 2000 Шт.
Время отклика Системы на запрос не более 30 сек.
Объемы хранимых данных в Системе не более 6000 Гб.
Максимальное количество сервисов 1000 Шт.
Количество подписчиков на сервис не более 5000 ВИС
Система должна обеспечивать сохранение производительности при приросте хранилища данных в течение месяца не более 100 Гб.
Количество транзакций в месяц, при условии размера одного сообщения 5 Мб. не более 1000000 Шт.

Функциональные требования к подсистемамФункциональные требования к подсистеме распределения задач
Подсистема распределения задач предназначена для осуществления информационного обмена между ведомственными информационными системами федерального и регионального уровня.
В подсистеме распределения задач должны быть реализованы следующие функции:
распределение входящих сообщений электронных сервисов между модулями «Сервисная шина» в подсистеме «Шлюз сервисов»;
предоставление внешним информационным системам WSDL и XSD описаний электронного сервиса из подсистемы «Реестр электронных сервисов»;
оповещение ИС участника информационного взаимодействия о статусе доставки сообщения.
Функциональные требования к подсистеме «Шлюз сервисов»
Подсистема «Шлюз сервисов» должен состоять из следующих модулей:
«Сервисная шина»;
«Очередь сообщений».
Каждый экземпляр модуля «Очередь сообщений» должен взаимодействовать со всеми экземплярами модуля «Сервисная шина» (Приложение В). Распределение сообщений между экземплярами модулей «Очередь сообщений» поступающих из экземпляров модулей «Сервисная шина» выполняется балансировщиком нагрузки размещенном в «Транспортном модуле». Подсистема «Шлюз сервисов» должна унаследовать ранее разработанные функции:
поддержка синхронного и асинхронного взаимодействия сервисов;
маршрутизация, основанная на правилах бизнес-процессов;
обмен электронными сообщениями на основе полученных сведений из файлов конфигурации;
протоколирование операций;
разграничение прав доступа участников информационного взаимодействия к электронным сервисам;
прием запросов электронных сервисов, подписанных электронной подписью;
проверка электронной подписи ИС отправителя входящих электронных сообщений;
поддержка механизмов преобразования данных во входящих и исходящих сообщениях к внутреннему каноническому формату сообщений передачи данных.
Подсистема «Шлюз сервисов» должна обеспечивать выполнение новых функций:
идентификация и авторизация информационной системы отправителя сообщения по ЭП-ОВ, расположенной в заголовке xml-сообщения;
прием запросов электронных сообщений, подписанных электронной подписью, и их отправка Поставщику информации с гарантией целостности;
выполнение форматно-логического контроля электронных сообщений с поддержкой актуальных форматов МР;
добавление ЭП РСМЭВ МО в унифицированный заголовок передаваемых xml-сообщений.
Требования к модулю «Сервисная шина»
Модуль «Сервисная шина» должен состоять из следующих модулей:
транспортный модуль;
модуль электронной подписи;
модуль разграничения доступа;
модуль форматно-логического контроля.
Необходимо обеспечить возможность запуска дополнительных экземпляров модуля «Сервисная шина» для распределения нагрузки.
Транспортный модуль должен обеспечивать выполнение следующих функций:
распределение сообщений между экземплярами модулей «Очередь сообщений» поступающих из экземпляров модулей «Сервисная шина»
обеспечение возможности организации взаимодействия между гетерогенными транспортными системами, которые могут различаться протоколами, форматами, правилами приема передачи данных. Функция должна быть реализована с помощью преобразования данных во входящих и исходящих сообщениях к внутреннему каноническому формату сообщений передачи данных;
управление процессом доставки электронного сообщения с гарантией целостности (направление на обработку, протоколирование);
обеспечение гарантированной доставки сообщений при синхронном и асинхронном взаимодействии с использованием промежуточного хранения в очереди сообщений и последующей пересылкой и поддержкой механизма уведомления потребителя;
поддержка маршрутизации поступивших запросов, в том числе маршрутизации, основанной на правилах бизнес-процессов и файлов конфигурации;
обеспечение взаимодействия посредством стандартного протокола SOAP.
Требования к модулю электронной подписи
Модуль электронной подписи должен осуществлять проверку электронной подписи ИС отправителя входящих электронных сообщений (валидация значений ЭП, проверка действительности сертификата).
Модуль электронной подписи должен использовать следующий алгоритм проверки подписи:
Расчет значения хэш-функции (DigestValue) от подписываемой части и её сравнение со значением элемента ds:DigestValue блока электронной подписи;
Если значения не совпадают, подпись считается некорректной;
Если значения хеш-функции совпадают, выполняется сравнение значений подписи (SignatureValue);
Если значения SignatureValue совпадают, подпись считается корректной.
Модуль электронной подписи должен проверять действительность сертификата электронной подписи отправителя сообщения.
Структура сертификата ключа проверки электронной подписи должна соответствовать Федеральному закону РФ от 06.04.2011 г. № 63-ФЗ «Об электронной подписи».
При прохождении электронных сообщений через РСМЭВ МО на них должна устанавливаться электронная подпись РСМЭВ МО в формате XMLDSIG (описание формата доступно по адресу: http://www.w3.org/TR/xmldsig-core/), подтверждающая:
факт прохождения электронного сообщения через РСМЭВ МО;
неизменность сведений, внесенных в электронное сообщение.
Унифицированный служебный заголовок РСМЭВ МО предназначен для размещения в сообщении сведений, добавляемых в него Системой.
Требования к модулю разграничения доступа
Модуль разграничения доступа предназначен для хранения данных матрицы доступа ведомственных информационных систем к электронным сервисам, зарегистрированным в РСМЭВ МО, и для осуществления проверки прав доступа при получении запросов от ведомственных информационных систем.
Доступ должен предоставляться на уровне всего электронного сервиса либо на уровне отдельных операций электронного сервиса.
Модуль разграничения доступа должен обеспечивать выполнение следующих функций:
контроль и предупреждение несанкционированного доступа к сервисам и информации;
управление доступом к электронным сервисам поставщиков в соответствии с перечнем поставщиков и потребителей сервисов, а также их правами;
назначение прав доступа участников информационного взаимодействия в соответствии с действующими нормативными правовыми документами;
ведение контрольной информации об изменениях в правах доступа;
идентификация и авторизация информационной системы отправителя сообщения по ЭП-ОВ, расположенной в заголовке xml-сообщения.
Модуль разграничения доступа должен предоставлять возможность редактирования прав доступа к электронным сервисам в АРМ администратора.
Настройка матрицы доступа к электронным сервисам должна осуществляться Оператором РСМЭВ МО.
Требования к модулю форматно-логического контроля
Форматно-логический контроль предназначен для предотвращения прохождения через РСМЭВ МО электронных сообщений, несоответствующих актуальному формату МР.
Ошибочные электронные сообщения должны размещаться в БД РСМЭВ МО с описанием найденной ошибки.
Форматно-логический контроль должен иметь 3 настраиваемых параметра:
блокировка некорректных сообщений;
идентификатор схемы валидации;
контроль значений полей, заполняемых из классификаторов (вкл/выкл).
В случае если включен режим блокировки некорректных сообщений, при получении сообщения, не проходящего ФЛК, РСМЭВ МО должна выдать отправителю сообщение об ошибке (Soap:Fault), её описание и прервать обработку сообщения.Идентификатор схемы валидации должен представлять собой идентификатор файла, в котором должны быть заданы:
XSD-схема, на соответствие которой нужно проверить сообщение;
перечень справочных полей и соответствующих им классификаторов.
Форматно-логический контроль должен состоять в проверке поступившего электронного сообщения на соответствие заданной XSD-схеме: формализации формата передачи данных.
Если соответствие не установлено, то ФЛК должен считаться не пройдённым. В этом случае должна быть произведена запись сообщения об ошибке в модуль протоколирования РСМЭВ МО.
Требования к модулю «Очередь сообщений»
Очередь электронных сообщений предназначена для синхронного и асинхронного взаимодействия между Поставщиками и Потребителями информации.
Очередь электронных сообщений должна удовлетворять следующим требованиям:
должна быть реализована возможность настройки количества попыток доставки электронного сообщения, помещенного в очередь;
должна быть реализована возможность настройки времени «жизни» электронного сообщения в очереди: времени, в течение которого должны предприниматься попытки доставки электронного сообщения.
Необходимо обеспечить возможность запуска дополнительных экземпляров модуля «Очередь сообщений».
Функциональные требования к подсистеме «Реестр электронных сервисов»
Реестр электронных сервисов (далее – реестр сервисов) предназначен для хранения и ведения данных об электронных сервисах, зарегистрированных в РСМЭВ МО, с обеспечением сохранения метаданных, описывающих используемые электронные сервисы участников информационного взаимодействия.
Реестр сервисов должен унаследовать ранее разработанные функции:
управление основными сущностями;
управление каталогом поставщиков;
управление документами;
управление справочниками;
управление ролями.
Реестр сервисов должен обеспечивать выполнение новых функций:
управление каталогом веб-сервисов;
протоколирование операций;
редактирование сведений в матрице доступа;
определение прикладных атрибутов сервиса по его мнемонике;
получение руководства пользователя по сервису;
получение контрольных примеров в соответствии с операциями (методами) электронного сервиса;
предоставление основной информации по электронным сервисам (владелец, идентификатор, наименование электронного сервиса, назначение, режим доступности, режим работы, область применения);
предоставление информации, содержащейся в форме паспорта электронного сервиса (детальная информация по характеристикам, возможным операциям и реестру прав доступа);
поиск/фильтрация зарегистрированных электронных сервисов по ключевым словам и категориям.
Все сообщения, проходящие через РСМЭВ должны соответствовать МР, в том числе и сервисы каталога веб-сервисов.
Протоколирование должно поддерживать единый стандарт записи для всех входящих сообщений, с указанием услуги, в рамках которой осуществляется межведомственный запрос.
Должна быть реализована возможность поддержки смены уровня протоколирования.
Для редактирования сведений в реестре сервисов должны быть реализованы следующие операции:
регистрация нового сервиса;
изменение атрибутов зарегистрированных сервисов.
Модуль должен обеспечивать предоставление адреса каждому электронному сервису Поставщика информации при его регистрации. Потребитель, предварительно зарегистрированный на РСМЭВ МО, может обратиться к электронному сервису по уникальному адресу.
При регистрации сервиса в реестре сервисов должна осуществляться автоматическая загрузка WSDL описаний сервиса, а также соответствующих XSD-схем.
После успешной регистрации все сервисы должны быть доступны в репозитории электронных сервисов.
АРМ администратора должен обеспечивать выполнение следующих функций:
конфигурирование подсистемы «Шлюз сервисов»;
управление каталогом веб-сервисов (добавление и редактирование сведений в реестре сервисов).
Конфигурирование подсистемы «Шлюз сервисов» должно позволять изменять настройки с сохранением функционирования Системы в штатном режиме.
Управление каталогом веб-сервисов должно позволять выполнять настройку каталога с сохранением функционирования Системы в штатном режиме.
Для редактирования сведений в реестре сервисов из внешних систем и подсистем должны быть реализованы интерфейсы, в виде электронных сервисов.
Функциональные требования к подсистеме протоколирования
Подсистема протоколирования предназначена для хранения и организации данных, проходящих через РСМЭВ МО.
В РСМЭВ МО должно осуществляться протоколирование всех электронных сообщений, проходящих через систему.
В случае если сообщения содержат ссылки на файлы (документы), хранящиеся во внешних ИС, в модуле хранения данных должно осуществляться сохранение этих сведений.
Должно быть реализовано протоколирование следующих событий:
электронных запросов до наложения ЭП РСМЭВ МО;
электронных ответов до наложения ЭП РСМЭВ МО;
электронных запросов после наложения ЭП РСМЭВ МО;
электронных ответов после наложения ЭП РСМЭВ МО;
событий, связанных с обработкой электронных сообщений внутри РСМЭВ МО;
событий, связанных с форматно-логическим контролем;
изменения статусов доставки электронного сообщения;
событий, связанных с попытками несанкционированного доступа;
регистрации, изменения и удаления идентификационных и аутентификационных данных субъектов доступа;
идентификация и аутентификация субъектов доступа;
создание, изменение, удаление правил контроля доступа.
Сбор и хранение результатов протоколирования должен выполнять модуль хранения данных.
Модуль мониторинга должен обеспечивать:
мониторинг доступности веб-сервисов Потребителей и Поставщиков, зарегистрированных в Системе;
мониторинг работоспособности подсистем и модулей Системы.
Функциональные требования к подсистеме статистики и отчетности
Подсистема статистики и отчетности должна выполнять следующие функции:
получение статистики межведомственного взаимодействия в различных разрезах;
предоставление информации по запросу Участников информационного взаимодействия.
Должна быть обеспечена возможность предоставления статистических данных по работе РСМЭВ МО. Состав и формат статистических данных должны быть согласованы с Заказчиком на этапе разработки ЧТЗ на развитие Системы. Масштабируемость подсистемы в реальном времени должна быть обеспечена с сохранением функционирования Системы в штатном режиме.
Участник информационного взаимодействия должен иметь возможность получать статистические данные о работе РСМЭВ на почтовый ящик по запросу.
Требования к электронным сообщениям ведомственных информационных систем, направляемым в РСМЭВ МО
Информационное взаимодействие в РСМЭВ МО осуществляется путем обмена XML сообщениями.
Входящие электронные сообщения, полученные по каналам связи системы взаимодействия, проходят контроль в следующем порядке:
проверка электронной подписи электронного сообщения (при необходимости);
форматно-логическая проверка электронного сообщения.
Проверка ЭП в электронных сообщениях производится на предмет корректности значений ЭП и на предмет действительности соответствующих сертификатов ключей подписи.
В случае если проверка корректности одного из значений ЭП или проверка действительности одного из сертификатов ключей подписи дала отрицательный результат, отправителю электронного сообщения направляется уведомление в виде служебного сообщения, а результат операции записывается в журнал регистрации событий системы взаимодействия.
В случае не прохождения форматно-логической проверки электронное сообщение исключается из дальнейшей обработки, данный факт фиксируется, и по каналам связи системы взаимодействия отправителю направляется служебное электронное сообщение, извещающее об отказе в приеме электронного сообщения.
Если принятое и успешно прошедшее процедуры контроля электронное сообщение является сообщением запроса на предоставление электронной услуги, то информационная система поставщика разрешает использование данного электронного сервиса.
Если принятое и успешно прошедшее процедуры контроля электронное сообщение является извещением о готовности данных, то информационная система оператора, имеющего право использования электронного сервиса в соответствии с настоящими Требованиями (далее – потребитель), при необходимости, инициирует сервис запроса этих данных.
Общая структура электронного сообщения включает в себя:
заголовок электронного сообщения системы взаимодействия (soap:header);
тело электронного сообщения системы взаимодействия (soap:body);
сообщение об ошибке (soap:Fault). Заголовок электронного сообщения системы взаимодействия включает в том числе:
передачу сведений об аутентификации и авторизации (WS-security);
Тело электронного сообщения системы взаимодействия в общем случае состоит из следующих элементов:
блок данных;
блок присоединенных документов;
блок ЭП.
Блок данных электронного сообщения должен содержать дату и время отправки электронного сообщения в систему взаимодействия.
Блок присоединенных документов может содержать информацию (текстовую, графическую и пр.), прилагаемую к электронному сообщению системы взаимодействия.
Блок ЭП должен содержать одну или несколько ЭП, фиксирующих целостность и авторство каждого из блоков данных.
Сообщение об ошибке содержит текстовое описание возникшей ошибки и ее код в рамках информационной системы, в которой она возникла.
Ответственным за содержание реквизитов электронного сообщения является участник информационного взаимодействия, отправивший данное электронное сообщение, если иное не предусмотрено настоящими Требованиями.
Ответственным за легитимность использования ЭП является участник информационного взаимодействия, отправивший электронное сообщение.
Все элементы метаданных в описании схемы данных должны быть документированы на русском языке.
Документирование элементов метаданных рекомендуется выполнять с использованием конструкции:
<xsd:annotation>
<xsd:documentation>Текст описания</xsd:documentation>
</xsd:annotation>
Синтаксическую конструкцию <!-- текст комментария --> рекомендуется применять только в качестве вспомогательных комментариев к описаниям данных, если это необходимо, и не использовать для документирования элементов метаданных.
При формировании наименования элементов метаданных рекомендуется осуществлять подбор слова или словосочетания из английского языка, соответствующего тому или иному используемому понятию.
Наименования, обозначающие общепринятые аббревиатуры, подлежат транслитерации на латиницу.
В исключительных случаях, если в английском языке отсутствует слово или словосочетание, достаточно однозначно определяющее описываемое понятие или допускающее большое количество вариантов обратного перевода, допустимо использовать транслитерацию на латинский алфавит.
Все слова в наименовании элемента метаданных рекомендуется использовать полностью, без сокращений.
Порядок записи слов в наименовании, в которых используется два или более слова, должен соответствовать правилам английского языка. Слова должны записываться подряд, без пробела и других знаков между ними.
Наименования метаданных должны записываться строчными буквами, кроме аббревиатур, записываемых полностью прописными (заглавными) буквами. Если используется два или более слова, то каждое последующее слово кроме первого должно начинаться с прописной (заглавной) буквы. По согласованию с оператором системы взаимодействия допускается использование в качестве первого (а также единственного) слова с прописной (заглавной) буквы.
В наименования простых и составных типов (simpleType, complexType) для обозначения их отличия от элементов (element), рекомендуется добавлять суффикс «Type».
Требования к проектированию подсистемы информационной безопасностиПеречень нормативных документов по обеспечению безопасности информации
При проведении работ по обеспечению безопасности информации должны учитываться требования следующих законодательных актов и методологических рекомендаций:
Указ Президента РФ от 06.03.1997 г. №188 «Об утверждении перечня сведений конфиденциального характера»;
Федеральный закон РФ от 27.07.2006 г. №149-ФЗ «Об информации, информационных технологиях и о защите информации»;
Федеральный закон РФ от 27.07.2006 г. №152-ФЗ «О персональных данных»;
Постановление Правительства РФ от 15.09.2008 г. № 687 « Об утверждении Положения об особенностях обработки персональных данных, осуществляемой без использования средств автоматизации»;
Постановление Правительства РФ от 15.05.2010 г. № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»;Постановление Правительства РФ от 01.11.2012 г. № 1119 «О требованиях к защите персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК от 15.02.2008 г. «О методике определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК от 15.02.2008 г. «О базовой модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК от 11.02.2013 г. № 17 «О требованиях к защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
Приказ ФСТЭК от 18.02.2013 г. № 21 «О составе и содержании организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСБ от 21.02.2008 г. №149/54-144 «О методических рекомендациях по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации»;
Приказ ФСБ от 21.02.2008 г. №149/54-144 «О типовых требованиях по организации и обеспечению функционирования шифровальных (криптографических) средств, предназначенных для защиты информации, не содержащей сведений, составляющих государственную тайну в случае их использования для обеспечения безопасности персональных данных при их обработке в информационных системах персональных данных»; Приказ ФСБ от 27.12.2011 г. № 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи»;
Приказ ФСБ от 27.12.2011 г. № 796 «Об утверждении требований к средствам электронной подписи и Требований к средствам удостоверяющего центра»;
Постановление Правительства Московской области от 27.11.2002 г. №573/46 «Об утверждении Положения о порядке обращения с информацией ограниченного доступа в исполнительных органах государственной власти Московской области, государственных органах и государственных учреждениях Московской области».
Общие требования к информационной безопасности
Для обеспечения защиты информации от неправомерного доступа, уничтожения, модифицирования, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий в отношении такой информации, в рамках проведения работ необходимо:
определить цель и задачи обеспечения защиты информации в Системе;
определить и описать объекты доступа, с которыми работает Система, классифицировать обрабатываемую информацию в соответствии с законодательством РФ, а также уровнем конфиденциальности данных, предъявляемым Заказчиком;
определить класс защищенности Системы;
разработать и утвердить модель угроз и модель нарушителя информационной безопасности Системы;
разработать и описать требуемые меры обеспечения безопасности, как в части технической защиты, так и в части организационных мер;
исключить дублирование средств и функций обеспечения информационной безопасности в рамках центра обработки данных;
провести оценку соответствия реализованных мер предъявляемым требованиям по безопасности информации.
Организационные меры защиты информации, реализуемые в Системе, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик Системы должны обеспечивать:
идентификацию и аутентификацию субъектов доступа и объектов доступа;
управление доступом;
ограничение программной среды;
защиту машинных носителей информации;
регистрацию событий безопасности;
контроль (анализ) защищенности информации;
целостность информационной системы и информации;
доступность информации.
При реализации мер по защите информации, реализуемых в Системе, должны использоваться: механизмы системного программного обеспечения Системы (ОС, СУБД, среда виртуализации), механизмы прикладного программного обеспечения Системы, а также дополнительные средства защиты информации.
При невозможности реализации в Системе отдельных выбранных мер защиты информации должны быть разработаны иные (компенсирующие) меры защиты информации, обеспечивающие адекватное блокирование (нейтрализацию) угроз безопасности информации.
При выявлении дополнительных угроз безопасности информации, для которых не определены меры защиты информации, должны быть разработаны компенсирующие меры.
Требования к реализации в Системе юридической значимости электронных документов
Юридическая значимость электронных документов в Системе должна обеспечиваться за счет функционирования средств криптографической защиты информации и используемого совместно с ними Удостоверяющего Центра Правительства МО в соответствии требованиями, предъявляемыми Федеральным законом от 06.04.2011 г. № 63-ФЗ «Об электронной подписи».
Для обеспечения создания квалифицированной подписи в составе Системы должны использоваться средства ЭП, удовлетворяющие требованиям к квалифицированной электронной подписи. Средства ЭП должны:
показывать лицу, подписывающему электронный̆ документ, содержание информации, которую он подписывает;
создавать ЭП только после подтверждения лицом, подписывающим электронный̆ документ, операции по созданию ЭП;
однозначно показывать, что ЭП создана.
При проверке ЭП средства ЭП должны:
показывать содержание электронного документа, подписанного ЭП;
показывать информацию о внесении изменений в подписанный̆ ЭП электронный̆ документ;
указывать на лицо, с использованием ключа ЭП которого подписаны электронные документы.
Дополнительные требования к информационной безопасности
Доступ пользователей к персонализированным функциям и данным Системы должен предоставляться только после прохождения пользователем процедур аутентификации и авторизации.
Доступ пользователей к функциям и данным Системы должен быть ограничен на основе ролевого принципа. Каждому пользователю должна быть сопоставлена учетная запись, ассоциированная с одной из нескольких предопределенных пользовательских ролей. Для каждой пользовательской роли должны быть определены конкретные ограничения на доступ к функциям и данным Системы.
Требования к защите информации при ее передаче
В Системе должна быть обеспечена возможность защиты информации от потери и несанкционированного доступа на этапах ее передачи и хранения.
На этапе информационного обмена с СМЭВ необходимо обеспечить:
маршрутизацию IP-трафика между РСМЭВ МО и СМЭВ через СКЗИ (криптомаршрутизаторы марки VipNet, предоставляемые оператором СМЭВ);
прохождение IP-трафика на СКЗИ и от него по протоколу UDP порт источника и назначения 55777. В случае занятости указанного порта иным устройством, выбирается любой другой порт, информация о котором передается оператору СМЭВ.
Должен быть реализован следующий комплекс мер, направленных на защиту от несанкционированного доступа к функциям административного интерфейса Системы:
возможность ограничения доступа к административному интерфейсу;
возможность ведения журналов действий пользователей в административном интерфейсе и журнала аутентификаций.
Для настройки прав пользователей должны создаваться отдельные роли пользователей с назначением разрешений на выполнение отдельных функций и ограничений по доступу к информации, обрабатываемой в Системе.
Система должна обеспечивать выполнение требований по информационной безопасности в части:
регистрации событий;
аутентификации и авторизации;
защиты данных;
использования ЭП.
Требования к аутентификации пользователей
Права доступа пользователей к функциям Системы должны быть разграничены для разных групп пользователей.
У администратора должна быть возможность управления правами доступа других пользователей к функциям Системы. Должна использоваться ролевая модель прав доступа – каждому пользователю должна быть сопоставлена одна или несколько ролей. Для каждой роли должны быть назначены разрешенные операции в рамках каждого из компонентов Системы. Для назначения пользователю прав администратора должна использоваться системная роль пользователей «Администратор».
Дополнительные требования к развиваемой системеТребования к решению по протоколам передачи данныхПротоколы передачи данных Системы должны удовлетворять требованиям к протоколам сетевого взаимодействия в соответствии с документом «Проект требований, предъявляемых к РСМЭВ в целях обеспечения подключения к СМЭВ».
Взаимодействие между подсистемами РСМЭВ МО должно осуществляться по протоколам TCP/IP, HTTP. При использовании сетевых протоколов передачи данных должны использоваться следующие спецификации:
протокол передачи гипертекста HTTP v. 1.1 – стандарт RFC 2616 инженерной группы проектировщиков информационно-телекоммуникационной сети Интернет (Internet Engineering Task Force, IETF);
модернизированный протокол http v. 1.1 с обеспечением безопасности транспортного уровня (TLS) для существующего протокола управления передачей (TCP);
протокол защищённых соединений SSL v. 3 / TLS – стандарт RFC 2246 инженерной группы проектировщиков информационно-телекоммуникационной сети Интернет (Internet Engineering Task Force, IETF);
сервисы поддержки пространства имен DNS (Domain Name Services) – стандарт RFC 1035 инженерной группы проектировщиков информационно-телекоммуникационной сети Интернет (Internet Engineering Task Force, IETF).
Информационный обмен субъектов взаимодействия должен базироваться на реализации электронных сервисов информационного обмена с соблюдением спецификаций:
спецификация электронных сервисов (WS-I Simple SOAP Binding Profile 1.0) - стандарт консорциума W3C;
спецификация протокола SOAP (Simple Object Access Protocol, SOAP 1.1) – рекомендации консорциума W3C;
язык описания электронных сервисов (Web Services Description Language, WSDL 1.1) – стандарт консорциума W3C;
политика использования электронных сервисов (Web Services Policy 1.2) – рекомендации консорциума W3C;
расширяемый язык разметки (Extensible Markup Language, XMLSchema 1.0) – рекомендации консорциума W3;
расширяемый язык таблиц стилей XSL v. 1.1 (Extensible Stylesheet Language) – рекомендации консорциума W3C;
базовый профиль интероперабельности v. 1.1 – стандарт Организации по интероперабельности веб-сервисов (Web Services Interoperability Organization Basic Profile 1.1).
Требования к организации взаимодействия между компонентами СистемыПри взаимодействии между компонентами Системы не должна происходить потеря сообщений.
Детальные требования к способам и средствам связи для информационного обмена между компонентами Системы должны быть определены на этапе разработки ЧТЗ.
Требования к техническому обеспечениюСистема должна размещаться на технических средствах Заказчика, определенных в разделе 3.2.
Требования к техническому обеспечению Системы могут быть уточнены на этапе создания ЧТЗ на развитие Системы по согласованию с Заказчиком.
Требования к организации эксплуатации и техническому обслуживаниюСистемное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация учебного процесса подготовки пользователей и другие работы (услуги) производятся на основании Государственных контрактов на выполнение соответствующих работ (услуг).
Требования к режимам функционированияСистема должна поддерживать следующие режимы функционирования:
основной режим;
профилактический режим.
В основном режиме функционирования Система должна обеспечивать решение своих функциональных задач.
В профилактическом режиме Система должна обеспечивать возможность проведения следующих работ:
реконфигурация и модернизация Системы и ее компонентов;
реконфигурация, модернизация и другое обслуживание аппаратных средств Системы;
реконфигурация, модернизация и другое обслуживание программных средств Системы.
Диагностирование Системы должно осуществляться во всех режимах её функционирования.
При диагностировании Системы в основном режиме должна быть обеспечена возможность мониторинга функционирования программных и аппаратных средств, технологических узлов Системы с целью обнаружения проблем, которые могут привести к возникновению аварийных ситуаций.
В профилактическом режиме, должна быть обеспечена возможность выполнения следующих работ по диагностированию Системы:
комплексная проверка работоспособности системы на контрольных примерах;
диагностирование целостности информации.
Регламент эксплуатации системы должен содержать порядок функционирования Системы в указанных режимах. Требования к регламенту эксплуатации приведены в разделе 7 настоящих Технических требований.

СОСТАВ, СОДЕРЖАНИЕ И РЕЗУЛЬТАТЫ РАБОТЭтапы, сроки и результаты работ по этапам приведены в таблице 13.
Этапы проведения работ
№ Наименование этапа и выполняемых работ Сроки выполнения Результаты работ
Начало Конец Этап 1. Формирование требований и ЧТЗ и Техно-рабочее проектирование и развитие СПО Системы первой очереди Дата заключения ГК 15.12.2014 Разработка и утверждение ЧТЗ на развитие Системы 05.12.2014 ЧТЗ на развитие Системы.
Разработка и утверждение ЧТЗ на подсистему информационной безопасности 05.12.2014 ЧТЗ на подсистему информационной безопасности.
Развертывание и испытания тестового контура СПО Системы 05.12.2014 Программа и методика испытаний тестового контура СПО Cистемы;
Протокол испытаний тестового контура СПО Cистемы;
Акт сдачи-приемки работ по этапу;
Акт о передаче исходных кодов и дистрибутива тестового контура СПО Системы;
Исходные коды и дистрибутив тестового контура СПО Системы.
Техническое проектирование СПО Системы 10.12.2014 Пояснительная записка к техническому проекту;
Описание автоматизированных функций;
Описание информационного обеспечения;
Описание программного обеспечения;
Проект приказа о вводе в действие политики информационной безопасности в Системе;
Отчет о ходе выполнения работ;
Модель угроз и нарушителя информационной безопасности Системы.
Рабочее проектирование СПО, в том числе развитие СПО Системы первой очереди, в составе:
подсистемы распределения задач;
подсистемы «Шлюз сервисов»;
подсистемы «Реестр электронных сообщений»;
подсистемы протоколирования (модуль хранения данных) 15.12.2014 СПО Системы первой очереди,
Программа и методика испытаний СПО Системы первой очереди;
Протокол приемочных испытаний СПО Системы первой очереди;
Акт сдачи-приемки работ по этапу;
Акт о передаче исходных кодов и дистрибутива СПО Системы первой очереди;
Исходные коды и дистрибутив СПО Системы первой очереди.
2. Этап 2. Развитие СПО второй очереди Системы и ввод в действие Дата завершения Этапа 2 30.03.2015 2.1 Развитие СПО Системы второй очереди, в составе:
подсистемы протоколирования (модуль мониторинга);
подсистемы статистики и отчетности. Дата окончания Этапа 1 28.02.2015 СПО Системы второй очереди;
Программа подготовки пользователей;
Руководство администратора;
Проект регламента эксплуатации Системы;
Ведомость машинных носителей информации.
Проект регламента информационного взаимодействия участников межведомственного взаимодействия в РСМЭВ МО.
Программа и методика испытаний СПО Системы второй очереди;
Протокол приемочных испытаний СПО Системы второй очереди;
Акт о передаче исходных кодов и дистрибутива СПО Системы второй очереди;
Акт сдачи-приемки работ по этапу;
Исходные коды и дистрибутив СПО Системы второй очереди.
2.2 Передача в эксплуатацию Системы Дата окончания Этапа 2.1 30.03.2015 2.2.1 Развертывание СПО Системы Дата окончания Этапа 2.1 08.03.2015 Акт выполнения пуско-наладочных работ СПО Системы.
2.2.2 Подготовка пользователей Системы Дата окончания Этапа 2.1 08.03.2015 Ведомость подготовки пользователей.
2.2.3 Предварительные испытания Системы Дата окончания Этапа 2.2.1 09.03.2015 Программа и методика предварительных испытаний;
Программа опытной эксплуатации;
Протокол предварительных испытаний;
Акт приемки в опытную эксплуатацию.
2.2.4 Опытная эксплуатация Системы Дата окончания Этапа 2.2.3 16.03.2015 Отчет о проведении опытной эксплуатации (включая Журнал опытной эксплуатации);
Акт о завершении опытной эксплуатации и готовности Системы к приемочным испытаниям.
2.2.5 Приемочные испытания Системы Дата окончания Этапа 2.2.4 30.03.2015 Проект РД Правительства МО о вводе Системы в промышленную эксплуатацию;
Программа и методика приемочных испытаний;
Протокол приемочных испытаний;
Акт о готовности Системы к промышленной эксплуатации;
Акт приема передачи научно-технической продукции;
Исходные коды и дистрибутив.

ТРЕБОВАНИЯ К РАБОТАМОбщие требованияТребования к качеству и результатам выполнения работЕсли реализация требований настоящих Технических требований не затрагивает каких-либо компонентов уже созданной Системы, требования, определённые в ЧТЗ на развитие Системы для этих компонентов, могут быть исключены из состава проверок при приёмке результатов работ. Решение об исключении соответствующих проверок принимает Заказчик при утверждении «Программы и методики испытаний».
Требования к составу и оформлению результатов работ определены разделами 5 и 7 настоящего документа.
Результаты работ передаются Заказчику в порядке, определенном Государственным контрактом в соответствии с Календарным планом работ Государственного контракта на основании Акта приема-передачи научно-технической продукции. Требования к оформлению указанного акта приведены в Приложении Г1.
Исполнитель должен передать Заказчику исходные коды всех программ и баз данных на электронном носителе c однократной записью. Одновременно Заказчику передаются спецификация разработки, техническая и пользовательская документация, описание модели компиляции программного кода.
Состав передаваемых на машинных носителях результатов работ оформляется документом «Ведомость машинных носителей информации». Требования к оформлению документа приведены в Приложении Г.
Документация на Систему передается на бумажном и на машинном носителях (CD|DVD) в двух экземплярах. Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах «MS Office».
Формирование требований к ЧТЗ
Требования к ЧТЗРазработанные ЧТЗ после утверждения Заказчиком становятся неотъемлемой частью Государственного контракта.
В ЧТЗ на развитие Системы должны быть учтены требования к Системе, изложенные в разделе 3 настоящих Технических требований.
В ЧТЗ на подсистему информационной безопасности должны быть учтены требования к Системе, изложенные в пункте 3.5.5 настоящих Технических требований.
ЧТЗ не должны включать разделы, дублирующие содержание разделов настоящих Технических требований.
ЧТЗ на подсистему информационной безопасности должно дополнительно включать следующие разделы:
требования к классу защищенности системы;
требования к численности и квалификации персонала системы и режиму его работы;
перечень аварийных ситуаций;
требования безопасности;
требования к техническим компонентам подсистемы информационной безопасности;
порядок контроля и приемки;
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы информационной безопасности в действие;
требования к документированию.
ЧТЗ должны включать все представленные в таблице 14 разделы, заполненные в соответствии с установленными в таблице 14 требованиями.
При необходимости должны быть даны ссылки на соответствующие разделы настоящих Технических требований.
Разрабатываемые ЧТЗ в совокупности с настоящими Техническими требованиями должны составлять полную систему требований к развитию Системы, всех видов ее обеспечения, а также требования к процессу ввода в действие.
Уточнения и дополнения требований, определенных в ЧТЗ, не должны расширять состав и объем работ, определенных настоящими Техническими требованиями.
При приемке (испытаниях) выполненных работ проводится проверка результатов на соответствие настоящим Техническим требованиям и ЧТЗ, а также на соответствие другим условиям Государственного контракта.
Структура и требования к содержанию ЧТЗ
№ Наименование раздела ЧТЗ Требования к заполнению разделов ЧТЗ
Термины и определения В разделе должны быть представлены все термины, определения и сокращения, не установленные правовыми актами или стандартами, но необходимые для однозначного понимания описанных в ЧТЗ требований.
Если термин имеет разные варианты интерпретации в правовых актах или стандартах, то в разделе приводится явное определение этого термина.
Описание процессов Исполнитель должен провести анализ всех административных, организационных, информационных, обслуживающих и иных процессов, процедур и действий, которые описаны непосредственно или в ссылочных документах, представленных в разделе 3.1 настоящих Технических требований. По результатам анализа Исполнитель должен включить в ЧТЗ описание всех действий (сгруппированных по процессам и процедурам), для всех вышеуказанных административных, организационных, информационных, обслуживающих и иных процессов, процедур и действий.
Описание для каждого действия должно включать следующую информацию:
действие пользователей Системы;
документ, регламентирующий действие;
пользователи Системы, осуществляющие указанное действие;
входные данные, используемые в указанном действии (указывается полный перечень и состав входных данных);
выходные данные (результат), возникающие в результате выполнения действия (указывается полный перечень и состав выходных данных);
ссылка на действие или действия (родительские действия), которые порождают описываемое действие.
Пользователи Системы По результатам анализа и подготовки описания процессов Исполнитель должен представить описание всех пользователей Системы, участвующих во всех процессах, процедурах и действиях, включенных в ЧТЗ.
Описание для каждого пользователя должно включать следующую информацию:
наименование пользователя;
численность пользователей данной группы;
территориальное расположение пользователей данной группы.
Функции Системы Исполнитель должен определить и полно описать в ЧТЗ функции, реализуемые в Системе и результаты их выполнения. Полнота описания функций Системы определяется по следующим критериям:
для каждого из процессов и процедур, предусмотренных описанием процессов, существует хотя бы одна функция Системы;
результаты выполнения любой функции должны приводить, либо к результату процесса или процедуры, либо к исходным данным, необходимым для выполнения другой функции Системы или передаваемых во внешнюю Систему в качестве исходных;
каждый набор исходных данных для выполнения функции является результатом выполнения какой-то другой функции, результатов ввода данных в систему пользователем или полученными от внешней системы исходными данными.
Функции могут быть сгруппированы в подсистемы Системы в случае, если они выполняются в рамках одной или связанных между собой процедур.
При описании процессов, процедур, структуры, организации данных и функций Системы должны приводиться модели, разработанные с применением любых средств проектирования и в любой нотации, определенной Исполнителем, но в рамках единой выбранной Исполнителем технологии моделирования.
Исполнитель приводит описание средств проектирования, принятой нотации и технологии моделирования в отчетной документации (документ «Пояснительная записка к техническому проекту»).
Требования к развертыванию тестового контура СПОТребования к разработке и описанию тестового контура СПО
Исполнитель должен разработать тестовый контур СПО в соответствии с требованиями Государственного контракта, представленными в таблице 15.
Требования к разработке тестового контура СПО
№ Вид требований Требования
Требования к функциям тестового контура СПО Исполнитель должен реализовать в тестовом контуре СПО - функции Системы, предусмотренные настоящим документом (Приложение Д). При этом Исполнитель может не реализовывать функции, непосредственно предназначенные для обслуживания Системы.
Требования к составу пользователей, имеющих возможность использовать тестовый контур СПО Исполнитель должен реализовать в тестовом контуре СПО функции для всех пользователей Системы, предусмотренные настоящим документом.
Требования к взаимодействию тестового контура СПО с внешними информационными системами Исполнитель должен реализовать в тестовом контуре СПО функции, необходимые для взаимодействия с внешними информационными система в соответствии с п. 3.5.2.
При этом реализация этих функций может быть проведена без непосредственного взаимодействия с внешними системами, за счет использования имитирующего программного обеспечения и данных, полно воспроизводящих требования к данным, получаемым или предоставляемым Системой.
Требования к программному обеспечению тестового контура СПО Должны быть реализованы требования, установленные в настоящих Технических требованиях к компонентам на уровне прикладной логики и уровне представления.
Требования к надежности и производительности тестового контура СПО Надежность и производительность тестового контура СПО должны быть достаточными для проведения демонстрации выполнения всех требований, предъявляемых к тестовому контуру СПО.
Дополнительные требования к тестовому контуру СПО Тестовый контур СПО должен обеспечивать выполнение следующих дополнительных требований, предусмотренных настоящим документом:
требования к организации взаимодействия между компонентами Системы;
требования к разработке моделей и алгоритмов;
требования к структуре и хранению данных в системе;
требования к организации ввода данных в систему.
Требования к информационному обеспечению тестового контура СПО Исполнителем должны быть выявлены и реализованы в тестовом контуре СПО все ключевые справочники и классификаторы, используемые в процессах, процедурах или отдельных действиях, осуществляемых пользователями с использованием Системы.
Данные, получаемые и передаваемые Системой в соответствии с требованиями настоящего документа, должны быть совместимы с информационным обеспечением (справочниками и классификаторами) внешних информационных систем.
Формы выходных документов и отчетов должны отвечать требованиям регламентирующих документов, указанных настоящем документе.
Исполнитель должен продемонстрировать работу тестового контура СПО на основании сценария испытаний тестового контура РСМЭВ МО, приведенного в Приложении Д.
Требования к реализации
Исполнитель должен разработать СПО в соответствии с требованиями Государственного контракта, ЧТЗ, разработанного в рамках работ по постановке задачи и требованиями, представленными в таблице 16.
Требования к разработке СПО
№ Вид требований Требования
Требования к функциям СПО Исполнитель должен реализовать в СПО функции Системы, предусмотренные в настоящих Технических требованиях.
Требования к составу пользователей, имеющих возможность использовать СПО Исполнитель должен реализовать в СПО функции для всех пользователей Системы, предусмотренных в настоящих Технических требованиях.
Требования к взаимодействию СПО с внешними информационными системами Исполнитель должен реализовать в СПО функции, необходимые для взаимодействия с внешними информационными системами, указанными в настоящих Технических требованиях.
Требования к программному обеспечению СПО Должны быть реализованы все требования, установленные в настоящих Технических требованиях к программному обеспечению.
Требования к СПО в части надежности и производительности СПО должно обеспечивать полное соответствие производительности и надежности Системы показателям, установленным в настоящих Технических требованиях.
Дополнительные требования к СПО СПО должно обеспечивать выполнение всех дополнительных требований, предусмотренных в настоящих Технических требованиях.
Требования к информационному обеспечению СПО Исполнителем должны быть выявлены и реализованы в СПО все справочники и классификаторы, используемые в процессах, процедурах или отдельных действиях, осуществляемых пользователями с использованием Системы.
Данные, получаемые и передаваемые Системой в соответствии с требованиями настоящих Технических требований, должны быть совместимы с информационным обеспечением (справочниками и классификаторами) внешних информационных систем.
Формы выходных документов и отчетов должны отвечать требованиям регламентирующих документов, указанных в настоящих Технических требованиях.
Требования к топологии СПО Исполнитель должен реализовать в СПО все компоненты, необходимые для обеспечения функционирования Системы с учетом особенностей территориального размещения компонентов Системы (связь с удаленными подразделениями Функциональных заказчиков, специальные требования к протоколам передачи данных и т.д.).
Исполнитель должен подготовить технический проект, включающий все разделы в соответствии с таблицей 17.
Требования к структуре и содержанию технического проекта
№ Раздел технического проекта Требования к содержанию раздела технического проекта
Описание функций СПО Должны быть описаны все функций, предусмотренные Техническим заданием и реализованные в СПО.
Пользователи Системы Должно быть представлено описание всех пользователей Системы и их групп, включая технологические и обслуживающие роли. Для технологических и обслуживающих ролей должны быть указаны требования к квалификации пользователей.
Функциональная структура Системы Приводится описание функциональной структуры Системы с указанием следующих сведений:
описание подсистем, входящей в состав Системы;
указание функций, реализуемых каждой подсистемой (включая взаимодействие с другими подсистемами и внешними системами);
существенные особенности подсистемы (специфические пользователи, важные компоненты подсистемы и т.д.).
Технические средства, используемые для функционирования Системы Приводится описание технических средств, фактически используемых для функционирования Системы на момент завершения этапа реализации.
Программные компоненты, используемые для Системы Приводится описание программных компонентов, фактически используемых для функционирования Системы на момент завершения этапа реализации.
Взаимодействие СПО с внешними информационными системами Приводится описание всех функций, необходимых для взаимодействия с внешними информационными системами и реализованных в СПО. Приводится описание способов взаимодействия с внешними системами.
Реализация требований к программному обеспечению Приводится описание способов и особенностей реализации всех требований, установленных в настоящих Технических требованиях.
Реализация дополнительных требований Приводится описание способов и особенностей реализации всех дополнительных требований, предусмотренных настоящими Техническими требованиями.
Информационное обеспечение Приводится описание всех справочников и классификаторов, используемых в процессах, процедурах или отдельных действиях, осуществляемых пользователями с использованием Системы. Описание должно включать сведения о виде, структуре и назначении справочника, состав полей, атрибутов и метаданных.
Топология Системы Приводится описание всех особенностей Системы, связанных с территориальным расположением компонентов Системы. Также приводится описание всех решений, необходимых для обеспечения пользовательских характеристик с учетом описанной топологии.
Требования к техно-рабочему проектуТребования к модели угроз и нарушителя информационной безопасности СистемыПри выполнении работ, предусмотренных настоящими Техническими требованиями, должно быть проведено обследование и определены угрозы безопасности публикуемой и обрабатываемой информации, оценены их вероятность (актуальность), возможные последствия их реализации.
Должна быть сформирована Модель угроз и нарушителя информационной безопасности Системы.
Модель угроз должна определять:
защищаемые объекты;
основные виды угроз безопасности информации, включая угрозы техногенного характера, стихийные бедствия и угрозы, реализуемые нарушителями;
критерии уязвимости Системы к деструктивным воздействиям;
классификацию типов возможных нарушителей информационной безопасности;
предположения об имеющейся у нарушителя информации;
основные каналы, цели и объекты атак;
предположения об имеющихся у нарушителя средствах;
перечень атак.
Модель угроз безопасности должна быть разработана на основе и с учетом требований следующих документов:
Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных»;
Постановление Правительства РФ от 01.11.2012 г. № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК от 14.02.2008 г. «О методике определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК от 15.02.2008 г. «О базовой модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных».
При разработке Модели должны учитываться требования и решения по обеспечению информационной безопасности, в том числе:
механизмы (способы) аутентификации пользователей;
защита идентификационной информации пользователей, хранимой и обрабатываемой Системой;
обеспечение и контроль прав доступа к защищенным ресурсам и информации;
минимизация прав доступа;
механизмы (способы) аутентификации;
механизмы (способы) аутентификации при взаимодействии с внешними системами;
обеспечение конфиденциальности и целостности передаваемой/принимаемой по каналам связи информации;
управление доступом к персональным данным;
резервирование, резервное копирование и восстановление данных;
антивирусная защита;
контроль целостности обрабатываемых и технологических данных Системы.
Требования к вводу Системы в действие
Работы по развертыванию и конфигурированию СистемыСистема должна быть развернута Исполнителем на оборудовании, предоставленном Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив ПО и обеспечена предварительная конфигурация Системы.
Дальнейшее конфигурирование должно быть выполнено Исполнителем (сервисным оператором) в соответствии с инструкцией по развертыванию системы, приведенной в руководстве Администратора.
В случае необходимости, Исполнителем должны быть установлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав Дистрибутива.
Исполнитель должен выполнить мероприятия для подготовки подключения Системы к СМЭВ в соответствии с регламентирующими документами в таблице 5 настоящих Технических требований.Требования к проведению мероприятий по подготовке пользователейПодготовка Пользователей проводится в форме консультационно-методических семинаров.
Исполнителю требуется провести консультирование ответственных лиц и технических специалистов Заказчика по вопросам внедрения и сопровождения Системы.
Перечень сотрудников в количестве не менее 10 человек, для участия в консультационно-методических семинарах предоставляется Заказчиком и направляется Исполнителю в письменной форме или по e-mail не позднее, чем за 10 (десять) рабочих дней до проведения семинара. Расписание семинаров разрабатывается Исполнителем и предоставляется Заказчику в срок не позднее 20 (двадцати) рабочих дней с даты начала этапа работ.
Количество консультационно-методических семинаров должно составлять не более 2-х семинаров в месяц на этапе подготовки пользователей Системы.
По завершении подготовки должны быть оформлены ведомости о проведенной консультации ответственных лиц и технических специалистов Заказчика.
Требования к сопровождению системы в период опытной эксплуатацииОпытная эксплуатация должна проводиться на технологической площадке Заказчика в соответствии с документом «Программа опытной эксплуатации».
При выполнении работ по сопровождению Исполнитель выполняет следующие обязательства (комплекс мероприятий):
консультирует сотрудников Заказчика;
устраняет обнаруженные в процессе эксплуатации дефекты в работе Системы;
принимает участие в восстановлении Системы после сбоев и аварий, вызванных дефектами и недокументированными возможностями Системы, выполняя при этом работы, связанные с восстановлением целостности данных, и обновление Системы;
вносит изменения в техническую и рабочую документацию на Систему на основании выявленных неточностей или обнаруженных недокументированных возможностей Системы;
осуществляет обновление СПО. Мероприятия по корректировке и обновлению СПО согласовываются с Заказчиком;
предоставляет организационное и методическое сопровождение и консультирование сотрудников Заказчика по вопросам функционирования СПО Системы;
предоставляет рекомендации по действиям, необходимым для штатного функционирования СПО Системы;
выдает необходимые рекомендации по настройке и конфигурированию СПО Системы.
Некорректное функционирование Системы не может быть признано дефектом Системы, если требования, предъявляемые к функциональным возможностям Системы, являются новыми по отношению к требованиям, зафиксированным в настоящих Технических требованиях и ЧТЗ.
Инцидент – это обращение и/или запрос Заказчика, в том числе созданный на основании запроса/обращения какой-либо ОГВ, ОМСУ в адрес Заказчика, об отклонении параметров работы Системы от штатного режима функционирования. Все инциденты (запросы/обращения) делятся по приоритетам. Любое обращение или запрос Заказчика, поданный в рамках Государственного контракта и в установленном порядке, является инцидентом и далее также по тексту именуется инцидентом.
Под приоритетом понимается ‒ установление важности и срочности выполняемых работ по инциденту, с учетом влияния, оказываемого на СПО Системы.
При выполнении работ выделяют три типа приоритетов для возникающих инцидентов:
1-й приоритет (критичный) – аварийная внештатная ситуация, связанная с полной потерей работоспособности СПО Системы или любой из основных функций СПО Системы;
2-й приоритет (высокий) – частичная потеря работоспособности СПО Системы или любой из основных функций СПО Системы, не приводящая к потере критичного (основного) функционала, возможны альтернативные варианты выполнения основных функций СПО Системы;
3-й приоритет (стандартный) – снижение производительности и прочие ситуации, не приводящие к потере основных функций СПО Системы.
Нормативное время работы с инцидентами приведено в таблице 18.
Нормативное время работы с инцидентами
Инцидент 1-го приоритета (критичный)
Режим работы с обращениями/запросами (инцидентами 1-го приоритета) Круглосуточно, включая выходные и праздничные дни
Время реакции Не более 1 часа с момента обращения/запроса. В данный период должен быть выделен ответственный сотрудник Исполнителя, который совместно с уполномоченным лицом Заказчика начнет анализ и локализацию инцидента, дефекта, выработку мер по устранению, а также впоследствии примет участие в подготовке аналитической справки о причинах и способах устранения инцидента.
Время восстановления (предоставление патча для устранения дефекта, временного обходного решения инцидента, предоставление консультаций по устранению инцидента) Не более 8 часов
Инцидент 2-го приоритета (высокий)
Режим работы с обращениями/запросами (инцидентами 2-го приоритета) В рабочие дни*, в рабочие часы (с 09-00 до 20-00 по московскому времени)
Время реакции Не более 6 рабочих часов
Время восстановления (предоставление патча для устранения дефекта предоставление консультаций по устранению инцидента, временного обходного решения инцидента) Не более 16 рабочих часов
Инцидент 3-го приоритета (стандартный)
Режим работы с обращениями/запросами (инцидентами 3-го приоритета) В рабочие дни, в рабочие часы (с 09-00 до 18-00 по московскому времени)
Время реакции Не более 16 рабочих часов
Время восстановления (предоставление патча для устранения дефекта, предоставление консультаций по устранению инцидента, временного обходного решения инцидента) Не более 40 рабочих часов
*Под рабочими днями понимаются будние дни с понедельника по пятницу (включительно), за исключением выходных праздничных дней, установленных действующим законодательством РФ.
Результаты проведения опытной эксплуатации должны отражаться в документе «Журнал опытной эксплуатации» (с указанием недостатков реализации Системы, рекомендаций и замечаний).
Условием завершения опытной эксплуатации является подписанный Заказчиком Акт о завершении опытной эксплуатации и готовности Системы к приемочным испытаниям.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫОбщие требования к приемке работ по этапамПриемка результатов работ осуществляется поэтапно в соответствии с календарным планом выполнения работ по Государственному контракту.
В течение 3 (трех) рабочих дней с даты заключения Государственного контракта Исполнитель должен предоставить Заказчику план-график выполнения работ с указанием сроков завершения работ.
Перед началом опытной эксплуатации Исполнитель передает Заказчику полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации. Указанные данные включаются в состав эксплуатационной документации.
Исполнитель передает техническую продукцию в составе определенном в разделе 7. Прием-передача научно-технической продукции должна быть оформлена в соответствии с Приложением Г.
При приемке научно-технической продукции Заказчиком в части документации на Систему производится проверка соответствия требованиям к документированию Системы в соответствии с п.6.5 и разделом 7.
Заказчик производит рассмотрение и утверждение документов в срок не более 7 (семи) рабочих дней с момента их получения.
Если в результате выполненных проверок установлены несоответствие требованиям к документации на Систему и\или неактуальность, противоречивость либо неполнота сведений, представленных в отчетных документах, Заказчик в порядке, определенном Государственным контрактом, возвращает Исполнителю указанную документацию на доработку с указанием причин отказа в приемке. В этом случае приемка работ откладывается в порядке, определенном Государственным контрактом, до момента полного устранения замечаний Заказчика по представленной отчетной документации.
В случае отсутствия замечаний Заказчика, предоставленных в срок не более 7 (семи) рабочих дней с момента получения документов, или получения подтверждения от Заказчика о согласовании документов, документы считаются утвержденными.
Приемка результатов выполнения работ оформляется Актом сдачи-приемки работ. Основанием для составления и подписания Акта сдачи-приемки работ является передача Исполнителем научно-технической продукции и наличие утвержденного Заказчиком Акта приема-передачи научно-технической продукции (Приложение Г1).
В случае отсутствия замечаний к представленной научно-технической продукции Заказчик в срок не более 2 (двух) рабочих дней с момента ее получения производит утверждение Акта сдачи-приемки научно-технической продукции.
Для контроля исполнения работ в рамках Государственного контракта Исполнитель не реже одного раза в неделю предоставляет Заказчику отчет о ходе выполнения работ, содержащий сведения:
о завершенных работах в течение отчетного периода;
о начатых в течение отчетного периода работах, завершение которых планируется в следующем периоде;
о работах, завершение которых планировалось в отчетном периоде, но по объективным причинам было перенесено на следующий период;
о работах, которые должны быть начаты в течение следующего периода;
о работах следующего периода, требующих участия Заказчика или предоставления сведений, материалов, оборудования, доступа к объектам и иное.
Исполнитель вправе изменять сроки в плане-графике выполнения работ в пределах сроков завершения этапов Государственного контракта.
При нарушении сроков исполнения этапа применяются соответствующие положения Государственного контракта.
Виды, состав, объем и методы испытаний СистемыИспытания должны быть организованы и проведены в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».
Предусмотрены следующие обязательные виды испытаний Системы:
Испытания тестового контура СПО;
Предварительные испытания;
Опытная эксплуатация;
Приемочные испытания.
Объем и методы испытаний определяются «Программой и методикой испытаний», соответсвующих работ по этапу.
Результаты испытаний отражают в протоколе испытаний соответствующих работ по этапу.
Протокол испытаний должен содержать заключение о возможности (невозможности) приемки Системы в эксплуатацию, а также перечень необходимых доработок (замечаний) и рекомендуемые сроки их устранения.
Решение о необходимости проведения дополнительных испытаний, состав и цели проведения дополнительных испытаний принимается в рамках опытной эксплуатации.
После завершения развертывания тестового контура СПО Исполнитель обязан провести для представителей Заказчика и привлеченных Заказчиком экспертов демонстрацию тестового контура СПО в соответствии с разработанной программой и методикой испытаний тестового контура СПО Системы. В случае выявления несоответствий требованиям к тестовому контуру СПО, Исполнитель обязан провести доработку и провести повторную демонстрацию.
Опытная эксплуатация проводится в соответствии с Программой опытной эксплуатации в течение 14 календарных дней. В опытной эксплуатации должны участвовать 10 центральных исполнительных органов государственной власти. Перечень центральных исполнительных органов государственной власти утверждается Заказчиком. В рамках опытной эксплуатации должны быть проверены все роли пользователей. Завершение опытной эксплуатации происходит после подписания Акта о завершении опытной эксплуатации и готовности системы к приемочным испытаниям.
При проведении перечисленных испытаний в части информационного взаимодействия Системы с внешними информационными системами проверяется наличие в Системе и соответствие установленным требованиям сервисов приема/передачи данных. Возможность проверки информационного взаимодействия обеспечивается в случае предоставления оператором внешней информационной системы данных, определенных в Регламенте информационного взаимодействия участников межведомственного взаимодействия в РСМЭВ МО. При отсутствии указанных данных, проверки в части информационного взаимодействия производятся на подготовленных Исполнителем тестовых (модельных) данных, состав и характеристики которых определяются в Программе и методике испытаний, соответсвующих работ по этапу в составе тестов (контрольных примеров).
Испытаниям предшествует экспертиза качества предъявленной документации. Решение о допуске Системы к предварительным испытаниям принимается Заказчиком по итогам экспертизы качества предъявленной документации. Возможен допуск Системы к испытаниям при наличии замечаний к качеству документации в случае, если эти замечания могут быть устранены в рамках актуализации документов по завершению опытной эксплуатации.
Допускается проведение предварительных испытаний на специальных испытательных стендах Исполнителя. В ходе предварительных испытаний определяется готовность Системы к запуску в опытную эксплуатацию.
Для проведения Испытаний должна быть организована испытательная комиссия в составе представителей Исполнителя, представителей Заказчика, представителей всех Функциональных заказчиков.
В ходе предварительных испытаний Системы члены испытательной комиссии должны удостовериться в соответствии предъявленных результатов работ требованиям ТТ и идентичности предъявленных решений их описанию в документации.
Для этого должны быть выполнены все или выборочные проверки функциональности, дана оценка предъявленным документам, дано заключение о возможности и готовности проведения опытной эксплуатации в соответствии с описанием порядка, приведенным в Программе опытной эксплуатации, а также подтверждена готовность предоставления в соответствии с планом-графиком выполнения работ оборудования, программного обеспечения, ресурсов, материалов и сведений, необходимых для ввода Системы в опытную эксплуатацию.В случае неготовности Системы к опытной эксплуатации в протоколе предварительных испытаний фиксируются замечания к реализации Системы, и назначается дата проведения повторных предварительных испытаний.
Число проводимых повторных предварительных испытаний не ограничено. При этом за нарушение сроков завершения этапов Государственного контракта Исполнитель несет ответственность согласно условиям Государственного контракта.
Опытная эксплуатация проводится только в производственной среде. Развертывание Системы и ее подготовку к опытной эксплуатации обеспечивает Исполнитель. Сопровождение Системы в период опытной эксплуатации обеспечивает Исполнитель.
В ходе опытной эксплуатации Исполнитель обеспечивает прием и регистрацию в журнале опытной эксплуатации замечаний пользователей к работе Системы, а также, фиксирует в журнале опытной эксплуатации факты проверки в реальных условиях функций Системы пользователями.
Замечания пользователей к работе системы должны классифицироваться по степени критичности для продолжения опытной эксплуатации и их влияния на возможность запуска Системы в промышленную эксплуатацию. Критичность замечаний устанавливается пользователем, заявившим о наличии замечания, но может быть изменена в процессе обработки по согласованию с Заказчиком.
Мероприятия по устранению замечаний пользователей к работе системы должны также фиксироваться в журнале опытной эксплуатации.
До устранения всех критичных замечаний пользователей, препятствующих запуску в промышленную эксплуатацию, Система находится в опытной эксплуатации.
Приемка Системы производится приемочной комиссией в составе представителей Исполнителя, представителей Заказчика, уполномоченных представителей всех пользователей, участвовавших в проведении опытной эксплуатации.
В рамках приемки Системы определяется готовность Системы к промышленной эксплуатации. Количество проводимых приемок не ограниченно. При этом за нарушение сроков завершения этапов Государственного контракта Исполнитель несет ответственность согласно условиям Государственного контракта. Приемка Системы завершается подписанием Акт о готовности Системы к промышленной эксплуатации.
Сведения о гарантийном обслуживании системыГарантийное обслуживание проводится в сроки, определенные Государственным контрактом.
Исполнитель должен гарантировать, что Система будет функционировать в соответствии со своим назначением не менее одного года. При этом возможны незначительные отклонения его технических и потребительских характеристик, а также отдельные ошибки, не создающие препятствий для получения положительных результатов от эксплуатации Системы.
Исполнитель не гарантирует отсутствие недостатков или сбоев в процессе работы, возникающих по причине несоответствия оборудования или установленного на рабочем месте программного обеспечения конечного пользователя требованиям, предъявляемым к характеристикам клиентских мест.
Под сроком предоставления гарантии качества товара, работ, услуг понимается период времени, начинающийся с момента завершения работ по Государственному контракту и подписания Акта сдачи-приемки работ, в течение которого Исполнитель обязуется в отношении Системы выполнять работы по устранению выявляемых технических ошибок (дефектов) в следующем объеме:
организация приема обращений по телефону, электронной почте о технических ошибках (дефектах) и нештатных ситуациях в установленное рабочее время;
поступившие обращения должны быть обработаны не позднее 3х рабочих дней с момента регистрации обращения;
анализ информации о технических ошибках (дефектах) в работе системы, выработка с ответственным сотрудником объекта автоматизации предложений по срокам и способам их преодоления;
внесение изменений в Систему в целях устранения выявленных технических ошибок (дефектов) и предоставление документированных обновлений Системы;
восстановление работоспособности Системы и баз данных при возникновении внештатных ситуаций, связанных с ошибками в ПО, с выездом специалистов Исполнителя на объект автоматизации.
Порядок выполнения доработок и устранения допущенных исполнителем ошибок, выявленных на стадии приемкиНедостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Исполнителем в рамках выполнения работ по Государственному контракту. Порядок устранения замечаний и реализации рекомендаций комиссии должен быть определен в документах «Программа и методика испытаний» и «Программа опытной эксплуатации». Сроки устранения замечаний и реализации рекомендаций, данных приемочной комиссией в ходе испытаний, определяются в Актах приемки в эксплуатацию.
Порядок проведения экспертизы документацииПри предъявлении результатов этапов Исполнитель должен учитывать срок экспертизы предъявляемых в качестве результата документов и возможной необходимости устранения замечаний к ним по итогам экспертизы. Предъявление документов и программного кода должно осуществляться в срок не менее чем за 5 (пять) рабочих дней до даты окончания этапа и не менее чем за 15 (пятнадцати) рабочих дней до завершения Государственного контракта.
Испытание документации заключается в оценке:
комплектности состава документации;
соответствия документации ЧТЗ;
полноты и ясности изложения организационных, технических и экономических аспектов описываемых явлений и процессов.
Проверка комплектности документов выполняется визуально путем сверки их состава с составом, определенным Государственным контрактом и Техническими требованиями.
Оценка целостности комплекта документов включает контроль взаимной непротиворечивости документов (отсутствия противоречий в описании функций в разных документах, противоречий в описании диагностических сообщений, отсутствие противоречий в описании действий пользователей и пр.), а также единства оформления комплекта документов.
Проверка содержания и оформления представленных технических документов выполняется визуально путем контроля соблюдения в документах требований нормативных документов:
к структуре и содержанию документов;
к построению, изложению и оформлению текстовых документов;
к используемой терминологии.
В том числе выполняется проверка соответствия содержания документов фактически представленным программным средствам.
В ходе проверки содержания и оформления эксплуатационных документов оценивается качество комплекта эксплуатационных документов с точки зрения их пригодности для использования персоналом при эксплуатации и сопровождении, включая подготовку персонала.
Каждый документ оценивается путем экспертных оценок по следующим направлениям:
соответствие требованиям, приведенным в разделе 7 настоящих Технических требований, к построению, изложению и оформлению документов;
уровень технического исполнения документа, единство форматирования документа;
соответствие содержания документа фактически представленным программным средствам, а также другим эксплуатационным документам;
соответствие структуры и содержания требованиям, приведенным в разделе 7 настоящих Технических требований;
полнота изложения (содержание разделов) с точки зрения пригодности документа для использования;
первичность информации в документе, отсутствие нелокализованных по документу фрагментов текстов других документов, отсутствие признаков плагиата, включая внутренний, наличие необходимых ссылок на авторство;
соответствие наименований и обозначений документов требованиям, приведенным в разделе 7 настоящих Технических требований.
Проверка считается выполненной успешно, если соблюдены все следующие условия:
установлено соответствие комплектности представленных документов;
для технических документов:
установлено соответствие структуры и содержания установленным требованиям;
не установлено нарушений построения, изложения и оформления текстовых документов;
не установлено нарушений использования терминологии.
установлена пригодность эксплуатационных документов для эксплуатации и сопровождения, включая подготовку персонала;
сделан итоговый вывод о целостности комплекта документов.
Протокол в разделе «Проверка отчетной документации» должен содержать позиции:
проверка комплектности представленных документов;
проверка содержания и оформления документов:
технических документов;
эксплуатационных документов;
оценка целостности комплекта документов.
По результатам проведения проверок соответствия документов требованиям к документации представитель Заказчика вносит запись в разделе «Проверка отчетной документации» Протокола о соответствии документов (не соответствии) требованиям.
При установлении несоответствия требованиям в соответствующей графе Протокола вносится запись об отмеченных нарушениях (замечание, документ к которому оно относится).
Замечания могут предъявляться в электронном виде, в форме примечаний к документу и должны содержать четкие указания о характере доработки, примеры которых сформулированы выше. Замечания предъявляются Заказчиком в рабочем порядке путем отправки на адрес электронной почты или передачей электронного носителя представителю Исполнителя. При этом предоставляет носитель и обеспечивает его доставку Исполнитель.
Изменения в документы должны вноситься в рабочем порядке в режиме правки с сохранением примечаний Заказчика.
Измененная версия документа должна быть повторно направлена на экспертизу.
ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮИсполнитель должен предоставить следующую техническую и рабочую документацию:
ЧТЗ на развитие Системы;
ЧТЗ на подсистему информационной безопасности;
модель угроз и нарушителя информационной безопасности Системы;
пояснительная записка к техническому проекту;
руководство администратора;
программа и методика испытаний тестового контура СПО;
программа и методика испытаний СПО Системы первой очереди;
программа и методика испытаний СПО Системы второй очереди;
Протокол приемочных испытаний СПО Системы первой очереди;
Протокол приемочных испытаний СПО Системы второй очереди;
программа и методика предварительных испытаний;
программа и методика приемочных испытаний;
программа опытной эксплуатации;
программа подготовки пользователей;
ведомость машинных носителей информации;
описание автоматизированных функций;
описание информационного обеспечения;
описание программного обеспечения.
Исполнитель должен предоставить следующую организационно-распорядительную документацию:
протокол испытаний тестового контура СПО;
протокол предварительных испытаний;
протокол приемочных испытаний;
акты сдачи приемки работ по этапам;
акт о передаче исходных кодов и дистрибутива тестового контура СПО Системы;
акт о передаче исходных кодов и дистрибутива СПО Системы первой очереди;
акт о передаче исходных кодов и дистрибутива СПО Системы второй очереди;
акт приемки в опытную эксплуатацию;
акт о готовности Системы к промышленной эксплуатации;
акт о завершении опытной эксплуатации и готовности Системы к приемочным испытаниям;
акт выполнения пуско-наладочных работ СПО Системы;
акт приема передачи научно-технической продукции;
ведомость подготовки пользователей;
отчет о проведении опытной эксплуатации (включая Журнал опытной эксплуатации);
отчет о ходе выполнения работ.
В части организационного обеспечения Исполнителем должны быть разработаны следующие проекты документов:
проект распорядительной документации Правительства Московской области о вводе Системы в промышленную эксплуатацию;
проект приказа о вводе в действие политики информационной безопасности в Системе;
проект регламента информационного взаимодействия участников межведомственного взаимодействия в РСМЭВ МО;
проект регламента эксплуатации Системы.
Регламент информационного взаимодействия участников межведомственного взаимодействия в РСМЭВ МО должен содержать:
условия и порядок взаимодействия Оператора РСМЭВ МО и Участника информационного взаимодействия при предоставлении государственных и муниципальных услуг в электронной форме с использованием РСМЭВ МО;
описание основных процедур, доступных Участнику информационного взаимодействия при работе с РСМЭВ МО, с указанием типовых форм заявлений и порядка обработки обращений.
Регламент эксплуатации системы должен содержать порядок:
обработки обращений пользователей;
консультирования пользователей;
восстановления после сбоев и аварий;
обновления системы и ее компонентов;
изменения настроек функционирования (в том числе перевод Системы в профилактический режим).
Документы на Систему оформляют в соответствии с требованиями ГОСТ 2.105 «Общие требования к текстовым документам» на листах формата А4, по ГОСТ 2.301 «Единая система конструкторской документации» без рамки, основной надписи и дополнительных граф к ней.
Документы не должны содержать в колонтитулах указаний на организацию Исполнителя (логотипы, реквизиты, контактную информацию и т.п.).
Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа.
Документы техно-рабочего проектирования должны соответствовать требованиям комплекса стандартов и руководящих документов на автоматизированные системы:
ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»– в части терминологии;
ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем» в части наименования и обозначения документов;
ГОСТ 34.603 -92 «Виды испытаний автоматизированных систем» – в части определения видов испытаний;
РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» – в части структуры и содержания документов.
Необходимая документация на уже созданную Систему предоставляется Заказчиком по запросу Исполнителя.
Полное соответствие документов на Систему требованиям РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы по всем позициям, определяемым РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» для отдельных документов.
Комплект эксплуатационной документации на Систему должен содержать сведения, достаточные для эксплуатации Системы в соответствии с требованиями нормативных правовых актов.
Комплект эксплуатационной документации на Систему в части ПО Системы должен содержать исчерпывающее описание СПО, обеспечивающее его установку, настройку, эксплуатацию, сопровождение, развитие в последующие периоды (технические требования (спецификации), инструкции по сопровождению, инструкции по вводу в действие (инсталляции) и т.д.):
инструкция по развертыванию СПО, включающая описание целевой архитектуры, необходимое ПО, порядок установки, описание действий;
инструкция по настройке Системы;
инструкция по настройке взаимодействия со смежными системами (где и как определяются и задаются адреса веб-сервисов внешних систем, по каким адресам опубликованы сервисы данной Системы, и т.д.);
логины и пароли ко всем элементам Системы, лицензии и ключи активации для ПО, необходимого для развертывания Системы.В части организации процесса учета и контроля над предоставлением доступа к Системе документ «Руководство администратора» по РД 50-34.698-90 должен, в том числе определять:
порядок процесса выдачи и оперативного отзыва параметров административного доступа к элементам системы (доступ к СУБД, к серверу приложений, доступ на сервер по RDP и т.п.);
порядок и формы учета фактов выдачи доступа: кому, на основании чего, на какой период, когда отозваны;
полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации.
При выполнении работ, предусмотренных настоящими Техническими требованиями, должно быть проведено обследование и определены угрозы безопасности публикуемой и обрабатываемой информации, оценены их вероятность (актуальность), возможные последствия их реализации.
Документ «Руководство администратора» по РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе Пользователя Системы, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. При этом в указанных документах должна быть отражена работа всех функций по подсистемам, определенным в технических требованиях. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в технических требованиях и другой документации на Систему.
Документ «Руководство администратора» должен соответствовать по составу и структуре разделов РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».
Документ «Пояснительная записка к техническому проекту» должен содержать развернутые описания конкретных решений с указанием их соответствия требованиям по разделам настоящих Технических требований. При этом должны быть явно указаны качественные и количественные характеристики и другие параметры решений.
ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙПеречень используемых в документе приложений:
Приложение А. Центральные исполнительные органы государственной власти, муниципальные районы и городские округа Московской области, предоставляющие государственные и муниципальные услуги.
Таблица А.1. Центральные исполнительные органы государственной власти Московской области.
Таблица А.2. Муниципальные районы и городские округа Московской области, предоставляющие муниципальные услуги.
Приложение Б. Перечень зарегистрированных электронных сервисов в РСМЭВ МО.
Таблица Б.1. Перечень запросов к сервисам ФОИВ
Таблица Б.2. Перечень запросов к сервисам РОИВ.
Таблица Б.3. Перечень запросов к сервисам РОИВ, доступных для РОИВ МО.
Таблица Б.4. Перечень сервисов для подачи заявлений с РПГУ.
Приложение В. Целевая функциональная схема развиваемой Системы.
Приложение Г. Форма акта приема-передачи научно-технической продукции и требования к документу ведомость машинных носителей информации.
Таблица Г.1.Типовая форма акта приема-передачи научно-технической продукции.
Таблица Г.2.Требования к документу ведомость машинных носителей информации.
Приложение Д. Сценарий испытаний тестового контура РСМЭВ МО.

ПРИЛОЖЕНИЕ АЦЕНТРАЛЬНЫЕ ИСПОЛНИТЕЛЬНЫЕ ОРГАНЫ ГОСУДАРСТВЕННОЙ ВЛАСТИ, МУНИЦИПАЛЬНЫЕ РАЙОНЫ И ГОРОДСКИЕ ОКРУГА МОСКОВСКОЙ ОБЛАСТИ, ПРЕДОСТАВЛЯЮЩИЕ ГОСУДАРСТВЕННЫЕ И МУНИЦИПАЛЬНЫЕ УСЛУГИ
Таблица А.1 - Центральные исполнительные органы государственной власти Московской области
№ Наименование исполнительных органов государственной власти
Главное архивное управление Московской области
Главное контрольное управление Московской области
Главное управление архитектуры и градостроительства Московской области
Главное управление ветеринарии Московской области
Главное управление государственного административно-технического надзора Московской области
Главное управление государственного строительного надзора Московской области
Главное управление государственной и муниципальной службы Московской области
Главное управление дорожного хозяйства Московской области
Главное управление записи актов гражданского состояния Московской области
Главное управление Московской области "Государственная жилищная инспекция Московской области"
Главное управление по информационной политике Московской области
Главное управление региональной безопасности Московской области
Главное управление социальных коммуникаций Московской области
Главное управление территориальной политики Московской области
Комитет лесного хозяйства Московской области
Комитет по конкурентной политике Московской области
Комитет по труду и занятости населения Московской области
Комитет по ценам и тарифам Московской области
Министерство государственного управления, информационных технологий и связи Московской области
Министерство жилищно-коммунального хозяйства Московской области
Министерство здравоохранения Московской области
Министерство имущественных отношений Московской области
Министерство инвестиций и инноваций Московской области
Министерство культуры Московской области
Министерство образования Московской области
Министерство потребительского рынка и услуг Московской области
Министерство сельского хозяйства и продовольствия Московской области
Министерство социальной защиты населения Московской области
Министерство строительного комплекса Московской области
Министерство транспорта Московской области
Министерство физической культуры, спорта и работы с молодежью Московской области
Министерство финансов Московской области
Министерство экологии и природопользования Московской области
Министерство экономики Московской области
Министерство энергетики Московской области
Таблица А.2 - Муниципальные районы и городские округа Московской области, предоставляющие муниципальные услуги
№ Наименование муниципального образования
1 Городской округ Балашиха Московской области
2 Городской округ Бронницы Московской области
3 Городской округ Власиха Московской области (закрытое административно-территориальное образование)
4 Городской округ Восход Московской области (закрытое административно-территориальное образование)
5 Городской округ Дзержинский Московской области
6 Городской округ Долгопрудный Московской области
7 Городской округ Домодедово Московской области
8 Городской округ Дубна Московской области
9 Городской округ Жуковский Московской области
10 Городской округ Звездный городок Московской области (закрытое административно-территориальное образование)
11 Городской округ Звенигород Московской области
12 Городской округ Ивантеевка Московской области
13 Городской округ Климовск Московской области
14 Городской округ Коломна Московской области
15 Городской округ Королев Московской области
16 Городской округ Котельники Московской области
17 Городской округ Красноармейск Московской области
18 Городской округ Краснознаменск Московской области (закрытое административно-территориальное образование)
19 Городской округ Лобня Московской области
20 Городской округ Лосино-Петровский Московской области
21 Городской округ Лыткарино Московской области
22 Городской округ Молодежный Московской области (закрытое административно-территориальное образование)
23 Городской округ Орехово-Зуево Московской области
24 Городской округ Подольск Московской области
25 Городской округ Протвино Московской области
26 Городской округ Пущино Московской области
27 Городской округ Реутов Московской области
28 Городской округ Рошаль Московской области
29 Городской округ Серпухов Московской области
30 Городской округ Фрязино Московской области
31 Городской округ Химки Московской области
32 Городской округ Черноголовка Московской области
33 Городской округ Электрогорск Московской области
34 Городской округ Электросталь Московской области
35 Волоколамский муниципальный район Московской области
36 Воскресенский муниципальный район Московской области
37 Дмитровский муниципальный район Московской области
38 Егорьевский муниципальный район Московской области
39 Железнодорожный Московской области
40 Зарайский муниципальный район Московской области
41 Истринский муниципальный район Московской области
42 Каширский муниципальный район Московской области
43 Клинский муниципальный район Московской области
44 Коломенский муниципальный район Московской области
45 Красногорский муниципальный район Московской области
46 Ленинский муниципальный район Московской области
47 Лотошинский муниципальный район Московской области
48 Луховицкий муниципальный район Московской области
49 Люберецкий муниципальный район Московской области
50 Можайский муниципальный район Московской области
51 Мытищинский муниципальный район Московской области
52 Наро-Фоминский муниципальный район Московской области
53 Ногинский муниципальный район Московской области
54 Одинцовский муниципальный район Московской области
55 Озерский муниципальный район Московской области
56 Орехово-Зуевский муниципальный район Московской области
57 Павлово-Посадский муниципальный район Московской области
58 Подольский муниципальный район Московской области
59 Пушкинский муниципальный район Московской области
60 Раменский муниципальный район Московской области
61 Рузский муниципальный район Московской области
62 Сергиево-Посадский муниципальный район Московской области
63 Серебряно-Прудский муниципальный район Московской области
64 Серпуховский муниципальный район Московской области
65 Солнечногорский муниципальный район Московской области
66 Ступинский муниципальный район Московской области
67 Талдомский муниципальный район Московской области
68 Чеховский муниципальный район Московской области
69 Шатурский муниципальный район Московской области
70 Шаховский муниципальный район Московской области
71 Щёлковский муниципальный район Московской области
ПРИЛОЖЕНИЕ Б
ПЕРЕЧЕНЬ ЗАРЕГИСТРИРОВАННЫХ ЭЛЕКТРОННЫХ СЕРВИСОВ В РСМЭВ МО
Таблица Б.1 Перечень запросов к сервисам ФОИВ
№ Владелец Наименование
1 ФНС России Запрос сведений из ЕГРЮЛ
2 ФНС России Запрос сведений из ЕГРИП
3 РосреестрЗапрос выписки из ЕГРП, содержащей общедоступные сведения о зарегистрированных правах на объект недвижимости
4 РосреестрЗапрос кадастровой выписки земельного участка
5 РосреестрВыписка из Единого государственного реестра прав на недвижимое имущество и сделок с ним о правах отдельного лица на имевшиеся (имеющиеся) у него объекты недвижимого имущества
6 ФСИН России Запрос сведений о нахождении гражданина в местах лишения свободы
7 РосреестрЗапрос кадастрового плана территории
8 РосреестрЗапрос кадастрового паспорта объекта недвижимости
9 РоскомнадзорПредоставление сведений из свидетельства СМИ
10 ФНС России Проверка ИНН ФЛ, проверка сведений об обособленных подразделениях юридического лица
11 ФНС России Запрос предоставления сведений из декларации о доходах физических лиц 3-НДФЛ
12 ФНС России Предоставлений сведений об идентификационном номере налогоплательщика, физического лица, на основании полных паспортных данных, по запросу органов исполнительной власти
13 ФНС России Сервис, принимающий сведения от лицензирующих органов о предоставлении лицензии, переоформлении документа, подтверждающего наличие лицензии, приостановлении, возобновлении или прекращении действия лицензии, аннулировании лицензии
14 ФНС России Предоставление сведений о наличии (отсутствии) задолженности по уплате налогов, сборов, пеней и штрафов за нарушение законодательства Российской Федерации о налогах и сборах, по запросу ОИВ
15 ФCC России Сведения об отсутствии регистрации родителей в ТО ФСС в качестве страхователей и о неполучении ими единовременного пособия при рождении ребенка и ежемесячного пособия по уходу за ребенком
16 МЧС России Электронный сервис «Акт о пожаре»
17 ФСС России Сведения о состоянии расчетов по страховым взносам, пеням и штрафам плательщика страховых взносов
18 РоспотребнадзорЗапрос на получение сведений из сан-эпид заключений о видах деятельности
19 ФМС России Сведения о действительности (недействительности) паспорта гражданина Российской Федерации
20 ФМС России Запрос паспортного досье гражданина Российской Федерации по установочным данным
21 ФМС России Получение адреса регистрации по месту жительства по ФИО и Паспортным данным гражданина Российской Федерации
22 ФМС России Получение адреса регистрации по месту пребывания по ФИО и Паспортным данным гражданина Российской Федерации
23 ФМС России Проверка регистрации иностранного гражданина или лиц без гражданства по месту жительства
24 ФМС России Проверка регистрации иностранного гражданина или лиц без гражданства по месту пребывания
25 ФМС России Проверка разрешения на временное проживание или вида на жительство иностранного гражданина
26 ФМС России Проверка разрешения на работу иностранному гражданину или лицу без гражданства
27 ФМС России Справка о получении компенсации вынужденным переселенцем
28 МВД России Сведения о наличии (отсутствии) судимости
29 МВД России Сведения о нахождении в розыске
30 МВД России Сведения о непогашенной или неснятой судимости
31 МВД России Сведения о получении пенсии на месяц установления доплаты и о прекращении выплаты или неполучении пенсии за выслугу лет
32 МВД России Сведения о назначенной пенсии
33 МВД России Сведения о получении пенсии на месяц установления доплаты
34 ФМБА Электронный сервис предоставления информации о санитарно-эпидемиологических заключениях
35 РоспотребнадзорПолучение сведений из санитарно-эпидемиологических заключений о соответствии (несоответствии) проектной документации требованиям государственных санитарно-эпидемиологических правил и нормативов (версия 2.4.4)
36 ПФР Сервис предоставления сведений о размере социальных выплат застрахованного лица из бюджетов всех уровней
37 ПФР Запрос СНИЛС версия 3.0
38 ПФР Запрос данных лицевого счета по СНИЛС
39 ФК Запрос на импорт начисления
40 ФК Запрос на экспорт всех квитанций ФЛ
41 ФК Запрос на экспорт всех квитанций ЮЛ
42 ФК Запрос на экспорт начислений и статусов их квитирования для ФЛ
43 ФК Запрос на экспорт начислений и статусов их квитирования для ЮЛ
44 ФК Запрос на экспорт платежей ФЛ
45 ФК Запрос на экспорт платежей ЮЛ
46 ФСКН Электронный сервис предоставления копии заключения органов по контролю за оборотом наркотических средств и психотропных веществ о соответствии установленным требованиям объектов и помещений, в которых осуществляется деятельность, связанная с оборотом наркотических средств и психотропных веществ, и (или) культивирование наркосодержащих растений, установленным требованиям к оснащению этих объектов и помещений инженерно – техническими средствами охраны47 ФСКН Электронный сервис предоставления копии заключения органов по контролю за оборотом наркотических средств и психотропных веществ об отсутствии у работников, которые в соответствии со своими служебными обязанностями должны иметь доступ к наркотическим средствам или психотропным веществам либо культивируемым наркосодержащим растениям, непогашенной или неснятой судимости за преступление средней тяжести, тяжкое, особо тяжкое преступление или преступление, связанное с незаконным оборотом наркотических средств, психотропных веществ, их прекурсоров либо с незаконным культивированием наркосодержащих растений, в том числе за преступление, совершенное за пределами Российской Федерации
48 ФСКН Электронный сервис предоставления сведений о размере выплат пенсионерам, состоящим на учете в отделе пенсионного обслуживания ФСКН
49 РосреестрВыписка из Единого государственного реестра прав на недвижимое имущество и сделок с ним о переходе прав на объект недвижимого имущества
50 РосреестрСправка о содержании правоустанавливающих документов
Таблица Б.2 Перечень запросов к сервисам РОИВ№ Владелец Наименование
1 Ответственное ведомство Московской области Сведения о неполучении ежемесячного пособия по уходу за ребенком в органах социальной защиты населения по месту жительства отца, матери ребенка (для одного из родителей в соответствующих случаях, а также для лиц, фактически осуществляющих уход за ребенком вместо матери (отца, обоих родителей) ребенка) в случае, если отец (мать, оба родителя) ребенка не работает (не служит) либо обучается по очной форме обучения в образовательных учреждениях начального профессионального, среднего профессионального и высшего профессионального образования и учреждениях послевузовского профессионального образования
2 Ответственное ведомство Московской области Сведения о нахождении гражданина на регистрационном учете в государственном учреждении службы занятости населения в целях поиска подходящей работы в качестве ищущего работу и признанного безработным, о назначенных безработному гражданину социальных выплатах, периодах участия в оплачиваемых общественных работах, переезде по направлению органов службы занятости в другую местность для трудоустройства
3 Ответственное ведомство Московской области Копия договора о предоставлении рыбопромыслового участка для осуществления рыболовства
4 Ответственное ведомство Московской области Сведения, содержащиеся в разрешении на ввод в эксплуатацию объекта капитального строительства
5 Ответственное ведомство Московской области Сведения, содержащиеся в договорах социального (коммерческого) найма жилого помещения
6 Ответственное ведомство Московской области Выписка из домовой книги
7 Ответственное ведомство Московской области Решение органа местного самоуправления о переводе жилого помещения в нежилое, нежилого помещения - в жилое
8 Ответственное ведомство Московской области Заключения о привлечении и об использовании иностранных работников
9 Ответственное ведомство Московской области Документ, подтверждающий принадлежность земельного участка к определенной категории земель
10 Ответственное ведомство Московской области Документ, подтверждающий установленное разрешенное использование земельного участка
11 Ответственное ведомство Московской области Заключение органа местного самоуправления поселения или городского округа, подтверждающее, что создаваемый или созданный объект недвижимого имущества расположен в пределах границ земельного участка, предназначенного для ведения личного подсобного хозяйства
12 Ответственное ведомство Московской области Сведения о согласовании маршрута движения транспортных средств, осуществляющих перевозку опасных грузов
13 Ответственное ведомство Московской области Сведения, содержащиеся в актах освидетельствования проведения основных работ по строительству объекта индивидуального жилищного строительства (монтаж фундамента, возведение стен и кровли) или проведения работ по реконструкции объекта индивидуального жилищного строительства, в результате которых общая площадь жилого помещения (жилых помещений) реконструируемого объекта увеличивается не менее чем на учетную норму площади жилого помещения, устанавливаемую в соответствии с жилищным законодательством Российской Федерации14 Ответственное ведомство Московской области Сведения, содержащиеся в разрешении на строительство
15 Ответственное ведомство Московской области Сведения о получении социальных выплат
16 Ответственное ведомство Московской области Согласование маршрута транспортного средства осуществляющего перевозки крупногабаритных и (или) тяжеловесных грузов
17 Ответственное ведомство Московской области Сведения о принадлежности имущества к государственной собственности субъекта Российской Федерации либо муниципальной собственности
18 Ответственное ведомство Московской области Сведения из реестра похозяйственных книг
Таблица Б.3 Перечень запросов к сервисам РОИВ доступных для РОИВ МО
№ Владелец Наименование
1 Ответственное ведомство Московской области Копия разрешения на строительство
2 Ответственное ведомство Московской области Градостроительный план земельного участка
3 Ответственное ведомство Московской области Проект планировки территории
4 Ответственное ведомство Московской области Сведения о разрешении на строительство
5 Ответственное ведомство Московской области Проект планировки и межевания территории
6 Ответственное ведомство Московской области Разрешение на отклонение от предельных параметров разрешенного строительства, реконструкции
7 Ответственное ведомство Московской области Запрос сведений о размере всех видов пособий, выплачиваемых органами местного самоуправления
8 Ответственное ведомство Московской области Градостроительная проработка, подготовленная в установленном порядке, в целях обоснования планируемого изменения категории земельного участка и последующего размещения объекта капитального строительства
9 Ответственное ведомство Московской области Заключение органа местного самоуправления о возможности перевода земельных участков из состава земель одной категории в другую
10 Ответственное ведомство Московской области Схема размещения земельного участка и/или объекта (объектов) строительства и реконструкции на топографической или картографической основе в масштабе 1:10000 или 1:2000
11 Ответственное ведомство Московской области Документ, подтверждающий несоответствие жилого помещения установленным санитарным и техническим правилам и нормам, иным требованиям законодательства
12 Ответственное ведомство Московской области Сведения из выписки из домовой книги
13 Ответственное ведомство Московской области Финансовый лицевой счет
14 Ответственное ведомство Московской области Выписка из карточки поквартирного учета
15 Ответственное ведомство Московской области Запрос сведений о размере всех видов пособий, выплачиваемых органами местного самоуправления
16 Ответственное ведомство Московской области Запрос заключения о признании жилого помещения непригодным для проживания
17 Ответственное ведомство Московской области Выписка из реестра муниципальной собственности
18 Ответственное ведомство Московской области Копия контракта конкурса или аукциона
19 Ответственное ведомство Московской области Постановление администрации городского округа о сносе или реконструкции здания
20 Ответственное ведомство Московской области Запрос разрешения на реконструкцию
21 Ответственное ведомство Московской области Градостроительный план земельного участка
22 Ответственное ведомство Московской области Постановление о разрешении на проектирование
23 Ответственное ведомство Московской области Запрос акта выбора земельного участка
24 Ответственное ведомство Московской области Запрос нормативного акта органа местного самоуправления
25 Ответственное ведомство Московской области Запрос подтверждения перечня потребителей теплоисточника и их тепловых нагрузок
26 Ответственное ведомство Московской области Запрос согласования строительства или реконструкции теплоисточника
27 Ответственное ведомство Московской области Пояснительная записка с обоснованием выбора вариантов размещения объекта (объектов) нового строительства и реконструкции зданий, сооружений и их комплексов на испрашиваемом земельном участке
28 Ответственное ведомство Московской области Архитектурно-планировочное задание, подготовленное органом местного самоуправления муниципального образования Московской области, на территории которого планируется строительство (реконструкция) объекта
29 Ответственное ведомство Московской области Согласованная схема расположения земельного участка на кадастровой карте территории
30 Ответственное ведомство Московской области Запрос сведений о регистрации гражданина в качестве безработного и о получении им пособия по безработице из комитета по труду и занятости населения Московской области
31 Ответственное ведомство Московской области Запрос сведений о регистрации гражданина в качестве безработного и о получении им пособия по безработице из комитета по труду и занятости населения Московской области
Таблица Б.4 Перечень сервисов для подачи заявлений с РПГУ
№ Владелец Наименование
1 Главное Управление ЗАГС Московской области Веб-сервис выбора органа ЗАГС, выбора времени и даты приёма в органе ЗАГС
2 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию расторжения брака
3 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию рождения
4 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию усыновления (удочерения)
5 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию перемены имени
6 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию смерти
8 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию установления отцовства
9 Главное Управление ЗАГС Московской области Веб-сервис оформления заявки на государственную регистрацию брака
10 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу по лицензированию медицинской деятельности медицинских организаций (за исключением медицинских организаций, подведомственных федеральным органам исполнительной власти, государственным академиям наук) (Предоставление лицензии на осуществление медицинской деятельности для индивидуальных предпринимателей)
11 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу по лицензированию медицинской деятельности медицинских организаций (за исключением медицинских организаций, подведомственных федеральным органам исполнительной власти, государственным академиям наук) (Предоставление лицензии на осуществление медицинской деятельности для юридических лиц)»
12 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу лицензирования образовательной деятельности (Переоформление лицензии, в случае необходимости дополнения лицензии сведениями о филиалах лицензиата, и (или) об адресах мест осуществления образовательной деятельности, и (или) об образовательных программах, изменения места нахождения лицензиата)
13 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу лицензирования образовательной деятельности (Переоформление лицензии в случае прекращения реализации образовательных программ, прекращения осуществления образовательной деятельности по адресу места ее осуществления)
14 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу лицензирования образовательной деятельности (Переоформление лицензии в случае изменения наименования образовательных программ, указанных в приложении к лицензии)
15 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу лицензирования образовательной деятельности (Переоформление лицензии в случае возникновения образовательного учреждения, научной организации или иной организации в результате реорганизации в форме слияния, в случае наличия лицензии у одного или нескольких реорганизованных юридических лиц, в случае реорганизации образовательного учреждения, научной организации или иной организации в форме присоединения к ним юридического лица в случае наличия лицензии у присоединенного юридического лица)
16 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу лицензирования образовательной деятельности (Переоформление лицензии в случае реорганизации лицензиата в форме преобразования, изменения наименования лицензиата (в том числе в случае создания образовательного учреждения путем изменения типа существующего государственного или муниципального образовательного учреждения, установления иного государственного статуса образовательного учреждения), изменения наименования места нахождения лицензиата, изменения наименования адреса места осуществления образовательной деятельности)
17 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу по лицензированию и государственной аккредитации образовательных учреждений в Московской области по всем реализуемым ими образовательным программам, за исключением образовательных учреждений, полномочия по лицензированию и аккредитации которых осуществляют федеральные органы государственной власти» посредством системы межведомственного электронного взаимодействия Московской области (Получение дубликата документа, подтверждающего наличие лицензии)
18 Министерство государственного управления, информационных технологий и связи Московской области Веб-сервис оформления заявки на государственную услугу по лицензированию и государственной аккредитации образовательных учреждений в Московской области по всем реализуемым ими образовательным программам, за исключением образовательных учреждений, полномочия по лицензированию и аккредитации которых осуществляют федеральные органы государственной власти» посредством системы межведомственного электронного взаимодействия Московской области (Получение дубликата документа, подтверждающего наличие лицензии)
20 Министерство внутренних дел Российской Федерации (МВД) Веб-сервис оформления заявки на государственную услугу по предоставлению сведений об административных правонарушениях в области дорожного движения
22 Министерство сельского хозяйства Российской Федерации (Минсельхоз России) Веб-сервис оформления заявки на государственную услугу по получению сведений о выполнении мероприятий, способствующих экономии затрат на подачу воды для орошения
23 Федеральная служба судебных приставов (ФССП) Веб-сервис Федеральной службы судебных приставов
24 Федеральная налоговая служба (ФНС) Веб-сервис, реализующий:
проверку сведений о руководителе юридического лица на основании ФИО, ОГРН и ЭП руководителя юридического лица;
предоставление сведений об ИНН физического лица на основании полных паспортных данных, по запросу органов исполнительной власти;
предоставление сведений о постановке на учет организации в налоговом органе по месту нахождения ее обособленного подразделения, содержащихся в ЕГРН, по запросу органов исполнительной власти
25 Федеральная миграционная служба (ФМС) Веб-сервис Федеральной миграционной службы

ПРИЛОЖЕНИЕ ВЦЕЛЕВАЯ ФУНКЦИОНАЛЬНАЯ СХЕМА СИСТЕМЫ

Рисунок В.1. Целевая функциональная схема Системы
ПРИЛОЖЕНИЕ ГФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ И ТРЕБОВАНИЯ К ДОКУМЕНТУ ВЕДОМОСТЬ МАШИННЫХ НОСИТЕЛЕЙ ИНФОРМАЦИИ
Г.1ТИПОВАЯ ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ
Документ «Акт приема-передачи технической продукции» должен быть оформлен в соответствии со следующим примером.
АКТ № __
приема-передачи
научно-технической продукции
по Государственному контракту № ______
от «__» ________ 201_ г.
«__» ________ 201_ г.
Мы, нижеподписавшиеся, представитель Заказчика в лице Министра государственного управления, информационных технологий и связи Московской области Шадаева Максута Игоревича, действующего на основании Положения о Министерстве государственного управления, информационных технологий и связи Московской области, и представитель Исполнителя в лице <_д_о_л_ж_н_о_с_т_ь_> <_о_р_г_а_н_и_з_а_ц_и_я_> <_Ф_а_м_и_л_и_я_ _И_м_я_ _О_т_ч_е_с_т_в_о_>, действующего на основании <_Д_о_к_у_м_е_н_т_>, составили настоящий акт о том, что в соответствии с Государственным контрактом от __.__.201_ г. № _________________ на выполнение ______________________ работ по теме: «Развитие региональной системы межведомственного электронного взаимодействия Московской области» (далее – Государственный контракт) Исполнитель передал, а Заказчик принял научно-техническую продукцию по <ссылка_на_пункт(ы)_Календарного_плана_выполнения_работ_или_Технического _Задания_с_указанием_номера_соответствующего_Приложения_к_Государственному_контракту>.
Переданная научно-техническая продукция полностью удовлетворяет условиям указанного Государственного контракта и оформлена в установленном порядке.
Научно-техническая продукция представлена на бумажном и электронном носителях (оптический диск – CD/DVD) в следующем составе:
Обозначение документа Наименование документа Кол-во листов Кол-во экз.
31415926.АС_ХХХХ.610.ВМ.04 Автоматизированная система «РСМЭВ МО»
Ввод в действие.
Ведомость машинных носителей информации 2
31415926.АС_ХХХХ.610.ПС.01.2 Автоматизированная система «РСМЭВ МО»
Ввод в действие.
Паспорт (проект) 2
31415926.АС_ХХХХ.610.90.04.01-М Автоматизированная система «РСМЭВ МО»
Техническая документация - 2 CD
31415926.АС_ХХХХ.610.12.04-М Автоматизированная система «РСМЭВ МО»
Программное обеспечение - 2 CD
СДАЛ
ИСПОЛНИТЕЛЬ ПРИНЯЛ
ГОСУДАРСТВЕННЫЙ ЗАКАЗЧИК
<_д_о_л_ж_н_о_с_т_ь_><_о_р_г_а_н_и_з_а_ц_и_я_> Министр
государственного управления, информационных технологий и связи Московской области
________________ И.О. Фамилия _______________ М.И. Шадаев
«__» ___________ 201_ г. «__» ___________ 201_ г.
Г.2ТРЕБОВАНИЯ К ДОКУМЕНТУ ВЕДОМОСТЬ МАШИННЫХ НОСИТЕЛЕЙ ИНФОРМАЦИИ
Содержательная часть документа «Ведомость машинных носителей информации» должна быть оформлена в соответствии со следующим примером.
№ п/п № CD Обозначение Наименование Имя файла Объем, байт
1 31415926.АС_ХХХХ.604.01-М Автоматизированная система РСМЭВ МО
Техно-рабочий проект. - -
1 31415926.АС_ХХХХ.604.ПД.01.2-М Автоматизированная система «РСМЭВ МО»
Техно-рабочий проект.
Общее описание системы 31415926.АС_ХХХХ.604.ПД.01.2.doc 991 232
1 31415926 АС_ХХХХ.605.П6.01-М Автоматизированная система «РСМЭВ МО»
Техно-рабочий проект.
Описание организации информационной базы 31415926.АС_ХХХХ.604.П6.01.doc 790 528
… … … … … …
1 31415926.АС_ХХХХ.604.ПМ.06-М Автоматизированная система «РСМЭВ МО»
Ввод в действие.
Программа и методика приемочных испытаний. 31415926.АС_ХХХХ.604.ПМ.06.doc 598 016
2 31415926.АС_ХХХХ.610.12.04-М Автоматизированная система «РСМЭВ МО»
Техно-рабочий проект. - -
2 СПО-М Специальное программное обеспечение Автоматизированной системы «РСМЭВ МО» СПО АС_ХХХХ.rar1 084 081 005
ПРИЛОЖЕНИЕ
СОСТАВ СПЕЦИАЛЬНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РСМЭВ МО»
Таблица 1
№ п/п Имя файла/каталога Объем, байт
REESTRSPECS
Global.asax99
Web.config7520
\bin Castle.ActiveRecord.dll 192512
Castle.ActiveRecord.pdb 710144
Castle.Components.Validator.pdb 210432
… … … … … … …
NSI.Web.dll 2235904
\deployCastle.DynamicProxy2DynProxy.snk 596
\Castle.Components.ValidatorMessages.resources2419
\NHibernateNamespaceSummary.xml 3390
nhibernate-configuration.xsd 8219
nhibernate-mapping.xsd 66026
\NSI.Web\Scriptscapicom.vbs 15062
\Files ПРИЛОЖЕНИЕ ДСЦЕНАРИЙ ИСПЫТАНИЙ ТЕСТОВОГО КОНТУРА РЕГИОНАЛЬНОЙ СИСТЕМЫ МЕЖВЕДОМСТВЕННОГО ЭЛЕКТРОННОГО ВЗАИМОДЕЙСТВИЯ МОСКОВСКОЙ ОБЛАСТИСПИСОК СОКРАЩЕНИЙ
Таблица SEQ Таблица \* ARABIC 1. Таблица сокращений
Сокращение Описание
API Application Programming Interface (Интерфейс программирования приложений)
SID Идентификатор электронного сервиса
SoapUIПриложение для тестирования, мониторинга, проверки функциональности и эмуляции веб-сервисов
WSDL Web Services Description Language (Язык описания веб-сервисов и доступа к ним, основанный на языке XML)
XML EXtensible Markup Language (Расширяемый язык разметки, с простым формальным синтаксисом, удобный для создания и обработки документов программами и одновременно удобный для чтения и создания документов человеком)
XSD XML Schema Definition (Язык описания структуры XML документа)
БД База данных
ГМУ Государственные и муниципальные услуги
ИБ Информационная безопасность
ИС Информационная система
МО Московская область
МР Методические рекомендации по разработке электронных сервисов и применению технологий электронной подписи при межведомственном электронном взаимодействии (версии 2.4.5, 2.5.6), утвержденные Протоколом заседания Правкомиссии по использованию информационных технологий при предоставлении ГМУ Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления от 20.04.2012 г. №11
НСД Несанкционированный доступ
ОВД Органы внутренних дел
ОГВ Органы государственной власти
ОМСУ Орган местного самоуправления
ПО Программное обеспечение
ПИБ Подсистема информационной безопасности
ППУ Портал поставщиков услуг
ПТР Программно-техническое решение
РПГУ Региональный портал государственных и муниципальных услуг (функций)
РС Реестр Сервисов
РСМЭВ МО Региональная система межведомственного электронного взаимодействия Московской области
СМЭВ Система межведомственного электронного взаимодействия
СПО Специальное программное обеспечение, программа для ЭВМ, разрабатываемая в рамках модернизации Системы
СУБД Система управления базами данных
ТТТехнические требования
УЦ Удостоверяющий центр
ФЛ Физические лица
ФЛК Форматно-логический контроль
ФОИВ Федеральный орган исполнительной власти
ФСТЭК Федеральная служба по техническому и экспортному контролю Российской Федерации
ЭП Электронная подпись
ЭП-ОВ Электронная подпись, формируемая от имени органа государственной власти, участвующего в межведомственном взаимодействии при оказании государственных услуг
ЭП-СП Электронная подпись, формируемая от имени должностного лица органа власти, участвующего в межведомственном взаимодействии при оказании государственных услуг
ЮЛ Юридические лица
ОБЪЕКТ ИСПЫТАНИЙПолное наименование системы: Региональная система межведомственного электронного взаимодействия Московской области.
Краткое наименование системы: РСМЭВ МО, Система.
Для проведения испытаний предъявляются:
Дистрибутив тестового контура СПО Системы.
Сценарий испытаний тестового контура СПО Системы;
ЦЕЛЬ ИСПЫТАНИЙЦелью испытаний тестового контура СПО Системы является проверка и оценка соответствия программного обеспечения техническим требованиям, предъявляемым к Системе.
В ходе испытаний осуществляется проверка функциональности тестового контура СПО Системы.
ОБЪЕМ ИСПЫТАНИЙПроверка выбранных технологий на соответствие техническим требованиям
Проверка применяемых технологий в рамках разработки модулей Системы проводится в соответствии с настоящими Техническими требованиями.
Перечень этапов испытанийПредполагается оценка соответствия функциональных возможностей, описанных в Технических требованиях и функциональных возможностей, реализованных в тестовом контуре СПО Системы.
Таблица SEQ Таблица \* ARABIC 2. Проверка состава и содержания проведенных работ по разворачиванию и настройке тестового контура СПО Системы
Обеспечение работоспособности подсистемы распределения задач
Обеспечение возможности предоставления внешним ИС WSDL и XSD описаний электронного сервиса Демонстрируется по методике проверки
Обеспечение возможности оповещения ИС участника информационного взаимодействия о статусе доставки сообщения Демонстрируется по методике проверки
Обеспечение синхронного взаимодействия Демонстрируется по методике проверки
Обеспечение асинхронного взаимодействия Демонстрируется по методике проверки
Обеспечение работоспособности подсистемы «Реестр электронных сервисов»
Осуществление возможности получения основной информации, содержащейся в форме паспорта электронного сервиса (детальная информация по характеристикам, возможным операциям и реестру прав доступа) Демонстрируется по методике проверки
Осуществление возможности регистрации нового сервиса Демонстрируется по методике проверки
Осуществление возможности изменения атрибутов зарегистрированных сервисов Демонстрируется по методике проверки
Осуществление возможности редактирование сведений в матрице доступа Демонстрируется по методике проверки
Осуществление возможности получения руководства пользователя по сервису Демонстрируется по методике проверки
Осуществление возможности получения контрольных примеров в соответствии с операциями (методами) электронного сервиса Демонстрируется по методике проверки
Осуществление возможности получения основной информации по электронным сервисам (владелец, идентификатор, наименование электронного сервиса, назначение, режим доступности, режим работы, область применения) Демонстрируется по методике проверки
Осуществление возможности поиска/фильтрации зарегистрированных электронных сервисов по ключевым словам и категориям Демонстрируется по методике проверки
Обеспечение прочих функций и требований
Обеспечение работоспособности подсистемы протоколирования Демонстрируется по методике проверки
Осуществление возможности получение статистики межведомственного взаимодействия в различных разрезах Демонстрируется по методике проверки
Последовательность проведения и режим испытанийПоследовательность проведения испытаний:
Подготовка тестового контура для проведения испытаний;
Установка и настройка ПО;
Запуск тестового контура СПО Системы;
Проведение испытаний по разработанной методике.
Для проведения испытаний в Системе определены роли пользователей, приведенные ниже в таблице
Таблица SEQ Таблица \* ARABIC 3. Описание ролей пользователей Системы
№ п/п Наименование роли Функции
Администратор РСМЭВ МО Пользователь, обладающий правами по настройке Системы.
УСЛОВИЯ И ПОРЯДОК ПРОВЕДЕНИЯ ИСПЫТАНИЙТребования к составу технических средствТехнические средства, привлекаемые к тестированию, должны удовлетворять требованиям, предъявляемым к аппаратуре и дополнительному программному обеспечению для функционирования Системы. При этом минимальными для проведения испытаний являются требования, предъявляемые к наиболее ресурсоемкому приложению, используемому на данном рабочем месте.
Требования к персоналу, проводящему испытание, порядок допуска к испытаниямСпециалисты, проводящие испытания, должны обладать следующими навыками:
установка программного обеспечения из дистрибутивов и настройка программного обеспечения в соответствии с инструкциями по установке и настройке;
администрирование операционных систем и прикладного программного обеспечения;
работа с утилитой SoapUI;
работа с прикладным программным обеспечением, функционирующим в среде Windows или Linux;
работа в интернет-браузере.
МЕТОДИКА ПРОВЕРКИ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ТЕСТОВОГО КОНТУРА СПО СИСТЕМЫОбеспечение работоспособности подсистемы распределения задач РСМЭВ МООбеспечение возможности предоставления внешним ИС WSDL и XSD описаний электронного сервисаТаблица SEQ Таблица \* ARABIC 4. Предоставление внешним ИС WSDL и XSD описаний электронного сервиса
Исходное состояние: установлен браузер
Шаг Ожидаемый результат Реальный результат и дефекты
Пользователь в адресной строке браузера указывает адрес зарегистрированного в РСМЭВ МО сервиса. В окне браузера отображается WSDL описание сервиса. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Обеспечение возможности оповещения ИС участника информационного взаимодействия о статусе доставки сообщенияТаблица SEQ Таблица \* ARABIC 5. Оповещение ИС участника информационного
взаимодействия о статусе доставки сообщения
Исходное состояние: установлено программное обеспечение для тестирования SOAP запросов (SOAP UI)
Шаг Ожидаемый результат Реальный результат и дефекты
Вызвать сервис, зарегистрированный в РСМЭВ МО, передав SOAP-сообщение, соответствующее актуальной версии Методических рекомендаций по разработке электронных сервисов и применению технологии электронной подписи. В РСМЭВ МО настроенные проверки входящего сообщения пройдены успешно и в ответе от сервиса содержится корректное сообщение-квиток с уведомлением, что запрос получен РСМЭВ МО. Сообщение подписано электронной подписью от лица Администратора РСМЭВ МО. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Обеспечение синхронного взаимодействияТаблица 6. Обеспечение синхронного взаимодействия
Исходное состояние: установлено программное обеспечение для тестирования SOAP запросов (SOAP UI), в РСМЭВ МО проксирован сервис ФОИВ, предварительно зарегистрированный в СМЭВ.
Шаг Ожидаемый результат Реальный результат и дефекты
Вызвать сервис, зарегистрированный в РСМЭВ МО, работающий в синхронном режиме, передав SOAP-сообщение, соответствующее контрольному примеру для данного сервиса, взятого с Технологического портала СМЭВ. В РСМЭВ МО в ответе от сервиса содержится сообщение с данными по запросу, не содержащее ошибок, соответствующее контрольному примеру для данного сервиса, взятого с Технологического портала СМЭВ. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Обеспечение асинхронного взаимодействияТаблица 7. Обеспечение асинхронного взаимодействия
Исходное состояние: установлено программное обеспечение для тестирования SOAP запросов (SOAP UI), в РСМЭВ МО проксирован сервис ФОИВ, предварительно зарегистрированный в СМЭВ.
Шаг Ожидаемый результат Реальный результат и дефекты
Вызвать сервис, зарегистрированный в РСМЭВ МО, работающий в асинхронном режиме, передав SOAP-сообщение, соответствующее контрольному примеру для данного сервиса, взятого с Технологического портала СМЭВ. В РСМЭВ МО в ответе от сервиса содержится корректное сообщение-квиток с уведомлением, что запрос получен ФОИВ. Сообщение подписано электронной подписью ФОИВ. Формат сообщения квитка соответствует контрольному примеру для данного сервиса, взятого с Технологического портала СМЭВ. Вызвать сервис статусов обработки сообщений передав SOAP-сообщение, содержащее полученный на предыдущем шаге квиток. В ответе от сервиса ФОИВ содержится статус обработки запроса, соответствующий контрольному примеру для сервиса, взятого с Технологического портала СМЭВ. Повторно вызвать сервис статусов обработки сообщений передав SOAP-сообщение, содержащее полученный на первом шаге квиток. В ответе от сервиса содержит-ся сообщение с результатом обработки запроса, не содержащее ошибок. Ответ соответствует контрольному примеру для сервиса, взятого с Технологического портала СМЭВ. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Обеспечение работоспособности реестра электронных сервисовОсуществление возможности получения основной информации по электронным сервисам (владелец, идентификатор, наименование электронного сервиса, назначение, режим доступности, режим работы, область применения)Таблица SEQ Таблица \* ARABIC 6. Получение основной информации по электронным сервисам
Описание:
Исходное состояние: открыт реестр электронных сервисов
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса, содержащий информацию по электронному сервису (владелец, идентификатор, наименование электронного сервиса, назначение, режим доступности, режим работы, область применения) Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности регистрации нового сервисаТаблица SEQ Таблица \* ARABIC 7. Регистрация нового сервиса
Описание:
Исходное состояние: запущен АРМ Администратора
Шаг Ожидаемый результат Реальный результат и дефекты
Открыть вкладку управления реестром сервисов
Нажать кнопку добавления нового сервиса Открыта страница для заполнения данных по сервису Заполнить основные поля ввода информации о сервисе. Загрузить руководство пользователя. Сохранить изменения Открыта таблица зарегистрированных сервисов. Добавленный сервис отображается в списке. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности изменения атрибутов зарегистрированных сервисовТаблица SEQ Таблица \* ARABIC 8. Изменение атрибутов зарегистрированных сервисов
Описание:
Исходное состояние: запущен АРМ Администратора
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис, нажать кнопку редактирования. Отображается страница редактирования данных выбранного сервиса. Изменить введенные ранее данные. Сохранить изменения. Отредактированный сервис отображается в списке. Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса с последними изменениями. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности редактирование сведений в матрице доступаТаблица SEQ Таблица \* ARABIC 9. Редактирование сведений в матрице доступа
Описание:
Исходное состояние: запущен АРМ Администратора
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис, нажать на кнопку редактирования. Отображается страница редактирования данных выбранного сервиса. Заполнить данные в разделе управления доступом к сервису. Сохранить изменения. Отредактированный сервис отображается в списке. Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса с последними изменениями прав доступа. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности получения руководства пользователя по сервисуТаблица SEQ Таблица \* ARABIC 10. Получение руководства пользователя
Описание:
Исходное состояние: открыт реестр электронных сервисов
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса. Нажать на ссылку для сохранения Руководства пользователя. На компьютере пользователя сохранен документ «Руководство пользователя». Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности получения контрольных примеров в соответствии с операциями (методами) электронного сервисаТаблица SEQ Таблица \* ARABIC 11. Получение контрольных примеров
Описание:
Исходное состояние: открыт реестр электронных сервисов
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса. Нажать на ссылку для сохранения контрольных примеров. На компьютер пользователя сохранен архив, содержащий контрольные примеры сервиса. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности получения основной информации, содержащейся в форме паспорта электронного сервиса (детальная информация по характеристикам, возможным операциям и реестру прав доступа)Таблица SEQ Таблица \* ARABIC 12. Получение основной информации, содержащейся
в форме паспорта электронного сервиса
Описание:
Исходное состояние: открыт реестр электронных сервисов
Шаг Ожидаемый результат Реальный результат и дефекты
Выбрать из списка зарегистрированный сервис. Отображается паспорт сервиса, содержащий информацию по электронному сервису. В паспорте сервиса перейти в раздел управления правами доступа. Отображается информация об операциях электронного сервиса и перечень ИС, имеющих к ним доступ. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности поиска/фильтрации зарегистрированных электронных сервисов по ключевым словам и категориямТаблица SEQ Таблица \* ARABIC 13. Поиск/фильтрация зарегистрированных электронных сервисов
Описание:
Исходное состояние: открыт реестр электронных сервисов
Шаг Ожидаемый результат Реальный результат и дефекты
В таблице, содержащей информацию о зарегистрированных сервисах нажать на название колонки. Список сервисов будет отсортирован по значению выбранной колонки. В окне поиска ввести ключевое слово (слова). В списке отображены сервисы, содержащие в своих атрибутах указанные ключевые слова Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Обеспечение прочих функций и требованийОбеспечение работоспособности подсистемы протоколированияТаблица SEQ Таблица \* ARABIC 14. Работоспособность подсистемы протоколирования
Описание:
Исходное состояние: запущен АРМ Администратора
Шаг Ожидаемый результат Реальный результат и дефекты
Перейти на вкладку протоколирования. На странице протоколирования отображаются таблицы, показывающие количество входящих/исходящих сообщений и загрузку памяти операционной системы, на которой установлен РСМЭВ МО. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): Осуществление возможности получение статистики межведомственного взаимодействия в различных разрезахТаблица SEQ Таблица \* ARABIC 15. Получение статистики межведомственного взаимодействия
Описание:
Исходное состояние: запущен портал подсистемы «Реестр сервисов»
Шаг Ожидаемый результат Реальный результат и дефекты
Перейти на вкладку статистики. На странице отображаются данные по количеству запросов поставщиков и потребителей сервисов. Статус проверки сценария: Дата выполнения:
Выполнил (ФИО): РЕЗУЛЬТАТ ИСПЫТАНИЙ ТЕСТОВОГО КОНТУРА СПО СИСТЕМЫРезультатом проведения испытаний тестового контура Системы является Протокол испытаний тестового контура СПО Системы.

Приложенные файлы

  • docx 7033402
    Размер файла: 681 kB Загрузок: 0

Добавить комментарий