Номер извещения: 0177200000926001895

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: АО «Сбербанк-АСТ»

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://www.sberbank-ast.ru

Размещение осуществляет: Уполномоченный орган МИНИСТЕРСТВО ЭКОНОМИЧЕСКОГО РАЗВИТИЯ РЕСПУБЛИКИ АЛТАЙ

Наименование объекта закупки: Оказание услуг по развитию (модернизации) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» в части обеспечения взаимодействия с региональной витриной данных и предоставления данных из информационных систем – источников данных

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202603772000122001000004

Контактная информация

Размещение осуществляет: Уполномоченный орган

Организация, осуществляющая размещение: МИНИСТЕРСТВО ЭКОНОМИЧЕСКОГО РАЗВИТИЯ РЕСПУБЛИКИ АЛТАЙ

Почтовый адрес: 649000, Респ Алтай, г Горно-Алтайск, ул В.И.Чаптынова, дом 24

Место нахождения: 649000, РЕСПУБЛИКА АЛТАЙ, г.о. ГОРОД ГОРНО-АЛТАЙСК, Г. ГОРНО-АЛТАЙСК, УЛ. ПАНФИЛОВЦЕВ, Д. 7

Ответственное должностное лицо: Шелегова О. В.

Адрес электронной почты: uorgan2@mineco04.ru

Номер контактного телефона: 8-8007-009440-282

Факс: 8-800700-9440

Дополнительная информация: Заказчик (наименование): КАЗЕННОЕ УЧРЕЖДЕНИЕ РЕСПУБЛИКИ АЛТАЙ ПО ЭКСПЛУАТАЦИИ РАДИОРЕЛЕЙНОЙ ЛИНИИ СВЯЗИ "ЭЛ ТЕЛКОМ"; ИНН заказчика: 0411115216; Место нахождения: 649000, РЕСПУБЛИКА АЛТАЙ, г.о. ГОРОД ГОРНО-АЛТАЙСК, Г. ГОРНО-АЛТАЙСК, УЛ. ЧОРОС-ГУРКИНА Г.И., Д. 38; Почтовый адрес: Российская Федерация, 649000, Алтай Респ, Чорос-Гуркина, 38, -; Адрес электронной почты: paz@eltelkom.ru; Номер контактного телефона: +73882229450; Ответственное должностное лицо: Пропиестис Александр Зигманто; ИКЗ позиции плана-графика: 262041111521604110100100020000000242;

Регион: Алтай Респ

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 16.06.2026 09:39 (МСК+4)

Дата и время окончания срока подачи заявок: 26.06.2026 09:00 (МСК+4)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 26.06.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 30.06.2026

Начальная (максимальная) цена контрактов

Начальная (максимальная) цена контракта: 10 146 971,62

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 262041111521604110100100020020000242

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 62.09.20.190 - развитие (модернизация) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» в части обеспечения взаимодействия с региональной витриной данных и предоставления данных из информационных систем – источников данных 1 ОБЩИЕ СВЕДЕНИЯ 1.2 Наименование Заказчика и Исполнителя Заказчик: Бюджетное учреждение Республики Алтай по эксплуатации радиорелейной линии связи «Эл Телком».. Исполнитель: определяется по результатам проведения конкурентной процедуры закупки в соответствии с Федеральным законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 1.3 Цели оказания Услуг Целью оказания услуг по развитию (модернизации) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее – Система) является реализация передачи в региональную витрину из региональных систем – источников данных, необходимых при оказании государственных услуг и для формирования отчетов, в соответствии с функционально-техническими требованиями согласно письму Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 21.04.2026 №ГБ-П30-35951 (далее – ФТТ) 1.4 Основание для оказания Услуг - Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»; - Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; - Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; - Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи»; - Указ Президента Российской Федерации от 7 мая 2024 года № 309 «О национальных целях развития Российской Федерации на период до 2030 года и на перспективу до 2036 года»; - Постановление Правительства Российской Федерации от 8 сентября 2010 г. № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 10 июля 2013 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме»; - Постановление Правительства РФ от 24.10.2011 № 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». - Постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 15 апреля 2014 года № 313 «Об утверждении государственной программы Российской Федерации «Информационное общество»; - Постановление Правительства Российской Федерации от 25 декабря 2024 года № 1886 «О внесении изменений в постановление Правительства Российской Федерации от 15 апреля 2014 г. № 313»; ... 2.1 Общая характеристика Исполнитель должен по требованию Заказчика предъявить документы, подтверждающие законное право на указанные в настоящем Техническом задании программное обеспечение «ИС.МЭВ», а именно: а) для участника, являющегося правообладателем – копия свидетельства об официальной регистрации программ или копия договора об отчуждении исключительного права на программу с копией документа, подтверждающего государственную регистрацию отчуждения исключительного права; б) для участника, которому права на программы переданы автором или иным правообладателем – копия действующего лицензионного (сублицензионного) договора о передаче прав на модификацию и иное использование программ, заключенного в письменной форме и устанавливающего объем и способы использования программ; в) копия действующего сертификата, выданного Правообладателем участнику закупки, по которому участник имеет право осуществлять услуги по распространению, внедрению, модификации и сопровождению программного обеспечения от своего имени с соблюдением авторских прав Правообладателя. Основание: Раздел VII ГК РФ "Права на результаты интеллектуальной деятельности и средства индивидуализации". Описание функционала программного обеспечения «ИС.МЭВ» приведено в Приложении №1. ... - Условная единица - 1,00 - 10 146 971,62 - 10 146 971,62

