Портал госуслуг

ЛОТ № 2

Шифр темы: 2104-05-08

Развитие типового решения реестра государственных услуг

Технические требования

Москва

2008 год

2

СОДЕРЖАНИЕТЕРМИНЫ И ОПРЕДЕЛЕНИЯ............................................................................................... 4

1 ОБЩИЕ СВЕДЕНИЯ........................................................... Error! Bookmark not defined.

2 ЦЕЛИ И ЗАДАЧИ................................................................................................................ 5

2.1 Цели ............................................................................................................................... 6

2.2 Задачи ............................................................................................................................ 6

2.3 Связь целей и задач с основными требованиями ФЦП «Электронная Россия

(2002-2010 годы)» ......................................................................................................... 6

3 ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ.................................................. 7

4 СОДЕРЖАНИЕ РАБОТ И ОСНОВНЫЕ ТРЕБОВАНИЯ К НИМ .................................... 8

4.1 Таблица распределения работ по источникам финансирования................................. 8

4.2 Требования к системе ................................................................................................... 8

4.2.1 Требования к системе в целом ............................................................................................8

4.2.1.1 Требования к структуре и функционированию системы ......................................................... 8

4.2.1.1.1 Требования к функциональной архитектуре системы ......................................................................8

4.2.1.1.2 Требования к технологической архитектуре Системы ..................................................................10

4.2.1.2 Требования к численности, квалификации и функциям персонала ...................................... 11

4.2.1.3 Требования к надежности ......................................................................................................... 11

4.2.1.4 Требования к защите информации от несанкционированного доступа................................ 11

4.2.1.5 Требования по обеспечению достоверности актуальности информации ............................. 11

4.2.1.6 Требования к режимам функционирования ............................................................................ 12

4.2.1.7 Требования по стандартизации и унификации........................................................................ 12

4.2.2 Требования к функциям и задачам, выполняемым системой ........................................13

4.2.2.1 Требования к подсистеме «Типовой реестр государственных услуг» .................................. 13

4.2.2.1.1 Требования к обеспечению работы с услугами муниципальных органов власти ..........................13

4.2.2.1.2 Требования к созданию системы единой классификации государственных федеральных,

региональных и муниципальных услуг ..............................................................................................13

4.2.2.1.3 Требования к учетной системе хода исполнения государственных и муниципальных услуг .......14

4.2.2.1.4 Требования к модулю формирования аналитических отчетов на основании информации,

хранящейся в реестре........................................................................................................................15

4.2.2.2 Требования к подсистеме «Типовой ведомственный шлюз»................................................. 15

4.2.2.2.1 Общие требования к подсистеме......................................................................................................15

4.2.2.2.2 Требования к обеспечению ввода информации в ручном режиме (АРМ оператора)....................15

4.2.2.2.3 Требования к обеспечению автоматического ввода информации из внутриведомственных

систем (интеграция) .........................................................................................................................16

4.2.2.3 Требования к подсистеме «Региональный портал государственных услуг»........................ 17


4.2.2.3.2 Требования к модулю предоставления пользователям информации о ходе процессов

предоставления им государственных и муниципальных услуг ......................................................17

4.2.2.4 Требования к транспортной подсистеме.................................................................................. 19


4.2.2.4.2 Требования к модулю взаимодействия с муниципальными образованиями ...................................19

3

4.2.2.4.3 Требования к модулю взаимодействия с органами власти – субъектами государственных и

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

услуг ....................................................................................................................................................19

4.2.3 Требования к видам обеспечения .....................................................................................19

4.2.3.1 Требования к информационному обеспечению ...................................................................... 19

4.2.3.2 Требования к программному обеспечению ............................................................................. 19

4.2.3.3 Требования к техническому обеспечению............................................................................... 20

4.2.3.4 Требования к организационному обеспечению ...................................................................... 20

4.2.3.5 Требования к методическому обеспечению ............................................................................ 20

4.3 Состав, содержание и результаты работ по созданию системы................................ 20

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

4.5 Требования к документированию .............................................................................. 23

5 РЕЗУЛЬТАТЫ РАБОТ ...................................................................................................... 24

5.1 Результаты работ в рамках описываемого проекта ................................................... 24

4

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯМФЦ Многофункциональный центр предоставления

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

АИС Автоматизированная информационная система

ОГВ Органы государственной власти

