Техническое задание Общие сведения



Скачать 277.39 Kb.
Дата25.07.2014
Размер277.39 Kb.
ТипТехническое задание
Техническое задание
1. Общие сведения

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

1.2. Заказчик: государственное казенное учреждение Самарской области «Региональный центр управления государственными и муниципальными информационными системами и ресурсами Самарской области» (далее – Заказчик).

1.3. Основанием выполнения работ по созданию системы автоматизированного межведомственного взаимодействия Самарской области является областная целевая программа «Развитие информационно -телекоммуникационной инфраструктуры Самарской области на 2012-2015 годы», утвержденная постановлением Правительства Самарской области от 13.11.2009 № 601.

1.4. Источник финансирования средства областного бюджета.

1.5. Место выполнения работ: 443068, г. Самара, ул. Н. Панова, д.16.

1.6.

В рамках настоящего технического задания используются следующие сокращения, термины и определения:

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

САМВ СО или Система – система автоматизированного межведомственного взаимодействия Самарской области, создаваемая в рамках настоящего технического задания;

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

пользователя Системы – уполномоченные сотрудники участников Системы;

СМЭВ СО – государственная информационная система Самарской области «Система межведомственного электронного взаимодействия»;

ЕПГУ – федеральная государственная информационная система «Единый портал государственных и муниципальных услуг (функций)»;

РПГУ – региональная информационная система «Портал государственных и муниципальных услуг (функций) Самарской области»;

РАИС МФЦ – единая региональная автоматизированная информационная система поддержки деятельности многофункциональных центров предоставления государственных и муниципальных услуг Самарской области;

федеральный сервис – электронный сервис, предоставляемый федеральными органами исполнительной власти;

ЭП – электронная подпись;

ЭП-ОВ – электронная подпись органа власти, средства технологической электронной подписи для информационной системы, подключаемой к СМЭВ СО;

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

FTP-сервер и WEB-сервер – сервера Системы, на которых происходит обработка и хранение: информации о пользователях и участниках Системы, форм заявлений, межведомственных запросов, ответов на межведомственные запросы;

XML – расширяемый язык разметки (eXtensible Markup Language);

НТМL – язык разметки гипертекста (HyperText Markup Language);

XSLT-преобразование – язык преобразования XML-файлов (Extensible Stylesheet Language Transformations);

БД – база данных;

СУБД – система управления базой данных;

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

тип запроса – уникальное наименование запроса (документа) согласно ТКМВ;

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

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

2.1. Целью настоящей Работы является автоматизация процессов межведомственного информационного взаимодействия в электронной форме между органами исполнительной власти Самарской области, предоставляющими государственные услуги (исполняющими государственные функции), органами местного самоуправления муниципальных образований в Самарской области, предоставляющими муниципальные услуги (исполняющими муниципальные функции), подведомственными органам исполнительной власти Самарской области или органам местного самоуправления муниципальных образований в Самарской области организациями, участвующими в предоставлении предусмотренных частью 1 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг» государственных или муниципальных услуг, иными государственными органами, органами местного самоуправления, органами государственных внебюджетных фондов, многофункциональными центрами.

2.2. Работы выполняются в рамках реализации мероприятия по развитию инфраструктуры электронного правительства в Самарской области, в соответствии с постановлением Правительства Самарской области от 13.11.2009 №601 «Об утверждении областной целевой программы «Развитие информационно-телекоммуникационной инфраструктуры Самарской области» на 2012-2015 годы».

2.3. Цель достигается за счет решения следующих задач:

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

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

2.4. Порядок выполнения, оформления и предъявления результатов работ регламентирован комплексом стандартов и руководящих документов:

ГОСТ 19.101-77. Виды программ и программных документов;

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем;

ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;

ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения;

ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

ГОСТ 34.603-92. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем;

ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования к текстовым документам;

РД 50-34.698-90. Методические указания. Автоматизированные системы. Требования к содержанию документов;

приказ Министерства связи и массовых коммуникаций Российской Федерации от 27.12.2011 № 190 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»;

постановление Правительства Самарской области от 28.04.2012 № 221 «О государственной информационной системе Самарской области «Система межведомственного электронного взаимодействия»;

разработанные Министерством связи и массовых коммуникаций Российской Федерации и актуальные на момент заключения государственного контракта:

«Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии» (далее – Методические рекомендации);

«Регламент взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия»;

«Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии»;

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

2.5. Выполнение Работ должно осуществляться в соответствии с действующим законодательством Российской Федерации.
3. Порядок выполнения и требования к результатам Работ

3.1. Исполнитель должен предоставить Календарный план выполнения Работ с разделением на этапы длительностью 14 (четырнадцать) календарных дней в течение 3 (трех) дней с даты заключения государственного контракта.

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

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

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

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

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


Наименование модуля

Функционал, назначение модуля

Модуль обработки входящих заявлений на оказание услуг (далее – модуль «Входящие заявления»)

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

Модуль обеспечивает выполнение следующих функций:

получение в электронном виде заявлений на оказание услуг посредством сервисов, опубликованных в СМЭВ СО, из следующих информационных систем: РПГУ, ЕПГУ, РАИС МФЦ;

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

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

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

отслеживание жизненного цикла оказания услуги;

обратное взаимодействие с заявителем по услуге;

отображение актуального регламента предоставления услуги и ее описания.


Модуль формирования запросов на получение информации, необходимой для оказания услуг в рамках межведомственного взаимодействия (далее – модуль «Формирование запросов»)

Модуль «Формирование запросов» позволяет формировать запросы к электронным сервисам, опубликованным в СМЭВ СО, в рамках оказания соответствующей услуги. Запросы, подписываются ЭП пользователя Системы.

Модуль содержит в своем составе реестр электронных сервисов, доступных для участника Системы.

Модуль «Формирование запросов» и модуль «Входящие заявления» имеют общий интерфейс.


Модуль обработки входящих запросов на получение информации (далее – модуль «Входящие запросы»)

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

Модуль позволяет пользователям Системы в автоматизированном режиме рассматривать поступившие межведомственные запросы, формировать и направлять ответы на такие запросы с использованием ЭП.



Модули администрирования

Модули администрирования предназначены для разграничения прав доступа пользователей Системы к услугам и сервисам запросов в рамках модулей «Входящие заявления», «Формирование запросов», и «Входящие запросы», регистрации участников и пользователей Системы, создание услуг и запросов администраторами Заказчика.

Модуль обеспечения электронной подписи

Модуль обеспечения ЭП предназначен для функционирования ЭП и установки ЭП на заявления, запросы и ответы на запросы в рамках модулей «Входящие заявления», «Формирование запросов» и «Входящие запросы».

Модуль аутентификации

Модуль предназначен для обеспечения входа в Систему одним из следующих способов:

посредством использования пары «Имя-Пароль»;

на основании сертификатов ЭП.


Модуль статистики

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

Модуль формирует отчеты о работе модулей «Входящие заявления», «Формирование запросов», «Входящие запросы».


3.4. Для достижения поставленных целей и решения задач требуется выполнить следующие Работы:

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

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

анализ, проектирование, согласование с Заказчиком организационно-технических требований разработке модуля простановки ЭП-ОВ;

анализ, проектирование и согласование с Заказчиком организационно-технических требований по разработке функциональных возможностей, обеспечивающих соответствие адаптеров СМЭВ СО, сервисов и модулей Системы актуальной версии Методических рекомендаций;

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

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

разработка новых функциональных возможностей базовых модулей Системы;

разработка модуля визирования;

разработка модуля простановки ЭП-ОВ;

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

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

разработка технической документации;

обучение представителей Заказчика;

проведение приемо-сдаточных испытаний.

3.5. В результате проведения анализа, проектирования всех работ по созданию Системы, описанных в пункте 3.4 настоящего технического задания, Исполнитель разрабатывает и согласовывает с Заказчиком проектную документацию в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ в течение 20 (двадцати) календарных дней с даты заключения Государственного контракта.

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

3.6. Общие требования к разработке новых функциональных возможностей базовых модулей Системы:

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

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

реализация дополнительного статуса «В работе» для запросов в модуле «Входящие запросы». В данном статусе находятся все запросы, которые приняты на исполнение, но ответ на запрос не отправлен;

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

реализация возможности копирования запроса в модуле «Формирование запросов»;

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

реализация единого номера запроса в модуле «Формирование запросов» и модуле «Входящие запросы». Номер, присваиваемый запросу в модуле «Формирование запросов» («Исходящий номер запроса»), должен также отображаться в модуле «Входящие запросы» («Входящий номер запроса»);

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

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

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

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

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

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

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

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

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

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