КАЗЕННОЕ УЧРЕЖДЕНИЕ РЕСПУБЛИКИ АЛТАЙ ПО ЭКСПЛУАТАЦИИ РАДИОРЕЛЕЙНОЙ ЛИНИИ СВЯЗИ "ЭЛ ТЕЛКОМ" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1 ОБЩИЕ СВЕДЕНИЯ 1.2 Наименование Заказчика и Исполнителя Заказчик: Бюджетное учреждение Республики Алтай по эксплуатации радиорелейной линии связи «Эл Телком».. Исполнитель: определяется по результатам проведения конкурентной процедуры закупки в соответствии с Федеральным законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 1.3 Цели оказания Услуг Целью оказания услуг по развитию (модернизации) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее – Система) является реализация передачи в региональную витрину из региональных систем – источников данных, необходимых при оказании государственных услуг и для формирования отчетов, в соответствии с функционально-техническими требованиями согласно письму Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 21.04.2026 №ГБ-П30-35951 (далее – ФТТ) Значение характеристики не может изменяться участником закупки 1.4 Основание для оказания Услуг - Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»; - Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; - Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; - Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи»; - Указ Президента Российской Федерации от 7 мая 2024 года № 309 «О национальных целях развития Российской Федерации на период до 2030 года и на перспективу до 2036 года»; - Постановление Правительства Российской Федерации от 8 сентября 2010 г. № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 10 июля 2013 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме»; - Постановление Правительства РФ от 24.10.2011 № 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». - Постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 15 апреля 2014 года № 313 «Об утверждении государственной программы Российской Федерации «Информационное общество»; - Постановление Правительства Российской Федерации от 25 декабря 2024 года № 1886 «О внесении изменений в постановление Правительства Российской Федерации от 15 апреля 2014 г. № 313»; Значение характеристики не может изменяться участником закупки - Постановление Правительства РФ от 01.11.2025 № 1733 «О внесении изменений в постановление Правительства Российской Федерации от 15.04.2014 г. № 313»; - Постановление Правительства РФ от 01.03.2022 № 277 «О направлении в личный кабинет заявителя в федеральной государственной информационной системе «Единый портал государственных и муниципальных услуг (функций)» сведений о ходе выполнения запроса о предоставлении государственной или муниципальной услуги, заявления о предоставлении услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг», а также результатов предоставления государственной или муниципальной услуги, результатов предоставления услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг»; - Постановление Правительства Российской Федерации от 6 июля 2015 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; - Постановление Правительства Российской Федерации от 8 июня 2011 года № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 8 сентября 2010 года № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 14 мая 2021 года № 733 «Об утверждении Положения о федеральной государственной информационной системе «Единая информационная платформа национальной системы управления данными» и о внесении изменений в некоторые акты Правительства Российской Федерации»; - Распоряжение Правительства Российской Федерации от 29 июня 2012 года № 1123-р «О перечне сведений, находящихся в распоряжении государственных органов субъектов РФ, органов местного самоуправления, территориальных государственных внебюджетных фондов»; - Функциональные и технические требования по предоставлению данных из информационных систем – источников данных в региональную витрину данных (далее – ФТТ). - Приказ ФСТЭК России от 11.04.2025 г. № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» - Приказ ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». - Приказ ФСБ России от 24.10.2014 № 524. 2.1 Общая характеристика Исполнитель должен по требованию Заказчика предъявить документы, подтверждающие законное право на указанные в настоящем Техническом задании программное обеспечение «ИС.МЭВ», а именно: а) для участника, являющегося правообладателем – копия свидетельства об официальной регистрации программ или копия договора об отчуждении исключительного права на программу с копией документа, подтверждающего государственную регистрацию отчуждения исключительного права; б) для участника, которому права на программы переданы автором или иным правообладателем – копия действующего лицензионного (сублицензионного) договора о передаче прав на модификацию и иное использование программ, заключенного в письменной форме и устанавливающего объем и способы использования программ; в) копия действующего сертификата, выданного Правообладателем участнику закупки, по которому участник имеет право осуществлять услуги по распространению, внедрению, модификации и сопровождению программного обеспечения от своего имени с соблюдением авторских прав Правообладателя. Основание: Раздел VII ГК РФ "Права на результаты интеллектуальной деятельности и средства индивидуализации". Описание функционала программного обеспечения «ИС.МЭВ» приведено в Приложении №1. Значение характеристики не может изменяться участником закупки Объектом автоматизации, выбранным Заказчиком в качестве опорной системы для реализации процесса централизованного сбора и отправки данных в региональную витрину данных (далее – РВД), является автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее - Система). В качестве технологической основы Системы используется программное обеспечение «ИС.МЭВ» (запись в Едином реестре российских программ для ЭВМ и баз данных 13268 от 11.04.2022 произведена на основании поручения Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 11.04.2022 по протоколу заседания экспертного совета от 04.04.2022 №410пр, ссылка https://reestr.digital.gov.ru/reestr/678288/). Заказчик располагает правом на использование программного обеспечения «ИС.МЭВ» на условиях простой неисключительной лицензии. Исполнитель в соответствии с настоящим Техническим заданием должен являться правообладателем указанного программного продукта либо иметь полномочия передавать право пользования на них Заказчику в порядке, установленном гражданским законодательством Российской Федерации. 2.2 Назначение системы Система предназначена для: - Обеспечения качественной работы исполнительных органов Республики Алтай при предоставлении государственных и муниципальных услуг в электронном виде; - Организации межведомственного электронного взаимодействия между организациями-участниками при оказании государственных (муниципальных) услуг в электронном виде; - Обеспечения исполнения государственных функций Организациями-участниками; - Обеспечения получения гражданами и организациями преимуществ от применения информационных и телекоммуникационных технологий за счет обеспечения равного доступа к информационным ресурсам, развития цифрового контента, применения инновационных технологий, повышения эффективности государственного управления. Автоматизации процессов оказания ИО и ОМСУ Республики Алтай государственных и муниципальных услуг и перевода их в электронный вид на основе существующих административных регламентов (порядков) оказания услуг, требований действующего законодательства, в том числе для обработки обращений на получение государственных и муниципальных услуг республики Алтай, поступающих через Единую систему межведомственного электронного взаимодействия с Единого портала государственных услуг (функций); - Обеспечения межведомственного электронного взаимодействия ИО, ОМСУ Республики Алтай и подведомственных им учреждений, как внутрирегионального, так и с ФОИВ с ИО и ОМСУ других регионов; - Обеспечения взаимодействия с ЕГР ЗАГС для получения сведений о государственной регистрации актов гражданского состояния, содержащихся в ЕГР ЗАГС, и сведений о внесении исправлений или изменений в записи актов гражданского состояния, содержащиеся в ЕГР ЗАГС. - Мониторинга хода оказания в электронной форме государственных и муниципальных услуг, межведомственного электронного взаимодействия, сбора статистических данных об указанных выше процессах и подготовки аналитической информации для принятия управленческих решений, совершенствования информационной системы, порядка её эксплуатации. Значение характеристики не может изменяться участником закупки 3.1 Требования к Системе в целом Оказание Услуг по развитию (модернизации) Системы должно обеспечить расширение функциональных возможностей Системы, существующая функциональность не должна быть уменьшена, накопленные в программном обеспечении данные должны быть сохранены. Развитие (модернизация) Системы должно включать в себя весь имеющийся функционал на момент начала оказание Услуг и функционировать на имеющемся аппаратном и программном обеспечении Заказчика. Развитие (модернизация) функционала Системы предполагает использование единых баз (справочники, базы данных) во всех ее компонентах. Оказание Услуг осуществляется в сроки, не превышающие и укладывающиеся во временные рамки, установленные для разработки, тестирования и ввода в промышленную эксплуатацию актуализированной функциональности. Значение характеристики не может изменяться участником закупки 3.2 Требования к развитию (модернизации) Системы в целях интеграции с региональной витриной данных Исполнитель обязан оказать Услуги по развитию (модернизации) Системы, включая следующие задачи: 1. Обеспечить возможности выгрузки, трансформации и загрузки данных из Системы в РВД. В рамках данного пункта Исполнителю необходимо создать ETL-компонент, обеспечивающий: а) получение данных из ИС-источников, их трансформацию в соответствии с требованиями РВД и загрузку в РВД с использованием компонентов REST-Uploader и DTM-Uploader; б) мониторинг выполнения операций по загрузке и обработке данных в РВД; в) автоматическое выполнение выгрузки данных из Системы в РВД по заданному расписанию; г) настройку РВД на вычислительных мощностях, предоставленных Заказчиком. 2. Разработать и согласовать с Заказчиком частное техническое задание (далее – ЧТЗ), содержащее детализированные требования к реализации работ по интеграции Системы с РВД; 3. Провести нагрузочное тестирование, в том числе, выполнить работы, связанные с утверждением методики и созданием и (или) модернизацией инструментов для проведения нагрузочного тестирования. 4. Разработать техническую документацию, включающую описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности. Место размещения РВД определяется согласно соответствующим функциональным и техническим требованиям, доведенным Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации, и уточняется в рамках ЧТЗ. Значение характеристики не может изменяться участником закупки 3.2.1 Обеспечение возможности выгрузки, трансформации и загрузки данных из Системы в региональную витрину данных В рамках оказания Услуг должен быть разработан и внедрен ETL-компонент, включающий: ­ ETL-модуль; ­ Модуль управления таблицами РВД; ­ Модуль клиентов РВД; ­ Модуль скриптов; ­ Модуль «Мониторинг операций с данными на РВД». Значение характеристики не может изменяться участником закупки 3.2.1.1 Требования к ETL-модулю ETL-модуль должен обеспечивать получение данных из ИС-источников, их трансформацию в соответствии с установленными правилами и последующую загрузку в РВД. Допускается использование готовых ETL-решений, включенных в реестр российского программного обеспечения, и (или) программного обеспечения с открытым исходным кодом при условии соответствия всем требованиям настоящего Технического задания. ETL-модуль должен обеспечивать выполнение следующих функций: ­ прием данных из ИС-источников. Атрибутивный состав, типы данных и форматы полей должны соответствовать требованиям, приведенным в ФТТ; ­ трансформацию данных, включая: • преобразование данных в соответствии с установленными правилами (маппинг полей, агрегация и иные операции); • настройку критериев корректности, целостности и полноты данных для отдельных наборов данных; ­ загрузку данных в РВД с использованием компонентов REST-Uploader и DTM-Uploader. Должны поддерживаться следующие операции: • загрузка данных в таблицы РВД из CSV-файлов; • удаление данных из таблиц РВД; • получение и обработка результатов выполнения операций загрузки и удаления данных. В рамках ETL-модуль должно быть обеспечено автоматическое выполнение выгрузки данных в РВД по заданному расписанию. Для управления расписанием выгрузки ETL-модуль должен обеспечивать: ­ создание расписаний выгрузки; ­ редактирование расписаний выгрузки; ­ настройку перечня выгружаемых наборов данных (реестров); ­ настройку параметров подключения к РВД. Форматы взаимодействия с ИС-источниками, состав и описание наборов данных, критерии проверки данных, а также требования к хранению и архивированию данных и периодичность выгрузки данных в РВД должны быть определены в ЧТЗ. Значение характеристики не может изменяться участником закупки 3.2.1.2 Требования к модулю управления таблицами РВД Модуль управления таблицами РВД должен обеспечивать создание и настройку таблиц РВД на основании метаструктуры, получаемой из ЕИП НСУД. Модуль должен обеспечивать выполнение следующих функций: ­ добавление новых таблиц; ­ создание таблиц посредством импорта SQL-файлов; ­ настройку параметров полей таблиц, включая: • определение типа поля; • настройку обязательности заполнения; • настройку признака уникальности значений; • установку ограничений на длину значений; • создание индексов Значение характеристики не может изменяться участником закупки 3.2.1.3 Требования к модулю клиентов РВД Модуль клиентов РВД должен обеспечивать ведение сведений об ИС-источниках, осуществляющих передачу данных в РВД. Модуль должен обеспечивать выполнение следующих функций: ­ создание записи о клиенте; ­ редактирование записи о клиенте; ­ просмотр перечня зарегистрированных клиентов. Значение характеристики не может изменяться участником закупки 3.2.1.4 Требования к модулю скриптов Модуль скриптов должен обеспечивать управление скриптами обработки данных, используемыми при загрузке данных в РВД. Модуль должен обеспечивать: ­ загрузку новых файлов скриптов; ­ выбор ранее загруженных файлов скриптов; ­ настройку параметров выполнения скриптов. Для каждого скрипта должна быть предусмотрена возможность указания: ­ точки входа – пути к функции, являющейся точкой запуска обработки; ­ параметров развертывания и запуска скрипта в ETL-модуле; ­ параметров потока обработки, включая путь к файлу, идентификатор клиента, идентификатор таблицы РВД и параметры обработки данных. Значение характеристики не может изменяться участником закупки 3.2.1.5 Требования к модулю «Мониторинг операций с данными на РВД» Модуль «Мониторинг операций с данными на РВД» должен обеспечивать контроль выполнения операций обработки данных в РВД. Модуль должен обеспечивать выполнение следующих функций: ­ получение и обработку сообщений об ошибках, возникающих при выполнении операций с данными; ­ выполнение настроенных действий в зависимости от типа выявленной ошибки; ­ формирование отчетов о результатах выполнения операций с данными в РВД. Правила обработки ошибок, состав отчетов, формат их представления и порядок формирования должны быть определены в ЧТЗ. Значение характеристики не может изменяться участником закупки 3.2.2 Требования к разработке ЧТЗ Исполнитель разрабатывает ЧТЗ и представляет его на согласование Заказчику в срок не более 30 рабочих дней с даты начала оказания услуг. ЧТЗ должно содержать: 1. полное описание требований к взаимодействию с РВД; 2. полное описание требований к мониторингу операций с данными на РВД; 3. полное описание наборов данных, выгрузка которых в РВД из Системы должна быть настроена в рамках выполнения работ, правил трансформации данных, параметров автоматического выполнения выгрузки данных в РВД; 4. требования к формату взаимодействия Системы с внешними источниками данных в целях выгрузки данных в РВД; 5. полное описание требований к ETL-модулю; 6. полное описание требований к развертыванию и настройке РВД; 7. перечень наборов данных, получаемых из внешних источников данных, их полное описание, критерии проверки корректности. Перечень наборов данных, включающих в себя также сведения для оказания государственных услуг и формирования отчетов, для которых в рамках оказания Услуг должна быть обеспечена выгрузка в РВД, формируется Исполнителем совместно с Заказчиком. Заказчик в течение 10 рабочих дней проверяет ЧТЗ на соответствие требованиям. Исполнитель должен провести предварительные мероприятия по настройке ETL-компонента с целью обеспечения возможности выгрузки, трансформации и загрузки данных из Системы в РВД. Значение характеристики не может изменяться участником закупки 3.2.3 Проведение нагрузочного тестирования, в том числе утверждение методики, создание и (или) модернизация инструментов для проведения нагрузочного тестирования Исполнитель должен провести нагрузочное тестирование РВД. Целями нагрузочного тестирования являются: 1. Проверка предельных уровней нагрузки, при которых обеспечивается работоспособность, уровень ошибок не превышает допустимый согласно требованиям ФТТ. 2. Оценка влияния нагрузки на время отклика (время отправки ответов на запросы) согласно требованиям ФТТ. 3. Оценка стабильности работы под нагрузкой. 4. Выработка рекомендаций по возможному увеличению производительности. По результатам нагрузочного тестирования Исполнитель формирует отчет о проведении нагрузочного тестирования, включающий: 1. Базовую информацию: а) объект тестирования; б) конфигурация тестовой среды; в) сценарии тестирования; г) требования к производительности. 2. Результаты тестирования (по каждому из сценариев): а) числовые показатели в соответствии с параметрами, подлежащими мониторингу; б) выявленные проблемы в процессе тестирования. 3. Выводы: а) соответствие предъявляемым требованиям к производительности; б) возможные ограничения производительности и рекомендации по их устранению. Значение характеристики не может изменяться участником закупки 3.2.4 Разработка технической документации, включающей описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности Исполнитель должен разработать отчеты и рабочую документацию, содержащую подробное описание работ, выполняемых в рамках модернизации Системы в целях интеграции с РВД, включающие в себя: 1) Отчет о работах, выполненных в рамках доработки (настройки) Системы и региональных информационных систем – источников данных и (или) модернизации их функциональности, с указанием сложности выполненных работ и содержащий проверку функций, описанных в разделе 3 ФТТ «Требования к Системе»; 2) Описание реализованных функций и (или) сценариев работы Системы; 3) Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; 4) Обновление эксплуатационной документации Системы; 5) Отчет о нагрузочном тестировании. Значение характеристики не может изменяться участником закупки 3.3 Требования к формату взаимодействия Системы с внешними источниками данных В рамках оказания Услуг по развитию Системы должно быть обеспечено взаимодействие с внешними источниками данных в целях выгрузки данных в РВД, перечень ИС-источников представлен ниже. Наименование ИС-источника Многофункциональная региональная информационная система Республики Алтай: Соцзащита Разработчик ИС-источника Общество с ограниченной ответственностью Научно-производственная компания «КАТАРСИС» ИНН 7825103271 Владелец ИС-источника Министерство труда, социального развития и занятости населения Республики Алтай, Форматы взаимодействия, полное описание наборов и перечень данных должны быть описаны в ЧТЗ. Для обеспечения получения данных из ИС-источников Заказчик обеспечивает предоставление сетевой связности и необходимых доступов между ETL-компонентом и ИС-источниками. Предоставление доступов осуществляется по согласованию с операторами соответствующих информационных систем в срок не позднее 10 (десяти) рабочих дней с даты заключения Контракта. Значение характеристики не может изменяться участником закупки 3.4.1 Требования к информационному обеспечению Хранение данных в Системе обеспечивается функциями СУБД, относящихся к Единому реестру российских программ для электронных вычислительных машин и баз данных или свободно-распространяемому ПО с открытым исходным кодом. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД. Средства СУБД, а также средства используемых операционных систем должны обеспечивать протоколирование обрабатываемой в Системе информации. Доступ к данным должен быть предоставлен только авторизованным пользователям, а также с учетом категории запрашиваемой информации. Значение характеристики не может изменяться участником закупки 3.4.2 Требования к лингвистическому обеспечению При развитии (модернизации) Системы Исполнитель должен учитывать язык программирования, на котором создан исходный код развиваемой Системы. В диалогах с пользователями в текстах сообщений применяется русский язык, за исключением сообщений общесистемного ПО, которые могут не подлежать переводу на русский язык, а также системных сообщений и интерфейсов администратора Системы. Способ организации диалога с пользователем должен обеспечивать: 1. уменьшение вероятности совершения оператором случайных ошибочных действий; 1. логический контроль ввода данных; 2. контроль ввода данных на непротиворечивость; 3. возможность корректировки вводимого текста. Все экранные и выходные формы, инструкции по работе, вся документация должны быть выполнены на русском языке. Исключения могут составлять только системные сообщения, не подлежащие русификации. Значение характеристики не может изменяться участником закупки 3.4.3 Требования к программному обеспечению Программное обеспечение и библиотеки программного кода, используемые Исполнителем при оказании Услуг по развитию (модернизации) Системы, должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. Графический пользовательский интерфейс должен быть реализован как веб-приложение, используемое пользователями через веб-браузеры. Значение характеристики не может изменяться участником закупки 3.4.4 Требования к методическому обеспечению В рамках оказания Услуг по развитию (модернизации) Системы Исполнителем должны быть актуализированы следующие эксплуатационные документы: 1. руководство пользователя (в случае функциональных изменений процесса использования Системы); 2. руководство администратора (в случае функциональных изменений процесса использования Системы). Значение характеристики не может изменяться участником закупки 3.5.1 Требования к надежности Общими требованиями к надежности Системы являются: 1. Система должна функционировать круглосуточно, в непрерывном режиме, кроме времени проведения работ по смене версий программного обеспечения, других профилактических работ по техническому обслуживанию, требующих остановку технических средств; 2. контроль целостности данных должен быть обеспечен на уровне СУБД; 3. выход из строя одной из подсистем не должен приводить к прекращению функционирования остальных подсистем, т.е. при этом должна обеспечиваться возможность выполнения функций всех оставшихся подсистем; 4. неправильные действия пользователей не должны приводить к возникновению аварийной ситуации в работе Системы; 5. должны быть минимизированы ошибки пользователей Системы, в том числе путем четкого разграничения прав доступа к Системе. Значение характеристики не может изменяться участником закупки 3.6 Требования по безопасности Все технические решения, использованные при развитии (модернизации) Системы, а также требования к аппаратному обеспечению должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации. Значение характеристики не может изменяться участником закупки 3.6.1 Защита информации от несанкционированного доступа Информационная безопасность Системы обеспечивается существующими средствами защиты информации, в том числе управление пользователями, доступом и мониторингом. Значение характеристики не может изменяться участником закупки 3.6.2 Требование к удаленному подключению Исполнитель в рамках развития (модернизации) Системы осуществляет удаленное подключение к аппаратному комплексу, на котором развернута Система с соблюдением текущего Законодательства Российской Федерации и информационной безопасности. Для оказания Услуг на вычислительных мощностях Заказчика, Исполнитель обязан организовать за свой счет подключение к защищенной сети передачи данных Государственного заказчика. Защищенная сеть передачи данных построена на базе аппаратного-программного комплекса шифрования «ViPNet». Значение характеристики не может изменяться участником закупки 3.6.3 Обеспечение сохранности информации при авариях Для обеспечения сохранности информации на серверах, на которых размещена Система, должна быть предусмотрена возможность: 1. периодического резервного копирования базы данных Системы; 2. восстановления данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбои операционной систем и др.); 3. восстановления данных при сбоях в работе сетевого программного и аппаратного обеспечения. Резервные копии базы данных Системы хранятся вне информационных ресурсов Системы и находятся в хоне ответственности Заказчика. Значение характеристики не может изменяться участником закупки 3.6.4 Требования к патентной чистоте Патентная чистота Системы и ее частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации. Без увеличения цены Контракта Исполнитель обязан передать Государственному заказчику права на использование охраняемых результатов интеллектуальной деятельности, права на которые принадлежат подрядчику (исполнителю) и которые использовались при оказании Услуг по Контракту, в объеме, необходимом для использования Заказчиком результатов оказанных Услуг по Контракту по их целевому назначению и в соответствии с условиями Контракта на весь срок действия использованных исключительных прав или на иной срок, установленный Заказчиком. Исполнитель передает Государственному заказчику указанные права посредством заключения лицензионного (сублицензионного) договора. Исполнитель обязан передать исходные коды, разработанные в ходе оказания Услуг программ для электронных вычислительных машин (ЭВМ) и дистрибутивы, сопровождая передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимости, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. В случае использования при оказании Услуг по Контракту программ для электронных вычислительных машин (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передаются права на их использование (исполнение), должны обеспечить отсутствие ограничений, препятствующих использованию результатов работ по их назначению. Использование при модернизации программ, принадлежащих исполнителю и/или третьим лицам, допускается только с согласия Заказчика. При оказании Услуг по настоящему Техническому заданию Исполнитель должен гарантировать соблюдение авторских, исключительных и иных прав на объекты интеллектуальной собственности третьих лиц. Значение характеристики не может изменяться участником закупки При использовании в Системе программ (программных комплексов или модулей), разработанных третьими лицами, условия, на которых передается право на использование (исполнение) этих программ, не должны накладывать ограничений, препятствующих использованию Системы по ее прямому назначению 4 СОСТАВ И СОДЕРЖАНИЕ УСЛУГ В рамках обязательств по настоящему ТЗ Исполнитель должен оказать Услуги по развитию (модернизации) Системы с передачей прав на ПО (модернизированное программное обеспечение). Исполнитель оказывает Услуги в соответствии с требованиями Государственного заказчика, приведенными в разделе 3 настоящего ТЗ 1 Разработка ЧТЗ В течение 30 рабочих дней с момента заключения Контракта, Итоговые документы - Согласованное ЧТЗ. 2 Развитие (модернизация) Системы в соответствии с требованиями, представленными в п. 3 настоящего ТЗ С момента заключения Контракта по 30.09.2026 (включительно), Итоговые документы - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор - Документ о приемке (акт оказанных Услуг). Значение характеристики не может изменяться участником закупки 5.1 Виды и объем испытаний систем Система подвергается следующим видам испытаний: Приемочные испытания. Состав, объем и методы приемочных испытаний Системы определяются документом «Программа и методика приемочных испытаний» (далее - ПМИ). Исполнитель разрабатывает и передает на утверждение Заказчику ПМИ в срок не позднее 10 рабочих дней до даты окончания оказания услуг по Контракту. Заказчик рассматривает и, в случае отсутствия замечаний, утверждает ПМИ в течение 5 рабочих дней со дня предоставления Исполнителем. Проведение приемочных испытаний включает: 1) Испытания Системы на соответствие требованиям настоящего ТЗ в соответствии с программой и методикой приемочных испытаний, разработанной Исполнителем и утвержденной Заказчиком; 2) Анализ результатов устранения недостатков, указанных в акте о завершении испытания; 3) Оформление Исполнителем и подписание Заказчиком акта о приемке Систем в эксплуатацию. Значение характеристики не может изменяться участником закупки 6 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ Полный перечень документации, предъявляемых по завершению оказания Услуг включает: - ЧТЗ; - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор; - Структурированный документ о приемке оказанных Услуг в электронном виде путем размещения в ЕИС. Документация должна предоставляться Заказчику на машинных носителях (флеш-диск или передана ссылка для скачивания). Документация, представленная в электронном виде, должна быть выполнена в формате *pdf *docx. Формат предоставления документации определяется Заказчиком. Документация должна быть выполнена на русском языке, за исключением официальных наименований используемого программного и технического обеспечения. Значение характеристики не может изменяться участником закупки 7 ОБЪЕМЫ И СРОКИ ГАРАНТИЙ КАЧЕСТВА Исполнитель гарантирует, что результаты оказанных Услуг соответствуют требованиям, установленным в Контракте, обязательным нормам и правилам, регулирующим данную деятельность (ГОСТ, ТУ), а также иным требованиям законодательства Российской Федерации, действующим на момент оказания услуг. Качество оказываемых Услуг должно соответствовать действующим нормам и техническим условиям, безопасности жизни и здоровья, а также иным требованиям сертификации, безопасности (санитарным нормам и правилам, государственным стандартам и т.п.), лицензирования, если такие требования предъявляются действующим законодательством РФ или настоящим Контрактом к данному виду Услуг. Гарантийный срок на результаты оказанных Услуг составляет 12 (двенадцать) месяцев с даты подписания Заказчиком документа о приемке оказанных Услуг. Под гарантией понимается устранение Исполнителем своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки оказанных услуг. Если в период гарантийного срока обнаружатся недостатки, то Исполнитель (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, согласованные Сторонами и зафиксированные в акте с перечнем выявленных недостатков и сроком их устранения. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Исполнитель гарантирует возможность безопасного использования результата оказанных Услуг по назначению в течение всего гарантийного срока. Значение характеристики не может изменяться участником закупки Перечень условных обозначений, терминов и сокращений. API (англ. Application Program Interface) Программный интерфейс для взаимодействия компонентов программного обеспечения CSV-ФАЙЛ Файл в формате CSV (англ. Comma-Separated Values — значения, разделенные запятыми), предназначенном для представления табличных данных. Строка таблицы соответствует строке текста в файле, которая содержит одно или несколько полей, разделенных запятыми или другими заданными разделителями Drag-and-drop Способ оперирования элементами интерфейса (как графическим, так и текстовым, где элементы графического пользовательского интерфейса реализованы при помощи псевдографики) с применением манипулятора «мышь» или сенсорного экрана. DATAMART STUDIO Приложение для установки и настройки витрин данных и СУБД ETL Компонент информационной системы, реализующий сервисы извлечения, преобразования, очистки и загрузки данных HTTP Протокол прикладного уровня передачи (англ. HyperText Transfer Protocol). HTTPS Расширение протокола HTTP для поддержки шифрования в целях повышения безопасности (англ. HyperText Transfer Protocol Secure). Low-code Подход к созданию, настройке и модификации систем с минимальным использованием ручного программирования. REST (англ. Representational state transfer) — архитектурный стиль взаимодействия компонентов распределенного приложения в сети REST API Набор правил, по которым различные программы могут взаимодействовать между собой и обмениваться данными с помощью протокола http REST-Uploader Сервис витрины данных для асинхронной загрузки табличных данных (загрузка CSV, удаление, проверка статуса, отчет ФЛК) из сторонних источников с использованием способа взаимодействия REST API DTM-Uploader Сервис витрины данных для бинарных файлов-вложений (загрузка/удаление в S3) из сторонних источников с использованием способа взаимодействия REST API Web-браузер Программное обеспечение для обработки и вывода разных составляющих веб-страницы и предоставление интерфейса между веб-сайтом и его посетителем. Значение характеристики не может изменяться участником закупки Web-интерфейс Web-страница или совокупность web-страниц, предоставляющая пользовательский интерфейс для взаимодействия с сервисом или устройством посредством протокола HTTP и web-браузера. Web-страница Документ или информационный ресурс, доступ к которому осуществляется с помощью web-браузера. XML eXtensible Markup Language, расширяемый язык разметки. XSD XML Schema definition - язык описания структуры XML документа. Агент ПОДД СМЭВ/ Агент СМЭВ 4 Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающие сопряжение Витрин данных с ПОДД СМЭВ БД База данных Бизнес-правила Набор условий, критериев, направленных на управление бизнес-сценарием Бизнес-процесс Набор непрерывно выполняемых мероприятий, пользователями Системы, по действиям и событиям бизнес-сценария с целью получения результата при выполнении Бизнес-сценарий Описание логики выполнения автоматизируемого процесса в Системе Вид сведений/ВС Вид сведений представляет собой комплект документации, определяющий технические требования и особенности предоставления конкретных сведений в СМЭВ. Витрина данных Компонент информационных систем органов и организаций государственного сектора, представляющий собой комплекс программных и технических средств, обеспечивающий загрузку, хранение и предоставление государственных данных из информационных систем органов и организаций государственного сектора другим органам и организациям государственного сектора с использованием ЕИП НСУД и посредством СМЭВ для предоставления государственных и муниципальных услуг, исполнения государственных и муниципальных функций в электронной форме. При создании витрин данных обычно применяется ТПО ВД. ГЕОП Государственная единая облачная платформа ГОСТ Государственный стандарт ЕИП НСУД, ФГИС «ЕИП НСУД» Федеральная государственная информационная система «Единая информационная платформа национальной системы управления данными» Оператор ЕИП НСУД – Минцифры России ЕПГУ Единый портал государственных и муниципальных услуг (функций) http://gosuslugi.ru ЕСИА Федеральная государственная информационная система «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», определенная в постановлении Правительства Российской Федерации от 28 ноября 2011 г. №977. ИС Информационная система ИС-источник, источник Информационная система субъекта РФ, содержащая сведения, подлежащие размещению на региональный витрине данных ОИВ Орган исполнительной власти ОЗУ Оперативное запоминающее устройство – оперативная память – энергозависимая часть системы компьютерной памяти, в которой во время работы компьютера хранится выполняемый машинный код (программы), а также входные, выходные и промежуточные данные, обрабатываемые процессором. ОМСУ Органы местного самоуправления ОС Операционная система ПО Программное обеспечение Портлет Подключаемый, сменный компонент пользовательского веб-интерфейса. Региональная витрина данных, РВД/ компонент региональной информационной системы субъекта РФ, размещенный на ГЕОП. РОИВ Региональные органы исполнительной власти СМЭВ Система межведомственного электронного взаимодействия Система Автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» СУБД Система управления базами данных. ТЗ Техническое задание ФЗ Федеральный закон ФЛК Форматно-логический контроль ФТТ Функциональные и технические требования по обеспечению взаимодействия с витринами данных, развернутыми на ГЕОП (приложение к письму Минцифры России от 21.04.2026 №ГБ-П30-35951) ЧТЗ Частное техническое задание ЭП Электронная подпись Приложение №1 1.10 Подсистема «Журналирование» Подсистема «Журналирования» предназначена для хранения и отображения сведений о событиях Системы. Подсистема состоит из следующих модулей: - модуль «Аудит действий пользователя»; - модуль «Журнал авторизации». 1.10.1 Модуль «Аудит действий пользователя» Модуль «Аудит действий пользователя» предоставляет возможность просматривать все события, которые происходят в Системе в рамках созданного бизнес-процесса. Модуль обеспечивает следующие функциональные возможности: - аудит действий пользователя: • регистрация действий пользователя, совершенных в бизнес-процессе; • просмотр журнала действий пользователей; • просмотр информации о событии с указанием времени, пользователя, типа и подтипа сущности, над которым было совершено действие, описание изменений со старым и новым значением. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала действий в файл в форматы .xlsx, .pdf. 1.10.2 Модуль «Журнал авторизации» Модуль «Журнал авторизации» обеспечивает фиксирование действий пользователей в части осуществления входа (выхода) в (из) Системы. Модуль обеспечивает следующие функциональные возможности: - аудит событий входа и выхода из Системы, с указанием: • тип события: вход через локальную авторизацию (логин / пароль), вход через ЕСИА, вход через ЕСИА по сертификату, выход пользователя из Системы; • дата события; • имя пользователя. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала авторизации в файл в форматы .xlsx, .pdf. Значение характеристики не может изменяться участником закупки Приложение №1 1.11 Компонент «Agent» Данный компонент обеспечивает минимизацию зависимости от типов и версионности обозревателей при использовании механизмов наложения подписи. Компонент «Агент» позволяет осуществлять подписание электронных запросов в сторону СМЭВ без использования технологии интерфейса подключаемых модулей Netscape (NPAPI). Значение характеристики не может изменяться участником закупки Приложение №1 1.12 Компонент «Гарантированная доставка» Компонент «Гарантированная доставка» обеспечивает организацию программной очереди из сформированных пользователями Системы запросов и не доставленных до получателя, их отправку в автоматическом режиме без участия пользователя Системы. Потребность в такой функции компонента «Гарантированная доставка» возможна в случаях возникновения отказов в работе СМЭВ, сервиса – получателя запроса или каких-либо других проблемах со связью между получателем и сервером Системы. Особенностями алгоритма работы блока являются: Первичная пятикратная непрерывная отправка запроса в сторону Поставщика в рамках пользовательского интерфейса. Данная особенность минимизирует процент недоставленных до Поставщика запросов по причине временной загруженности сервиса – Поставщика сведений. При неудачной первичной отправке запроса Поставщику сведений запрос переходит в статус «Отправляется». Последующие попытки отправки запроса осуществляются по следующим правилам: - первые пять минут после создания - раз в 30 секунд; - последующий час – раз в пять минут; - далее раз в 30 минут в течении двух дней; после чего запрос исключается из очереди на отправку и переводится в статус «Сбой при отправке». При неудачной первичной попытке отправки запроса все последующие, вплоть до исключения запроса из очереди на отправку, также происходят по принципу пятикратной непрерывной отправки. Значение характеристики не может изменяться участником закупки Приложение №1 1.3 Подсистема «Реестр записей бизнес-процесса» В подсистеме «Реестр записей бизнес-процесса» отображается перечень обращений по созданному бизнес-процессу в виде записей, с которыми пользователь Системы может работать на соответствующем этапе бизнес-процесса в зависимости от своей роли в Системе. Для удобства работы с записями реестра необходимо реализовать систему фильтрации и сортировки по всем элементам реестра. Обеспечена возможность выгрузки реестров в файлы формата .xlsx и .pdf. Значение характеристики не может изменяться участником закупки Приложение №1 1.4 Подсистема взаимодействия со СМЭВ 8) настройка возможности подписания запроса ЭП-СП; 9) настройка выбора среды СМЭВ 3 (тестовая или продуктивная), по которой будет происходить опрос; 10) дублирование видов сведений для осуществления настройки подписания ВС несколькими подписями; 11) добавление к виду сведений шаблона печатных форм в формате jrxml. - подключение приема в подсистему входящих запросов по конкретным ВС, по которым Система выступает в качестве поставщика; - создание регламентированных запросов к витринам посредством СМЭВ 4 обработчика, с возможностью создания атрибутов запроса, указание мнемоники витрины и запроса, версии; - возможность ручной проверки очереди обработки заявок. 1.4.2 Модуль «СМЭВ-адаптер» Модуль «СМЭВ-адаптер» осуществляет взаимодействие со СМЭВ в рамках приема входящих запросов ВС и ответов, на исходящие из Системы запросов, а также в рамках отправки исходящих запросов ВС и ответов на входящие запросы. Для обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4 реализована техническая возможность использовать Агент ПОДД СМЭВ на подготовленных мощностях и развернутом ПО. Модуль с заданной периодичностью опрашивает указанные адреса ВС на наличие входящих запросов и добавлять их в Систему для дальнейшей обработки и отправки ответа, а также обеспечивать отправку XML-запроса ВС по указанному адресу в СМЭВ. Модуль обеспечивает гарантированную доставку запросов, за счет механизма повторных вызовов электронных сервисов при сбоях. Модуль обращается к установленному в Системе специальному контейнеру ключа ведомства с защищенными файлами сертификатов, для получения электронной подписи, необходимой для принятия входящих запросов и отправки исходящих запросов (в модуле также должна содержаться информация о владельце данного ключа) в зависимости от ведомства – ответчика на запрос и ведомства-инициатора исходящего запроса. В модуле фиксируется история всех запросов с возможностью просмотра следующих параметров: Значение характеристики не может изменяться участником закупки Подсистема состоит из следующих модулей: - модуль «Конструктор запросов»; - модуль «СМЭВ-Адаптер»; 1.4.1 Модуль «Конструктор запросов» Модуль «Конструктор запросов» обеспечивает возможность осуществления настройки видов сведений (далее – ВС), используемых в рамках функционирования Системы, а также преобразование переданного XML-запроса в JSON и преобразование из JSON в XML-запрос. Модуль выполняет следующие функции: - ведение реестра заявок – данных, которыми Система обмениваемся с другими системами через СМЭВ, для просмотра необходимой информации о входящих и исходящих межведомственных запросах. Заявка должна содержать атрибуты запроса, атрибуты ответа, а также сведения о наличии ошибок при отработке запроса. В реестре должна быть реализована возможность фильтрации по типу запроса (входящий, исходящий), ответственному ведомству, ВС, статусу заявки, дате создания и дате ответа по заявке. - выгрузка реестра заявок в файл формата .xlsx; - формирование исходящих запросов и ответов на входящие запросы в формате XML для передачи в модуль, а также преобразование входящего запроса или ответа из формата XML в формат JSON; - ведение реестров ведомств – департаментов, к которым Система обращается для получения каких-либо сведений, подключенных к Системе, через СМЭВ; - ведение библиотеки ВС со следующими функциональными возможностями: 1) возможность создания адаптеров к ВС СМЭВ 3 с указанием общих параметров адаптера (название сведений, версия сведений, идентификатор класса, тип запроса, источник поступления запросов или передачи ответов); 2) импорт XSD-схемы ВС (с описанием необходимых наборов полей) и генерация форм запроса и ответа; 3) экспорт описания наборов полей в формате JSON; 4) импорт архива описания наборов полей в формате JSON; 5) редактирование форм запроса и ответа ВС; 6) фильтрация реестра по типу запроса (входящий, исходящий), ответственному ведомству и названию сведения; 7) выбор ЭП-ОВ, которой будет подписываться запрос; - номер запроса с возможностью перехода просмотра статуса сообщения в ЛК УВ; - дата запроса; - дата ответа на запрос; - статус запроса; - идентификатор (messageId) запроса; - текст запроса в формате XML; - текст ответа в формате XML; - SOAP-пакеты. В модуле реализована возможность опроса очереди СМЭВ по пространству имен (namespace) ВС. Для возможности просмотра ошибок, которые имеются в работе СМЭВ 3 или по определенному виду сведений реализован журнал ошибок при взаимодействии со СМЭВ. В журнале выводятся следующие ошибки с указанием наименования вида сведений, даты блокировки, даты разблокировки: - Ошибка подключения к веб-сервису СМЭВ 3; - Ошибка подписания сообщения определенной подписью; - Ошибка отправки сообщения - доступ запрещен для определенной подписи; - Ошибка подписания сообщения крипто-провайдером; - Ошибка добавления сообщения в очередь ответчика - очередь переполнена; - Ошибка отправки сообщения - вид сведений недоступен для определенной подписи; - Ошибка СМЭВ. Приложение №1 1.5 Подсистема «Реестр исходящих запросов» Подсистема обеспечивает возможность обмена данными с ФОИВ, РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки запросов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Поставщику сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает возможность отправки запроса в витрину данных, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ версии 4. В подсистеме доступны запросы к витринам, которые были добавлены в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик», в статусе «Активный». Доступно добавление (подключение) новых витрин данных и активация запросов к ним в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. Значение характеристики не может изменяться участником закупки Приложение №1 1.6 Подсистема «Реестр входящих запросов» Подсистема обеспечивает возможность обмена данными с РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки ответов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Потребителю сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. Значение характеристики не может изменяться участником закупки Приложение №1 1.7 Подсистема взаимодействия с ЕГР ЗАГС Дополнительно для реестра «Сведения о государственной регистрации смерти» обеспечена возможность следующих выгрузок: - выгрузка реестра по форме 1.2.1 риур; - выгрузка реестра по форме 1.2 риур; - Экспорт актов в XLSX; - Отчет по количеству актов; - Отчет для «ГАС Выборы» в формате txt; Значение характеристики не может изменяться участником закупки Подсистема взаимодействия с ЕГР ЗАГС обеспечивает функционал по получению, обработке и использованию данных о записях актов гражданского состояния в составе следующих компонентов: - сведения о государственной регистрации смерти; - сведения о государственной регистрации установления отцовства; - сведения о государственной регистрации перемены имени; - сведения о государственной регистрации заключения брака; - сведения о государственной регистрации расторжения брака; - сведения о государственной регистрации рождения. Для получения сведений ЗАГС подсистема использует библиотеку адаптеров, при этом взаимодействие Системы со СМЭВ должно происходить в качестве «Поставщика вида сведений» по следующему сценарию работы: Система, в соответствии с заданным интервалом времени, осуществляет опрос информационной системы Федеральной налоговой службы на наличие данных об актах гражданского состояния, через отправку запроса к соответствующим видам сведения СМЭВ 3.Х; В ответ на запрос Система получает набор запрашиваемых данных и направляет подтверждение получения запроса. В Системе осуществляется проверка оригинальности полученных данных, после чего записи, которые не сохранены в базе данных Системы или были обновлены в ЕГР ЗАГС будут добавлены и/или обновлены в локальных реестрах хранения информации ЕГР ЗАГС. Для использования данных, получаемых в результате взаимодействия с ЕГР ЗАГС, в Системе обеспечена возможность формирования реестров полученных актовых записей, включающих все поступившие записи. В Системе обеспечена возможность доступа для сотрудников к реестрам с возможностью просмотра и выгрузки записей, предназначенных только для ведомства сотрудника. Для удобства работы с записями реестра реализована система фильтрации и сортировки по всем элементам реестра. В Системе для всех реестров обеспечена возможность фильтрации по элементам реестра и выгрузки в файлы форматов: XLSX. Приложение №1 1.8 Подсистема «Запись на прием» По каждому учреждению допускается создание расписания, на основе которого Система будет генерировать слоты времени для записи на прием через ЕПГУ. Запись о расписании представляет собой правило генерации слотов времени, которые будет видеть заявитель на ЕПГУ при бронировании времени приема. В Системе правило расписания должно состоять из следующих атрибутов: -наименование: задается произвольное название правила; - подразделение: выбор из справочника подразделений учреждения; - количество окон: указывается количество одновременно принимающих операторов; - дата (и время) начала: указывается дата начала действия расписания; указывается время начала рабочего дня; - время приема: длительность временного интервала; - дата (и время) окончания: указывается дата окончания действия расписания; указывается время окончания рабочего дня; - дни недели: указываются рабочие дни недели. Значение характеристики не может изменяться участником закупки Приложение №1 1.9 Подсистема «Аналитика» В аналитическом модуле отражаются статистические показатели межведомственных запросов: - количество обработанных входящих запросов; - количество обработанных исходящих запросов. Реализованы 10 готовых форм отчетов по исходящим запросам: 1) Потребители и сведения – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 2) Потребители и поставщики – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование поставщика вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 3) Потребители и поставщики (верхнеуровневый) – аналогично п.2, но количество запросов суммируется по верхнеуровневым организациям. 4) Рейтинг поставщиков – со следующей информацией: - Наименование поставщика вида сведений; - Всего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 5) Рейтинг потребителей – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - сего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 6) Рейтинг пользователей – со следующей информацией: - ФИО сотрудника; - Наименование ведомства; - Всего запросов. 7) Активность по месяцам – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование ведомства-поставщика сведений; - Месяц; - Всего запросов. Значение характеристики не может изменяться участником закупки 8) Общая статистика – со следующей информацией: - Внутренний идентификатор запроса; - Messageid запроса; - Дата формирования запроса; - Дата изменения запроса; - Автор запроса; - Статус запроса; - Наименование ВС; - Поставщик; - Ведомство-потребитель. 9) Внутрирегиональные запросы – со следующей информацией: - Внутренний идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус; - Потребитель; - Наименование сведений; - Ведомство-поставщик; - Количество дней на обработку; - Обработан (в срок/истек срок). 10) Внутрирегиональные запросы (верхнеуровневый) – аналогично п.9, но с указанием верхнеуровневых организаций. - Реализована форма отчета по входящим запросам со следующей информацией: - Идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус запроса; - Потребитель; - Наименование ВС; - ОКТМО; - Поставщик; - Ведомство-поставщик. Приложение №1 к техническому заданию «Описание функциональных характеристик программного обеспечения» содержит перечень функциональных возможностей программного обеспечения «ИС.МЭВ» (Далее – ПО). Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица. Сценарий включает следующие шаги: 1) пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА». 2) Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа. 3) ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь ещё не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации. 4) когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений. 5) если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код. 6) Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код. 7) ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации. 8) Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным. После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа. Значение характеристики не может изменяться участником закупки - Стандартные компоненты: • текстовое поле – универсальное поле для хранения строковых данных в одной строке; • электронная почта – поле для ввода электронной почты (email адреса) с автоматической проверкой корректности введенного адреса; • текстовая область – расширяемая (вручную или автоматически) область для хранения строковых данных, занимающих несколько строк; • номер телефона – поле для ввода номер телефона с предустановленной маской для проверки корректности введенного номера; • дата / время – поле для ввода даты и/или времени в заданном в настройках компонента формате. В компоненте предусмотрены выбор даты и времени с помощью виджета «Календарь – время» и ограничение вводимых (выбираемых) даты или времени; • флажок» – специальное поле, пребывающее в двух состояниях: «Установлен» (истина), «Не установлен» (ложь); • выпадающий список – специальное поле для выбора значения (значений) из определенного в настройках компонента списка возможных значений, в том числе из справочника; • радиокнопка – набор радиокнопок (их количество, название и значение изменяются в настройках), предназначен для выбора только одного из возможных вариантов; • файл – специальное поле для хранения и загрузки файлов различных типов, обладает обширной конфигурацией от ограничения размера загружаемых файлов до предпросмотра некоторых файлов в новой вкладке браузера; 1.2.4.3 Подмодуль «Конструктор критериев экранных форм» Подмодуль «Конструктор критериев экранных форм» позволяет задавать условия выполнения действий (переходов) между экранными формами. Требования для выполнения критерия зависит от компонентов заявки, расположенных на экранной форме. Данный модуль разграничивает выполнение условий по критерию, задавать несколько значений или выполнять определенное из заданного перечня. 1.2.5 Модуль печатных форм Модуль печатных форм предоставляет возможность внесения электронных форм документов (печатных форм) в формате, используемых в Системе на определенном шаге бизнес-процесса. Модуль предоставляет возможность заполнения полей электронной формы документа из компонентов заявки, расположенных на экранной форме. Электронные формы документов (печатные формы), загружаемые в Систему, разрабатывваются в свободно распространяемом ПО. 1.2.4.2 Подмодуль «Конструктор макетов экранных форм» Подмодуль «Конструктор макетов экранных форм» предоставляет следующие возможности: - выбор формы модели – должен содержать все созданные в модуле «Конструктор модели бизнес-процесса» экранные формы для возможности выбора определенной экранной формы для просмотра и/или редактирования; - назначение роли – должен обеспечивать разграничение доступа к экранной форме пользователям, текущая роль которых не входит в число выбранных в списке ролей; - загрузка компонентов из подмодуля «Конструктор компонентов заявки» – должен обеспечивать загрузку шаблона экранной формы, в качестве содержимого выбранной экранной формы; - очистить компоненты – удаление компонентов выбранной экранной формы; - копирование экранной формы – копирование компонентов экранной формы для вставки на других формах; - вставка формы с заменой – должен позволять вставить скопированную экранную форму с полной заменой содержимого экранной формы, на которой вызывается вставка; - вставка формы с сохранением существующей – должен позволять вставить скопированную экранную форму, как дополнение к содержимому экранной формы, на которой вызывается операция вставки. - сохранение экранной формы – сохранение всех изменений только на выбранной экранной форме; - вернуть первоначальную форму – должен позволять отменить не сохраненные изменения содержимого экранной формы; - использование данных модуля «Аудит действия пользователя» – должен позволять при работе с записью по БП на выбранной экранной форме нажать действие «Перейти к журналу действий» и просмотреть журнал действий (кто, когда и какие изменения вносил по данной записи БП) по данной записи БП; - использование панели компонентов – отображение категоризированного списка компонентов, созданных в модуле «Конструктор компонентов заявки». Для размещения компонентов на определенной экранной форме должен быть использован метод Drag-and-drop. - использование рабочей области конструктора – должен позволять размещать, редактировать, перемещать и взаимодействовать с различными компонентами экранной формы. Структура экранной формы и представление данных визуализируется посредством использования метода drag-and-drop. - Дополнительные компоненты: • динамический список – набор записей (строк), содержащих один и тот же набор компонентов, с возможностями неограниченного (по умолчанию) добавления таких записей, а также их изменения и удаления; • сетка данных – аналогичен динамическому списку, однако, записи в данном компоненте свернуты, а значения компонентов отображаются в упрощенном виде (в виде текста); • ссылка – поле для ввода ссылки с автоматической проверкой корректности введенной ссылки; • адрес – специальное поле для хранения адреса, имеет возможности ручного ввода или поиск посредством сервиса ФИАС; • группа флажков – набор флажков (их количество, название и значение изменяются в настройках), которые могут пребывать в двух состояниях: «Установлен» (истина), «Не установлен» (ложь). Предназначен для выбора от одного до максимально возможного количества вариантов; • кнопка – представляет собой кнопку, к которой можно привязать любое действие, расположенное в модуле «Конструктор действий». Возможность внесения изменений в настройки компонентов заявки должна быть предоставлена на любом этапе бизнес-процесса в состоянии редактирования. ИС.МЭВ – программное обеспечение, предназначенное для организации межведомственного электронного взаимодействия органов исполнительной власти, органов местного самоуправления и организаций, участвующих в предоставлении государственных, муниципальных услуг, услуг иных организаций, осуществляющих функции, связанные с предоставлением государственных, муниципальных услуг, и услуг иных организаций с соблюдением юридической значимости при реализации иных полномочий, возложенных на эти органы и организации нормативными правовыми актами. ПО состоит из электронных сервисов межведомственного взаимодействия в целях обмена сведениями, требуемыми в процессе предоставления государственных/муниципальных услуг, а также выполнения иных функции и услуг, осуществляемых в рамках межведомственного взаимодействия. ПО внесено единый реестр российских программ для электронных вычислительных машин и баз данных (Реестровая запись №13268 от 11.04.2022 г.). ОБЩАЯ ИНФОРМАЦИЯ Доступ к функциональным возможностям ПО предоставляется через web-браузер. ПО имеет следующие функциональные возможности: - прием и обработка заявлений с ЕПГУ / Личное обращение, интеграция с ЕЛК; - добавление адаптеров видов сведений СМЭВ 3; - обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4; - интеграция с конструктором цифровых регламентов КЦР; - взаимодействие органов власти с ЕГР ЗАГС; - взаимодействие органов власти с ФССП; - формирование печатных форм документов, обмен исполнительными документами с использованием ЭЦП; - настройка ролевой модели доступа. 1.2.3 Модуль «Конструктор событий» Модуль «Конструктор событий» предназначен для создания статусов обработки заявления и рассылки уведомлений, предназначенных для пользователей Системы, о наступлении определенного события в бизнес-процессе. Основные способы информирования: - системное уведомление – краткое сообщение, опубликованное в Системе для пользователя; - e-mail сообщения - поступающие на адрес электронной почты пользователя. В модуле должна быть возможность для созданного статуса добавить срок обработки, с возможностью указания цветовой индикации записи заявления при наступлении события. 1.2.4 Модуль «Конструктор экранных форм» Модуль «Конструктор экранных форм» состоит из следующих подмодулей: - конструктор компонентов заявки; - конструктор макетов экранных форм; - конструктор критериев экранных форм. 1.2.4.1 Подмодуль «Конструктор компонентов заявки» В подмодуле «Конструктор компонентов заявки» предоставлена возможность использовать и настраивать определенный компонент заявки на экранной форме. Настройка компонентов заявки предусматривает следующие возможности: - создание компонентов; - указывать общие параметры компонента заявки (название, обязательность, маска и др); - указывать параметры по настройке зависимости между компонентами заявки; - указывать параметры по настройке автозаполнения компонентов заявки данными из ЛК. При создании компонентов заявки доступны следующее типы компонентов: Подсистема администрирования Подсистема администрирования состоит из следующих модулей: - модуль управления пользователями и организациями; - модуль «Конфигурация системы». Подсистема администрирования доступна только для пользователей с ролью администратор системы. 1.1.1 Подсистема управления пользователями и организациями Модуль управления пользователями и организациями обеспечивает следующие функциональные возможности: - управление учетными записями пользователей Системы: • создание пользователей; • создание пользователей через импорт файла в формате xlsx; • редактирование атрибутов карточки пользователя; • отключение пользователей; • назначение пользователям ролей доступа к подсистемам и модулям; • создание групп пользователей; • просмотр списка пользователей; • поиск пользователей. - управление списком организаций Системы: • создание организаций; • редактирование атрибутов карточки организации; • отключение организации; • назначение / исключение пользователей к организации; • просмотр списка организаций; • хранение и редактирование древовидной структуры подразделений / организаций; • поиск организации. - реализация ролевого метода управления доступом субъектов доступа (пользователей) к объектам доступа на основе ролей субъектов доступа: • создание ролей доступа и определение прав доступа к подсистемам и модулям • редактирование атрибутов ролей; • назначение роли пользователю, группам пользователей; • удаление ролей доступа; • просмотр списка ролей; • поиск ролей. - просмотр списка активных сессий. 1.1.2 Модуль «Конфигурация системы» Модуль «Конфигурация системы» обеспечивает следующие функциональные возможности: - администрирование сервера: • контроль аппаратной части: объем использованной памяти, всего задействовано ОЗУ, предельный объем памяти; • управление кэшем: удаление кэша БД, сервлетов. - конфигурирование параметров Системы Подсистема авторизации и аутентификации пользователей Доступ к функциям авторизации предоставляется только пользователям, успешно прошедшим процедуру регистрации. Подсистема обеспечивает следующие функциональные возможности: - обеспечение идентификации и аутентификации пользователей по специальным идентификаторам – именам учетных записей пользователей, обеспечение аутентификации пользователей с использованием паролей; - защита аутентификационной информации в процессе ее ввода для аутентификации от возможного использования лицами, не имеющими на это полномочий. Защита осуществляется путем исключения отображения для пользователя действительного значения аутентификационной информации. Вводимые символы пароля должны отображаться условными знаками «*»; - настройку политики блокировки учетной записи пользователя после неудачных попыток авторизации; - осуществление отключения пользователя от Системы при отсутствии активности. В случае неактивности пользователя более установленного промежутка времени происходит автоматическое завершение сессии. Дальнейшая работа возможна только после повторного входа в Систему. Данный функционал предназначен для повышения безопасности работы с Системой и предотвращения несанкционированного доступа в Систему; - исключение возможности установки пользователем по умолчанию аутентификационных данных для входа в систему; - запрет на использование пользователями определенного числа последних использованных паролей при создании новых паролей для предотвращения повторного использования старого пароля; - установление и проверка синтаксиса пароля: • задание минимальной сложности пароля с определяемыми требованиями к регистру, количеству символов, сочетанию букв верхнего и нижнего регистра, чисел и специальных символов; • задание регулярного выражения, используемого для проверки пароля пользователя. • задание срока действия пароля. 1.2 Модуль «Конструктор бизнес-процессов» Подсистема «Конструктор бизнес-процессов» состоит из следующих модулей: - модуль «Конструктор модели бизнес-процесса»; - модуль «Конструктор действий»; - модуль «Конструктор событий»; - модуль «Конструктор экранных форм». При моделировании и автоматизации бизнес-процессов подсистема использует подход low-code, с возможностями, позволяющими автоматизировать бизнес-сценарий в единой цифровой среде за счет визуального редактора сквозных процессов. 1.2.1 Модуль «Конструктор модели бизнес-процесса» Модуль «Конструктор модели бизнес-процесса» позволяет моделировать диаграммы процессов любой сложности с большим количеством разветвлений, условий используя принятые бизнес-правила BPMN. Проектирование осуществляется посредством использования интуитивно понятных графических элементов, каждый из которых визуализирует определенный шаг процесса. Спроектированная модель является исполняемой в Системе. Администратор Системы может опубликовать (запустить) бизнес-процесс, либо деактивировать с целью внесения изменений. 1.2.2 Модуль «Конструктор действий» Модуль «Конструктор действий» отвечает за настройку действий (переходов) между мероприятиями, которые были созданы в модуле «Конструктор модели бизнес-процесса». Модуль предоставляет возможность настроить определенное действие, указать последовательность выполнения, задать условия перехода, установить правила автоматического выполнения шагов процесса или обработки. Стандартное действие Позволяет перейти на следующее мероприятие с изменением статуса (с проверкой заполнения обязательных полей) Удаление Позволяет удалить заявку Печать Позволяет вывести печатную форму, в рамках заявки Назад Позволяет перейти на следующее мероприятие с изменением статуса (без проверки заполнения обязательных полей) Сохранить Позволяет сохранить внесенные изменения в заявке - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1 ОБЩИЕ СВЕДЕНИЯ - 1.2 Наименование Заказчика и Исполнителя Заказчик: Бюджетное учреждение Республики Алтай по эксплуатации радиорелейной линии связи «Эл Телком».. Исполнитель: определяется по результатам проведения конкурентной процедуры закупки в соответствии с Федеральным законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 1.3 Цели оказания Услуг Целью оказания услуг по развитию (модернизации) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее – Система) является реализация передачи в региональную витрину из региональных систем – источников данных, необходимых при оказании государственных услуг и для формирования отчетов, в соответствии с функционально-техническими требованиями согласно письму Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 21.04.2026 №ГБ-П30-35951 (далее – ФТТ) - - Значение характеристики не может изменяться участником закупки - 1.4 Основание для оказания Услуг - - Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»; - Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; - Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; - Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи»; - Указ Президента Российской Федерации от 7 мая 2024 года № 309 «О национальных целях развития Российской Федерации на период до 2030 года и на перспективу до 2036 года»; - Постановление Правительства Российской Федерации от 8 сентября 2010 г. № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 10 июля 2013 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме»; - Постановление Правительства РФ от 24.10.2011 № 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». - Постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 15 апреля 2014 года № 313 «Об утверждении государственной программы Российской Федерации «Информационное общество»; - Постановление Правительства Российской Федерации от 25 декабря 2024 года № 1886 «О внесении изменений в постановление Правительства Российской Федерации от 15 апреля 2014 г. № 313»; - - Значение характеристики не может изменяться участником закупки - - Постановление Правительства РФ от 01.11.2025 № 1733 «О внесении изменений в постановление Правительства Российской Федерации от 15.04.2014 г. № 313»; - Постановление Правительства РФ от 01.03.2022 № 277 «О направлении в личный кабинет заявителя в федеральной государственной информационной системе «Единый портал государственных и муниципальных услуг (функций)» сведений о ходе выполнения запроса о предоставлении государственной или муниципальной услуги, заявления о предоставлении услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг», а также результатов предоставления государственной или муниципальной услуги, результатов предоставления услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг»; - Постановление Правительства Российской Федерации от 6 июля 2015 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; - Постановление Правительства Российской Федерации от 8 июня 2011 года № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 8 сентября 2010 года № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 14 мая 2021 года № 733 «Об утверждении Положения о федеральной государственной информационной системе «Единая информационная платформа национальной системы управления данными» и о внесении изменений в некоторые акты Правительства Российской Федерации»; - - Распоряжение Правительства Российской Федерации от 29 июня 2012 года № 1123-р «О перечне сведений, находящихся в распоряжении государственных органов субъектов РФ, органов местного самоуправления, территориальных государственных внебюджетных фондов»; - Функциональные и технические требования по предоставлению данных из информационных систем – источников данных в региональную витрину данных (далее – ФТТ). - Приказ ФСТЭК России от 11.04.2025 г. № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» - Приказ ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». - Приказ ФСБ России от 24.10.2014 № 524. - 2.1 Общая характеристика - Исполнитель должен по требованию Заказчика предъявить документы, подтверждающие законное право на указанные в настоящем Техническом задании программное обеспечение «ИС.МЭВ», а именно: а) для участника, являющегося правообладателем – копия свидетельства об официальной регистрации программ или копия договора об отчуждении исключительного права на программу с копией документа, подтверждающего государственную регистрацию отчуждения исключительного права; б) для участника, которому права на программы переданы автором или иным правообладателем – копия действующего лицензионного (сублицензионного) договора о передаче прав на модификацию и иное использование программ, заключенного в письменной форме и устанавливающего объем и способы использования программ; в) копия действующего сертификата, выданного Правообладателем участнику закупки, по которому участник имеет право осуществлять услуги по распространению, внедрению, модификации и сопровождению программного обеспечения от своего имени с соблюдением авторских прав Правообладателя. Основание: Раздел VII ГК РФ "Права на результаты интеллектуальной деятельности и средства индивидуализации". Описание функционала программного обеспечения «ИС.МЭВ» приведено в Приложении №1. - - Значение характеристики не может изменяться участником закупки - Объектом автоматизации, выбранным Заказчиком в качестве опорной системы для реализации процесса централизованного сбора и отправки данных в региональную витрину данных (далее – РВД), является автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее - Система). В качестве технологической основы Системы используется программное обеспечение «ИС.МЭВ» (запись в Едином реестре российских программ для ЭВМ и баз данных 13268 от 11.04.2022 произведена на основании поручения Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 11.04.2022 по протоколу заседания экспертного совета от 04.04.2022 №410пр, ссылка https://reestr.digital.gov.ru/reestr/678288/). Заказчик располагает правом на использование программного обеспечения «ИС.МЭВ» на условиях простой неисключительной лицензии. Исполнитель в соответствии с настоящим Техническим заданием должен являться правообладателем указанного программного продукта либо иметь полномочия передавать право пользования на них Заказчику в порядке, установленном гражданским законодательством Российской Федерации. - 2.2 Назначение системы - Система предназначена для: - Обеспечения качественной работы исполнительных органов Республики Алтай при предоставлении государственных и муниципальных услуг в электронном виде; - Организации межведомственного электронного взаимодействия между организациями-участниками при оказании государственных (муниципальных) услуг в электронном виде; - Обеспечения исполнения государственных функций Организациями-участниками; - Обеспечения получения гражданами и организациями преимуществ от применения информационных и телекоммуникационных технологий за счет обеспечения равного доступа к информационным ресурсам, развития цифрового контента, применения инновационных технологий, повышения эффективности государственного управления. Автоматизации процессов оказания ИО и ОМСУ Республики Алтай государственных и муниципальных услуг и перевода их в электронный вид на основе существующих административных регламентов (порядков) оказания услуг, требований действующего законодательства, в том числе для обработки обращений на получение государственных и муниципальных услуг республики Алтай, поступающих через Единую систему межведомственного электронного взаимодействия с Единого портала государственных услуг (функций); - Обеспечения межведомственного электронного взаимодействия ИО, ОМСУ Республики Алтай и подведомственных им учреждений, как внутрирегионального, так и с ФОИВ с ИО и ОМСУ других регионов; - Обеспечения взаимодействия с ЕГР ЗАГС для получения сведений о государственной регистрации актов гражданского состояния, содержащихся в ЕГР ЗАГС, и сведений о внесении исправлений или изменений в записи актов гражданского состояния, содержащиеся в ЕГР ЗАГС. - Мониторинга хода оказания в электронной форме государственных и муниципальных услуг, межведомственного электронного взаимодействия, сбора статистических данных об указанных выше процессах и подготовки аналитической информации для принятия управленческих решений, совершенствования информационной системы, порядка её эксплуатации. - - Значение характеристики не может изменяться участником закупки - 3.1 Требования к Системе в целом - Оказание Услуг по развитию (модернизации) Системы должно обеспечить расширение функциональных возможностей Системы, существующая функциональность не должна быть уменьшена, накопленные в программном обеспечении данные должны быть сохранены. Развитие (модернизация) Системы должно включать в себя весь имеющийся функционал на момент начала оказание Услуг и функционировать на имеющемся аппаратном и программном обеспечении Заказчика. Развитие (модернизация) функционала Системы предполагает использование единых баз (справочники, базы данных) во всех ее компонентах. Оказание Услуг осуществляется в сроки, не превышающие и укладывающиеся во временные рамки, установленные для разработки, тестирования и ввода в промышленную эксплуатацию актуализированной функциональности. - - Значение характеристики не может изменяться участником закупки - 3.2 Требования к развитию (модернизации) Системы в целях интеграции с региональной витриной данных - Исполнитель обязан оказать Услуги по развитию (модернизации) Системы, включая следующие задачи: 1. Обеспечить возможности выгрузки, трансформации и загрузки данных из Системы в РВД. В рамках данного пункта Исполнителю необходимо создать ETL-компонент, обеспечивающий: а) получение данных из ИС-источников, их трансформацию в соответствии с требованиями РВД и загрузку в РВД с использованием компонентов REST-Uploader и DTM-Uploader; б) мониторинг выполнения операций по загрузке и обработке данных в РВД; в) автоматическое выполнение выгрузки данных из Системы в РВД по заданному расписанию; г) настройку РВД на вычислительных мощностях, предоставленных Заказчиком. 2. Разработать и согласовать с Заказчиком частное техническое задание (далее – ЧТЗ), содержащее детализированные требования к реализации работ по интеграции Системы с РВД; 3. Провести нагрузочное тестирование, в том числе, выполнить работы, связанные с утверждением методики и созданием и (или) модернизацией инструментов для проведения нагрузочного тестирования. 4. Разработать техническую документацию, включающую описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности. Место размещения РВД определяется согласно соответствующим функциональным и техническим требованиям, доведенным Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации, и уточняется в рамках ЧТЗ. - - Значение характеристики не может изменяться участником закупки - 3.2.1 Обеспечение возможности выгрузки, трансформации и загрузки данных из Системы в региональную витрину данных - В рамках оказания Услуг должен быть разработан и внедрен ETL-компонент, включающий: ­ ETL-модуль; ­ Модуль управления таблицами РВД; ­ Модуль клиентов РВД; ­ Модуль скриптов; ­ Модуль «Мониторинг операций с данными на РВД». - - Значение характеристики не может изменяться участником закупки - 3.2.1.1 Требования к ETL-модулю - ETL-модуль должен обеспечивать получение данных из ИС-источников, их трансформацию в соответствии с установленными правилами и последующую загрузку в РВД. Допускается использование готовых ETL-решений, включенных в реестр российского программного обеспечения, и (или) программного обеспечения с открытым исходным кодом при условии соответствия всем требованиям настоящего Технического задания. ETL-модуль должен обеспечивать выполнение следующих функций: ­ прием данных из ИС-источников. Атрибутивный состав, типы данных и форматы полей должны соответствовать требованиям, приведенным в ФТТ; ­ трансформацию данных, включая: • преобразование данных в соответствии с установленными правилами (маппинг полей, агрегация и иные операции); • настройку критериев корректности, целостности и полноты данных для отдельных наборов данных; ­ загрузку данных в РВД с использованием компонентов REST-Uploader и DTM-Uploader. Должны поддерживаться следующие операции: • загрузка данных в таблицы РВД из CSV-файлов; • удаление данных из таблиц РВД; • получение и обработка результатов выполнения операций загрузки и удаления данных. В рамках ETL-модуль должно быть обеспечено автоматическое выполнение выгрузки данных в РВД по заданному расписанию. Для управления расписанием выгрузки ETL-модуль должен обеспечивать: ­ создание расписаний выгрузки; ­ редактирование расписаний выгрузки; ­ настройку перечня выгружаемых наборов данных (реестров); ­ настройку параметров подключения к РВД. Форматы взаимодействия с ИС-источниками, состав и описание наборов данных, критерии проверки данных, а также требования к хранению и архивированию данных и периодичность выгрузки данных в РВД должны быть определены в ЧТЗ. - - Значение характеристики не может изменяться участником закупки - 3.2.1.2 Требования к модулю управления таблицами РВД - Модуль управления таблицами РВД должен обеспечивать создание и настройку таблиц РВД на основании метаструктуры, получаемой из ЕИП НСУД. Модуль должен обеспечивать выполнение следующих функций: ­ добавление новых таблиц; ­ создание таблиц посредством импорта SQL-файлов; ­ настройку параметров полей таблиц, включая: • определение типа поля; • настройку обязательности заполнения; • настройку признака уникальности значений; • установку ограничений на длину значений; • создание индексов - - Значение характеристики не может изменяться участником закупки - 3.2.1.3 Требования к модулю клиентов РВД - Модуль клиентов РВД должен обеспечивать ведение сведений об ИС-источниках, осуществляющих передачу данных в РВД. Модуль должен обеспечивать выполнение следующих функций: ­ создание записи о клиенте; ­ редактирование записи о клиенте; ­ просмотр перечня зарегистрированных клиентов. - - Значение характеристики не может изменяться участником закупки - 3.2.1.4 Требования к модулю скриптов - Модуль скриптов должен обеспечивать управление скриптами обработки данных, используемыми при загрузке данных в РВД. Модуль должен обеспечивать: ­ загрузку новых файлов скриптов; ­ выбор ранее загруженных файлов скриптов; ­ настройку параметров выполнения скриптов. Для каждого скрипта должна быть предусмотрена возможность указания: ­ точки входа – пути к функции, являющейся точкой запуска обработки; ­ параметров развертывания и запуска скрипта в ETL-модуле; ­ параметров потока обработки, включая путь к файлу, идентификатор клиента, идентификатор таблицы РВД и параметры обработки данных. - - Значение характеристики не может изменяться участником закупки - 3.2.1.5 Требования к модулю «Мониторинг операций с данными на РВД» - Модуль «Мониторинг операций с данными на РВД» должен обеспечивать контроль выполнения операций обработки данных в РВД. Модуль должен обеспечивать выполнение следующих функций: ­ получение и обработку сообщений об ошибках, возникающих при выполнении операций с данными; ­ выполнение настроенных действий в зависимости от типа выявленной ошибки; ­ формирование отчетов о результатах выполнения операций с данными в РВД. Правила обработки ошибок, состав отчетов, формат их представления и порядок формирования должны быть определены в ЧТЗ. - - Значение характеристики не может изменяться участником закупки - 3.2.2 Требования к разработке ЧТЗ - Исполнитель разрабатывает ЧТЗ и представляет его на согласование Заказчику в срок не более 30 рабочих дней с даты начала оказания услуг. ЧТЗ должно содержать: 1. полное описание требований к взаимодействию с РВД; 2. полное описание требований к мониторингу операций с данными на РВД; 3. полное описание наборов данных, выгрузка которых в РВД из Системы должна быть настроена в рамках выполнения работ, правил трансформации данных, параметров автоматического выполнения выгрузки данных в РВД; 4. требования к формату взаимодействия Системы с внешними источниками данных в целях выгрузки данных в РВД; 5. полное описание требований к ETL-модулю; 6. полное описание требований к развертыванию и настройке РВД; 7. перечень наборов данных, получаемых из внешних источников данных, их полное описание, критерии проверки корректности. Перечень наборов данных, включающих в себя также сведения для оказания государственных услуг и формирования отчетов, для которых в рамках оказания Услуг должна быть обеспечена выгрузка в РВД, формируется Исполнителем совместно с Заказчиком. Заказчик в течение 10 рабочих дней проверяет ЧТЗ на соответствие требованиям. Исполнитель должен провести предварительные мероприятия по настройке ETL-компонента с целью обеспечения возможности выгрузки, трансформации и загрузки данных из Системы в РВД. - - Значение характеристики не может изменяться участником закупки - 3.2.3 Проведение нагрузочного тестирования, в том числе утверждение методики, создание и (или) модернизация инструментов для проведения нагрузочного тестирования - Исполнитель должен провести нагрузочное тестирование РВД. Целями нагрузочного тестирования являются: 1. Проверка предельных уровней нагрузки, при которых обеспечивается работоспособность, уровень ошибок не превышает допустимый согласно требованиям ФТТ. 2. Оценка влияния нагрузки на время отклика (время отправки ответов на запросы) согласно требованиям ФТТ. 3. Оценка стабильности работы под нагрузкой. 4. Выработка рекомендаций по возможному увеличению производительности. По результатам нагрузочного тестирования Исполнитель формирует отчет о проведении нагрузочного тестирования, включающий: 1. Базовую информацию: а) объект тестирования; б) конфигурация тестовой среды; в) сценарии тестирования; г) требования к производительности. 2. Результаты тестирования (по каждому из сценариев): а) числовые показатели в соответствии с параметрами, подлежащими мониторингу; б) выявленные проблемы в процессе тестирования. 3. Выводы: а) соответствие предъявляемым требованиям к производительности; б) возможные ограничения производительности и рекомендации по их устранению. - - Значение характеристики не может изменяться участником закупки - 3.2.4 Разработка технической документации, включающей описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности - Исполнитель должен разработать отчеты и рабочую документацию, содержащую подробное описание работ, выполняемых в рамках модернизации Системы в целях интеграции с РВД, включающие в себя: 1) Отчет о работах, выполненных в рамках доработки (настройки) Системы и региональных информационных систем – источников данных и (или) модернизации их функциональности, с указанием сложности выполненных работ и содержащий проверку функций, описанных в разделе 3 ФТТ «Требования к Системе»; 2) Описание реализованных функций и (или) сценариев работы Системы; 3) Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; 4) Обновление эксплуатационной документации Системы; 5) Отчет о нагрузочном тестировании. - - Значение характеристики не может изменяться участником закупки - 3.3 Требования к формату взаимодействия Системы с внешними источниками данных - В рамках оказания Услуг по развитию Системы должно быть обеспечено взаимодействие с внешними источниками данных в целях выгрузки данных в РВД, перечень ИС-источников представлен ниже. Наименование ИС-источника Многофункциональная региональная информационная система Республики Алтай: Соцзащита Разработчик ИС-источника Общество с ограниченной ответственностью Научно-производственная компания «КАТАРСИС» ИНН 7825103271 Владелец ИС-источника Министерство труда, социального развития и занятости населения Республики Алтай, Форматы взаимодействия, полное описание наборов и перечень данных должны быть описаны в ЧТЗ. Для обеспечения получения данных из ИС-источников Заказчик обеспечивает предоставление сетевой связности и необходимых доступов между ETL-компонентом и ИС-источниками. Предоставление доступов осуществляется по согласованию с операторами соответствующих информационных систем в срок не позднее 10 (десяти) рабочих дней с даты заключения Контракта. - - Значение характеристики не может изменяться участником закупки - 3.4.1 Требования к информационному обеспечению - Хранение данных в Системе обеспечивается функциями СУБД, относящихся к Единому реестру российских программ для электронных вычислительных машин и баз данных или свободно-распространяемому ПО с открытым исходным кодом. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД. Средства СУБД, а также средства используемых операционных систем должны обеспечивать протоколирование обрабатываемой в Системе информации. Доступ к данным должен быть предоставлен только авторизованным пользователям, а также с учетом категории запрашиваемой информации. - - Значение характеристики не может изменяться участником закупки - 3.4.2 Требования к лингвистическому обеспечению - При развитии (модернизации) Системы Исполнитель должен учитывать язык программирования, на котором создан исходный код развиваемой Системы. В диалогах с пользователями в текстах сообщений применяется русский язык, за исключением сообщений общесистемного ПО, которые могут не подлежать переводу на русский язык, а также системных сообщений и интерфейсов администратора Системы. Способ организации диалога с пользователем должен обеспечивать: 1. уменьшение вероятности совершения оператором случайных ошибочных действий; 1. логический контроль ввода данных; 2. контроль ввода данных на непротиворечивость; 3. возможность корректировки вводимого текста. Все экранные и выходные формы, инструкции по работе, вся документация должны быть выполнены на русском языке. Исключения могут составлять только системные сообщения, не подлежащие русификации. - - Значение характеристики не может изменяться участником закупки - 3.4.3 Требования к программному обеспечению - Программное обеспечение и библиотеки программного кода, используемые Исполнителем при оказании Услуг по развитию (модернизации) Системы, должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. Графический пользовательский интерфейс должен быть реализован как веб-приложение, используемое пользователями через веб-браузеры. - - Значение характеристики не может изменяться участником закупки - 3.4.4 Требования к методическому обеспечению - В рамках оказания Услуг по развитию (модернизации) Системы Исполнителем должны быть актуализированы следующие эксплуатационные документы: 1. руководство пользователя (в случае функциональных изменений процесса использования Системы); 2. руководство администратора (в случае функциональных изменений процесса использования Системы). - - Значение характеристики не может изменяться участником закупки - 3.5.1 Требования к надежности - Общими требованиями к надежности Системы являются: 1. Система должна функционировать круглосуточно, в непрерывном режиме, кроме времени проведения работ по смене версий программного обеспечения, других профилактических работ по техническому обслуживанию, требующих остановку технических средств; 2. контроль целостности данных должен быть обеспечен на уровне СУБД; 3. выход из строя одной из подсистем не должен приводить к прекращению функционирования остальных подсистем, т.е. при этом должна обеспечиваться возможность выполнения функций всех оставшихся подсистем; 4. неправильные действия пользователей не должны приводить к возникновению аварийной ситуации в работе Системы; 5. должны быть минимизированы ошибки пользователей Системы, в том числе путем четкого разграничения прав доступа к Системе. - - Значение характеристики не может изменяться участником закупки - 3.6 Требования по безопасности - Все технические решения, использованные при развитии (модернизации) Системы, а также требования к аппаратному обеспечению должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации. - - Значение характеристики не может изменяться участником закупки - 3.6.1 Защита информации от несанкционированного доступа - Информационная безопасность Системы обеспечивается существующими средствами защиты информации, в том числе управление пользователями, доступом и мониторингом. - - Значение характеристики не может изменяться участником закупки - 3.6.2 Требование к удаленному подключению - Исполнитель в рамках развития (модернизации) Системы осуществляет удаленное подключение к аппаратному комплексу, на котором развернута Система с соблюдением текущего Законодательства Российской Федерации и информационной безопасности. Для оказания Услуг на вычислительных мощностях Заказчика, Исполнитель обязан организовать за свой счет подключение к защищенной сети передачи данных Государственного заказчика. Защищенная сеть передачи данных построена на базе аппаратного-программного комплекса шифрования «ViPNet». - - Значение характеристики не может изменяться участником закупки - 3.6.3 Обеспечение сохранности информации при авариях - Для обеспечения сохранности информации на серверах, на которых размещена Система, должна быть предусмотрена возможность: 1. периодического резервного копирования базы данных Системы; 2. восстановления данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбои операционной систем и др.); 3. восстановления данных при сбоях в работе сетевого программного и аппаратного обеспечения. Резервные копии базы данных Системы хранятся вне информационных ресурсов Системы и находятся в хоне ответственности Заказчика. - - Значение характеристики не может изменяться участником закупки - 3.6.4 Требования к патентной чистоте - Патентная чистота Системы и ее частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации. Без увеличения цены Контракта Исполнитель обязан передать Государственному заказчику права на использование охраняемых результатов интеллектуальной деятельности, права на которые принадлежат подрядчику (исполнителю) и которые использовались при оказании Услуг по Контракту, в объеме, необходимом для использования Заказчиком результатов оказанных Услуг по Контракту по их целевому назначению и в соответствии с условиями Контракта на весь срок действия использованных исключительных прав или на иной срок, установленный Заказчиком. Исполнитель передает Государственному заказчику указанные права посредством заключения лицензионного (сублицензионного) договора. Исполнитель обязан передать исходные коды, разработанные в ходе оказания Услуг программ для электронных вычислительных машин (ЭВМ) и дистрибутивы, сопровождая передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимости, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. В случае использования при оказании Услуг по Контракту программ для электронных вычислительных машин (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передаются права на их использование (исполнение), должны обеспечить отсутствие ограничений, препятствующих использованию результатов работ по их назначению. Использование при модернизации программ, принадлежащих исполнителю и/или третьим лицам, допускается только с согласия Заказчика. При оказании Услуг по настоящему Техническому заданию Исполнитель должен гарантировать соблюдение авторских, исключительных и иных прав на объекты интеллектуальной собственности третьих лиц. - - Значение характеристики не может изменяться участником закупки - При использовании в Системе программ (программных комплексов или модулей), разработанных третьими лицами, условия, на которых передается право на использование (исполнение) этих программ, не должны накладывать ограничений, препятствующих использованию Системы по ее прямому назначению - 4 СОСТАВ И СОДЕРЖАНИЕ УСЛУГ - В рамках обязательств по настоящему ТЗ Исполнитель должен оказать Услуги по развитию (модернизации) Системы с передачей прав на ПО (модернизированное программное обеспечение). Исполнитель оказывает Услуги в соответствии с требованиями Государственного заказчика, приведенными в разделе 3 настоящего ТЗ 1 Разработка ЧТЗ В течение 30 рабочих дней с момента заключения Контракта, Итоговые документы - Согласованное ЧТЗ. 2 Развитие (модернизация) Системы в соответствии с требованиями, представленными в п. 3 настоящего ТЗ С момента заключения Контракта по 30.09.2026 (включительно), Итоговые документы - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор - Документ о приемке (акт оказанных Услуг). - - Значение характеристики не может изменяться участником закупки - 5.1 Виды и объем испытаний систем - Система подвергается следующим видам испытаний: Приемочные испытания. Состав, объем и методы приемочных испытаний Системы определяются документом «Программа и методика приемочных испытаний» (далее - ПМИ). Исполнитель разрабатывает и передает на утверждение Заказчику ПМИ в срок не позднее 10 рабочих дней до даты окончания оказания услуг по Контракту. Заказчик рассматривает и, в случае отсутствия замечаний, утверждает ПМИ в течение 5 рабочих дней со дня предоставления Исполнителем. Проведение приемочных испытаний включает: 1) Испытания Системы на соответствие требованиям настоящего ТЗ в соответствии с программой и методикой приемочных испытаний, разработанной Исполнителем и утвержденной Заказчиком; 2) Анализ результатов устранения недостатков, указанных в акте о завершении испытания; 3) Оформление Исполнителем и подписание Заказчиком акта о приемке Систем в эксплуатацию. - - Значение характеристики не может изменяться участником закупки - 6 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - Полный перечень документации, предъявляемых по завершению оказания Услуг включает: - ЧТЗ; - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор; - Структурированный документ о приемке оказанных Услуг в электронном виде путем размещения в ЕИС. Документация должна предоставляться Заказчику на машинных носителях (флеш-диск или передана ссылка для скачивания). Документация, представленная в электронном виде, должна быть выполнена в формате *pdf *docx. Формат предоставления документации определяется Заказчиком. Документация должна быть выполнена на русском языке, за исключением официальных наименований используемого программного и технического обеспечения. - - Значение характеристики не может изменяться участником закупки - 7 ОБЪЕМЫ И СРОКИ ГАРАНТИЙ КАЧЕСТВА - Исполнитель гарантирует, что результаты оказанных Услуг соответствуют требованиям, установленным в Контракте, обязательным нормам и правилам, регулирующим данную деятельность (ГОСТ, ТУ), а также иным требованиям законодательства Российской Федерации, действующим на момент оказания услуг. Качество оказываемых Услуг должно соответствовать действующим нормам и техническим условиям, безопасности жизни и здоровья, а также иным требованиям сертификации, безопасности (санитарным нормам и правилам, государственным стандартам и т.п.), лицензирования, если такие требования предъявляются действующим законодательством РФ или настоящим Контрактом к данному виду Услуг. Гарантийный срок на результаты оказанных Услуг составляет 12 (двенадцать) месяцев с даты подписания Заказчиком документа о приемке оказанных Услуг. Под гарантией понимается устранение Исполнителем своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки оказанных услуг. Если в период гарантийного срока обнаружатся недостатки, то Исполнитель (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, согласованные Сторонами и зафиксированные в акте с перечнем выявленных недостатков и сроком их устранения. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Исполнитель гарантирует возможность безопасного использования результата оказанных Услуг по назначению в течение всего гарантийного срока. - - Значение характеристики не может изменяться участником закупки - Перечень условных обозначений, терминов и сокращений. - API (англ. Application Program Interface) Программный интерфейс для взаимодействия компонентов программного обеспечения CSV-ФАЙЛ Файл в формате CSV (англ. Comma-Separated Values — значения, разделенные запятыми), предназначенном для представления табличных данных. Строка таблицы соответствует строке текста в файле, которая содержит одно или несколько полей, разделенных запятыми или другими заданными разделителями Drag-and-drop Способ оперирования элементами интерфейса (как графическим, так и текстовым, где элементы графического пользовательского интерфейса реализованы при помощи псевдографики) с применением манипулятора «мышь» или сенсорного экрана. DATAMART STUDIO Приложение для установки и настройки витрин данных и СУБД ETL Компонент информационной системы, реализующий сервисы извлечения, преобразования, очистки и загрузки данных HTTP Протокол прикладного уровня передачи (англ. HyperText Transfer Protocol). HTTPS Расширение протокола HTTP для поддержки шифрования в целях повышения безопасности (англ. HyperText Transfer Protocol Secure). Low-code Подход к созданию, настройке и модификации систем с минимальным использованием ручного программирования. REST (англ. Representational state transfer) — архитектурный стиль взаимодействия компонентов распределенного приложения в сети REST API Набор правил, по которым различные программы могут взаимодействовать между собой и обмениваться данными с помощью протокола http REST-Uploader Сервис витрины данных для асинхронной загрузки табличных данных (загрузка CSV, удаление, проверка статуса, отчет ФЛК) из сторонних источников с использованием способа взаимодействия REST API DTM-Uploader Сервис витрины данных для бинарных файлов-вложений (загрузка/удаление в S3) из сторонних источников с использованием способа взаимодействия REST API Web-браузер Программное обеспечение для обработки и вывода разных составляющих веб-страницы и предоставление интерфейса между веб-сайтом и его посетителем. - - Значение характеристики не может изменяться участником закупки - Web-интерфейс Web-страница или совокупность web-страниц, предоставляющая пользовательский интерфейс для взаимодействия с сервисом или устройством посредством протокола HTTP и web-браузера. Web-страница Документ или информационный ресурс, доступ к которому осуществляется с помощью web-браузера. XML eXtensible Markup Language, расширяемый язык разметки. XSD XML Schema definition - язык описания структуры XML документа. Агент ПОДД СМЭВ/ Агент СМЭВ 4 Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающие сопряжение Витрин данных с ПОДД СМЭВ БД База данных Бизнес-правила Набор условий, критериев, направленных на управление бизнес-сценарием Бизнес-процесс Набор непрерывно выполняемых мероприятий, пользователями Системы, по действиям и событиям бизнес-сценария с целью получения результата при выполнении Бизнес-сценарий Описание логики выполнения автоматизируемого процесса в Системе Вид сведений/ВС Вид сведений представляет собой комплект документации, определяющий технические требования и особенности предоставления конкретных сведений в СМЭВ. Витрина данных Компонент информационных систем органов и организаций государственного сектора, представляющий собой комплекс программных и технических средств, обеспечивающий загрузку, хранение и предоставление государственных данных из информационных систем органов и организаций государственного сектора другим органам и организациям государственного сектора с использованием ЕИП НСУД и посредством СМЭВ для предоставления государственных и муниципальных услуг, исполнения государственных и муниципальных функций в электронной форме. При создании витрин данных обычно применяется ТПО ВД. ГЕОП Государственная единая облачная платформа ГОСТ Государственный стандарт ЕИП НСУД, ФГИС «ЕИП НСУД» Федеральная государственная информационная система «Единая информационная платформа национальной системы управления данными» Оператор ЕИП НСУД – Минцифры России - ЕПГУ Единый портал государственных и муниципальных услуг (функций) http://gosuslugi.ru ЕСИА Федеральная государственная информационная система «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», определенная в постановлении Правительства Российской Федерации от 28 ноября 2011 г. №977. ИС Информационная система ИС-источник, источник Информационная система субъекта РФ, содержащая сведения, подлежащие размещению на региональный витрине данных ОИВ Орган исполнительной власти ОЗУ Оперативное запоминающее устройство – оперативная память – энергозависимая часть системы компьютерной памяти, в которой во время работы компьютера хранится выполняемый машинный код (программы), а также входные, выходные и промежуточные данные, обрабатываемые процессором. ОМСУ Органы местного самоуправления ОС Операционная система ПО Программное обеспечение Портлет Подключаемый, сменный компонент пользовательского веб-интерфейса. Региональная витрина данных, РВД/ компонент региональной информационной системы субъекта РФ, размещенный на ГЕОП. РОИВ Региональные органы исполнительной власти СМЭВ Система межведомственного электронного взаимодействия Система Автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» СУБД Система управления базами данных. ТЗ Техническое задание ФЗ Федеральный закон ФЛК Форматно-логический контроль ФТТ Функциональные и технические требования по обеспечению взаимодействия с витринами данных, развернутыми на ГЕОП (приложение к письму Минцифры России от 21.04.2026 №ГБ-П30-35951) ЧТЗ Частное техническое задание ЭП Электронная подпись - Приложение №1 1.10 Подсистема «Журналирование» - Подсистема «Журналирования» предназначена для хранения и отображения сведений о событиях Системы. Подсистема состоит из следующих модулей: - модуль «Аудит действий пользователя»; - модуль «Журнал авторизации». 1.10.1 Модуль «Аудит действий пользователя» Модуль «Аудит действий пользователя» предоставляет возможность просматривать все события, которые происходят в Системе в рамках созданного бизнес-процесса. Модуль обеспечивает следующие функциональные возможности: - аудит действий пользователя: • регистрация действий пользователя, совершенных в бизнес-процессе; • просмотр журнала действий пользователей; • просмотр информации о событии с указанием времени, пользователя, типа и подтипа сущности, над которым было совершено действие, описание изменений со старым и новым значением. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала действий в файл в форматы .xlsx, .pdf. 1.10.2 Модуль «Журнал авторизации» Модуль «Журнал авторизации» обеспечивает фиксирование действий пользователей в части осуществления входа (выхода) в (из) Системы. Модуль обеспечивает следующие функциональные возможности: - аудит событий входа и выхода из Системы, с указанием: • тип события: вход через локальную авторизацию (логин / пароль), вход через ЕСИА, вход через ЕСИА по сертификату, выход пользователя из Системы; • дата события; • имя пользователя. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала авторизации в файл в форматы .xlsx, .pdf. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.11 Компонент «Agent» - Данный компонент обеспечивает минимизацию зависимости от типов и версионности обозревателей при использовании механизмов наложения подписи. Компонент «Агент» позволяет осуществлять подписание электронных запросов в сторону СМЭВ без использования технологии интерфейса подключаемых модулей Netscape (NPAPI). - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.12 Компонент «Гарантированная доставка» - Компонент «Гарантированная доставка» обеспечивает организацию программной очереди из сформированных пользователями Системы запросов и не доставленных до получателя, их отправку в автоматическом режиме без участия пользователя Системы. Потребность в такой функции компонента «Гарантированная доставка» возможна в случаях возникновения отказов в работе СМЭВ, сервиса – получателя запроса или каких-либо других проблемах со связью между получателем и сервером Системы. Особенностями алгоритма работы блока являются: Первичная пятикратная непрерывная отправка запроса в сторону Поставщика в рамках пользовательского интерфейса. Данная особенность минимизирует процент недоставленных до Поставщика запросов по причине временной загруженности сервиса – Поставщика сведений. При неудачной первичной отправке запроса Поставщику сведений запрос переходит в статус «Отправляется». Последующие попытки отправки запроса осуществляются по следующим правилам: - первые пять минут после создания - раз в 30 секунд; - последующий час – раз в пять минут; - далее раз в 30 минут в течении двух дней; после чего запрос исключается из очереди на отправку и переводится в статус «Сбой при отправке». При неудачной первичной попытке отправки запроса все последующие, вплоть до исключения запроса из очереди на отправку, также происходят по принципу пятикратной непрерывной отправки. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.3 Подсистема «Реестр записей бизнес-процесса» - В подсистеме «Реестр записей бизнес-процесса» отображается перечень обращений по созданному бизнес-процессу в виде записей, с которыми пользователь Системы может работать на соответствующем этапе бизнес-процесса в зависимости от своей роли в Системе. Для удобства работы с записями реестра необходимо реализовать систему фильтрации и сортировки по всем элементам реестра. Обеспечена возможность выгрузки реестров в файлы формата .xlsx и .pdf. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.4 Подсистема взаимодействия со СМЭВ - 8) настройка возможности подписания запроса ЭП-СП; 9) настройка выбора среды СМЭВ 3 (тестовая или продуктивная), по которой будет происходить опрос; 10) дублирование видов сведений для осуществления настройки подписания ВС несколькими подписями; 11) добавление к виду сведений шаблона печатных форм в формате jrxml. - подключение приема в подсистему входящих запросов по конкретным ВС, по которым Система выступает в качестве поставщика; - создание регламентированных запросов к витринам посредством СМЭВ 4 обработчика, с возможностью создания атрибутов запроса, указание мнемоники витрины и запроса, версии; - возможность ручной проверки очереди обработки заявок. 1.4.2 Модуль «СМЭВ-адаптер» Модуль «СМЭВ-адаптер» осуществляет взаимодействие со СМЭВ в рамках приема входящих запросов ВС и ответов, на исходящие из Системы запросов, а также в рамках отправки исходящих запросов ВС и ответов на входящие запросы. Для обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4 реализована техническая возможность использовать Агент ПОДД СМЭВ на подготовленных мощностях и развернутом ПО. Модуль с заданной периодичностью опрашивает указанные адреса ВС на наличие входящих запросов и добавлять их в Систему для дальнейшей обработки и отправки ответа, а также обеспечивать отправку XML-запроса ВС по указанному адресу в СМЭВ. Модуль обеспечивает гарантированную доставку запросов, за счет механизма повторных вызовов электронных сервисов при сбоях. Модуль обращается к установленному в Системе специальному контейнеру ключа ведомства с защищенными файлами сертификатов, для получения электронной подписи, необходимой для принятия входящих запросов и отправки исходящих запросов (в модуле также должна содержаться информация о владельце данного ключа) в зависимости от ведомства – ответчика на запрос и ведомства-инициатора исходящего запроса. В модуле фиксируется история всех запросов с возможностью просмотра следующих параметров: - - Значение характеристики не может изменяться участником закупки - Подсистема состоит из следующих модулей: - модуль «Конструктор запросов»; - модуль «СМЭВ-Адаптер»; 1.4.1 Модуль «Конструктор запросов» Модуль «Конструктор запросов» обеспечивает возможность осуществления настройки видов сведений (далее – ВС), используемых в рамках функционирования Системы, а также преобразование переданного XML-запроса в JSON и преобразование из JSON в XML-запрос. Модуль выполняет следующие функции: - ведение реестра заявок – данных, которыми Система обмениваемся с другими системами через СМЭВ, для просмотра необходимой информации о входящих и исходящих межведомственных запросах. Заявка должна содержать атрибуты запроса, атрибуты ответа, а также сведения о наличии ошибок при отработке запроса. В реестре должна быть реализована возможность фильтрации по типу запроса (входящий, исходящий), ответственному ведомству, ВС, статусу заявки, дате создания и дате ответа по заявке. - выгрузка реестра заявок в файл формата .xlsx; - формирование исходящих запросов и ответов на входящие запросы в формате XML для передачи в модуль, а также преобразование входящего запроса или ответа из формата XML в формат JSON; - ведение реестров ведомств – департаментов, к которым Система обращается для получения каких-либо сведений, подключенных к Системе, через СМЭВ; - ведение библиотеки ВС со следующими функциональными возможностями: 1) возможность создания адаптеров к ВС СМЭВ 3 с указанием общих параметров адаптера (название сведений, версия сведений, идентификатор класса, тип запроса, источник поступления запросов или передачи ответов); 2) импорт XSD-схемы ВС (с описанием необходимых наборов полей) и генерация форм запроса и ответа; 3) экспорт описания наборов полей в формате JSON; 4) импорт архива описания наборов полей в формате JSON; 5) редактирование форм запроса и ответа ВС; 6) фильтрация реестра по типу запроса (входящий, исходящий), ответственному ведомству и названию сведения; 7) выбор ЭП-ОВ, которой будет подписываться запрос; - - номер запроса с возможностью перехода просмотра статуса сообщения в ЛК УВ; - дата запроса; - дата ответа на запрос; - статус запроса; - идентификатор (messageId) запроса; - текст запроса в формате XML; - текст ответа в формате XML; - SOAP-пакеты. В модуле реализована возможность опроса очереди СМЭВ по пространству имен (namespace) ВС. Для возможности просмотра ошибок, которые имеются в работе СМЭВ 3 или по определенному виду сведений реализован журнал ошибок при взаимодействии со СМЭВ. В журнале выводятся следующие ошибки с указанием наименования вида сведений, даты блокировки, даты разблокировки: - Ошибка подключения к веб-сервису СМЭВ 3; - Ошибка подписания сообщения определенной подписью; - Ошибка отправки сообщения - доступ запрещен для определенной подписи; - Ошибка подписания сообщения крипто-провайдером; - Ошибка добавления сообщения в очередь ответчика - очередь переполнена; - Ошибка отправки сообщения - вид сведений недоступен для определенной подписи; - Ошибка СМЭВ. - Приложение №1 1.5 Подсистема «Реестр исходящих запросов» - Подсистема обеспечивает возможность обмена данными с ФОИВ, РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки запросов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Поставщику сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает возможность отправки запроса в витрину данных, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ версии 4. В подсистеме доступны запросы к витринам, которые были добавлены в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик», в статусе «Активный». Доступно добавление (подключение) новых витрин данных и активация запросов к ним в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.6 Подсистема «Реестр входящих запросов» - Подсистема обеспечивает возможность обмена данными с РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки ответов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Потребителю сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.7 Подсистема взаимодействия с ЕГР ЗАГС - Дополнительно для реестра «Сведения о государственной регистрации смерти» обеспечена возможность следующих выгрузок: - выгрузка реестра по форме 1.2.1 риур; - выгрузка реестра по форме 1.2 риур; - Экспорт актов в XLSX; - Отчет по количеству актов; - Отчет для «ГАС Выборы» в формате txt; - - Значение характеристики не может изменяться участником закупки - Подсистема взаимодействия с ЕГР ЗАГС обеспечивает функционал по получению, обработке и использованию данных о записях актов гражданского состояния в составе следующих компонентов: - сведения о государственной регистрации смерти; - сведения о государственной регистрации установления отцовства; - сведения о государственной регистрации перемены имени; - сведения о государственной регистрации заключения брака; - сведения о государственной регистрации расторжения брака; - сведения о государственной регистрации рождения. Для получения сведений ЗАГС подсистема использует библиотеку адаптеров, при этом взаимодействие Системы со СМЭВ должно происходить в качестве «Поставщика вида сведений» по следующему сценарию работы: Система, в соответствии с заданным интервалом времени, осуществляет опрос информационной системы Федеральной налоговой службы на наличие данных об актах гражданского состояния, через отправку запроса к соответствующим видам сведения СМЭВ 3.Х; В ответ на запрос Система получает набор запрашиваемых данных и направляет подтверждение получения запроса. В Системе осуществляется проверка оригинальности полученных данных, после чего записи, которые не сохранены в базе данных Системы или были обновлены в ЕГР ЗАГС будут добавлены и/или обновлены в локальных реестрах хранения информации ЕГР ЗАГС. Для использования данных, получаемых в результате взаимодействия с ЕГР ЗАГС, в Системе обеспечена возможность формирования реестров полученных актовых записей, включающих все поступившие записи. В Системе обеспечена возможность доступа для сотрудников к реестрам с возможностью просмотра и выгрузки записей, предназначенных только для ведомства сотрудника. Для удобства работы с записями реестра реализована система фильтрации и сортировки по всем элементам реестра. В Системе для всех реестров обеспечена возможность фильтрации по элементам реестра и выгрузки в файлы форматов: XLSX. - Приложение №1 1.8 Подсистема «Запись на прием» - По каждому учреждению допускается создание расписания, на основе которого Система будет генерировать слоты времени для записи на прием через ЕПГУ. Запись о расписании представляет собой правило генерации слотов времени, которые будет видеть заявитель на ЕПГУ при бронировании времени приема. В Системе правило расписания должно состоять из следующих атрибутов: -наименование: задается произвольное название правила; - подразделение: выбор из справочника подразделений учреждения; - количество окон: указывается количество одновременно принимающих операторов; - дата (и время) начала: указывается дата начала действия расписания; указывается время начала рабочего дня; - время приема: длительность временного интервала; - дата (и время) окончания: указывается дата окончания действия расписания; указывается время окончания рабочего дня; - дни недели: указываются рабочие дни недели. - - Значение характеристики не может изменяться участником закупки - Приложение №1 1.9 Подсистема «Аналитика» - В аналитическом модуле отражаются статистические показатели межведомственных запросов: - количество обработанных входящих запросов; - количество обработанных исходящих запросов. Реализованы 10 готовых форм отчетов по исходящим запросам: 1) Потребители и сведения – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 2) Потребители и поставщики – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование поставщика вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 3) Потребители и поставщики (верхнеуровневый) – аналогично п.2, но количество запросов суммируется по верхнеуровневым организациям. 4) Рейтинг поставщиков – со следующей информацией: - Наименование поставщика вида сведений; - Всего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 5) Рейтинг потребителей – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - сего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 6) Рейтинг пользователей – со следующей информацией: - ФИО сотрудника; - Наименование ведомства; - Всего запросов. 7) Активность по месяцам – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование ведомства-поставщика сведений; - Месяц; - Всего запросов. - - Значение характеристики не может изменяться участником закупки - 8) Общая статистика – со следующей информацией: - Внутренний идентификатор запроса; - Messageid запроса; - Дата формирования запроса; - Дата изменения запроса; - Автор запроса; - Статус запроса; - Наименование ВС; - Поставщик; - Ведомство-потребитель. 9) Внутрирегиональные запросы – со следующей информацией: - Внутренний идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус; - Потребитель; - Наименование сведений; - Ведомство-поставщик; - Количество дней на обработку; - Обработан (в срок/истек срок). 10) Внутрирегиональные запросы (верхнеуровневый) – аналогично п.9, но с указанием верхнеуровневых организаций. - Реализована форма отчета по входящим запросам со следующей информацией: - Идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус запроса; - Потребитель; - Наименование ВС; - ОКТМО; - Поставщик; - Ведомство-поставщик. - Приложение №1 к техническому заданию «Описание функциональных характеристик программного обеспечения» содержит перечень функциональных возможностей программного обеспечения «ИС.МЭВ» (Далее – ПО). - Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица. Сценарий включает следующие шаги: 1) пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА». 2) Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа. 3) ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь ещё не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации. 4) когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений. 5) если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код. 6) Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код. 7) ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации. 8) Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным. После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа. - - Значение характеристики не может изменяться участником закупки - - Стандартные компоненты: • текстовое поле – универсальное поле для хранения строковых данных в одной строке; • электронная почта – поле для ввода электронной почты (email адреса) с автоматической проверкой корректности введенного адреса; • текстовая область – расширяемая (вручную или автоматически) область для хранения строковых данных, занимающих несколько строк; • номер телефона – поле для ввода номер телефона с предустановленной маской для проверки корректности введенного номера; • дата / время – поле для ввода даты и/или времени в заданном в настройках компонента формате. В компоненте предусмотрены выбор даты и времени с помощью виджета «Календарь – время» и ограничение вводимых (выбираемых) даты или времени; • флажок» – специальное поле, пребывающее в двух состояниях: «Установлен» (истина), «Не установлен» (ложь); • выпадающий список – специальное поле для выбора значения (значений) из определенного в настройках компонента списка возможных значений, в том числе из справочника; • радиокнопка – набор радиокнопок (их количество, название и значение изменяются в настройках), предназначен для выбора только одного из возможных вариантов; • файл – специальное поле для хранения и загрузки файлов различных типов, обладает обширной конфигурацией от ограничения размера загружаемых файлов до предпросмотра некоторых файлов в новой вкладке браузера; - 1.2.4.3 Подмодуль «Конструктор критериев экранных форм» Подмодуль «Конструктор критериев экранных форм» позволяет задавать условия выполнения действий (переходов) между экранными формами. Требования для выполнения критерия зависит от компонентов заявки, расположенных на экранной форме. Данный модуль разграничивает выполнение условий по критерию, задавать несколько значений или выполнять определенное из заданного перечня. 1.2.5 Модуль печатных форм Модуль печатных форм предоставляет возможность внесения электронных форм документов (печатных форм) в формате, используемых в Системе на определенном шаге бизнес-процесса. Модуль предоставляет возможность заполнения полей электронной формы документа из компонентов заявки, расположенных на экранной форме. Электронные формы документов (печатные формы), загружаемые в Систему, разрабатывваются в свободно распространяемом ПО. - 1.2.4.2 Подмодуль «Конструктор макетов экранных форм» Подмодуль «Конструктор макетов экранных форм» предоставляет следующие возможности: - выбор формы модели – должен содержать все созданные в модуле «Конструктор модели бизнес-процесса» экранные формы для возможности выбора определенной экранной формы для просмотра и/или редактирования; - назначение роли – должен обеспечивать разграничение доступа к экранной форме пользователям, текущая роль которых не входит в число выбранных в списке ролей; - загрузка компонентов из подмодуля «Конструктор компонентов заявки» – должен обеспечивать загрузку шаблона экранной формы, в качестве содержимого выбранной экранной формы; - очистить компоненты – удаление компонентов выбранной экранной формы; - копирование экранной формы – копирование компонентов экранной формы для вставки на других формах; - вставка формы с заменой – должен позволять вставить скопированную экранную форму с полной заменой содержимого экранной формы, на которой вызывается вставка; - вставка формы с сохранением существующей – должен позволять вставить скопированную экранную форму, как дополнение к содержимому экранной формы, на которой вызывается операция вставки. - сохранение экранной формы – сохранение всех изменений только на выбранной экранной форме; - вернуть первоначальную форму – должен позволять отменить не сохраненные изменения содержимого экранной формы; - использование данных модуля «Аудит действия пользователя» – должен позволять при работе с записью по БП на выбранной экранной форме нажать действие «Перейти к журналу действий» и просмотреть журнал действий (кто, когда и какие изменения вносил по данной записи БП) по данной записи БП; - использование панели компонентов – отображение категоризированного списка компонентов, созданных в модуле «Конструктор компонентов заявки». Для размещения компонентов на определенной экранной форме должен быть использован метод Drag-and-drop. - - использование рабочей области конструктора – должен позволять размещать, редактировать, перемещать и взаимодействовать с различными компонентами экранной формы. Структура экранной формы и представление данных визуализируется посредством использования метода drag-and-drop. - - Дополнительные компоненты: • динамический список – набор записей (строк), содержащих один и тот же набор компонентов, с возможностями неограниченного (по умолчанию) добавления таких записей, а также их изменения и удаления; • сетка данных – аналогичен динамическому списку, однако, записи в данном компоненте свернуты, а значения компонентов отображаются в упрощенном виде (в виде текста); • ссылка – поле для ввода ссылки с автоматической проверкой корректности введенной ссылки; • адрес – специальное поле для хранения адреса, имеет возможности ручного ввода или поиск посредством сервиса ФИАС; • группа флажков – набор флажков (их количество, название и значение изменяются в настройках), которые могут пребывать в двух состояниях: «Установлен» (истина), «Не установлен» (ложь). Предназначен для выбора от одного до максимально возможного количества вариантов; • кнопка – представляет собой кнопку, к которой можно привязать любое действие, расположенное в модуле «Конструктор действий». Возможность внесения изменений в настройки компонентов заявки должна быть предоставлена на любом этапе бизнес-процесса в состоянии редактирования. - ИС.МЭВ – программное обеспечение, предназначенное для организации межведомственного электронного взаимодействия органов исполнительной власти, органов местного самоуправления и организаций, участвующих в предоставлении государственных, муниципальных услуг, услуг иных организаций, осуществляющих функции, связанные с предоставлением государственных, муниципальных услуг, и услуг иных организаций с соблюдением юридической значимости при реализации иных полномочий, возложенных на эти органы и организации нормативными правовыми актами. ПО состоит из электронных сервисов межведомственного взаимодействия в целях обмена сведениями, требуемыми в процессе предоставления государственных/муниципальных услуг, а также выполнения иных функции и услуг, осуществляемых в рамках межведомственного взаимодействия. ПО внесено единый реестр российских программ для электронных вычислительных машин и баз данных (Реестровая запись №13268 от 11.04.2022 г.). ОБЩАЯ ИНФОРМАЦИЯ Доступ к функциональным возможностям ПО предоставляется через web-браузер. ПО имеет следующие функциональные возможности: - прием и обработка заявлений с ЕПГУ / Личное обращение, интеграция с ЕЛК; - добавление адаптеров видов сведений СМЭВ 3; - обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4; - интеграция с конструктором цифровых регламентов КЦР; - взаимодействие органов власти с ЕГР ЗАГС; - взаимодействие органов власти с ФССП; - формирование печатных форм документов, обмен исполнительными документами с использованием ЭЦП; - настройка ролевой модели доступа. - 1.2.3 Модуль «Конструктор событий» Модуль «Конструктор событий» предназначен для создания статусов обработки заявления и рассылки уведомлений, предназначенных для пользователей Системы, о наступлении определенного события в бизнес-процессе. Основные способы информирования: - системное уведомление – краткое сообщение, опубликованное в Системе для пользователя; - e-mail сообщения - поступающие на адрес электронной почты пользователя. В модуле должна быть возможность для созданного статуса добавить срок обработки, с возможностью указания цветовой индикации записи заявления при наступлении события. 1.2.4 Модуль «Конструктор экранных форм» Модуль «Конструктор экранных форм» состоит из следующих подмодулей: - конструктор компонентов заявки; - конструктор макетов экранных форм; - конструктор критериев экранных форм. 1.2.4.1 Подмодуль «Конструктор компонентов заявки» В подмодуле «Конструктор компонентов заявки» предоставлена возможность использовать и настраивать определенный компонент заявки на экранной форме. Настройка компонентов заявки предусматривает следующие возможности: - создание компонентов; - указывать общие параметры компонента заявки (название, обязательность, маска и др); - указывать параметры по настройке зависимости между компонентами заявки; - указывать параметры по настройке автозаполнения компонентов заявки данными из ЛК. При создании компонентов заявки доступны следующее типы компонентов: - Подсистема администрирования Подсистема администрирования состоит из следующих модулей: - модуль управления пользователями и организациями; - модуль «Конфигурация системы». Подсистема администрирования доступна только для пользователей с ролью администратор системы. 1.1.1 Подсистема управления пользователями и организациями Модуль управления пользователями и организациями обеспечивает следующие функциональные возможности: - управление учетными записями пользователей Системы: • создание пользователей; • создание пользователей через импорт файла в формате xlsx; • редактирование атрибутов карточки пользователя; • отключение пользователей; • назначение пользователям ролей доступа к подсистемам и модулям; • создание групп пользователей; • просмотр списка пользователей; • поиск пользователей. - управление списком организаций Системы: • создание организаций; • редактирование атрибутов карточки организации; • отключение организации; • назначение / исключение пользователей к организации; • просмотр списка организаций; • хранение и редактирование древовидной структуры подразделений / организаций; • поиск организации. - реализация ролевого метода управления доступом субъектов доступа (пользователей) к объектам доступа на основе ролей субъектов доступа: • создание ролей доступа и определение прав доступа к подсистемам и модулям • редактирование атрибутов ролей; • назначение роли пользователю, группам пользователей; • удаление ролей доступа; • просмотр списка ролей; • поиск ролей. - просмотр списка активных сессий. 1.1.2 Модуль «Конфигурация системы» Модуль «Конфигурация системы» обеспечивает следующие функциональные возможности: - администрирование сервера: • контроль аппаратной части: объем использованной памяти, всего задействовано ОЗУ, предельный объем памяти; • управление кэшем: удаление кэша БД, сервлетов. - конфигурирование параметров Системы - Подсистема авторизации и аутентификации пользователей Доступ к функциям авторизации предоставляется только пользователям, успешно прошедшим процедуру регистрации. Подсистема обеспечивает следующие функциональные возможности: - обеспечение идентификации и аутентификации пользователей по специальным идентификаторам – именам учетных записей пользователей, обеспечение аутентификации пользователей с использованием паролей; - защита аутентификационной информации в процессе ее ввода для аутентификации от возможного использования лицами, не имеющими на это полномочий. Защита осуществляется путем исключения отображения для пользователя действительного значения аутентификационной информации. Вводимые символы пароля должны отображаться условными знаками «*»; - настройку политики блокировки учетной записи пользователя после неудачных попыток авторизации; - осуществление отключения пользователя от Системы при отсутствии активности. В случае неактивности пользователя более установленного промежутка времени происходит автоматическое завершение сессии. Дальнейшая работа возможна только после повторного входа в Систему. Данный функционал предназначен для повышения безопасности работы с Системой и предотвращения несанкционированного доступа в Систему; - исключение возможности установки пользователем по умолчанию аутентификационных данных для входа в систему; - запрет на использование пользователями определенного числа последних использованных паролей при создании новых паролей для предотвращения повторного использования старого пароля; - установление и проверка синтаксиса пароля: • задание минимальной сложности пароля с определяемыми требованиями к регистру, количеству символов, сочетанию букв верхнего и нижнего регистра, чисел и специальных символов; • задание регулярного выражения, используемого для проверки пароля пользователя. • задание срока действия пароля. - 1.2 Модуль «Конструктор бизнес-процессов» Подсистема «Конструктор бизнес-процессов» состоит из следующих модулей: - модуль «Конструктор модели бизнес-процесса»; - модуль «Конструктор действий»; - модуль «Конструктор событий»; - модуль «Конструктор экранных форм». При моделировании и автоматизации бизнес-процессов подсистема использует подход low-code, с возможностями, позволяющими автоматизировать бизнес-сценарий в единой цифровой среде за счет визуального редактора сквозных процессов. 1.2.1 Модуль «Конструктор модели бизнес-процесса» Модуль «Конструктор модели бизнес-процесса» позволяет моделировать диаграммы процессов любой сложности с большим количеством разветвлений, условий используя принятые бизнес-правила BPMN. Проектирование осуществляется посредством использования интуитивно понятных графических элементов, каждый из которых визуализирует определенный шаг процесса. Спроектированная модель является исполняемой в Системе. Администратор Системы может опубликовать (запустить) бизнес-процесс, либо деактивировать с целью внесения изменений. 1.2.2 Модуль «Конструктор действий» Модуль «Конструктор действий» отвечает за настройку действий (переходов) между мероприятиями, которые были созданы в модуле «Конструктор модели бизнес-процесса». Модуль предоставляет возможность настроить определенное действие, указать последовательность выполнения, задать условия перехода, установить правила автоматического выполнения шагов процесса или обработки. Стандартное действие Позволяет перейти на следующее мероприятие с изменением статуса (с проверкой заполнения обязательных полей) Удаление Позволяет удалить заявку Печать Позволяет вывести печатную форму, в рамках заявки Назад Позволяет перейти на следующее мероприятие с изменением статуса (без проверки заполнения обязательных полей) Сохранить Позволяет сохранить внесенные изменения в заявке

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

1 ОБЩИЕ СВЕДЕНИЯ - 1.2 Наименование Заказчика и Исполнителя Заказчик: Бюджетное учреждение Республики Алтай по эксплуатации радиорелейной линии связи «Эл Телком».. Исполнитель: определяется по результатам проведения конкурентной процедуры закупки в соответствии с Федеральным законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 1.3 Цели оказания Услуг Целью оказания услуг по развитию (модернизации) автоматизированной информационной системы предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее – Система) является реализация передачи в региональную витрину из региональных систем – источников данных, необходимых при оказании государственных услуг и для формирования отчетов, в соответствии с функционально-техническими требованиями согласно письму Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 21.04.2026 №ГБ-П30-35951 (далее – ФТТ) - - Значение характеристики не может изменяться участником закупки