ГУ, госусулуги Государственные услуги органов государственной власти

БД База банных

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

СПГУ, Система Система порталов государственных услуг

5

1 ОБЩИЕ СВЕДЕНИЯ

1.1. Полное наименование лота: Развитие типового решения реестра государственных услуг

1.2. Исполнитель работ: определяется на конкурсной основе в соответствии с действующим законодательством.

1.3. Сроки выполнения работ: не более 96 календарных дней, но не позднее 15.11.2008 г.

1.4. Лимитная стоимость работ в 2008 году всего 40 000 000,00 рублей (Сорок миллионов рублей 00 копеек), включая НДС.

1.5. Источник финансирования по статье «прочие расходы» - 40 000 000,00 рублей (Сорок миллионов рублей 00 копеек).

6

2 ЦЕЛИ И ЗАДАЧИ

2.1 ЦЕЛИТиповое решение регионального сегмента системы порталов государственных

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

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

Повышение информационной открытости и прозрачности деятельности органов исполнительной власти и Правительства Российской Федерации;

Повышение осведомленности граждан и организаций об оказываемых услугах органов власти;

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

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

2.2 ЗАДАЧИВ настоящее время разработано программное и методическое обеспечение

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

Размещение в Системе информации о муниципальных услугах;

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

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

2.3 СВЯЗЬ ЦЕЛЕЙ И ЗАДАЧ С ОСНОВНЫМИ ТРЕБОВАНИЯМИ ФЦП«ЭЛЕКТРОННАЯ РОССИЯ (2002-2010 ГОДЫ)»

Основной целью ФЦП «Электронная Россия (2002-2010 годы)» является «повышение эффективности государственного управления за счет внедрения и массового распространения информационных и коммуникационных технологий, обеспечения прав на свободный поиск, получение, передачу, производство и распространение информации, расширения подготовки специалистов по информационным и коммуникационным технологиям и квалифицированных пользователей».

Создание Системы будет способствовать решению следующих основных задач ФЦП «Электронная Россия (2002-2010 годы)»:

7

повышение эффективности взаимодействия органов государственной власти на основе использования современных информационных и коммуникационных технологий (далее – ИКТ);

совершенствование деятельности органов государственной власти на основе использования ИКТ;

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

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

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

3 ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИОбъектами автоматизации являются органы государственной власти субъектов

Российской Федерации.

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

Пользователями Системы являются:

Граждане и организации Российской Федерации;

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

8

4 СОДЕРЖАНИЕ РАБОТ И ОСНОВНЫЕ ТРЕБОВАНИЯ К НИМ

4.1 ТАБЛИЦА РАСПРЕДЕЛЕНИЯ РАБОТ ПО ИСТОЧНИКАМФИНАНСИРОВАНИЯ

Этапы НИОКР Прочие расходы Капитальные вложения

1 этап - 2008год

— Развитие типового решения реестра государственных

услуг

—

4.2 ТРЕБОВАНИЯ К СИСТЕМЕ

4.2.1 Требования к системе в целом

4.2.1.1 Требования к структуре и функционированию системы

4.2.1.1.1 Требования к функциональной архитектуре системыСистема в настоящее время имеет территориально-распределенную иерархическую

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

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

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

o Модуль регистрации и хранения информации о государственных услугах;

o Автоматизированное рабочее место (АРМ) оператора реестра.

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

o Модуль отображения информации через интернет-браузеры;

o Модуль индексации информации о государственных услугах, органах власти и документов;

o Модуль администрирования портала.

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

9

o Модуль взаимодействия с региональными реестрамигосударственных услуг;

o Модуль взаимодействия с автономными АРМ Реестра;

o Модуль взаимодействия с Региональным порталом государственных услуг;

o Модуль взаимодействия с другими узлами системы порталовгосударственных услуг;

o Модуль хранения консолидированной информации узла (информация реестра узла и реестров других узлов, относящаяся к территории данного узла);

Региональные узлы системы взаимодействуют со следующими внешними системами:

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

Федеральный узел системы взаимодействует со следующими внешними системами:

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

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

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

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

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

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

o Учетная система хода исполнения государственных и муниципальных услуг в регионе;

o Модуль формирования аналитических отчетов на основании информации, хранящейся в реестре.

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

10