создание дополнительного параметра «Просроченные ответы» в модуле «Входящие запросы» для запросов, по которым даны ответы по истечении установленного срока;

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

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

обеспечение возможности пакетного прикрепления файлов без ограничений по количеству и форматам файлов;

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

ввести поле «№ услуги по ТКМВ»;

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

реализация автоматической отправки из модулей Системы в РПГУ и ЕПГУ уведомлений статуса рассмотрения заявления, статуса межведомственных запросов, а также промежуточных статусов и данных (документов, постановлений, справок), которые приходят в ответах на отправленные запросы;

реализация возможности уведомления отправителя запроса (ответа на запрос) о некорректности предоставленных сведений в запросе (ответе на запрос). Необходимо обеспечение уведомления с указанием причины некорректности предоставленных сведений и отображение у отправителя и получателя запроса (ответа на запрос) статуса «Некорректный запрос» («Некорректный ответ»);

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

реализация в модуле «Формирование запросов» возможности назначения на запрос исполнителя из подведомственных учреждений;

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

реализация механизма, позволяющего в Модуле «Входящие запросы» принимать и отображать XML-файлы запросов и ответов на запросы;

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

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

регистрация пользователей;

редактирование информации о пользователях;

назначение суперпользователей по услугам и запросам;

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

предоставление/ограничение доступа к типам запросов (документам).

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

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

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

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

3.7. Общие требования к модулю визирования

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

3.8. Общие требования к разработке новых функциональных возможностей модулей администрирования Системы:

реализация возможности включения/отключения обязательности простановки ЭП на формах заявлений, запросов, ответов на запросы, а также аутентификации в Системе по ЭП;

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

реализация возможности пакетного создания услуг из внешнего файла, по формату согласованному с Заказчиком;

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

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

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

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

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

реализация автоматического заполнения адресов FTP-сервера и WEB-сервера Системы, необходимых при прикреплении к запросу организаций получателей, по умолчанию, их просмотра и редактирования;

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

реализация фильтра в графе «Организация» во всех модулях администрирования Системы;

ввести поле «№ услуги по ТКМВ»;

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

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

обеспечение автоматической простановки срока ответа на запрос (по умолчанию 5 рабочих дней) и возможности редактирования срока ответа;

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

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

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

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