1.4 Основание для оказания Услуг - - Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»; - Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; - Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; - Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи»; - Указ Президента Российской Федерации от 7 мая 2024 года № 309 «О национальных целях развития Российской Федерации на период до 2030 года и на перспективу до 2036 года»; - Постановление Правительства Российской Федерации от 8 сентября 2010 г. № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 10 июля 2013 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме»; - Постановление Правительства РФ от 24.10.2011 № 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». - Постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 15 апреля 2014 года № 313 «Об утверждении государственной программы Российской Федерации «Информационное общество»; - Постановление Правительства Российской Федерации от 25 декабря 2024 года № 1886 «О внесении изменений в постановление Правительства Российской Федерации от 15 апреля 2014 г. № 313»; - - Значение характеристики не может изменяться участником закупки

- Постановление Правительства РФ от 01.11.2025 № 1733 «О внесении изменений в постановление Правительства Российской Федерации от 15.04.2014 г. № 313»; - Постановление Правительства РФ от 01.03.2022 № 277 «О направлении в личный кабинет заявителя в федеральной государственной информационной системе «Единый портал государственных и муниципальных услуг (функций)» сведений о ходе выполнения запроса о предоставлении государственной или муниципальной услуги, заявления о предоставлении услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг», а также результатов предоставления государственной или муниципальной услуги, результатов предоставления услуги, указанной в части 3 статьи 1 Федерального закона «Об организации предоставления государственных и муниципальных услуг»; - Постановление Правительства Российской Федерации от 6 июля 2015 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; - Постановление Правительства Российской Федерации от 8 июня 2011 года № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; - Постановление Правительства Российской Федерации от 8 сентября 2010 года № 697 «О единой системе межведомственного электронного взаимодействия»; - Постановление Правительства Российской Федерации от 14 мая 2021 года № 733 «Об утверждении Положения о федеральной государственной информационной системе «Единая информационная платформа национальной системы управления данными» и о внесении изменений в некоторые акты Правительства Российской Федерации»;