o Модуль предоставления пользователям информации о ходе процессов предоставления им государственных и муниципальных услуг;

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

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

o Модуль взаимодействия с муниципальными образованиями;

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

Детальные требования к перечисленным подсистемам и модулям приведены в разделе 4.2.2.

4.2.1.1.2 Требования к технологической архитектуре СистемыВ данном разделе перечислены требования к технологической архитектуре

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

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

Работа пользователей подсистемы «Типовой ведомственный шлюз» должна быть организована в двухуровневой («клиент – сервер БД») либо в трехуровневой («клиент –сервер приложений – сервер БД») архитектуре.

Доступ пользователей к Порталу должен быть организован в трехуровневой архитектуре «клиент – сервер веб-приложений – сервер БД».

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

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

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

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

сеть Интернет;

передача файлов в ручном режиме.

11

4.2.1.2 Требования к численности, квалификации и функциям персонала

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

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

4.2.1.3 Требования к надежностиВ случае возникновения сбоев, аварий и отказов на отдельных рабочих станциях

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

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

контроль целостности данных на уровне СУБД;

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

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

резервное копирование информации на внешние электронные носители с возможностью оперативного восстановления.

4.2.1.4 Требования к защите информации от несанкционированного доступа

В соответствии с руководящим документом Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа (НСД) к информации. Классификация автоматизированных систем и требования по защите информации» данная система относится к группе многопользовательских автоматизированных систем (АС), в которых одновременно обрабатывается и хранится информация разных уровней конфиденциальности.

4.2.1.5 Требования по обеспечению достоверности актуальности информации

Архитектура системы должна разрабатываться с учетом планов по модернизации (в 2009-2010 годах), которые будут заключаться в обеспечении интерактивного получения услуг через Систему и реализации в этой связи свойств учетности, а именно:

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

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

архивирование событий (изменения учетных данных);

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

12

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

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

4.2.1.6 Требования к режимам функционированияСистема должна иметь возможность функционировать в следующих режимах:

штатный режим;

режим системного администрирования.

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

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

4.2.1.7 Требования по стандартизации и унификацииПри разработке Системы должно быть минимизировано использование

нестандартных, ненормативных классификаторов.

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

Для организации обмена информацией между подсистемами и с внешними системами должна быть:

1. Разработаны и описаны в виде XML Schema спецификации файлов в формате XML;

2. Реализована возможность информационного обмена при помощи файлов в формате и структуре, соответствующей разработанным XML Schema.

3. Использована технология веб-вервисов для он-лайн взаимодействия подсистем.

Проводимые работы должны соответствовать требованиям ФЦП «Электронная Россия» по отчуждаемости и совместимости:

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

13

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

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

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

4.2.2 Требования к функциям и задачам, выполняемым

системой

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

4.2.2.1 Требования к подсистеме «Типовой реестр государственных услуг»

4.2.2.1.1 Требования к обеспечению работы с услугами муниципальныхорганов власти

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

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

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

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

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

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

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

14

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

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

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

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

2. Разнородные услуги (относящиеся к разным функциям государства) должны принадлежать к разным классам;

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

4. Должна быть обеспечена возможность уточнения и/или расширения системы классификации со временем.

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

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

Учетная система должна удовлетворять следующим требованиям:

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

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

3. Должна осуществляться проверка событий хода процесса на соответствие хранящемуся в Реестре описанию процесса оказания государственной или муниципальной услуги (см.п.Error! Reference source not found.), регистрация фактов нарушения сроков административных действий либо предоставления услуги в целом;

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

5. Информация о событиях хода процессов должна передаваться на Федеральный узел Системы;

6. Должны быть предоставлены автоматизированные рабочие места (АРМ) для мониторинга своевременности и полноты предоставления информации от органов исполнительной власти о ходе процессов предоставления ими

15

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

4.2.2.1.4 Требования к модулю формирования аналитических отчетов на основании информации, хранящейся в реестре

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

1. Количественная оценка государственных и муниципальных услуг, предоставляемых регионами и муниципальными образованиями, в т.ч. в разрезе единого классификатора государственных и муниципальных услуг (см.п. 4.2.2.1.2);

2. Оценка востребованности услуг на основании информации о процессах их предоставления (см.п. 4.2.2.1.3);

3. Оценка качества представления государственных и муниципальных услуг на основании зарегистрированных фактов нарушения порядка и сроков процессов их предоставления;