Должна быть реализована возможность использования сертифицированного ФСБ России криптопровайдера КриптоПро CSP при аутентификации посредством ЭП и при простановки ЭП в модулях Системы дополнительно к уже используемым в Системе криптопровайдерам. При доработке модуля обеспечения электронной подписи необходимо использование комплекта SDK КриптоПро (руководство разработчика и набор динамических библиотек опубликованы сети Интернет по адресу http://cpdn.cryptopro.ru/).

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

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

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

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

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

В рамках данных работ необходимо:

обеспечить возможность однократного направления первичного запроса (согласно составу полей запроса в АИС «Реестр сведений» расположенной по адресу http://reestr.210fz.ru/) в федеральный орган исполнительной власти;

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

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

обеспечение настройки частоты проверки статуса по запросу. По умолчанию частота проверки статусов и получения ответа должна быть 2 (два) раза в день (время согласовывается с Заказчиком);

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

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

3.12. Общие требования к разработке модуля простановки ЭП-ОВ.

Модуль простановки ЭП-ОВ обеспечивает хранение и ведение в актуальном состоянии следующих сведений:

наименование информационной системы участника межведомственного электронного взаимодействия;

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

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

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

Для защищенного хранения закрытых ключей ЭП-ОВ необходимо применение сертифицированных носителей информации (eToken).

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

Все ЭП-СП должны проставляться пользователями и храниться в базе данных Системы.

При выполнении работ по разработке модуля простановки ЭП-ОВ необходимо использовать комплекты SDK от поставщиков (разработчиков) средств криптографической защиты информации ViPNet и КриптоПРО (руководство программиста, набор динамических библиотек для разработчика).

3.13. Общие требования к архитектуре Системы, а также функционированию модулей

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

Модуль «Формирование запросов» должен позволять осуществить запрос к любому электронному сервису ведомственной информационной системы, опубликованному в СМЭВ СО, в том числе к федеральным электронным сервисам.

Модуль «Входящие запросы» должен представлять собой интерфейс для ответа пользователей Системы на структурированные запросы, поступающие посредством электронных сервисов, опубликованных в СМЭВ СО. Запросы должны формироваться в виде XML-файла согласно требованиям документов, указанных в пункте 2.4 настоящего технического задания.

Модуль «Формирование запросов» должен позволять осуществлять запросы к Модулю «Входящие запросы» через электронные сервисы Системы и адаптеры СМЭВ СО.

Доступ к электронным сервисам Системы возможен как в пределах Системы, так и в рамках межведомственного взаимодействия с другими ведомственными информационными системами с использованием СМЭВ СО.

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

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

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

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

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

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

Пользовательский интерфейс Системы должен функционировать в следующих браузерах: Internet Explorer, Mozilla Firefox, Google Chrome.

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

ознакомление с новыми функциональными возможностями Системы;

бизнес-процессы визирования заявлений, запросов, ответов на запросы в Системе;

обучение работе в модуле администрирования;

ознакомление с архитектурой Системы.

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

3.15. Исполнитель должен иметь возможность выполнять Работы по защищенному каналу связи между Исполнителем и Заказчиком. Для организации защищенного канала связи с шифрованием передаваемого трафика необходимо использовать сертифицированные ФСБ России средства криптографической защиты информации, совместимые с продуктовой линейкой защищенной VipNet-сети Правительства Самарской области № 923. Количество используемых компонентов шифрования должно соответствовать количеству используемых узлов (серверов) в системе. Необходимые средства защиты должны быть приобретены за счет средств Исполнителя.

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

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

3.17. Результаты Работ в виде документов предоставляются на бумажном носителе в двух экземплярах и в электронном виде в форматах «pdf» и «doc».

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

При оформлении результатов Работ Исполнитель должен следовать государственным стандартам и руководящим документам:

ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения;

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем;

ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;

ГОСТ 34.603-92. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем;

РД 50-34.698-90. Методические указания. Автоматизированные системы. Требования к содержанию документов;

ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования к текстовым документам.

3.19. Результаты работ в виде установочных модулей, исходных кодов программных компонентов предоставляются на DVD или CD в 2 (двух) экземплярах.

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

3.20. Требования к исходным кодам

Система классов программы должна отвечать парадигме объектно-ориентированного программирования.

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

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

3.21. Для выполнения работ по реализации модуля простановки ЭП-ОВ



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

Похожие:

Техническое задание Общие сведения iconТехническое задание на текущий ремонт объектов метрополитена в части букв общие сведения

Техническое задание Общие сведения iconТехническое задание на разработку сайта Компании общие сведения
Договор № от 2006 г. И приложения к договору между и ООО «М. Дизайн»
Техническое задание Общие сведения iconТехническое задание Общие сведения и обоснования актуальности
Российской Федерации, является значительное улучшение кадрового обеспечения организаций и предприятий, разрабатывающих и использующих...
Техническое задание Общие сведения iconТехническое задание на 1 листах Действует с Содержание 1 Общие сведения 3 2 Назначение и цели создания сзпдн 6
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов сзпдн 11
Техническое задание Общие сведения iconТехническое задание на разработку автомата выдачи жетонов авж санкт-Петербург 2012 г. Общие сведения
Цель разработки: создание изделия (автомата продажи жетонов), входящего в комплекс станционного оборудования аскопм
Техническое задание Общие сведения iconТехническое задание на выполнение работ по топографической съёмке масштаба 1: 500 объектов гуп «Петербургский метрополитен» 1 «Общие сведения»
...
Техническое задание Общие сведения iconТехническое задание «Определение величины арендной платы за использование причальных стенок»
Данное техническое задание (далее тз) содержит стандартные требования
Техническое задание Общие сведения iconТехническое задание на программный продукт или что значит фраза "по форме гост 19. 201-78"
Рассмотрим, как правильно составить техническое задание на разработку программного продукта
Техническое задание Общие сведения iconТехническое задание на выполнение работы «Разработка Стратегии развития города Харькова до 2030 года»
...
Техническое задание Общие сведения iconТехническое задание (учебное) на разработку программы обработки топологии имс 3 Подход к реализации 4 Ядро 5 Реализация 5
Данное техническое задание было предложено разбить разработку программы на две составляющие
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org