- Распоряжение Правительства Российской Федерации от 29 июня 2012 года № 1123-р «О перечне сведений, находящихся в распоряжении государственных органов субъектов РФ, органов местного самоуправления, территориальных государственных внебюджетных фондов»; - Функциональные и технические требования по предоставлению данных из информационных систем – источников данных в региональную витрину данных (далее – ФТТ). - Приказ ФСТЭК России от 11.04.2025 г. № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» - Приказ ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». - Приказ ФСБ России от 24.10.2014 № 524.

2.1 Общая характеристика - Исполнитель должен по требованию Заказчика предъявить документы, подтверждающие законное право на указанные в настоящем Техническом задании программное обеспечение «ИС.МЭВ», а именно: а) для участника, являющегося правообладателем – копия свидетельства об официальной регистрации программ или копия договора об отчуждении исключительного права на программу с копией документа, подтверждающего государственную регистрацию отчуждения исключительного права; б) для участника, которому права на программы переданы автором или иным правообладателем – копия действующего лицензионного (сублицензионного) договора о передаче прав на модификацию и иное использование программ, заключенного в письменной форме и устанавливающего объем и способы использования программ; в) копия действующего сертификата, выданного Правообладателем участнику закупки, по которому участник имеет право осуществлять услуги по распространению, внедрению, модификации и сопровождению программного обеспечения от своего имени с соблюдением авторских прав Правообладателя. Основание: Раздел VII ГК РФ "Права на результаты интеллектуальной деятельности и средства индивидуализации". Описание функционала программного обеспечения «ИС.МЭВ» приведено в Приложении №1. - - Значение характеристики не может изменяться участником закупки