4. Оценка полноты предоставления информации по государственным услугам в Реестре.

4.2.2.2 Требования к подсистеме «Типовой ведомственный шлюз»

4.2.2.2.1 Общие требования к подсистемеПодсистема «Типовой ведомственный шлюз» (далее – Шлюз) предназначена для

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

Подсистема предназначена для установки в органах власти и должна:

1. Предоставлять органам власти автоматизированные рабочие места (АРМ) для ввода информации о событиях процессов оказания государственных и муниципальных услуг в ручном режиме;

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

4.2.2.2.2 Требования к обеспечению ввода информации в ручном режиме (АРМ оператора)

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

1. В части работы с информацией о процессах предоставления услуг:

16

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

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

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

2. В части ввода информации о начале процесса предоставления услуги:

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

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

3. В части ввода информации о событии процесса (административном действии):

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

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

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

4. В части ввода информации о завершении внутреннего процесса оказания услуги:

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

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

5. В части завершения процесса

а. Оператор АРМ должен иметь возможность ввести информацию о факте предоставления результатов услуги получателю услуги.

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

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

17

4.2.2.3 Требования к подсистеме «Региональный портал государственных услуг»

4.2.2.3.1 Требования к обеспечению работы с услугами муниципальных органов власти

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

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

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

3. Типовой Портал должен иметь возможность использоваться в качестве отдельного портала услуг муниципального образования.

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

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

Модуль предоставления пользователям информации о ходе процессов предоставления им государственных и муниципальных услуг (далее – Модуль информирования) предназначен для информирования пользователей Портала о ходе предоставления им государственных и муниципальных услуг органами власти на основании информации, регистрируемой в Учетной системе хода исполнения государственных и муниципальных услуг (см.п. 4.2.2.1.3).

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

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

2. «Эталонное» описание процесса оказания услуги на основании описания процессов предоставления услуги, содержащегося в Реестре, в т.ч. описание последовательности и деталей Административных действий, условий перехода от одного действия к другому, возможных результатов и т.д.;

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

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

5. После завершения внутреннего процесса предоставления услуги – описание полученного результата, способов его получения пользователем, общий срок предоставления услуги;

18

6. После передачи результатов получателю услуги – отметка о передаче результатов и завершении процесса.

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

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

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

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

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

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

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

б. Защищать регистрационную информацию от несанкционированного доступа как внутри узлов СПГУ, так и при обмене этой информацией между узлами;

в. Проводить авторизацию зарегистрированных пользователей на Портале.

19

4.2.2.4 Требования к транспортной подсистеме

4.2.2.4.1 Требования к обеспечению работы с услугами муниципальных органов власти

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

4.2.2.4.2 Требования к модулю взаимодействия с муниципальными образованиями

Для муниципальных сегментов Системы необходимо обеспечить:

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

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

3. Обмен нормативно-справочной информацией.

4.2.2.4.3 Требования к модулю взаимодействия с органами власти –субъектами государственных и муниципальных услуг в части обмена информацией о процессах оказания государственных услуг

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

1. Передачу «эталонных» описаний процессов предоставления государственных услуг из Реестра в Шлюзы;

2. Прием информации о процессах и событиях процессов предоставления государственных услуг.

4.2.3 Требования к видам обеспечения

4.2.3.1 Требования к информационному обеспечениюВ требования к информационному обеспечению Исполнителем должны быть

включены следующие разделы:

1. Требования к составу, структуре и способам организации данных в системе.

2. Требования к информационной совместимости со смежными системами.

3. Требования по использованию нормативно-справочной информации.

4. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы.

5. Требования к контролю, хранению, обновлению и восстановлению данных.

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

требующее лицензионных отчислений при тиражировании его в регионах.

20

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

4.2.3.3 Требования к техническому обеспечениюДля корректного функционирования Системы необходимы следующие

технические средства:

серверы баз данных;

серверы приложений (опционально);

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

локальная вычислительная сеть (опционально);

средства предоставления доступа к сети Интернет.

4.2.3.4 Требования к организационному обеспечениюВ учреждениях и подразделениях, где планируется эксплуатация Системы, должны

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

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

4.2.3.5 Требования к методическому обеспечениюВ рамках разработки Системы для возможности использования новых её

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

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

