dedoc/tz_dataset huggingface dataset:
государственных функций исполнительными органами государственной
власти субъектов Российской Федерации, а также предоставления
муниципальных услуг и исполнения муниципальных функций органами
местного самоуправления;
- отдельные информационные системы иных органов и организаций,
участвующих в предоставлении государственных и муниципальных услуг и
исполнении государственных и муниципальных функций на основе
договорённости указанных органов или организаций и оператора системы
Пользователями СМЭВ являются:
1) оператор СМЭВ;
2) ответственные специалисты участников информационного
взаимодействия, в том числе:
а. региональные администраторы;
б. разработчики ИС участников взаимодействия.
3.3 Текущее состояние объекта автоматизации
В ходе выполнения работ по разработке и развитию СМЭВ в период
2010 - 2014 годах реализованы и доработаны подсистемы, приведённые в
таблице 2:
Таблица 2 – Подсистемы СМЭВ
4 ТРЕБОВАНИЯ К СИСТЕМЕ
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные
характеристики
Требования к разработке новых и доработке существующих подсистем
СМЭВ приведены в таблице 3:
Таблица 3 – Требования к доработке подсистем СМЭВ
4.1.1.2 Требования к способам и средствам связи для
информационного обмена между компонентами системы
Дополнительные требования к способам и средствам связи для
информационного обмена между компонентами системы при развитии
системы не предъявляются.
4.1.1.3 Требования к характеристикам взаимосвязей со смежными
системами
Дополнительные требования к характеристикам взаимосвязей со
смежными системами не предъявляются.
4.1.1.4 Требования к режимам функционирования системы
Создаваемые и дорабатываемые в рамках Технического задания
подсистемы СМЭВ должны иметь возможность функционировать в
следующих режимах:
штатный режим;
режим системного администрирования.
Штатный режим должен являться основным режимом
функционирования, обеспечивающим выполнение задач Системы.
Режим системного администрирования должен являться
технологическим режимом и использоваться для сопровождения Системы.
4.1.1.5 Требования по диагностированию системы
Дополнительные требования по диагностированию системы при
развитии системы не предъявляются.
4.1.1.6 Перспективы развития, модернизации системы
Дополнительные требования по перспективам развития и модернизации
4.1.2 Требования к численности и квалификации персонала
системы
Дополнительные требования по численности, квалификации и режиму
работы персонала системы не предъявляются.
4.1.3 Показатели назначения
Доработанные и разработанные подсистемы должны обеспечивать
следующие показатели назначения:
1) время на полный запуск (или перезапуск) системы и
компонентов системы должно составлять не более 15 минут;
2) REST API подсистемы администрирования СМЭВ: 50 запросов
в минуту при времени отклика не более трёх секунд;
3) режим отправки/приемки сообщений клиента СМЭВ на основе
разработанного SDK с интенсивностью не менее 100 запросов в
секунду при среднем размере конверта 300 Кб.
Требования к аппаратной части и масштабированию для обеспечения
перечисленных показателей должны быть определены на этапе технического
проектирования.
4.1.4 Требования к надёжности
Все компоненты системы должны иметь возможность резервирования,
что повысит надёжность и позволит сохранять работоспособность системы и
целостность данных при частичном выходе из строя программно-аппаратных
средств.
Для разрабатываемых и дорабатываемых подсистем в рамках
обеспечения работы по МР3.x устанавливаются следующие количественные
значения показателей надёжности:
- режим работы в целом – 7 дней в неделю 24 часа в сутки;
- общее допустимое времени простоя в неделю не должно превышать 30
минут, включая проведение сервисных и регламентных работ при строгом
соблюдении регламентных процедур.
Детальные требования к надёжности системы должны быть определены
на этапе разработки ЧТЗ.
4.1.5 Требования к безопасности
Дополнительные требования к безопасности СМЭВ не предъявляются.
4.1.6 Требования к эргономике и технической эстетике
Пользовательские интерфейсы для следующих подсистем должны быть
выполнены в виде веб-интерфейсов:
подсистема администрирования, включая Журнал СМЭВ.
Доработанные веб-интерфейсы должны быть адаптированы под
минимальную ширину 1280 пикселя.
Переходы пользователя между всеми веб-страницами пользовательского
интерфейса должны осуществляться через систему навигации, включающую
гиперссылки и другие элементы перехода между страницами.
Доработанные веб-интерфейсы перечисленных выше подсистем должны
корректно работать и отображаться на следующих браузерах:
- Microsoft Internet Explorer версии 10 и выше;
- Mozilla Firefox версии 27 и выше;
- Google Chrome версии 28 и выше.
4.1.7 Требования к эксплуатации, техническому обслуживанию,
ремонту и хранению компонентов системы
Дополнительные требования к эксплуатации, техническому
обслуживанию, ремонту и хранению компонентов системы СМЭВ не
предъявляются.
4.1.8 Требования к защите информации от несанкционированного
доступа
Дополнительные требования к защите информации от
несанкционированного доступа не предъявляются.
4.1.9 Требования по сохранности информации при авариях
Доработанная СМЭВ должна обеспечивать возможность сохранения
информации в случае возникновения следующих аварийных ситуаций:
- при частичном разрушении данных,
- при частичных механических и электронных сбоях и отказах в работе
компьютеров
за счет резервирования компонентов системы.
Доработанная СМЭВ должна автоматически восстанавливаться в
рабочее состояние при перезапуске аппаратных средств.
4.1.10 Требования к защите от влияния внешних воздействий
Дополнительные требования к защите от влияния внешних воздействий
при развитии системы не предъявляются.
4.1.11 Требования к патентной чистоте
Система должна отвечать требованиям к патентной чистоте согласно
действующему законодательству Российской Федерации.
4.1.12 Требования по стандартизации и унификации
Разработка системы должна осуществляться в рамках рекомендаций по
стандартизации Р50.1.028-2001 «Информационные технологии поддержки
жизненного цикла продукции. Методология функционального
моделирования».
4.2 Требования к функциям, выполняемым системой
4.2.1 Перечень функций, задач или их комплексов
геораспределенной архитектуры СМЭВ3.x
Геораспределенность – это географическое разнесение узлов системы,
при которой каждый узел системы замыкает на себя обслуживание части
участников взаимодействия при сохранении информационной и
функциональной целостности системы.
Отдельным узлом геораспреденного СМЭВ могут обслуживаться
участники взаимодействия того или иного региона, расположенные в
относительной географической близости с ЦОД данного региона. При этом
для участника взаимодействия данного региона сохранится возможность
взаимодействия как с участниками его собственного региона, так и с
участниками других регионов.
Работы по обеспечению геораспределенной архитектуры СМЭВ3.x
проводятся с целью:
1) повышения отказоустойчивости системы;
2) распределения нагрузки на ЦОДы и каналы;
3) использования текущей инфраструктуры ЦОДов и КЦОДов
СМЭВ;
4) снижение требований к каналам по сравнению с текущей
централизованной архитектурой реализацией СМЭВ3.x.
При этом должны выполняться следующие условия:
1) все узлы СМЭВ3.x имеют доступ друг к другу;
2) информационные системы участников взаимодействия имеют
доступ только к одному основному и не менее, чем к одному
резервному узлу СМЭВ3.x;
3) приоритетный механизм взаимодействия между ЦОДами
СМЭВ3.x – асинхронный, с гарантированной доставкой.
В рамках задачи должны быть спроектированы и разработаны:
1) механизм маршрутизации сообщений между узлами СМЭВ3.x;
2) механизм обмена сообщениями (в том числе с вложениями от
5Мб до 1Гб) между узлами СМЭВ для обеспечения обмена
сообщениями между информационными системами подключёнными
к различным узлам СМЭВ3.x;
3) решение по всем дополнительным функциям СМЭВ3.x в
контексте геораспределенности:
а. конфигурирование;
б. логирование;
в. архивирование;
г. мониторинг.
Требование о геораспределенности не распространяется на тестовую и
разработческую среды СМЭВ3.х.
4.2.1.2 Требования к разработке механизма подключения ЕПГУ к
СМЭВ3.x
В рамках задачи должен быть реализован механизм подключения ЕПГУ
к СМЭВ3.x с учетом обеспечения функционирования интерактивных форм,
возвращения статусов заявок и других интерактивных возможностей ЕПГУ.
В рамках задачи необходимо разработать типовую схему
взаимодействия ЕПГУ с СМЭВ3.х, включая обеспечение функционирования
интерактивных форм и отслеживание статуса запросов. Типовая схема должна
обеспечивать универсальные подходы к переводу текущих сервисов ЕПГУ от
СМЭВ2.0 к СМЭВ3.0. Приоритетом является минимизация доработок на
стороне ЕПГУ при сохранении текущей функциональности.
В рамки задачи не входят доработки на стороне ЕПГУ и
информационных систем ведомств участников взаимодействия. Должны быть
предоставлены рекомендации по интеграции ЕПГУ и информационных
систем поставщиков сведений для ЕПГУ со СМЭВ3.х.
4.2.1.1 Требования к разработке SDK клиента СМЭВ3.x
Необходимо разработать SDK клиента СМЭВ3.0 для Java и .Net
платформ для подключения к СМЭВ3.x информационных систем участников
SDK, путем предоставления готового многофункционального решения,
должен минимизировать трудозатраты по подключению информационных
систем участников взаимодействия к СМЭВ3.x. SDK должен предоставлять
разработчику информационных систем возможность собрать клиент
СМЭВ3.x, максимально адаптированный под его информационную систему.
Для выполнения данной задачи клиент должен обеспечивать следующие
отделяемые модули:
1) механизма соотнесения (маппинга) структуры данных
информационных систем участников взаимодействия со структурами
запросов/ответов видов сведений;
2) API передачи бизнес-данных запроса/ответа в СМЭВ3.х;
3) формирования конверта сообщения СМЭВ (запрос, ответ,
получение статуса), включая случай отправки файлов посредством
файлового хранилища;
4) подписания сообщения (ЭП-СП, ЭП-ОВ);
5) отправки/получения сообщений СМЭВ3.x;
6) контроля интенсивности отправки сообщений согласно МР3.х;
7) формирования запросов/ответов СМЭВ3.x через
специализированную web-форму (с ее автогенерацией на основе
заданной схемы вида сведения);
8) квитирования запросов с ответами.
SDK должен предоставляться в виде готового для сборки исходного
кода.
Исходный код должен иметь расширенный объем документирования,
включая описание алгоритмов работы каждого программного модуля.
4.2.1.2 Требования к доработке транспортной подсистемы СМЭВ
4.2.1.2.1 Требования по обеспечению совместимости СМЭВ с
новыми стандартами криптозащиты
В рамках доработки транспортной подсистемы СМЭВ необходимо
обеспечить проверку электронных подписей участников взаимодействия и
подписание конвертов СМЭВ ЭП-СМЭВ на основании актуального на данный
момент ГОСТ Р 34.10.2012.
При этом в СМЭВ должна быть реализована настройка переключения
проверки и подписи конвертов СМЭВ3.х по ГОСТ Р 34.10.2012 или по ГОСТ
Р 34.10-2001.
4.2.1.2.2 Требования к разработке функционала расширенных
сообщений об ошибках
В целях сокращения сроков расследований ошибочных ситуаций в
работе системы необходимо определить полный перечень возможных точек
отказа системы и обеспечить для каждого случая генерацию
соответствующего сообщения об ошибке - как в лог системы, так и, при
необходимости, в адрес участников взаимодействия.
Необходимо ввести кодовую систему маркировки ошибок. Код ошибки
должен иметь иерархическую структуру – содержать коды узла, компонента и
других структур, где произошла ошибка.
Полный список точек отказа системы должен быть зафиксирован в ходе
разработки технического проекта и отражен в Руководстве администратора
системы и МР3.х (для ошибок, возвращаемых ИС участников