Объектом автоматизации, выбранным Заказчиком в качестве опорной системы для реализации процесса централизованного сбора и отправки данных в региональную витрину данных (далее – РВД), является автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» (далее - Система). В качестве технологической основы Системы используется программное обеспечение «ИС.МЭВ» (запись в Едином реестре российских программ для ЭВМ и баз данных 13268 от 11.04.2022 произведена на основании поручения Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 11.04.2022 по протоколу заседания экспертного совета от 04.04.2022 №410пр, ссылка https://reestr.digital.gov.ru/reestr/678288/). Заказчик располагает правом на использование программного обеспечения «ИС.МЭВ» на условиях простой неисключительной лицензии. Исполнитель в соответствии с настоящим Техническим заданием должен являться правообладателем указанного программного продукта либо иметь полномочия передавать право пользования на них Заказчику в порядке, установленном гражданским законодательством Российской Федерации.

2.2 Назначение системы - Система предназначена для: - Обеспечения качественной работы исполнительных органов Республики Алтай при предоставлении государственных и муниципальных услуг в электронном виде; - Организации межведомственного электронного взаимодействия между организациями-участниками при оказании государственных (муниципальных) услуг в электронном виде; - Обеспечения исполнения государственных функций Организациями-участниками; - Обеспечения получения гражданами и организациями преимуществ от применения информационных и телекоммуникационных технологий за счет обеспечения равного доступа к информационным ресурсам, развития цифрового контента, применения инновационных технологий, повышения эффективности государственного управления. Автоматизации процессов оказания ИО и ОМСУ Республики Алтай государственных и муниципальных услуг и перевода их в электронный вид на основе существующих административных регламентов (порядков) оказания услуг, требований действующего законодательства, в том числе для обработки обращений на получение государственных и муниципальных услуг республики Алтай, поступающих через Единую систему межведомственного электронного взаимодействия с Единого портала государственных услуг (функций); - Обеспечения межведомственного электронного взаимодействия ИО, ОМСУ Республики Алтай и подведомственных им учреждений, как внутрирегионального, так и с ФОИВ с ИО и ОМСУ других регионов; - Обеспечения взаимодействия с ЕГР ЗАГС для получения сведений о государственной регистрации актов гражданского состояния, содержащихся в ЕГР ЗАГС, и сведений о внесении исправлений или изменений в записи актов гражданского состояния, содержащиеся в ЕГР ЗАГС. - Мониторинга хода оказания в электронной форме государственных и муниципальных услуг, межведомственного электронного взаимодействия, сбора статистических данных об указанных выше процессах и подготовки аналитической информации для принятия управленческих решений, совершенствования информационной системы, порядка её эксплуатации. - - Значение характеристики не может изменяться участником закупки

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

3.2 Требования к развитию (модернизации) Системы в целях интеграции с региональной витриной данных - Исполнитель обязан оказать Услуги по развитию (модернизации) Системы, включая следующие задачи: 1. Обеспечить возможности выгрузки, трансформации и загрузки данных из Системы в РВД. В рамках данного пункта Исполнителю необходимо создать ETL-компонент, обеспечивающий: а) получение данных из ИС-источников, их трансформацию в соответствии с требованиями РВД и загрузку в РВД с использованием компонентов REST-Uploader и DTM-Uploader; б) мониторинг выполнения операций по загрузке и обработке данных в РВД; в) автоматическое выполнение выгрузки данных из Системы в РВД по заданному расписанию; г) настройку РВД на вычислительных мощностях, предоставленных Заказчиком. 2. Разработать и согласовать с Заказчиком частное техническое задание (далее – ЧТЗ), содержащее детализированные требования к реализации работ по интеграции Системы с РВД; 3. Провести нагрузочное тестирование, в том числе, выполнить работы, связанные с утверждением методики и созданием и (или) модернизацией инструментов для проведения нагрузочного тестирования. 4. Разработать техническую документацию, включающую описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности. Место размещения РВД определяется согласно соответствующим функциональным и техническим требованиям, доведенным Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации, и уточняется в рамках ЧТЗ. - - Значение характеристики не может изменяться участником закупки