2. Типовое соглашение с органом власти о предоставлении информации о ходе предоставления государственных услуг;

3. Типовое соглашение с пользователем Портала государственных услуг о предоставлении информации о порядке и ходе предоставления государственных услуг;

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

5. Методика описания порядка предоставления государственных и муниципальных услуг для внесения в Единый реестр государственных услуг;

6. Методика анализа информации Единого реестра государственных услуг.

4.3 СОСТАВ, СОДЕРЖАНИЕ И РЕЗУЛЬТАТЫ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ

Создание и внедрение Системы должно осуществляться поэтапно.

21

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

В пилотную зону должны войти 5 регионов (субъектов Российской Федерации) по согласованию с Заказчиком.

В этих регионах должны быть проведены работы одного из 2-х типов (тип работ определяется для каждого из регионов индивидуально):

Внедрены либо обновлены компоненты Системы (далее - Работы, проводимые в Регионе Внедрения) – 3 (три) региона;

Подготовка региона к внедрению компонентов Системы (далее - Работы, проводимые в Регионе Подготовки) – 2 (два) региона).

Порядок выполнения работ:

1. Разработка Технических Требований и проектов нормативно-правовых актов

Цель данного этапа – разработать технические требования на работы по разработке.

На данном этапе должны быть выполнены следующие работы:

Федеральные работы:

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

2. Разработка Технического Задания на доработку Единого реестра государственных и муниципальных услуг, включая:

a. Типовой Реестр государственных услуг;

b. Транспортную подсистему.

3. Разработка Технического Задания на доработку типового Регионального портала государственных и муниципальных услуг.

4. Разработка Технического Задания на разработку Типового Ведомственного шлюза.

Работы, проводимые в Регионе Внедрения

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

2. Разработка Системы

Цель данного этапа – доработать имеющиеся и разработать новые компоненты Системы.



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

2. Доработка программного обеспечения Транспортной подсистемы.

22

3. Доработка программного обеспечения типового Регионального портала государственных и муниципальных услуг.

4. Разработка программного обеспечения Типового Ведомственного шлюза.


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

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

Работы, проводимые в Регионе Подготовки

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

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

3. Подготовка Системы к опытной эксплуатации

Цель данного этапа – внедрение решения в опытную эксплуатацию.

Для начала выполнения работ данного этапа в Регионах пилотной зоны должны быть выполнены все работы Этапа 2.



1. Обеспечение совместного функционирования доработанных и исходных версий программного обеспечения Системы в регионах Внедрения.


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

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

3. Развертывание Типового Ведомственного шлюза в пилотных органах государственной власти.

4. Ввод доработанной Системы в опытную эксплуатацию.

4.4 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫПриемка работ по созданию и приемке Системы осуществляется поэтапно, в

соответствии с составом работ по созданию Системы (п. 4.3).

Испытания и приемка Системы осуществляются на технических средствах Заказчика.

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

23

4.5 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮТЗ разрабатывается по ГОСТ 34.602-89.

В соответствии с ГОСТ 34.601-90, для АИС необходимо создание Технического проекта (ТП) и Рабочей документации (РД). Перечень документов технического проекта и рабочей документации указан в ГОСТ. Все документы ТП и РД должны иметь содержание в соответствии с РД 50 34-698-90.

Если в состав АИС входит ПО, то для этого ПО в соответствии с п. 1.3.2., 2.4. ГОСТ 34.201-89 создается дополнительно документация по ГОСТ 19.

24

5 РЕЗУЛЬТАТЫ РАБОТ

5.1 РЕЗУЛЬТАТЫ РАБОТ В РАМКАХ ОПИСЫВАЕМОГО ПРОЕКТА1. Доработанное типовое программное обеспечение «Региональный портал

государственных услуг»

2. Доработанное программное обеспечение «Единый реестр государственных услуг» в составе:

а. Доработанное программное обеспечение «Типовой реестр государственных и муниципальных услуг»

б. Доработанное программное обеспечение «Транспортная подсистема»

3. Программное обеспечение «Типовой ведомственный шлюз».

4. Введенные в опытную эксплуатацию в регионах внедрения системы:

а. Доработанный региональный сегмент «Единого реестрагосударственных услуг»;

б. Доработанный «Региональный портал государственных услуг»;

в. Разработанный «Типовой ведомственный шлюз».

Портал госуслуг

Technology