3.2.1 Обеспечение возможности выгрузки, трансформации и загрузки данных из Системы в региональную витрину данных - В рамках оказания Услуг должен быть разработан и внедрен ETL-компонент, включающий: ­ ETL-модуль; ­ Модуль управления таблицами РВД; ­ Модуль клиентов РВД; ­ Модуль скриптов; ­ Модуль «Мониторинг операций с данными на РВД». - - Значение характеристики не может изменяться участником закупки

3.2.1.1 Требования к ETL-модулю - ETL-модуль должен обеспечивать получение данных из ИС-источников, их трансформацию в соответствии с установленными правилами и последующую загрузку в РВД. Допускается использование готовых ETL-решений, включенных в реестр российского программного обеспечения, и (или) программного обеспечения с открытым исходным кодом при условии соответствия всем требованиям настоящего Технического задания. ETL-модуль должен обеспечивать выполнение следующих функций: ­ прием данных из ИС-источников. Атрибутивный состав, типы данных и форматы полей должны соответствовать требованиям, приведенным в ФТТ; ­ трансформацию данных, включая: • преобразование данных в соответствии с установленными правилами (маппинг полей, агрегация и иные операции); • настройку критериев корректности, целостности и полноты данных для отдельных наборов данных; ­ загрузку данных в РВД с использованием компонентов REST-Uploader и DTM-Uploader. Должны поддерживаться следующие операции: • загрузка данных в таблицы РВД из CSV-файлов; • удаление данных из таблиц РВД; • получение и обработка результатов выполнения операций загрузки и удаления данных. В рамках ETL-модуль должно быть обеспечено автоматическое выполнение выгрузки данных в РВД по заданному расписанию. Для управления расписанием выгрузки ETL-модуль должен обеспечивать: ­ создание расписаний выгрузки; ­ редактирование расписаний выгрузки; ­ настройку перечня выгружаемых наборов данных (реестров); ­ настройку параметров подключения к РВД. Форматы взаимодействия с ИС-источниками, состав и описание наборов данных, критерии проверки данных, а также требования к хранению и архивированию данных и периодичность выгрузки данных в РВД должны быть определены в ЧТЗ. - - Значение характеристики не может изменяться участником закупки

3.2.1.2 Требования к модулю управления таблицами РВД - Модуль управления таблицами РВД должен обеспечивать создание и настройку таблиц РВД на основании метаструктуры, получаемой из ЕИП НСУД. Модуль должен обеспечивать выполнение следующих функций: ­ добавление новых таблиц; ­ создание таблиц посредством импорта SQL-файлов; ­ настройку параметров полей таблиц, включая: • определение типа поля; • настройку обязательности заполнения; • настройку признака уникальности значений; • установку ограничений на длину значений; • создание индексов - - Значение характеристики не может изменяться участником закупки

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

3.2.1.4 Требования к модулю скриптов - Модуль скриптов должен обеспечивать управление скриптами обработки данных, используемыми при загрузке данных в РВД. Модуль должен обеспечивать: ­ загрузку новых файлов скриптов; ­ выбор ранее загруженных файлов скриптов; ­ настройку параметров выполнения скриптов. Для каждого скрипта должна быть предусмотрена возможность указания: ­ точки входа – пути к функции, являющейся точкой запуска обработки; ­ параметров развертывания и запуска скрипта в ETL-модуле; ­ параметров потока обработки, включая путь к файлу, идентификатор клиента, идентификатор таблицы РВД и параметры обработки данных. - - Значение характеристики не может изменяться участником закупки

3.2.1.5 Требования к модулю «Мониторинг операций с данными на РВД» - Модуль «Мониторинг операций с данными на РВД» должен обеспечивать контроль выполнения операций обработки данных в РВД. Модуль должен обеспечивать выполнение следующих функций: ­ получение и обработку сообщений об ошибках, возникающих при выполнении операций с данными; ­ выполнение настроенных действий в зависимости от типа выявленной ошибки; ­ формирование отчетов о результатах выполнения операций с данными в РВД. Правила обработки ошибок, состав отчетов, формат их представления и порядок формирования должны быть определены в ЧТЗ. - - Значение характеристики не может изменяться участником закупки

3.2.2 Требования к разработке ЧТЗ - Исполнитель разрабатывает ЧТЗ и представляет его на согласование Заказчику в срок не более 30 рабочих дней с даты начала оказания услуг. ЧТЗ должно содержать: 1. полное описание требований к взаимодействию с РВД; 2. полное описание требований к мониторингу операций с данными на РВД; 3. полное описание наборов данных, выгрузка которых в РВД из Системы должна быть настроена в рамках выполнения работ, правил трансформации данных, параметров автоматического выполнения выгрузки данных в РВД; 4. требования к формату взаимодействия Системы с внешними источниками данных в целях выгрузки данных в РВД; 5. полное описание требований к ETL-модулю; 6. полное описание требований к развертыванию и настройке РВД; 7. перечень наборов данных, получаемых из внешних источников данных, их полное описание, критерии проверки корректности. Перечень наборов данных, включающих в себя также сведения для оказания государственных услуг и формирования отчетов, для которых в рамках оказания Услуг должна быть обеспечена выгрузка в РВД, формируется Исполнителем совместно с Заказчиком. Заказчик в течение 10 рабочих дней проверяет ЧТЗ на соответствие требованиям. Исполнитель должен провести предварительные мероприятия по настройке ETL-компонента с целью обеспечения возможности выгрузки, трансформации и загрузки данных из Системы в РВД. - - Значение характеристики не может изменяться участником закупки

3.2.3 Проведение нагрузочного тестирования, в том числе утверждение методики, создание и (или) модернизация инструментов для проведения нагрузочного тестирования - Исполнитель должен провести нагрузочное тестирование РВД. Целями нагрузочного тестирования являются: 1. Проверка предельных уровней нагрузки, при которых обеспечивается работоспособность, уровень ошибок не превышает допустимый согласно требованиям ФТТ. 2. Оценка влияния нагрузки на время отклика (время отправки ответов на запросы) согласно требованиям ФТТ. 3. Оценка стабильности работы под нагрузкой. 4. Выработка рекомендаций по возможному увеличению производительности. По результатам нагрузочного тестирования Исполнитель формирует отчет о проведении нагрузочного тестирования, включающий: 1. Базовую информацию: а) объект тестирования; б) конфигурация тестовой среды; в) сценарии тестирования; г) требования к производительности. 2. Результаты тестирования (по каждому из сценариев): а) числовые показатели в соответствии с параметрами, подлежащими мониторингу; б) выявленные проблемы в процессе тестирования. 3. Выводы: а) соответствие предъявляемым требованиям к производительности; б) возможные ограничения производительности и рекомендации по их устранению. - - Значение характеристики не может изменяться участником закупки

3.2.4 Разработка технической документации, включающей описание всех работ, выполняемых в рамках модернизации Системы с указанием их сложности - Исполнитель должен разработать отчеты и рабочую документацию, содержащую подробное описание работ, выполняемых в рамках модернизации Системы в целях интеграции с РВД, включающие в себя: 1) Отчет о работах, выполненных в рамках доработки (настройки) Системы и региональных информационных систем – источников данных и (или) модернизации их функциональности, с указанием сложности выполненных работ и содержащий проверку функций, описанных в разделе 3 ФТТ «Требования к Системе»; 2) Описание реализованных функций и (или) сценариев работы Системы; 3) Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; 4) Обновление эксплуатационной документации Системы; 5) Отчет о нагрузочном тестировании. - - Значение характеристики не может изменяться участником закупки

3.3 Требования к формату взаимодействия Системы с внешними источниками данных - В рамках оказания Услуг по развитию Системы должно быть обеспечено взаимодействие с внешними источниками данных в целях выгрузки данных в РВД, перечень ИС-источников представлен ниже. Наименование ИС-источника Многофункциональная региональная информационная система Республики Алтай: Соцзащита Разработчик ИС-источника Общество с ограниченной ответственностью Научно-производственная компания «КАТАРСИС» ИНН 7825103271 Владелец ИС-источника Министерство труда, социального развития и занятости населения Республики Алтай, Форматы взаимодействия, полное описание наборов и перечень данных должны быть описаны в ЧТЗ. Для обеспечения получения данных из ИС-источников Заказчик обеспечивает предоставление сетевой связности и необходимых доступов между ETL-компонентом и ИС-источниками. Предоставление доступов осуществляется по согласованию с операторами соответствующих информационных систем в срок не позднее 10 (десяти) рабочих дней с даты заключения Контракта. - - Значение характеристики не может изменяться участником закупки

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

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

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

3.4.4 Требования к методическому обеспечению - В рамках оказания Услуг по развитию (модернизации) Системы Исполнителем должны быть актуализированы следующие эксплуатационные документы: 1. руководство пользователя (в случае функциональных изменений процесса использования Системы); 2. руководство администратора (в случае функциональных изменений процесса использования Системы). - - Значение характеристики не может изменяться участником закупки

3.5.1 Требования к надежности - Общими требованиями к надежности Системы являются: 1. Система должна функционировать круглосуточно, в непрерывном режиме, кроме времени проведения работ по смене версий программного обеспечения, других профилактических работ по техническому обслуживанию, требующих остановку технических средств; 2. контроль целостности данных должен быть обеспечен на уровне СУБД; 3. выход из строя одной из подсистем не должен приводить к прекращению функционирования остальных подсистем, т.е. при этом должна обеспечиваться возможность выполнения функций всех оставшихся подсистем; 4. неправильные действия пользователей не должны приводить к возникновению аварийной ситуации в работе Системы; 5. должны быть минимизированы ошибки пользователей Системы, в том числе путем четкого разграничения прав доступа к Системе. - - Значение характеристики не может изменяться участником закупки

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

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

3.6.2 Требование к удаленному подключению - Исполнитель в рамках развития (модернизации) Системы осуществляет удаленное подключение к аппаратному комплексу, на котором развернута Система с соблюдением текущего Законодательства Российской Федерации и информационной безопасности. Для оказания Услуг на вычислительных мощностях Заказчика, Исполнитель обязан организовать за свой счет подключение к защищенной сети передачи данных Государственного заказчика. Защищенная сеть передачи данных построена на базе аппаратного-программного комплекса шифрования «ViPNet». - - Значение характеристики не может изменяться участником закупки

3.6.3 Обеспечение сохранности информации при авариях - Для обеспечения сохранности информации на серверах, на которых размещена Система, должна быть предусмотрена возможность: 1. периодического резервного копирования базы данных Системы; 2. восстановления данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбои операционной систем и др.); 3. восстановления данных при сбоях в работе сетевого программного и аппаратного обеспечения. Резервные копии базы данных Системы хранятся вне информационных ресурсов Системы и находятся в хоне ответственности Заказчика. - - Значение характеристики не может изменяться участником закупки

3.6.4 Требования к патентной чистоте - Патентная чистота Системы и ее частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации. Без увеличения цены Контракта Исполнитель обязан передать Государственному заказчику права на использование охраняемых результатов интеллектуальной деятельности, права на которые принадлежат подрядчику (исполнителю) и которые использовались при оказании Услуг по Контракту, в объеме, необходимом для использования Заказчиком результатов оказанных Услуг по Контракту по их целевому назначению и в соответствии с условиями Контракта на весь срок действия использованных исключительных прав или на иной срок, установленный Заказчиком. Исполнитель передает Государственному заказчику указанные права посредством заключения лицензионного (сублицензионного) договора. Исполнитель обязан передать исходные коды, разработанные в ходе оказания Услуг программ для электронных вычислительных машин (ЭВМ) и дистрибутивы, сопровождая передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимости, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. В случае использования при оказании Услуг по Контракту программ для электронных вычислительных машин (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передаются права на их использование (исполнение), должны обеспечить отсутствие ограничений, препятствующих использованию результатов работ по их назначению. Использование при модернизации программ, принадлежащих исполнителю и/или третьим лицам, допускается только с согласия Заказчика. При оказании Услуг по настоящему Техническому заданию Исполнитель должен гарантировать соблюдение авторских, исключительных и иных прав на объекты интеллектуальной собственности третьих лиц. - - Значение характеристики не может изменяться участником закупки

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

4 СОСТАВ И СОДЕРЖАНИЕ УСЛУГ - В рамках обязательств по настоящему ТЗ Исполнитель должен оказать Услуги по развитию (модернизации) Системы с передачей прав на ПО (модернизированное программное обеспечение). Исполнитель оказывает Услуги в соответствии с требованиями Государственного заказчика, приведенными в разделе 3 настоящего ТЗ 1 Разработка ЧТЗ В течение 30 рабочих дней с момента заключения Контракта, Итоговые документы - Согласованное ЧТЗ. 2 Развитие (модернизация) Системы в соответствии с требованиями, представленными в п. 3 настоящего ТЗ С момента заключения Контракта по 30.09.2026 (включительно), Итоговые документы - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор - Документ о приемке (акт оказанных Услуг). - - Значение характеристики не может изменяться участником закупки

5.1 Виды и объем испытаний систем - Система подвергается следующим видам испытаний: Приемочные испытания. Состав, объем и методы приемочных испытаний Системы определяются документом «Программа и методика приемочных испытаний» (далее - ПМИ). Исполнитель разрабатывает и передает на утверждение Заказчику ПМИ в срок не позднее 10 рабочих дней до даты окончания оказания услуг по Контракту. Заказчик рассматривает и, в случае отсутствия замечаний, утверждает ПМИ в течение 5 рабочих дней со дня предоставления Исполнителем. Проведение приемочных испытаний включает: 1) Испытания Системы на соответствие требованиям настоящего ТЗ в соответствии с программой и методикой приемочных испытаний, разработанной Исполнителем и утвержденной Заказчиком; 2) Анализ результатов устранения недостатков, указанных в акте о завершении испытания; 3) Оформление Исполнителем и подписание Заказчиком акта о приемке Систем в эксплуатацию. - - Значение характеристики не может изменяться участником закупки

6 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - Полный перечень документации, предъявляемых по завершению оказания Услуг включает: - ЧТЗ; - Описание реализованных функций и (или) сценариев работы Системы; - Описание внешних и внутренних информационных потоков, входных и выходных данных в рамках взаимодействия между источниками данных, Системой и РВД; - Отчет о нагрузочном тестировании. - Руководство пользователя; - Руководство администратора; - Программа и методика приемочных испытаний; - Протокол проведения приемочных испытаний; - Акт передачи исключительных /неисключительных прав; - Лицензионный договор; - Структурированный документ о приемке оказанных Услуг в электронном виде путем размещения в ЕИС. Документация должна предоставляться Заказчику на машинных носителях (флеш-диск или передана ссылка для скачивания). Документация, представленная в электронном виде, должна быть выполнена в формате *pdf *docx. Формат предоставления документации определяется Заказчиком. Документация должна быть выполнена на русском языке, за исключением официальных наименований используемого программного и технического обеспечения. - - Значение характеристики не может изменяться участником закупки

7 ОБЪЕМЫ И СРОКИ ГАРАНТИЙ КАЧЕСТВА - Исполнитель гарантирует, что результаты оказанных Услуг соответствуют требованиям, установленным в Контракте, обязательным нормам и правилам, регулирующим данную деятельность (ГОСТ, ТУ), а также иным требованиям законодательства Российской Федерации, действующим на момент оказания услуг. Качество оказываемых Услуг должно соответствовать действующим нормам и техническим условиям, безопасности жизни и здоровья, а также иным требованиям сертификации, безопасности (санитарным нормам и правилам, государственным стандартам и т.п.), лицензирования, если такие требования предъявляются действующим законодательством РФ или настоящим Контрактом к данному виду Услуг. Гарантийный срок на результаты оказанных Услуг составляет 12 (двенадцать) месяцев с даты подписания Заказчиком документа о приемке оказанных Услуг. Под гарантией понимается устранение Исполнителем своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки оказанных услуг. Если в период гарантийного срока обнаружатся недостатки, то Исполнитель (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, согласованные Сторонами и зафиксированные в акте с перечнем выявленных недостатков и сроком их устранения. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Исполнитель гарантирует возможность безопасного использования результата оказанных Услуг по назначению в течение всего гарантийного срока. - - Значение характеристики не может изменяться участником закупки

Перечень условных обозначений, терминов и сокращений. - API (англ. Application Program Interface) Программный интерфейс для взаимодействия компонентов программного обеспечения CSV-ФАЙЛ Файл в формате CSV (англ. Comma-Separated Values — значения, разделенные запятыми), предназначенном для представления табличных данных. Строка таблицы соответствует строке текста в файле, которая содержит одно или несколько полей, разделенных запятыми или другими заданными разделителями Drag-and-drop Способ оперирования элементами интерфейса (как графическим, так и текстовым, где элементы графического пользовательского интерфейса реализованы при помощи псевдографики) с применением манипулятора «мышь» или сенсорного экрана. DATAMART STUDIO Приложение для установки и настройки витрин данных и СУБД ETL Компонент информационной системы, реализующий сервисы извлечения, преобразования, очистки и загрузки данных HTTP Протокол прикладного уровня передачи (англ. HyperText Transfer Protocol). HTTPS Расширение протокола HTTP для поддержки шифрования в целях повышения безопасности (англ. HyperText Transfer Protocol Secure). Low-code Подход к созданию, настройке и модификации систем с минимальным использованием ручного программирования. REST (англ. Representational state transfer) — архитектурный стиль взаимодействия компонентов распределенного приложения в сети REST API Набор правил, по которым различные программы могут взаимодействовать между собой и обмениваться данными с помощью протокола http REST-Uploader Сервис витрины данных для асинхронной загрузки табличных данных (загрузка CSV, удаление, проверка статуса, отчет ФЛК) из сторонних источников с использованием способа взаимодействия REST API DTM-Uploader Сервис витрины данных для бинарных файлов-вложений (загрузка/удаление в S3) из сторонних источников с использованием способа взаимодействия REST API Web-браузер Программное обеспечение для обработки и вывода разных составляющих веб-страницы и предоставление интерфейса между веб-сайтом и его посетителем. - - Значение характеристики не может изменяться участником закупки

Web-интерфейс Web-страница или совокупность web-страниц, предоставляющая пользовательский интерфейс для взаимодействия с сервисом или устройством посредством протокола HTTP и web-браузера. Web-страница Документ или информационный ресурс, доступ к которому осуществляется с помощью web-браузера. XML eXtensible Markup Language, расширяемый язык разметки. XSD XML Schema definition - язык описания структуры XML документа. Агент ПОДД СМЭВ/ Агент СМЭВ 4 Типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающие сопряжение Витрин данных с ПОДД СМЭВ БД База данных Бизнес-правила Набор условий, критериев, направленных на управление бизнес-сценарием Бизнес-процесс Набор непрерывно выполняемых мероприятий, пользователями Системы, по действиям и событиям бизнес-сценария с целью получения результата при выполнении Бизнес-сценарий Описание логики выполнения автоматизируемого процесса в Системе Вид сведений/ВС Вид сведений представляет собой комплект документации, определяющий технические требования и особенности предоставления конкретных сведений в СМЭВ. Витрина данных Компонент информационных систем органов и организаций государственного сектора, представляющий собой комплекс программных и технических средств, обеспечивающий загрузку, хранение и предоставление государственных данных из информационных систем органов и организаций государственного сектора другим органам и организациям государственного сектора с использованием ЕИП НСУД и посредством СМЭВ для предоставления государственных и муниципальных услуг, исполнения государственных и муниципальных функций в электронной форме. При создании витрин данных обычно применяется ТПО ВД. ГЕОП Государственная единая облачная платформа ГОСТ Государственный стандарт ЕИП НСУД, ФГИС «ЕИП НСУД» Федеральная государственная информационная система «Единая информационная платформа национальной системы управления данными» Оператор ЕИП НСУД – Минцифры России

ЕПГУ Единый портал государственных и муниципальных услуг (функций) http://gosuslugi.ru ЕСИА Федеральная государственная информационная система «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», определенная в постановлении Правительства Российской Федерации от 28 ноября 2011 г. №977. ИС Информационная система ИС-источник, источник Информационная система субъекта РФ, содержащая сведения, подлежащие размещению на региональный витрине данных ОИВ Орган исполнительной власти ОЗУ Оперативное запоминающее устройство – оперативная память – энергозависимая часть системы компьютерной памяти, в которой во время работы компьютера хранится выполняемый машинный код (программы), а также входные, выходные и промежуточные данные, обрабатываемые процессором. ОМСУ Органы местного самоуправления ОС Операционная система ПО Программное обеспечение Портлет Подключаемый, сменный компонент пользовательского веб-интерфейса. Региональная витрина данных, РВД/ компонент региональной информационной системы субъекта РФ, размещенный на ГЕОП. РОИВ Региональные органы исполнительной власти СМЭВ Система межведомственного электронного взаимодействия Система Автоматизированная информационная система предоставления государственных и муниципальных услуг Республики Алтай «Доверие» СУБД Система управления базами данных. ТЗ Техническое задание ФЗ Федеральный закон ФЛК Форматно-логический контроль ФТТ Функциональные и технические требования по обеспечению взаимодействия с витринами данных, развернутыми на ГЕОП (приложение к письму Минцифры России от 21.04.2026 №ГБ-П30-35951) ЧТЗ Частное техническое задание ЭП Электронная подпись

Приложение №1 1.10 Подсистема «Журналирование» - Подсистема «Журналирования» предназначена для хранения и отображения сведений о событиях Системы. Подсистема состоит из следующих модулей: - модуль «Аудит действий пользователя»; - модуль «Журнал авторизации». 1.10.1 Модуль «Аудит действий пользователя» Модуль «Аудит действий пользователя» предоставляет возможность просматривать все события, которые происходят в Системе в рамках созданного бизнес-процесса. Модуль обеспечивает следующие функциональные возможности: - аудит действий пользователя: • регистрация действий пользователя, совершенных в бизнес-процессе; • просмотр журнала действий пользователей; • просмотр информации о событии с указанием времени, пользователя, типа и подтипа сущности, над которым было совершено действие, описание изменений со старым и новым значением. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала действий в файл в форматы .xlsx, .pdf. 1.10.2 Модуль «Журнал авторизации» Модуль «Журнал авторизации» обеспечивает фиксирование действий пользователей в части осуществления входа (выхода) в (из) Системы. Модуль обеспечивает следующие функциональные возможности: - аудит событий входа и выхода из Системы, с указанием: • тип события: вход через локальную авторизацию (логин / пароль), вход через ЕСИА, вход через ЕСИА по сертификату, выход пользователя из Системы; • дата события; • имя пользователя. - фильтрация записей в журнале по заданным атрибутам; - экспорт журнала авторизации в файл в форматы .xlsx, .pdf. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.11 Компонент «Agent» - Данный компонент обеспечивает минимизацию зависимости от типов и версионности обозревателей при использовании механизмов наложения подписи. Компонент «Агент» позволяет осуществлять подписание электронных запросов в сторону СМЭВ без использования технологии интерфейса подключаемых модулей Netscape (NPAPI). - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.12 Компонент «Гарантированная доставка» - Компонент «Гарантированная доставка» обеспечивает организацию программной очереди из сформированных пользователями Системы запросов и не доставленных до получателя, их отправку в автоматическом режиме без участия пользователя Системы. Потребность в такой функции компонента «Гарантированная доставка» возможна в случаях возникновения отказов в работе СМЭВ, сервиса – получателя запроса или каких-либо других проблемах со связью между получателем и сервером Системы. Особенностями алгоритма работы блока являются: Первичная пятикратная непрерывная отправка запроса в сторону Поставщика в рамках пользовательского интерфейса. Данная особенность минимизирует процент недоставленных до Поставщика запросов по причине временной загруженности сервиса – Поставщика сведений. При неудачной первичной отправке запроса Поставщику сведений запрос переходит в статус «Отправляется». Последующие попытки отправки запроса осуществляются по следующим правилам: - первые пять минут после создания - раз в 30 секунд; - последующий час – раз в пять минут; - далее раз в 30 минут в течении двух дней; после чего запрос исключается из очереди на отправку и переводится в статус «Сбой при отправке». При неудачной первичной попытке отправки запроса все последующие, вплоть до исключения запроса из очереди на отправку, также происходят по принципу пятикратной непрерывной отправки. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.3 Подсистема «Реестр записей бизнес-процесса» - В подсистеме «Реестр записей бизнес-процесса» отображается перечень обращений по созданному бизнес-процессу в виде записей, с которыми пользователь Системы может работать на соответствующем этапе бизнес-процесса в зависимости от своей роли в Системе. Для удобства работы с записями реестра необходимо реализовать систему фильтрации и сортировки по всем элементам реестра. Обеспечена возможность выгрузки реестров в файлы формата .xlsx и .pdf. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.4 Подсистема взаимодействия со СМЭВ - 8) настройка возможности подписания запроса ЭП-СП; 9) настройка выбора среды СМЭВ 3 (тестовая или продуктивная), по которой будет происходить опрос; 10) дублирование видов сведений для осуществления настройки подписания ВС несколькими подписями; 11) добавление к виду сведений шаблона печатных форм в формате jrxml. - подключение приема в подсистему входящих запросов по конкретным ВС, по которым Система выступает в качестве поставщика; - создание регламентированных запросов к витринам посредством СМЭВ 4 обработчика, с возможностью создания атрибутов запроса, указание мнемоники витрины и запроса, версии; - возможность ручной проверки очереди обработки заявок. 1.4.2 Модуль «СМЭВ-адаптер» Модуль «СМЭВ-адаптер» осуществляет взаимодействие со СМЭВ в рамках приема входящих запросов ВС и ответов, на исходящие из Системы запросов, а также в рамках отправки исходящих запросов ВС и ответов на входящие запросы. Для обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4 реализована техническая возможность использовать Агент ПОДД СМЭВ на подготовленных мощностях и развернутом ПО. Модуль с заданной периодичностью опрашивает указанные адреса ВС на наличие входящих запросов и добавлять их в Систему для дальнейшей обработки и отправки ответа, а также обеспечивать отправку XML-запроса ВС по указанному адресу в СМЭВ. Модуль обеспечивает гарантированную доставку запросов, за счет механизма повторных вызовов электронных сервисов при сбоях. Модуль обращается к установленному в Системе специальному контейнеру ключа ведомства с защищенными файлами сертификатов, для получения электронной подписи, необходимой для принятия входящих запросов и отправки исходящих запросов (в модуле также должна содержаться информация о владельце данного ключа) в зависимости от ведомства – ответчика на запрос и ведомства-инициатора исходящего запроса. В модуле фиксируется история всех запросов с возможностью просмотра следующих параметров: - - Значение характеристики не может изменяться участником закупки

Подсистема состоит из следующих модулей: - модуль «Конструктор запросов»; - модуль «СМЭВ-Адаптер»; 1.4.1 Модуль «Конструктор запросов» Модуль «Конструктор запросов» обеспечивает возможность осуществления настройки видов сведений (далее – ВС), используемых в рамках функционирования Системы, а также преобразование переданного XML-запроса в JSON и преобразование из JSON в XML-запрос. Модуль выполняет следующие функции: - ведение реестра заявок – данных, которыми Система обмениваемся с другими системами через СМЭВ, для просмотра необходимой информации о входящих и исходящих межведомственных запросах. Заявка должна содержать атрибуты запроса, атрибуты ответа, а также сведения о наличии ошибок при отработке запроса. В реестре должна быть реализована возможность фильтрации по типу запроса (входящий, исходящий), ответственному ведомству, ВС, статусу заявки, дате создания и дате ответа по заявке. - выгрузка реестра заявок в файл формата .xlsx; - формирование исходящих запросов и ответов на входящие запросы в формате XML для передачи в модуль, а также преобразование входящего запроса или ответа из формата XML в формат JSON; - ведение реестров ведомств – департаментов, к которым Система обращается для получения каких-либо сведений, подключенных к Системе, через СМЭВ; - ведение библиотеки ВС со следующими функциональными возможностями: 1) возможность создания адаптеров к ВС СМЭВ 3 с указанием общих параметров адаптера (название сведений, версия сведений, идентификатор класса, тип запроса, источник поступления запросов или передачи ответов); 2) импорт XSD-схемы ВС (с описанием необходимых наборов полей) и генерация форм запроса и ответа; 3) экспорт описания наборов полей в формате JSON; 4) импорт архива описания наборов полей в формате JSON; 5) редактирование форм запроса и ответа ВС; 6) фильтрация реестра по типу запроса (входящий, исходящий), ответственному ведомству и названию сведения; 7) выбор ЭП-ОВ, которой будет подписываться запрос;

- номер запроса с возможностью перехода просмотра статуса сообщения в ЛК УВ; - дата запроса; - дата ответа на запрос; - статус запроса; - идентификатор (messageId) запроса; - текст запроса в формате XML; - текст ответа в формате XML; - SOAP-пакеты. В модуле реализована возможность опроса очереди СМЭВ по пространству имен (namespace) ВС. Для возможности просмотра ошибок, которые имеются в работе СМЭВ 3 или по определенному виду сведений реализован журнал ошибок при взаимодействии со СМЭВ. В журнале выводятся следующие ошибки с указанием наименования вида сведений, даты блокировки, даты разблокировки: - Ошибка подключения к веб-сервису СМЭВ 3; - Ошибка подписания сообщения определенной подписью; - Ошибка отправки сообщения - доступ запрещен для определенной подписи; - Ошибка подписания сообщения крипто-провайдером; - Ошибка добавления сообщения в очередь ответчика - очередь переполнена; - Ошибка отправки сообщения - вид сведений недоступен для определенной подписи; - Ошибка СМЭВ.

Приложение №1 1.5 Подсистема «Реестр исходящих запросов» - Подсистема обеспечивает возможность обмена данными с ФОИВ, РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки запросов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Поставщику сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает возможность отправки запроса в витрину данных, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ версии 4. В подсистеме доступны запросы к витринам, которые были добавлены в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик», в статусе «Активный». Доступно добавление (подключение) новых витрин данных и активация запросов к ним в модуле «Конструктор запросов» с типом «СМЭВ 4 – обработчик». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.6 Подсистема «Реестр входящих запросов» - Подсистема обеспечивает возможность обмена данными с РОИВ и ОМСУ, используя инфраструктуру межведомственного электронного взаимодействия СМЭВ, соответствующая актуальной версии методических рекомендаций по работы с СМЭВ версии 3.x. Для отправки ответов данных в Системе поддерживаться возможность формирования xml файла, в соответствии с форматами взаимодействия видов сведений, и передачу xml в СМЭВ для отправки Потребителю сведений. Подсистема обеспечивает возможность подписания запросов ЭП-СП и ЭП-ОВ. Настройка данных функций осуществляется в модуле «Конструктор запросов». Подсистема обеспечивает формирование печатных форм запросов, макеты которых загружены в модуле «Конструктор запросов». Подсистема обеспечивает разграничение доступа к видам сведений по ролям пользователей, настраиваемое администратором Системы. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.7 Подсистема взаимодействия с ЕГР ЗАГС - Дополнительно для реестра «Сведения о государственной регистрации смерти» обеспечена возможность следующих выгрузок: - выгрузка реестра по форме 1.2.1 риур; - выгрузка реестра по форме 1.2 риур; - Экспорт актов в XLSX; - Отчет по количеству актов; - Отчет для «ГАС Выборы» в формате txt; - - Значение характеристики не может изменяться участником закупки

Подсистема взаимодействия с ЕГР ЗАГС обеспечивает функционал по получению, обработке и использованию данных о записях актов гражданского состояния в составе следующих компонентов: - сведения о государственной регистрации смерти; - сведения о государственной регистрации установления отцовства; - сведения о государственной регистрации перемены имени; - сведения о государственной регистрации заключения брака; - сведения о государственной регистрации расторжения брака; - сведения о государственной регистрации рождения. Для получения сведений ЗАГС подсистема использует библиотеку адаптеров, при этом взаимодействие Системы со СМЭВ должно происходить в качестве «Поставщика вида сведений» по следующему сценарию работы: Система, в соответствии с заданным интервалом времени, осуществляет опрос информационной системы Федеральной налоговой службы на наличие данных об актах гражданского состояния, через отправку запроса к соответствующим видам сведения СМЭВ 3.Х; В ответ на запрос Система получает набор запрашиваемых данных и направляет подтверждение получения запроса. В Системе осуществляется проверка оригинальности полученных данных, после чего записи, которые не сохранены в базе данных Системы или были обновлены в ЕГР ЗАГС будут добавлены и/или обновлены в локальных реестрах хранения информации ЕГР ЗАГС. Для использования данных, получаемых в результате взаимодействия с ЕГР ЗАГС, в Системе обеспечена возможность формирования реестров полученных актовых записей, включающих все поступившие записи. В Системе обеспечена возможность доступа для сотрудников к реестрам с возможностью просмотра и выгрузки записей, предназначенных только для ведомства сотрудника. Для удобства работы с записями реестра реализована система фильтрации и сортировки по всем элементам реестра. В Системе для всех реестров обеспечена возможность фильтрации по элементам реестра и выгрузки в файлы форматов: XLSX.

Приложение №1 1.8 Подсистема «Запись на прием» - По каждому учреждению допускается создание расписания, на основе которого Система будет генерировать слоты времени для записи на прием через ЕПГУ. Запись о расписании представляет собой правило генерации слотов времени, которые будет видеть заявитель на ЕПГУ при бронировании времени приема. В Системе правило расписания должно состоять из следующих атрибутов: -наименование: задается произвольное название правила; - подразделение: выбор из справочника подразделений учреждения; - количество окон: указывается количество одновременно принимающих операторов; - дата (и время) начала: указывается дата начала действия расписания; указывается время начала рабочего дня; - время приема: длительность временного интервала; - дата (и время) окончания: указывается дата окончания действия расписания; указывается время окончания рабочего дня; - дни недели: указываются рабочие дни недели. - - Значение характеристики не может изменяться участником закупки

Приложение №1 1.9 Подсистема «Аналитика» - В аналитическом модуле отражаются статистические показатели межведомственных запросов: - количество обработанных входящих запросов; - количество обработанных исходящих запросов. Реализованы 10 готовых форм отчетов по исходящим запросам: 1) Потребители и сведения – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 2) Потребители и поставщики – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование поставщика вида сведений в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов – количество отправленных исходящих запросов; - Вывод итогов – всего в разрезе ведомств – потребителей. 3) Потребители и поставщики (верхнеуровневый) – аналогично п.2, но количество запросов суммируется по верхнеуровневым организациям. 4) Рейтинг поставщиков – со следующей информацией: - Наименование поставщика вида сведений; - Всего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 5) Рейтинг потребителей – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - сего запросов; - Всего запросов в разрезе статусов: ответ получен, ошибка выполнения, направлено запросов. 6) Рейтинг пользователей – со следующей информацией: - ФИО сотрудника; - Наименование ведомства; - Всего запросов. 7) Активность по месяцам – со следующей информацией: - Наименование ведомства-потребителя – наименование организации, созданной в ИС; - Наименование ведомства-поставщика сведений; - Месяц; - Всего запросов. - - Значение характеристики не может изменяться участником закупки

8) Общая статистика – со следующей информацией: - Внутренний идентификатор запроса; - Messageid запроса; - Дата формирования запроса; - Дата изменения запроса; - Автор запроса; - Статус запроса; - Наименование ВС; - Поставщик; - Ведомство-потребитель. 9) Внутрирегиональные запросы – со следующей информацией: - Внутренний идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус; - Потребитель; - Наименование сведений; - Ведомство-поставщик; - Количество дней на обработку; - Обработан (в срок/истек срок). 10) Внутрирегиональные запросы (верхнеуровневый) – аналогично п.9, но с указанием верхнеуровневых организаций. - Реализована форма отчета по входящим запросам со следующей информацией: - Идентификатор запроса; - Дата формирования запроса; - Дата изменения запроса; - Статус запроса; - Потребитель; - Наименование ВС; - ОКТМО; - Поставщик; - Ведомство-поставщик.

Приложение №1 к техническому заданию «Описание функциональных характеристик программного обеспечения» содержит перечень функциональных возможностей программного обеспечения «ИС.МЭВ» (Далее – ПО). - Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица. Сценарий включает следующие шаги: 1) пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА». 2) Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа. 3) ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь ещё не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации. 4) когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений. 5) если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код. 6) Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код. 7) ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации. 8) Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным. После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа. - - Значение характеристики не может изменяться участником закупки

- Стандартные компоненты: • текстовое поле – универсальное поле для хранения строковых данных в одной строке; • электронная почта – поле для ввода электронной почты (email адреса) с автоматической проверкой корректности введенного адреса; • текстовая область – расширяемая (вручную или автоматически) область для хранения строковых данных, занимающих несколько строк; • номер телефона – поле для ввода номер телефона с предустановленной маской для проверки корректности введенного номера; • дата / время – поле для ввода даты и/или времени в заданном в настройках компонента формате. В компоненте предусмотрены выбор даты и времени с помощью виджета «Календарь – время» и ограничение вводимых (выбираемых) даты или времени; • флажок» – специальное поле, пребывающее в двух состояниях: «Установлен» (истина), «Не установлен» (ложь); • выпадающий список – специальное поле для выбора значения (значений) из определенного в настройках компонента списка возможных значений, в том числе из справочника; • радиокнопка – набор радиокнопок (их количество, название и значение изменяются в настройках), предназначен для выбора только одного из возможных вариантов; • файл – специальное поле для хранения и загрузки файлов различных типов, обладает обширной конфигурацией от ограничения размера загружаемых файлов до предпросмотра некоторых файлов в новой вкладке браузера;

1.2.4.3 Подмодуль «Конструктор критериев экранных форм» Подмодуль «Конструктор критериев экранных форм» позволяет задавать условия выполнения действий (переходов) между экранными формами. Требования для выполнения критерия зависит от компонентов заявки, расположенных на экранной форме. Данный модуль разграничивает выполнение условий по критерию, задавать несколько значений или выполнять определенное из заданного перечня. 1.2.5 Модуль печатных форм Модуль печатных форм предоставляет возможность внесения электронных форм документов (печатных форм) в формате, используемых в Системе на определенном шаге бизнес-процесса. Модуль предоставляет возможность заполнения полей электронной формы документа из компонентов заявки, расположенных на экранной форме. Электронные формы документов (печатные формы), загружаемые в Систему, разрабатывваются в свободно распространяемом ПО.

1.2.4.2 Подмодуль «Конструктор макетов экранных форм» Подмодуль «Конструктор макетов экранных форм» предоставляет следующие возможности: - выбор формы модели – должен содержать все созданные в модуле «Конструктор модели бизнес-процесса» экранные формы для возможности выбора определенной экранной формы для просмотра и/или редактирования; - назначение роли – должен обеспечивать разграничение доступа к экранной форме пользователям, текущая роль которых не входит в число выбранных в списке ролей; - загрузка компонентов из подмодуля «Конструктор компонентов заявки» – должен обеспечивать загрузку шаблона экранной формы, в качестве содержимого выбранной экранной формы; - очистить компоненты – удаление компонентов выбранной экранной формы; - копирование экранной формы – копирование компонентов экранной формы для вставки на других формах; - вставка формы с заменой – должен позволять вставить скопированную экранную форму с полной заменой содержимого экранной формы, на которой вызывается вставка; - вставка формы с сохранением существующей – должен позволять вставить скопированную экранную форму, как дополнение к содержимому экранной формы, на которой вызывается операция вставки. - сохранение экранной формы – сохранение всех изменений только на выбранной экранной форме; - вернуть первоначальную форму – должен позволять отменить не сохраненные изменения содержимого экранной формы; - использование данных модуля «Аудит действия пользователя» – должен позволять при работе с записью по БП на выбранной экранной форме нажать действие «Перейти к журналу действий» и просмотреть журнал действий (кто, когда и какие изменения вносил по данной записи БП) по данной записи БП; - использование панели компонентов – отображение категоризированного списка компонентов, созданных в модуле «Конструктор компонентов заявки». Для размещения компонентов на определенной экранной форме должен быть использован метод Drag-and-drop.

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

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

ИС.МЭВ – программное обеспечение, предназначенное для организации межведомственного электронного взаимодействия органов исполнительной власти, органов местного самоуправления и организаций, участвующих в предоставлении государственных, муниципальных услуг, услуг иных организаций, осуществляющих функции, связанные с предоставлением государственных, муниципальных услуг, и услуг иных организаций с соблюдением юридической значимости при реализации иных полномочий, возложенных на эти органы и организации нормативными правовыми актами. ПО состоит из электронных сервисов межведомственного взаимодействия в целях обмена сведениями, требуемыми в процессе предоставления государственных/муниципальных услуг, а также выполнения иных функции и услуг, осуществляемых в рамках межведомственного взаимодействия. ПО внесено единый реестр российских программ для электронных вычислительных машин и баз данных (Реестровая запись №13268 от 11.04.2022 г.). ОБЩАЯ ИНФОРМАЦИЯ Доступ к функциональным возможностям ПО предоставляется через web-браузер. ПО имеет следующие функциональные возможности: - прием и обработка заявлений с ЕПГУ / Личное обращение, интеграция с ЕЛК; - добавление адаптеров видов сведений СМЭВ 3; - обеспечения унифицированного доступа к данным, размещённым на витринах Поставщиков в СМЭВ 4; - интеграция с конструктором цифровых регламентов КЦР; - взаимодействие органов власти с ЕГР ЗАГС; - взаимодействие органов власти с ФССП; - формирование печатных форм документов, обмен исполнительными документами с использованием ЭЦП; - настройка ролевой модели доступа.

1.2.3 Модуль «Конструктор событий» Модуль «Конструктор событий» предназначен для создания статусов обработки заявления и рассылки уведомлений, предназначенных для пользователей Системы, о наступлении определенного события в бизнес-процессе. Основные способы информирования: - системное уведомление – краткое сообщение, опубликованное в Системе для пользователя; - e-mail сообщения - поступающие на адрес электронной почты пользователя. В модуле должна быть возможность для созданного статуса добавить срок обработки, с возможностью указания цветовой индикации записи заявления при наступлении события. 1.2.4 Модуль «Конструктор экранных форм» Модуль «Конструктор экранных форм» состоит из следующих подмодулей: - конструктор компонентов заявки; - конструктор макетов экранных форм; - конструктор критериев экранных форм. 1.2.4.1 Подмодуль «Конструктор компонентов заявки» В подмодуле «Конструктор компонентов заявки» предоставлена возможность использовать и настраивать определенный компонент заявки на экранной форме. Настройка компонентов заявки предусматривает следующие возможности: - создание компонентов; - указывать общие параметры компонента заявки (название, обязательность, маска и др); - указывать параметры по настройке зависимости между компонентами заявки; - указывать параметры по настройке автозаполнения компонентов заявки данными из ЛК. При создании компонентов заявки доступны следующее типы компонентов:

Подсистема администрирования Подсистема администрирования состоит из следующих модулей: - модуль управления пользователями и организациями; - модуль «Конфигурация системы». Подсистема администрирования доступна только для пользователей с ролью администратор системы. 1.1.1 Подсистема управления пользователями и организациями Модуль управления пользователями и организациями обеспечивает следующие функциональные возможности: - управление учетными записями пользователей Системы: • создание пользователей; • создание пользователей через импорт файла в формате xlsx; • редактирование атрибутов карточки пользователя; • отключение пользователей; • назначение пользователям ролей доступа к подсистемам и модулям; • создание групп пользователей; • просмотр списка пользователей; • поиск пользователей. - управление списком организаций Системы: • создание организаций; • редактирование атрибутов карточки организации; • отключение организации; • назначение / исключение пользователей к организации; • просмотр списка организаций; • хранение и редактирование древовидной структуры подразделений / организаций; • поиск организации. - реализация ролевого метода управления доступом субъектов доступа (пользователей) к объектам доступа на основе ролей субъектов доступа: • создание ролей доступа и определение прав доступа к подсистемам и модулям • редактирование атрибутов ролей; • назначение роли пользователю, группам пользователей; • удаление ролей доступа; • просмотр списка ролей; • поиск ролей. - просмотр списка активных сессий. 1.1.2 Модуль «Конфигурация системы» Модуль «Конфигурация системы» обеспечивает следующие функциональные возможности: - администрирование сервера: • контроль аппаратной части: объем использованной памяти, всего задействовано ОЗУ, предельный объем памяти; • управление кэшем: удаление кэша БД, сервлетов. - конфигурирование параметров Системы

Подсистема авторизации и аутентификации пользователей Доступ к функциям авторизации предоставляется только пользователям, успешно прошедшим процедуру регистрации. Подсистема обеспечивает следующие функциональные возможности: - обеспечение идентификации и аутентификации пользователей по специальным идентификаторам – именам учетных записей пользователей, обеспечение аутентификации пользователей с использованием паролей; - защита аутентификационной информации в процессе ее ввода для аутентификации от возможного использования лицами, не имеющими на это полномочий. Защита осуществляется путем исключения отображения для пользователя действительного значения аутентификационной информации. Вводимые символы пароля должны отображаться условными знаками «*»; - настройку политики блокировки учетной записи пользователя после неудачных попыток авторизации; - осуществление отключения пользователя от Системы при отсутствии активности. В случае неактивности пользователя более установленного промежутка времени происходит автоматическое завершение сессии. Дальнейшая работа возможна только после повторного входа в Систему. Данный функционал предназначен для повышения безопасности работы с Системой и предотвращения несанкционированного доступа в Систему; - исключение возможности установки пользователем по умолчанию аутентификационных данных для входа в систему; - запрет на использование пользователями определенного числа последних использованных паролей при создании новых паролей для предотвращения повторного использования старого пароля; - установление и проверка синтаксиса пароля: • задание минимальной сложности пароля с определяемыми требованиями к регистру, количеству символов, сочетанию букв верхнего и нижнего регистра, чисел и специальных символов; • задание регулярного выражения, используемого для проверки пароля пользователя. • задание срока действия пароля.

1.2 Модуль «Конструктор бизнес-процессов» Подсистема «Конструктор бизнес-процессов» состоит из следующих модулей: - модуль «Конструктор модели бизнес-процесса»; - модуль «Конструктор действий»; - модуль «Конструктор событий»; - модуль «Конструктор экранных форм». При моделировании и автоматизации бизнес-процессов подсистема использует подход low-code, с возможностями, позволяющими автоматизировать бизнес-сценарий в единой цифровой среде за счет визуального редактора сквозных процессов. 1.2.1 Модуль «Конструктор модели бизнес-процесса» Модуль «Конструктор модели бизнес-процесса» позволяет моделировать диаграммы процессов любой сложности с большим количеством разветвлений, условий используя принятые бизнес-правила BPMN. Проектирование осуществляется посредством использования интуитивно понятных графических элементов, каждый из которых визуализирует определенный шаг процесса. Спроектированная модель является исполняемой в Системе. Администратор Системы может опубликовать (запустить) бизнес-процесс, либо деактивировать с целью внесения изменений. 1.2.2 Модуль «Конструктор действий» Модуль «Конструктор действий» отвечает за настройку действий (переходов) между мероприятиями, которые были созданы в модуле «Конструктор модели бизнес-процесса». Модуль предоставляет возможность настроить определенное действие, указать последовательность выполнения, задать условия перехода, установить правила автоматического выполнения шагов процесса или обработки. Стандартное действие Позволяет перейти на следующее мероприятие с изменением статуса (с проверкой заполнения обязательных полей) Удаление Позволяет удалить заявку Печать Позволяет вывести печатную форму, в рамках заявки Назад Позволяет перейти на следующее мероприятие с изменением статуса (без проверки заполнения обязательных полей) Сохранить Позволяет сохранить внесенные изменения в заявке

Преимущества, требования к участникам

Преимущества: Преимущество в соответствии с ч. 3 ст. 30 Закона № 44-ФЗ - Размер преимущества не установлен

Требования к участникам: 1. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ 2. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 3. Требование к участникам закупок в соответствии с п. 1 ч. 1 ст. 31 Закона № 44-ФЗ Дополнительные требования Наличие права на модификацию программного кода программное обеспечение «ИС.МЭВ» (запись в Едином реестре российских программ для ЭВМ и баз данных 13268 от 11.04.2022 произведена на основании поручения Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 11.04.2022 по протоколу заседания экспертного совета от 04.04.2022 №410пр, ссылка https://reestr.digital.gov.ru/reestr/678288/). в объеме, достаточном для обеспечения обязательств по оказанию услуг в рамках исполнения Контракта. Наличие у участника закупки одного из документов, подтверждающих право на распространение, внедрение, сопровождение и иное использование программы по предмету торгов: а) для участника, являющегося правообладателем – копия свидетельства об официальной регистрации программ или копия договора об отчуждении исключительного права на программу с копией документа, подтверждающего государственную регистрацию отчуждения исключительного права; б) для участника, которому права на программы переданы автором или иным правообладателем – копия действующего лицензионного (сублицензионного) договора о передаче прав на модификацию и иное использование программ, заключенного в письменной форме и устанавливающего объем и способы использования программ; в) копия действующего сертификата, выданного Правообладателем участнику закупки, по которому участник имеет право осуществлять услуги по распространению, внедрению, модификации и сопровождению программного обеспечения от своего имени с соблюдением авторских прав Правообладателя. Основание: Раздел VII ГК РФ "Права на результаты интеллектуальной деятельности и средства индивидуализации".

Применение национального режима по ст. 14 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ: Основанием для установки указания запретов, ограничений закупок товаров, происходящих из иностранных государств, выполняемых работ, оказываемых услуг иностранными лицами, а так же преимуществ в отношении товаров российского происхождения, а также товаров происходящих из стран ЕАЭС, выполняемых работ, оказываемых услуг российскими лицами, а также лицами, зарегистрированными в странах ЕАЭС, является Постановление Правительства Российской Федерации о мерах по предоставлению национального режима от 23.12.2024 № 1875.

Сведения о связи с позицией плана-графика

Сведения о связи с позицией плана-графика: 202603772000122001000004

Начальная (максимальная) цена контракта: 10 146 971,62

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 262041111521604110100100020020000242

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 31.10.2026

Закупка за счет бюджетных средств: Да

Наименование бюджета: республиканский бюджет Республики Алтай

Вид бюджета: бюджет субъекта Российской Федерации

Код территории муниципального образования: 84000000: Муниципальные образования Республики Алтай

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

Размер обеспечения заявки: 101 469,72 Российский рубль

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, предусмотренной статьей 45 Закона № 44-ФЗ. Выбор способа обеспечения осуществляется участником закупки самостоятельно. Срок действия независимой гарантии должен составлять не менее месяца с даты окончания срока подачи заявок. Участник закупки вправе предоставить обеспечение заявки в соответствии со ст. 44-45 Закона № 44-ФЗ. Участники закупки, являющиеся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением РФ, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением РФ, вправе предоставить обеспечение заявок в соответствии с Постановлением Правительства РФ от 10.04.2023 № 579 «Об особенностях порядка предоставления обеспечения заявок на участие в закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд участниками таких закупок, являющимися иностранными лицами».

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03222643840000007700, л/c 05772D02210, БИК 045004109, ОКЦ № 1 СибГУ Банка России//УФК по Республике Алтай, г Горно-Алтайск, к/c 40102810745370000109

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО РЕСПУБЛИКЕ АЛТАЙ (УФК ПО РЕСПУБЛИКЕ АЛТАЙ) () ИНН: 0411008817 КПП: 041101001 КБК: 00011610000000000140 ОКТМО: 84701000001 40102810745370000109 03100643000000017700 045004109

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, респ. Алтай, г. Горно-Алтайск, ул. Чаптынова, д. 24.

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

Размер обеспечения исполнения контракта: 5 %

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Исполнение контракта может обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Закона № 44-ФЗ, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия независимой гарантии определяются в соответствии с требованиями Закона № 44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. При этом срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со статьей 95 Закона № 44-ФЗ. Контракт заключается после предоставления участником закупки, с которым заключается контракт, обеспечения исполнения контракта в соответствии с Законом № 44-ФЗ. В случае непредоставления участником закупки, с которым заключается контракт, обеспечения исполнения контракта в срок, установленный для заключения контракта, такой участник считается уклонившимся от заключения контракта. В случае, если предложенные в заявке участника закупки цена, сумма цен единиц товара, работы, услуги снижены на двадцать пять и более процентов по отношению к начальной (максимальной) цене контракта, начальной сумме цен единиц товара, работы, услуги, участник закупки, с которым заключается контракт, предоставляет обеспечение исполнения контракта с учетом положений статьи 37 Закона № 44-ФЗ. Участник закупки вправе предоставить обеспечение исполнения контракта в соответствии с Законом № 44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03222643840000007700, л/c 05772D02210, БИК 045004109, ОКЦ № 1 СибГУ Банка России//УФК по Республике Алтай, г Горно-Алтайск, к/c 40102810745370000109

Банковское или казначейское сопровождение контракта не требуется

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

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 31.10.2026

Закупка за счет бюджетных средств: Да

Наименование бюджета: республиканский бюджет Республики Алтай

Вид бюджета: бюджет субъекта Российской Федерации

Код территории муниципального образования: 84000000: Муниципальные образования Республики Алтай

Документы

Общая информация

Документы

Журнал событий