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

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

Наименование объекта закупки: На выполнение работ по развитию автоматизированной информационной системы управления льготными и субсидированными перевозками, включая подготовку к размещению на единой цифровой платформе Российской Федерации «ГосТех»

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

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РОСЭЛТОРГ (АО«ЕЭТП»)

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

Размещение осуществляет: Заказчик ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ "СИТУАЦИОННО-ИНФОРМАЦИОННЫЙ ЦЕНТР МИНИСТЕРСТВА ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ"

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

Организация, осуществляющая размещение: ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ "СИТУАЦИОННО-ИНФОРМАЦИОННЫЙ ЦЕНТР МИНИСТЕРСТВА ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ"

Почтовый адрес: 107078, г. Москва, ул. Садовая-Спасская, д. 18, стр. 1

Место нахождения: Российская Федерация, 107078, Москва, УЛ САДОВАЯ-СПАССКАЯ, Д. 18, СТР. 1, ПОМЕЩ. 1

Ответственное должностное лицо: Доровский С. С.

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

Номер контактного телефона: 7-945-2490302

Факс: Информация отсутствует

Дополнительная информация: Заказчик : Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Юридический адрес: 107078, г. Москва, вн. тер. г. муниципальный округ Красносельский, ул. Садовая-Спасская, д.18 стр. 1, помещ. 1. E-mail: info@sicmt.ru. Телефон: +7(495)2490302. Ответственное должностное лицо Заказчика: Доровский С.С.

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

Дата и время окончания срока подачи заявок: 08.05.2024 08:00

Дата рассмотрения и оценки первых частей заявок на участие в закупке: 14.05.2024

Дата проведения процедуры подачи предложений о цене контракта: 15.05.2024

Дата рассмотрения и оценки вторых частей заявок на участие в закупке: 17.05.2024

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

Условия контракта

Начальная (максимальная) цена контракта: 80000000.00 Российский рубль

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

Дата начала исполнения контракта: 01.06.2024

Дата окончания исполнения контракта: 31.12.2024

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

Закупка за счет собственных средств организации: Да

Финансовое обеспечение закупки

Всего: - Оплата за 2024 год - Оплата за 2025 год - Оплата за 2026 год - Сумма на последующие годы

80000000.00 - 80000000.00 - 0.00 - 0.00 - 0.00

Этапы исполнения контракта

Финансирование за счет внебюджетных средств

Дата начала исполнения этапа - Дата окончания исполнения этапа

01.06.2024 - 26.08.2024

Всего: - Оплата за 2024 год - Оплата за 2025 год - Оплата за 2026 год - Сумма на последующие годы

23117277.96 - 23117277.96 - 0.00 - 0.00 - 0.00

Дата начала исполнения этапа: Дата окончания исполнения этапа

01.06.2024: 26.08.2024

Код видов расходов - Сумма контракта (в валюте контракта)

на 2024 год - на 2025 год - на 2026 год - на 2027 год

1 - 2 - 3 - 4 - 5

244 - 23117277.96 - 0 - 0 - 0

Итого - 23117277.96 - 0.00 - 0.00 - 0.00

Код видов расходов: Сумма контракта (в валюте контракта)

Финансирование за счет внебюджетных средств

Дата начала исполнения этапа - Дата окончания исполнения этапа

19.07.2024 - 16.12.2024

Всего: - Оплата за 2024 год - Оплата за 2025 год - Оплата за 2026 год - Сумма на последующие годы

47029388.09 - 47029388.09 - 0.00 - 0.00 - 0.00

Дата начала исполнения этапа: Дата окончания исполнения этапа

19.07.2024: 16.12.2024

Код видов расходов - Сумма контракта (в валюте контракта)

на 2024 год - на 2025 год - на 2026 год - на 2027 год

1 - 2 - 3 - 4 - 5

244 - 47029388.09 - 0 - 0 - 0

Итого - 47029388.09 - 0.00 - 0.00 - 0.00

Код видов расходов: Сумма контракта (в валюте контракта)

Финансирование за счет внебюджетных средств

Дата начала исполнения этапа - Дата окончания исполнения этапа

08.11.2024 - 31.12.2024

Всего: - Оплата за 2024 год - Оплата за 2025 год - Оплата за 2026 год - Сумма на последующие годы

9853333.95 - 9853333.95 - 0.00 - 0.00 - 0.00

Дата начала исполнения этапа: Дата окончания исполнения этапа

08.11.2024: 31.12.2024

Код видов расходов - Сумма контракта (в валюте контракта)

на 2024 год - на 2025 год - на 2026 год - на 2027 год

1 - 2 - 3 - 4 - 5

244 - 9853333.95 - 0 - 0 - 0

Итого - 9853333.95 - 0.00 - 0.00 - 0.00

Код видов расходов: Сумма контракта (в валюте контракта)

Идентификационный код закупки: 241770411620577080100100110016201244

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, Московская обл, работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Объект закупки

Этап №1: Техническое проектирование АИС УЛСП и модификация существующих подсистем АИС УЛСП Идентификатор: 149119304 - 62.01.11.000 - - - - - 1 - Условная единица - 23117277.96 - 23117277.96

5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ АИС УЛСП - В соответствии с настоящим Техническим заданием Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения Этапа 1 Подрядчик должен выполнить Техническое проектирование АИС УЛСП и модификацию существующих подсистем АИС УЛСП, включая: – Техническое проектирование в соответствии с ГОСТ 34.602-2020. Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы; – Обеспечение поддержки новых типов мер социальной поддержки (защиты) пассажиров согласно п. 4.2.1 настоящего Технического задания. В рамках исполнения Этапа 2 Подрядчик должен выполнить работы по разработке новых сервисов, согласно п. 4.2.2 – 4.2.8 настоящего Технического задания и разработке механизмов и порядка миграции АИС УЛСП и ее компонентов на ЕЦП «ГосТех» (при условии технологической готовности ЕЦП «ГосТех»), включая выполнение работ по разворачиванию существующих компонентов Системы в тестовом контуре ЕЦП «ГосТех»: – Выполнение работ реализации сервисов согласно в п. 4.2.2 – 4.2.8 Технического задания; – Выполнение работ по разворачиванию и тестированию разработанных сервисов в тестовом контуре ЕЦП «ГосТех» согласно п. 4.2.8 Технического задания; В рамках исполнения Этапа 3 Подрядчик должен выполнить работы по проведению предварительных испытаний АИС УЛСП, ее опытной эксплуатации и приемочных испытаний в соответствии с «ГОСТ Р 59792-2021. «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». – Проведение предварительных испытаний; – Проведение опытной эксплуатации АИС УЛСП; – Проведение приемочных испытаний АИС УЛСП. Опытная эксплуатация АИС УЛСП и ее приемочные испытания должны проводиться на мощностях Заказчика или на ЕЦП «ГосТех» по решению Заказчика в зависимости от уровня технологической готовности ЕЦП «ГосТех». - - Значение характеристики не может изменяться участником закупки

5.1 Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке

№ этапа 1 Техническое проектирование АИС УЛСП и модификация существующих подсистем АИС УЛСП 1.1. Техническое проектирование Начало: 01.06.2024; Окончание: не позднее 01.07.2024 1. Технический проект на АИС УЛСП в составе Пояснительной записки к техническому проекту, включая (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Схема структурная комплекса технических средств, – Описание автоматизируемых функций (детальное описание функциональных требований по автоматизируемым процессам, включая межведомственный информационный обмен), – Описание информационного обеспечения системы, – Описание организации информационной базы, – Описание программного обеспечения; – Описание организационного обеспечения; – Ведомость технического проекта; – Ведомость машинных носителей информации. 1.2. Обеспечение поддержки новых типов мер социальной поддержки (защиты) пассажиров согласно п. 4.2.1 настоящего Технического задания Начало: 01.06.2024; Окончание: не позднее 18.07.2024 1. Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.1. настоящего Технического задания. 2. Комплект рабочей документации в составе (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Начало: с 01.06.2024; Окончание: не позднее 18.07.2024

№ этапа 2 Работы по развитию АИС УЛСП и подготовка к миграции АИС УЛСП и её компонентов на ЕЦП «ГосТех» согласно раздела 4.2 Технического задания 2.1 Выполнение работ реализации сервисов согласно в п. 4.2.2 – 4.2.8 Технического задания Начало: 19.07.2024; Окончание: не позднее 07.11.2024 Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.2. – 4.2.8 настоящего Технического задания настоящего Технического задания Комплект рабочей документации в составе (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Системы; – Отчёт о проведении тестовых испытаний; – Акт о готовности Системы к проведению нагрузочного испытания; – Отчёт о подготовке к развёртыванию Системы в тестовом контуре ЕЦП «ГосТех»; – Программа и методика предварительных испытаний; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации; – Руководство по установке (развертыванию) всех компонентов Системы с учетом доработок по настоящему Техническому заданию Начало: 19.07.2024 Окончание: не позднее 07.11.2024

№ этапа 3 Предварительные испытания, опытная эксплуатация, приемочные испытания 3.1. Проведение предварительных испытаний в соответствии с п.6.3.1. ТЗ Начало: 08.11.2024; Окончание: не позднее 18.11.2024 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Протокол предварительных испытаний Системы; – Акт о приемке Системы в опытную эксплуатацию; – Руководство пользователя системы; – Руководство администратора системы; – Программа и методика опытной эксплуатации. 3.2. Проведение опытной эксплуатации в соответствии с п. 6.3.3, 6.3.4 ТЗ Начало: 19.11.2024; Окончание: не позднее 05.12.2024 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Исходные коды и дистрибутивы на электронных носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке программного обеспечения); – Протокол пуско-наладочных работ; – Протокол опытной эксплуатации Системы; – Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатации; – Программа инструктажа пользователей; – Протокол инструктажа пользователей; – Акт о завершении опытной эксплуатации Системы – Программа и методика приемочных испытаний; – Актуальные версии документов, предоставленных Заказчику при исполнении Контракта (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Систему). 3.3. Проведение приемочных испытаний АИС УЛСП в соответствии с п. 6.3.5, 6.3.6 ТЗ. Начало: 06.12.2024; Окончание: не позднее 13.12.2024 – Протокол приемочных испытаний Системы; – Акт передачи исключительных прав; – Акт о готовности ввода Системы в эксплуатацию – Документы в соответствии с разделами 4.3.1, 4.1.14 ТТЗ – Обеспечение исп. гарант. обязательств в соответствии с усл. Контракта Начало: 08.11.2024; Окончание: не позднее 13.12.2024

6 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ, ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ - 6.1 Результаты работ В рамках выполнения работ по Этапу 1: 1) Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.1. настоящего Технического задания. 2) Комплект рабочей документации в составе: – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения. 3) Технический проект на АИС УЛСП в составе Пояснительной записки к техническому проекту, включая: – Схема структурная комплекса технических средств, – Описание автоматизируемых функций (детальное описание функциональных требований по автоматизируемым процессам, включая межведомственный информационный обмен), – Описание информационного обеспечения системы, – Описание организации информационной базы, – Описание программного обеспечения; – Описание организационного обеспечения; – Ведомость технического проекта; – Ведомость машинных носителей информации. В рамках выполнения работ по Этапу 2: 1) Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.2. – 4.2.8 настоящего Технического задания настоящего Технического задания – Комплект рабочей документации в составе: – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Системы; – Отчёт о проведении тестовых испытаний; – Акт о готовности Системы к проведению нагрузочного испытания; – Отчёт о подготовке к развёртыванию Системы в тестовом контуре ЕЦП «ГосТех»; – Программа и методика предварительных испытаний; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации; – Руководство по установке (развертыванию) всех компонентов Системы (с учетом доработок по настоящему Техническому заданию) - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по Этапу 3: – Протокол предварительных испытаний Системы; – Акт о приемке Системы в опытную эксплуатацию; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке программного обеспечения); – Программа и методика опытной эксплуатации; – Протокол пуско-наладочных работ; – Протокол опытной эксплуатации Системы; – Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатации; – Руководство пользователя системы; – Руководство администратора системы; – Программа инструктажа пользователей; – Протокол инструктажа пользователей; – Акт о завершении опытной эксплуатации Системы – Программа и методика приемочных испытаний; – Протокол приемочных испытаний Системы; – Акт передачи исключительных прав; – Акт о готовности ввода Системы в эксплуатацию; – Актуальные версии документов, предоставленных Заказчику при исполнении Контракта (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Систему); – Документы в соответствии с разделами 4.3.1, 4.1.14 Технического задания

6.2 Виды, состав, объем и методы испытаний системы и ее составных частей Работоспособность Системы должна определяться по результатам испытаний, проводимым по утверждённой программе и методике испытаний. Виды, состав, объём и методы испытаний должны соответствовать требованиям ГОСТ Р 59792-2021 «Виды испытаний автоматизированных систем». Формат и сроки проведения испытаний должны соответствовать последовательности работ, указанной в п. 5.1. настоящего Технического задания «Состав работ и график их выполнения». Объем и методы приемочных испытаний определяются единой программой и методикой испытаний. Порядок проверки устранения замечаний должен быть указан в программе и методике для соответствующего вида испытаний

6.3 Порядок контроля и приемки 6.3.1 Общие требования к выполнению работ по обеспечению проведения предварительных испытаний До начала испытаний Подрядчик совместно с Заказчиком должен произвести пуско-наладочные работы доработанной Системы в тестовом контуре на выделенных ресурсах Заказчика или на ЕЦП «ГосТех». Монтажные и пуско-наладочные работы осуществляются (при необходимости) Заказчиком. В ходе выполнения работ по доработке АИС УЛСП и ее компонентов должны быть проведены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов. Опытная эксплуатация проводится на вычислительных ресурсах, предоставленных Заказчиком, или на ЕЦП «ГосТех» по решению Заказчика. Во время опытной эксплуатации ведут журнал опытной эксплуатации, в который заносят сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям

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

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

6.3.2 Требования к предварительным испытаниям Предварительные испытания АИС УЛСП должны предусматривать проверки соответствия АИС УЛСП требованиям данного технического задания, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП должно проверяться: - соответствие АИС УЛСП требованиям, установленным в настоящем Техническом задании; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП. По итогам предварительных испытаний АИС УЛСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП. Протокол предварительных испытаний АИС УЛСП должен содержать заключение о готовности (неготовности) АИС УЛСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.3.3 Общие требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного программного обеспечения в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируются весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Протокол опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний

Опытная эксплуатация АИС УЛСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП. Целями опытной эксплуатации АИС УЛСП являются: – определение полноты реализации требований технического задания; – определение фактических функциональных характеристик АИС УЛСП; – определение готовности персонала к работе в условиях функционирования АИС УЛСП; – определение фактической эффективности АИС УЛСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП должны определяться эксплуатационные характеристики АИС УЛСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП. Данные опытной эксплуатации АИС УЛСП должны заноситься в журнал опытной эксплуатации АИС УЛСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП. По результатам опытной эксплуатации принимают решение о готовности предъявления частей АИС УЛСП на приемочные испытания, или о неготовности предъявления частей АИС УЛСП на приемочные испытания АИС УЛСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП

6.3.4 Общие требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного программного обеспечения. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего Технического задания и по согласованию с Заказчиком. До начала испытаний Подрядчик совместно с Заказчиком должен произвести пуско-наладочные работы доработанной Системы в продуктовом контуре Заказчика или на ЕЦП «ГосТех» по решению Заказчика. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и программное обеспечение, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований Технического задания в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. По результатам приемочных испытаний АИС УЛСП принимается решение о возможности ввода Системы в эксплуатацию. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Актом о передаче Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком

После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП. На приемочных испытаниях АИС УЛСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП, а также возможность приемки АИС УЛСП в промышленную эксплуатацию. В процессе приемочных испытаний АИС УЛСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП требованиям данного технического задания и Технического задания на развитие на АИС УЛСП. Результаты приемочных испытаний АИС УЛСП должны заноситься в протокол приемочных испытаний АИС УЛСП. По окончании приемочных испытаний АИС УЛСП должен составляться акт приемки АИС УЛСП в постоянную эксплуатацию, который должен утверждаться с момента выдачи аттестата соответствия на АИС УЛСП

6.4 Порядок приёмки работ по развитию Системы В целях обеспечения приемки работ по развитию Системы Заказчиком должна быть создана Комиссия по приемке Системы (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика и/или Платформы «ГосТех» (при технологической готовности платформы). В случае необходимости и в случае технологической готовности платформы ЕЦП «ГосТех» Заказчик может организовать включение в комиссию представителей Оператора Платформы «ГосТех». Приёмка Системы осуществляется на основании результатов приёмочных испытаний. Приемочные испытания должны проходить только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приёмочные испытания должны проводиться в соответствии с Программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приёмочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: 1. Дистрибутивный комплект Системы на носителе данных. 2. Программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Систему в порядке, предусмотренном Государственным контрактом. После проведения приёмки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

7 ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ - Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 6.1 Технического задания. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105-95 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жёсткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе - - Значение характеристики не может изменяться участником закупки

8 ИСТОЧНИКИ РАЗРАБОТКИ - Разработка Технического производилась с учётом положений следующих нормативно-технические документов: 1. ГОСТ 2.105-95 «Общие требования к текстовым документам». 2. ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом». 3. ГОСТ 19.105-78 «Общие требования к программным документам». 4. ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». 5. ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки

3 СВЕДЕНИЯ ОБ ОБЪЕКТАХ АВТОМАТИЗАЦИИ - 3.1 Описание объектов автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу по Контракту ОК/23_03 от 03.07.2023 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770411620523000022). АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р. в части создания «единого сервиса предоставления льгот и субсидий» - - Значение характеристики не может изменяться участником закупки

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

Перечень функциональных подсистем федерального сегмента: Функция Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот - иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. «Администрирование» Управление учётными записями пользователей федерального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи (ролевая модель). Управление таксономией льгот, включая блок нормативно-справочной информации по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы. «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.).

Перечень функциональных подсистем регионального сегмента: Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной либо субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе. «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах - иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учётными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи. Управление составом и содержанием справочников и классификаторов. «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платёжных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: – сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) уровне; – информационное взаимодействие с общегосударственными информационными системами, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи, а также об указанных мерах, доступных тому или иному гражданину; – подтверждение наличия у гражданина РФ права на приобретение авиабилетов по специальным тарифам согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Постановлении Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» (с изменениями и дополнениями); АИС УЛСП соответствует Требованиям о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены приказом ФСТЭК России от 11.02.2013 № 17), предъявляемым к информационным системам класса защищенности «К2» и Составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных 2-го уровня защищенности (утверждены приказом ФСТЭК России от 18.02.2013 № 21). Текущая архитектура АИС УЛСП приведена на рисунке Рис. 1

3.3 Объект автоматизации в рамках настоящего Технического задания Объектом автоматизации в рамках выполнения работ по настоящему Техническому заданию являются процессы: – определения и разработки механизмов для подготовки к переводу функционала Системы на платформу «ГосТех»; – цифрового подтверждения права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); – цифрового подтверждения права пассажира на приобретение билета на воздушный транспорт по специальному тарифу для жителей Калининградской области; – цифрового подтверждения наличия права на приобретение билета на воздушный транспорт по специальному тарифу у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры в учебных заведениях на территории Калининградской области; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда на основании данных геолокации;

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

Перечень функциональных подсистем, разрабатываемых в рамках настоящего Технического задания: Функция Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов «Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры

«Сервис учета данных Виртуальных социальных карт» Обмен данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт Требования к целевой архитектуре и схеме внешних взаимодействий приведена на Рис. 2

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АСОП Автоматизированная система оплаты проезда АРМ Автоматизированное рабочее место БД База данных ВС Вид сведений ВСК Виртуальная социальная карта Минцифры России ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГосСОПКА Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации Дашборд Информационная панель, которая получает данные из других систем и отображает их в визуализированном формате ДУЛ Документ, удостоверяющий личность ЕГИССО Единая государственная информационная система социального обеспечения ЕСИА Единая система идентификации и аутентификации Контракт Контракт, в рамках которого исполняется настоящее Техническое задание ИС Информационная система МСП Меры социальной поддержки МСЗ Меры социальной защиты НКЦКИ Национальный координационный центр по компьютерным инцидентам НПА Нормативный правовой акт НПБ Нормативно-правовая база НСИ Нормативно-справочная информация ОАО «РЖД» Открытое акционерное общество «Российские железные дороги» ООЗ Описание объекта закупки ОС Операционная система Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» - экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПМИ Программа и методика испытаний ПО Программное обеспечение ПОИБ Подсистема обеспечения информационной безопасности - - Значение характеристики не может изменяться участником закупки

ППК ЦР Президиум Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности ПСП Портал субсидированных перевозок РОИВ Региональный орган исполнительной власти РФ Российская Федерация СЗИ Средства защиты информации СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СПО Системное программное обеспечение СУБД Система управления базой данных СФР Фонд пенсионного и социального страхования Российской Федерации ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС ЕРН Федеральная государственная информационная система ведения Единого федерального информационного регистра, содержащего сведения о населении Российской Федерации ФГИС ФРИ Федеральная государственная информационная система «Федеральный реестр инвалидов» ФИО Фамилия, имя, отчество ФНС Федеральная налоговая служба Российской Федерации ФПСС Фонд пенсионного и социального страхования ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЭТТ Электронное транспортное требование ЭВМ Электронная вычислительная машина - комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Frontend Визуальная часть Системы, которую пользователь видит и с которой может взаимодействовать при помощи браузера HTTPS HyperText Transfer Protocol Secure - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности

1 ОБЩИЕ СВЕДЕНИЯ - 21. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 22. ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 23. ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226-ст. 24. ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст - - Значение характеристики не может изменяться участником закупки

1.5 Сроки начала и окончания работ Начало работ: с 01.06.2024 Окончание работ: по 13.12.2024 Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом-графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего Технического задания (далее – Календарный план)

1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определённом Контрактом в сроки, установленные п. 5.1 настоящего Технического задания, в соответствии с Календарным планом.

1.1 Наименование системы Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП, Система. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками, включая подготовку к размещению на единой цифровой платформе Российской Федерации «ГосТех» (далее – Работы). Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения»

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры

1.3 Основания для выполнения работ 1. Указ Президента Российской Федерации «О создании, развитии и эксплуатации государственных информационных систем с использованием единой цифровой платформы Российской Федерации «ГосТех» от 31.03.2023 № 231. 2. Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023. 3. Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства РФ от 03.11.2023 г. № 3097-р. 4. Федеральный закон от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 5. Федеральный закон от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 6. Федеральный закон от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости. 7. Постановление Правительства РФ от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 8. Постановление Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»

10. Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1. Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 2. Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 3. Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 4. Федеральный закон «О федеральном бюджете на 2024 год и на плановый период 2025 и 2026 годов» от 27.11.2023 № 540-ФЗ. 5. «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 6. Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 7. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 8. Постановление Правительства РФ от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 9. Постановление Правительства Российской Федерации от 28.11.2011 № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме». 10. Постановление правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»

11. Постановление правительства Российской Федерации от 16.11.2015 № 1236 и «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 12. Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех». 13. Протокол стратегической сессии под председательством Председателя Правительства Российской Федерации М.В. Мишустина по созданию, развитию и эксплуатации единой цифровой платформы Российской Федерации «ГосТех» от 10.05.2023 № 2. 14. Методические рекомендации по проектированию и утверждению целевой архитектуры домена с использованием единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 13.07.2022 № 26. 15. Методические рекомендации «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 № 30. 16. Методические рекомендации по эксплуатации государственных информационных систем на Единой цифровой платформе «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54.

17. Методические рекомендации «Стандарт по управлению динамической инфраструктурой Единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54. 18. Методические рекомендации по разработке разделов технического задания, составу и содержанию требований, включаемых в техническое задание на создание, развитие государственных информационных систем, создаваемых (развиваемых) на единой цифровой платформе Российской Федерации «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.12.2023 № 47пр. 19. Методические рекомендации по вопросам разработки государственных информационных систем с использованием платформы «ГосТех» и определения обязательности повторного использования цифровых продуктов платформы «ГосТех» при их создании и развитии, утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.10.2023 № 47пр. 20. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст

2 НАЗНАЧЕНИЕ И ЦЕЛИ РАЗВИТИЯ СИСТЕМЫ - 2.1 Назначение Системы АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социально поддержки (защиты) на транспорте в безбумажный формат - - Значение характеристики не может изменяться участником закупки

2.2 Цели развития Системы Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363 р. Обеспечение комфортных мультимодальных поездок, в т.ч. с использованием единого цифрового инструмента оплаты проезда и возможности применения цифровых льгот и субсидий. Недостаточное проникновение бесконтактных средств оплаты проезда, включая полностью цифровые инструменты, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенной на заседании Президиума Госсовета по развитию общественного транспорта 17.08.2023. Целями развития Системы является подготовка для ее размещения на ЕЦП «ГосТех», а также расширение видов обрабатываемых транспортных льгот, субсидий и компенсаций, а также типов перевозочных документов, видов транспорта, типов получателей мер социальной поддержки (защиты), регионов и перевозчиков, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками в межрегиональном и внутрирегиональном сообщении, в том числе в рамках мультимодального заказа

2.3 Состав выполняемых задач Для реализации указанных целей развитие Системы должно решать следующие задачи: 1. Развитие АИС УЛСП, проработку механизмов и подготовку к миграции Системы на ЕЦП «ГосТех», предусматривающее: – разработку сервиса сбора, обработки и хранения данных о региональных тарифах и льготах, представляющего собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан; – разработку сервиса «Личный кабинет региона», предназначенного для отображения статистических данных по тарифам (скидкам) на транспорт и льготам; – разработку сервиса «Маломобильные», предназначенного для обеспечения возможности маломобильным категориям населения оформлять запрос на сопровождение в объектах транспортной инфраструктуры, а также осуществлять заказ парковочного разрешения на объектах транспортной инфраструктуры; – разработку «Сервиса подтверждения льготных перевозок по электронным транспортным требованиям», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов и провоза багажа на железнодорожном транспорте в пригородном сообщении и дальнем следовании по служебным и личным надобностям; – разработку «Сервиса подтверждения льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов на железнодорожный транспорт в пригородном сообщении и дальнем следовании лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры и в соответствии с нормативными правовыми актами РФ имеющим право на льготный проезд;

2. Модификация функционала сервисов АИС УЛСП с целью обеспечения автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область («житель КГД» и «Студент КГД»);

3. Обеспечение возможности информационного взаимодействия: – с цифровыми сервисами, обеспечивающими функционирование виртуальной социальной карты (далее – ВСК) с целью обеспечения межведомственного взаимодействия и обмена данными по федеральным и региональным мерам социальной поддержки (защиты) на транспорте для разных видов транспорта и типов сообщения с целью реализации положений Постановления Правительства Российской Федерации от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами»; – с информационными системами, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня;

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

4 ТРЕБОВАНИЯ К СИСТЕМЕ - 4.2.1.2 Требования к модификации Подсистемы хранения и обработки информации С целью обработки и хранения полученных от систем-источников новых типов сведений должна быть выполнена модификации внутримашинной информационной базы в части подтверждения личности и типа пассажира, включая следующие таблицы: – PassengersRequests – таблица данных запроса от ПСП по пассажиру; – Passengers – таблица данных пассажира; – IdentityConfirmations – таблица данных результатов подтверждения личности пассажиров; – PassengerTypeConfirmations – таблица данных результатов подтверждения типов пассажиров; – Document – таблица данных документов удостоверяющих личность пассажиров. Дополнительно со стороны внутренней логики подтверждения личности и типа пассажира должна быть выполнена модификация в части: 1) обеспечения подтверждения типа пассажира «житель КГД» по следующим маркерам: - личность подтверждена во ФГИС ЕРН; - запрошенный во ФГИС ЕРН код региона постоянной регистрации пассажира совпадает с кодом региона Калининградской области. Возрастные ограничения на новые типы пассажира не должны применяться; 2) обеспечения подтверждения типа пассажира «студент КГД» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования, сведения подтверждают обучение пассажира в ВУЗе, расположенном на территории Калининградской области; - на пассажира с типом «Студент КГД» не должно накладываться требование о наличии постоянной регистрации в субъекте РФ «Калининградская область». 3) обеспечения подтверждения типа пассажира «Студент» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования сведения подтверждают обучение пассажира в ВУЗе, имеющем государственную аккредитацию на территории РФ на очной форме обучения. - на пассажира с типом «Студент» должно накладываться требование о наличии постоянной регистрации на территории РФ - - Значение характеристики не может изменяться участником закупки

4.2.2 Требования к реализации сервиса сбора, обработки и хранения данных о региональных тарифах и льготах Сервис сбора, обработки и хранения данных о региональных тарифах и льготах должен представлять собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан пилотных регионов, которое должно обеспечивать выполнение следующих функций: 1) предоставления региональным органам исполнительной власти, являющихся держателями реестров льготных категорий граждан, а также отвечающих за организацию транспортного обслуживания населения, программного интерфейса для консолидации данных по категориям получателей транспортных льгот; 2) унификации различных форматов данных о льготных категориях граждан и льготах в соответствии с реестрами и региональными нормативными правовыми актами для обеспечения единой таксономии региональных льгот; 3) отображения информации по видам, типам, форматам предоставления мер социальной поддержки (защиты) на разных видах транспорта и типах сообщения; 4) отображения информации о государственных информационных системах, обрабатывающих данных по мерам социальной защиты (поддержки) на транспорте, а также информационных системах перевозчиков разных видов транспорта, задействованных в процессах информационного обмена с целью перехода к безбумажному оформлению льготного проезда;

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологическом стеке (п. 4.2.8 настоящего Технического задания) в инфраструктуре Заказчика a. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика 2) Решение должно работать в изолированной сети (без доступа информационно-телекоммуникационной сети «Интернет») 3) Должна быть возможность редактировать список доверенных корневых сертификатов для решения a. По умолчанию список доверенных сертификатов должен быть пустым 4) Должна быть возможность редактировать список допустимых EKU (связано с п.п. 9) пункта 4.3.4.) a. По умолчанию список допустимых EKU должен быть пустым b. Список допустимых EKU должен вестись отдельно для каждого защищённого подключения 5) Допускается использование только кластеризованных баз данных a. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика 6) Решение должно быть отказоустойчивым a. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов b. Использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо 7) Любые соединения, устанавливаемые решением, должны быть защищёнными a. Защищёнными считаются соединения, устанавливаемые по протоколу HTTPS, либо с использованием протокола TLS b. Соединения, устанавливаемые в рамках одного пространства имён (namespace) и в рамках одной контейнерной платформы, могут использовать протокол HTTP, либо подключаться без использования протокола TLS c. План восстановления d. Допустимо только по согласованию с техническими специалистами Заказчика 8) Любая сервисная учётная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на неё задач a. Использование учётных записей с административными полномочиями не допускается

9) Реляционные базы данных решения должны соответствовать четвёртой нормальной форме или выше; 10) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy) 11) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity Access Management, IAM), имеющих сертификат ФСТЭК по 4-ому классу доверия и имеющимися у Заказчика 12) Контейнеры, разворачиваемые вне Kubernetes, должны разворачиваться с использованием docker compose a. Допустимо только по согласованию с техническими специалистами Заказчика 13) Разворачивание в платформу контейнеризации на базе Kubernetes должно производиться с использованием helm chart версии 3 a. Не допускается использование нескольких helm chart для разворачивания одного решения b. Допускается использование «зонтичного» helm chart (helm chart который запускает другие helm chart) c. Запрещается использование любого метода кодирования в файлах helm chart 14) Передать Заказчику в момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика: a. Пакеты, требуемые для работы решения b. Исходный код решения c. Контейнеры, требуемые для работы решения 15) Установка решения в продуктивный контур производится силами и сотрудниками Заказчика 16) Подрядчик не имеет доступа в продуктивный контур a. Запрещается передача данных из тестового контура в продуктивный

4.1.2 Требования к технологической архитектуре Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes в тестовом контуре на платформе «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом обязательна подготовка к использованию базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При осуществлении разработки и развития Подсистем, а также их подготовки к миграции на ЕЦП «ГосТех», следует использовать не только инструменты управления планированием, требованиями, релизами, дефектами, тестированием и отслеживанием версионности (услуги: управление планированием (1.20), управление требованиями (1.21), управление релизами (1.22), управление дефектами (1.23), управление тестированием (1.24)), но и инструменты управления сборкой программного обеспечения, а также аналитики и мониторинга производственного процесса. Результаты разработки, перед сборкой программного обеспечения, должны проходить анализ качества кода с использованием базового сервиса платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). В подсистемах, предусматривающих взаимодействие с пользователями Системы, веб серверы должны размещаться в рамках соответствующих пространств имен кластеров Kubernetes. Хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). Реализация хранения вложений в базах данных подсистем не допускается

Для каждой подсистемы, в зависимости от функционала, при подготовке к миграции на ЕЦП «ГосТех» необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом не допускается использование одной инсталляции СУБД для использования разными подсистемами. Для аутентификации всех уровней пользователей необходима интеграция подготовленных к миграции подсистем с сервисом IAM (при наличии технологической готовности ЕЦП «ГосТех») (услуга 1.13). Должна быть обеспечена возможность взаимодействия подсистем друг с другом для обеспечения сквозной передачи данных. В случае обоснованного использования ЦОД, не относящегося к платформе «ГосТех», параметры ЦОД, в котором размещается ГИС, должны соответствовать требованиям ГОСТ Р 70139-2022 для ЦОД класса ГИС-3, а также параметрам отказоустойчивости и катастрофоустойчивости с учетом требований Приказа Минцифры России от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех», а также иметь действующие аттестаты соответствия требованиям по защите информации уровня защищенности персональных данных не ниже УЗ-2 и классу защищенности К2. При проработке механизмов и порядка миграции существующих подсистем АИС УЛСП на платформу «ГосТех» необходимо обеспечить переход на использование соответствующего технологического стека, в частности: 1. Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

5) самостоятельного ввода, редактирования и удаления информации, хранящейся в сервисе, с помощью инструментов Личного кабинета региона согласно п. 4.2.3. Технического задания; 6) формирования и хранения статистических данных для их отображения в сервисе «Личный кабинет региона». С целью реализации функциональности сбора реестров в Сервисе должен быть реализован модуль Подсистемы информационного обмена, который должен поддерживать импорт данных в файловом формате, обмен данными с использованием API и осуществлять информационный обмен с использованием СМЭВ. Выбор формата обмена данными зависит от технологической готовности на стороне системы РОИВ. Обязательный набор сведений регионального реестра должен включать в себя: – СНИЛС; – код льготы согласно классификатору СФР (ЕГИССО); – дата начала действия льготы; – дата окончания действия льготы. В качестве дополнительной НСИ от РОИВ должна передаваться и своевременно обновляться справочная информация, содержащая перечень кодов и описаний льготных категорий граждан. Блок-схема сервиса «Сбора, обработки и хранения данных о региональных тарифах и льготах» представлена на Рис. 3

4.2.3 Требования к реализации сервиса «Личный кабинет региона» Сервис «Личный кабинет региона» должен представлять собой инструмент, позволяющий РОИВ управлять данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании и пр. Сервис должен представлять собой web интерфейс, являющийся Frontend-компонентом сервиса сбора, обработки и хранения данных о региональных тарифах и льготах (требования приведены в п. 4.2.2 Технического задания), позволяющий управлять таксономией транспортных льгот региона, и иметь следующую функциональность: 1) заведение и изменение региональных нормативных правовых актов (далее - НПА), регламентирующих меры социальной защиты (поддержки) на транспорте, предоставляемые отдельным категориям граждан на территории субъекта РФ; 2) заведение и изменение перечня транспортных мер социальной защиты (поддержки) граждан, регламентированными НПА, действующими на территории субъекта, включая вид, тип, формат предоставления льгот на различных видах транспорта; 3) получение данных льготных категорий граждан региона путем импорта реестров, а также информационного обмена через API или СМЭВ; 4) отображение дашборда со статистическими данными о льготах региона с разделением по видам транспорта и категориям получателей льгот. Перечень отображаемых данных и формат их отображения должен быть согласован с Заказчиком на этапе технического проектирования

2. В качестве системы управления базами данных необходимо использовать базовые сервисы платформы «Гостех» указанные в п. 4.1.1 Технического задания. 3. В качестве объектного хранилища необходимо обеспечить переход на сервис объектное хранилище платформы «ГосТех» (услуга 1.8). При доработке подсистем АИС УЛСП необходимо использовать языки программирования, позволяющие проводить анализ исходного кода на наличие уязвимостей и незадекларированных возможностей, применяемых на платформе «ГосТех». Для разработки могут быть использованы один или несколько языков программирования из списка: Python; Golang (Go); Node.js; Java; Ruby; .net; C#; HTML, CSS, JavaScript, JSF, TypeScript; React.js; VueJS. При необходимости допускается использование иных языков программирования по согласованию с Заказчиком. Использование выбранного языка не должно приводить к обязательности использования программного обеспечения (средств компиляции и прочего) иностранного производства. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика

4.1.3 Требования к интеграционной архитектуре Взаимодействие со сторонними и смежными информационными системами и сервисами при развитии Системы должно осуществляться с использованием процедур и методов, поддерживаемых тем или иным решением. Определение соответствия структуры информации внешних и смежных систем со структурой информации АИС УЛСП должно осуществляться по заранее определенным правилам соответствия с возможностью настройки сопоставления. Правила определения соответствия должны использоваться для автоматического преобразования входящей и исходящей информации. Информационная совместимость должна обеспечиваться согласованием общих справочников и общих классификаторов. Хранение идентификаторов элементов НСИ и основных данных, используемых внешними и смежными системами, должно осуществляться с возможностью настройки сопоставления с аналогичными идентификаторами Систем, с последующим автоматическим преобразованием идентификаторов при обработке входящих и формировании исходящих сообщений. В рамках реализации программных сервисов, обеспечивающих взаимодействие внутренних компонентов Системы между собой при подготовке к миграции необходимо обеспечить использование базового компонента платформы «ГосТех» «Сервис управления очередями сообщений» в целях снижения связности между компонентами ПО при их взаимодействии, а также созданию высокодоступной и высоконадежной системы обмена сообщениями. Взаимодействие внутренних компонентов системы должно быть документировано в рамках технического проектирования

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

4.2.4 Требования к реализации сервиса «Маломобильные» Сервис «Маломобильные» предназначен для подтверждения принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом. Сервис должен предоставлять функциональность подтверждения группы инвалидности: – инвалид 1 группы, – инвалид 2 группы, – инвалид 3 группы, – ребенок-инвалид посредством отправки запроса, содержащего СНИЛС пассажира, полученный из информационных систем перевозчиков, в ГИС ЕЦП (требования к интеграции с ГИС ЕЦП описаны в п. 4.2.1.1.1 настоящего Технического задания). Получение сервисом «Маломобильные» номера СНИЛС для последующего подтверждения группы инвалидности должно быть предусмотрено для следующих сценариев: 1) создание заявки на сопровождение в выбранных объектах транспортной инфраструктуры железнодорожного транспорта, осуществляющих деятельность по обслуживанию пассажиров при покупке билета, посадке/высадке на поезд; 2) содействие резервированию специальных мест для инвалидов в поездах дальнего следования в дополнение к имеющимся цифровым сервисам перевозчиков; 3) заказ парковочного разрешения для инвалидов в выбранных объектах транспортной инфраструктуры железнодорожного транспорта. Порядок создания заявки, в рамках вышеуказанных сценариев предусматривает ввод соответствующих сведений в информационных системах перевозчиков, в связи с чем для Сервиса «Маломобильные» собственного интерфейса для ввода данных и функциональности валидации личности не предусматривается

Для организации информационного обмена данными по маломобильным категориям граждан между АИС УЛСП и информационными системами перевозчиков и организаций железнодорожного транспорта, должна быть предусмотрена возможность реализации интеграционного взаимодействия посредством REST API. В сервисе должны быть предусмотрены возможности развития его функционала, в частности перспективное расширение на все виды транспорта, а также отработка сценариев подтверждения сведений об управлении транспортным средством инвалидом или перевозке транспортным средством инвалида, посредством запроса в ГИС ЕЦП по государственному номеру транспортного средства при создании заявки на реализацию права на бесплатное использование мест для парковки транспортных средств, в случае реализации смежными системами такой функциональности. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.1.15 Требования к персоналу Численность персонала Системы должна определяться с учетом следующих требований: – структура Системы должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности. – системное и прикладное программное обеспечение Системы должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП утверждается штатным расписанием Оператора АИС УЛСП. Численность персонала АИС УЛСП должна уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы. Система должна быть спроектирована и реализована с учетом её эксплуатации функциональными группами пользователей: – системный администратор: доступ на уровне системного и прикладного ПО без непосредственного доступа к функциям подсистем федерального сегмента и регионального сервиса; – администратор Системы: доступа к функциям подсистем федерального сегмента и регионального сервиса через графический интерфейс; – оператор федерального сегмента: доступ к подсистемам федерального сегмента и регионального сервиса через графический интерфейс; – оператор регионального сервиса: доступ к подсистемам регионального сервиса через графический интерфейс

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

4.3.3 Требования к защищённым соединениям и шифрованию 1) Решение должно содержать запрет на применение протокола HTTP в явном виде 2) При подключении к решению с использование протокола HTTP должно происходить перенаправление на HTTPS 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 5) Допустимо использовать только эллиптические кривые из списка a. X25519 b. prime256v1 c. secp521r1 d. secp384r1 6) Допустимо использовать только алгоритмы шифрования из списка a. ECDHE-ECDSA-AES128-GCM-SHA256 b. ECDHE-RSA-AES128-GCM-SHA256 c. ECDHE-ECDSA-AES256-GCM-SHA384 d. ECDHE-RSA-AES256-GCM-SHA384 e. ECDHE-ECDSA-CHACHA20-POLY1305 f. ECDHE-RSA-CHACHA20-POLY1305 g. DHE-RSA-AES128-GCM-SHA256 h. DHE-RSA-AES256-GCM-SHA384 7) Решение должно содержать явный запрет на использование алгоритмов шифрования, не входящих в пункт 6) п.п. 4.3.3 8) Решение должно содержать явный запрет на использование режима сцепления блоков шифротекста (CBC) при шифровании 9) Решение должно содержать явный запрет на использование следующих алгоритмов хеширования данных: a. MD5 b. SHA1 10) Запрещено использовать алгоритм RSA с длинной ключа менее 4096 бит

4.1.4 Требования к режимам функционирования Функционирование Системы должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Система должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме АИС УЛСП обеспечивает возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Системы, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Системы с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Системы и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Системы

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

4.3.4 Требования к использованию и работе с сертификатами Все алгоритмы проверки, требования, наименование полей и иные технические термины применяются здесь и далее в соответствии со следующими стандартами: 1) RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» 2) RFC 8399 «Internationalization Updates to RFC 5280» 3) RFC 6818 «Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» Список применяемых терминов: Термин в документе Термин по RFC Самозаверенный сертификат Self-signed certificate Самоподписанный сертификат Self-signed certificate Отзыв Revocation Центр сертификации Certification Authority Субъект сертификата Subject Альтернативное имя субъекта сертификата Subject Alternative Name Период действия Validity 1) При подключении по защищённому каналу решение должно проверять предоставляемый сертификат на доверие, отзыв и соответствие его параметров дополнительным требованиям 2) В случае, если сертификат признан недоверенным, подключение не может быть установлено a. В случае, если сертификат перестал быть доверенным в момент, когда подключение уже было установлено, подключение должно быть прервано 3) Сертификат, предъявляемый при установлении соединения не может быть самоподписанным a. В противном случае выдать ошибку следующего содержания «End entity certificate is self-signed» и не устанавливать/разорвать защищённое соединение 4) Проверка сертификата должна происходить не реже, чем раз в час, даже если подключение установлено

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

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

4.2.5 Требования к реализации сервиса льготных перевозок по электронным транспортным требованиям Под электронным транспортным требованием должен подразумеваться электронный документ, наличие которого является основанием для пассажира на получение проездного документа, а для перевозчика – на компенсацию за перевозку. Сервис льготных перевозок по электронным транспортным требованиям должен быть предназначен для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании. Сервис должен предоставлять следующую функциональность: – Получение идентификатора ЭТТ из подключаемой внешней информационной системы; – формирование и передача запроса на цифровую проверку; – проведение проверки и формирование результата; – предоставление (отказ в предоставлении) услуги по продаже билета на железнодорожный транспорт пригородного и дальнего сообщения по ЭТТ. Сервис должен поддерживать следующий порядок информационного обмена: 1) оформление ЭТТ во внешней информационной системе организации, включающее в себя: a. создание заявки с заполнением сведений: i. личные данные пассажира; ii. данные поездки; iii. данные о перевозимых членах семьи; iv. цель; v. дата выдачи; vi. тип требования. b. согласование заявки и формирование ЭТТ; c. сохранение данных ЭТТ во внешней информационной системе организации; d. генерацию уникального идентификатора ЭТТ, позволяющего однозначно определить запись в системе; e. передачу пользователю идентификатора ЭТТ

2) передачу уникального идентификатора ЭТТ из внешней информационной системы в АИС УЛСП с последующим сохранением идентификатора в архиве Сервиса перевозок по ЭТТ; 3) ввод пассажиром на официальном ресурсе организации железнодорожного транспорта параметров поездки с указанием наличия права на льготу; 4) ввод пассажиром уникального кода ЭТТ на веб-странице авторизации АИС УЛСП, куда он был переадресован с официального ресурса организации железнодорожного транспорта; 5) сопоставление в АИС УЛСП уникального идентификатора ЭТТ, полученных из внешней информационной системы на шаге 2 с уникальным идентификаторам ЭТТ, полученным от пассажира и информационной системы организации железнодорожного транспорта на шаге 4; 6) передача результирующих сведений в информационную систему перевозчика для оформления билета / отказа в оформлении билета. Для обеспечения вышеуказанного взаимодействия АИС УЛСП должна быть интегрирована с ИС, хранящей данные по ЭТТ и с системами интернет-продаж перевозчиков. Все операции, совершенные с ЭТТ, должны протоколироваться в АИС УЛСП. Взаимодействие АИС УЛСП с информационными системами организаций и предприятий, осуществляющих оформление ЭТТ, должно происходить по каналам связи, защищенным с использованием шифровальных (криптографических) средств, сертифицированных ФСБ России. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АИС УЛСП должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АИС УЛСП. Интерфейс АИС УЛСП должен обеспечивать возможность масштабирования под любую ширину экрана и отображение на мобильных устройствах. Указанное действие должно происходить за счёт изменения ширины колонок сайта, их переноса вниз предыдущей колонки или отключения второстепенных элементов сайта для малых разрешений экранов (адаптивная верстка). Визуальное представление элементов пользовательского интерфейса разрабатываемой АИС УЛСП, адаптивная верстка интерфейса Системы, состав отображаемой информации подлежит согласованию Заказчиком в процессе выполнения работ по созданию Системы

5) Система должна проводить проверку имени субъекта сертификата и проверку альтернативного имени субъекта сертификата a. Имя, к которому осуществляется подключение, должно совпадать с субъектом сертификата b. Имя, к которому осуществляется подключение, должно совпадать с альтернативным именем субъекта сертификата c. В случае, если имя, к которому осуществляется подключение, совпадает с альтернативным именем субъекта сертификата, но не совпадает с субъектом сертификата, считать проверку успешной d. В любом другом случае выдать ошибку следующего содержания «Subject name or SAN does not match the connection» и не устанавливать/разорвать защищённое соединение 6) Система должна проверять, что период действия сертификата уже начался и ещё не истёк a. Значение в секции notBefore должно быть меньше, чем текущая дата b. Значение в секции notAfter должно быть больше, чем текущая дата c. В противном случае выдать ошибку следующего содержания «Certificate expired or not yet valid» и не устанавливать/разорвать защищённое соединение 7) Система должна проверять цепочку доверия вплоть до корневого сертификата a. Предоставленный при подключении исходный сертификат (Сертификат А) должен содержать поле «Authority Information Access» i. В противном случае выдать ошибку следующего содержания «No AIA field available» и не устанавливать/разорвать защищённое соединение b. Сертификат, представленный в данном поле (Сертификат Б), должен быть тем сертификатом, который подписал Сертификат А i. В противном случае выдать ошибку следующего содержания «Certificate signed not by CA in AIA» и не устанавливать/разорвать защищённое соединение c. Если сертификат Б является самоподписанным, то проверить, что сертификат находится в списке доверия i. В противном случае выдать ошибку следующего содержания «Root CA is not trusted» и не устанавливать/разорвать защищённое соединение d. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а

4.1.5 Показатели назначения Ключевым показателем назначения Системы является выполнение действующих, а также функциональных требований, перечисленных в разделе 4.2 настоящего документа. Архитектура Системы должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание: изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Система должна обеспечивать возможность одновременного доступа пользователей в соответствии с Таблицей 3 – Показатели производительности, при условии использования разных учётных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Система должна обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Системы. Показатели назначения в части использования инфраструктурных технологических сервисов, базовых сервисов и типовых решений платформы «ГосТех»: ? использование не менее 10 базовых сервисов в составе Системы; ? обеспечение совместимости уровня «Compatible» мигрируемых подсистем Системы с платформой «ГосТех»

Иные показатели назначения представлены в таблицах 2, 3 и 4 ниже. Таблица 2 – Показатели назначения № Параметр Значение 1 Количество профилей пассажиров не менее 1 млн. человек 2 Система должна обеспечивать сохранение производительности при ежемесячном приросте данных в хранилище не менее 350 Mб 3 Период хранения данных не менее 3 лет Таблица 3 – Показатели производительности № Показатель Штатный режим Пиковый режим 1 Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 100 2 Количество одновременно подключенных смежных систем 30 100 Таблица 4 – Целевое время отклика № Показатель Средняя величина не более, с Максимальная величина не более, с Время отклика на запрос в API 1 при получении данных от одного источника 0,2 1 2 при обновлении данных от одного источника 0,2 1 Время отклика на запрос в Административной панели 3 при выполнении операций поиска информации 3 10 4 при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП не учитывает задержку формирования ответа на запрос на стороне системы источника. Показатели назначения АИС УЛСП могут быть уточнены на этапе технического проектирования

4.1.6 Требования к надежности функционирования и доступности для пользователей Показатели надежности Системы должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Система должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций. В целях обеспечения надежности и сохранности информации при подготовке к миграции должны использоваться сервисы и средства платформы «ГосТех». Должно быть предусмотрено резервное копирование (в т.ч. средствами Платформы «ГосТех» при осуществлении миграции) как по команде администратора, так и по заранее составленному расписанию, что должно определяться соглашением, заключенным между Оператором АИС УЛСП и Оператором платформы «ГосТех»

8) Система должна проверять сертификат на отзыв с использованием CRL или OCSP a. Предоставленный при подключении исходный сертификат (Сертификат А) НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Сертификат, взятый из поля «Authority Information Access» (Сертификат Б), НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Если сертификат Б является самоподписанным, то проверка отзыва не проводится и цикл завершается b. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а. 9) Система должна проверять, что значения в поле «Extended Key Usage» присутствуют в списке разрешённых EKU для конкретного подключения a. В противном случае выдать ошибку следующего содержания «Certificate’s EKU does not match approved ones» и не устанавливать/разорвать защищённое соединение 10) Система должна проверять поле «Basic Constraints» a. В случае, если поле отсутствует, выдать ошибку следующего содержания «Basic Constraints filed is empty» и не устанавливать/разорвать защищённое соединение b. В случае, если сертификат, предоставленный при подключении содержит значение TRUE в секции «CA», выдать ошибку следующего содержания «End entity certificate is CA certificate» и не устанавливать/разорвать защищённое соединение c. При проведении проверки согласно п.п. 7) пункта 4.3.4 проверять поле Basic Constraints согласно требованиям RFC 5280 (секция 4.2.1.9. Basic Constraints)

4.2 Функциональные требования к развитию АИС УЛСП 4.2.1 Требования к модификации существующих подсистем АИС УЛСП в рамках обеспечения поддержки новых типов мер социальной поддержки (защиты) пассажиров В связи с изменением нормативно-правовой базы, а также вводом в действие новых информационных систем федеральных органов исполнительной власти, участвующих в информационном обмене с АИС УЛСП, необходимо провести модификацию и доработку Системы с целью обеспечения цифрового подтверждения права на проезд по льготному, сниженному, специальному или безденежному тарифу для новых категорий пассажиров на разных видах транспорта, а также доработать подсистему информационного обмена АИС УЛСП с целью обеспечить устойчивый обмен данными с новыми системами-источниками и системами-потребителями. Модификация системы производится на мощностях Заказчика, разработанная Система запускается в опытную эксплуатацию в рамках продуктивного контура ФГБУ «СИЦ Минтранса России». 4.2.1.1 Требования к модификации Подсистемы информационного обмена Подсистема информационного обмена АИС УЛСП обеспечивает взаимодействие с системами-источниками и системами-потребителями, в частности с информационными системами Федеральной Налоговой службы России (ИС ФНС) и Социального Фонда России (ИС СФР), Министерства труда и социальной защиты Российской Федерации с целью проверки данных пассажира, получения данных о месте жительства и действующих льготных категориях гражданина

4.2.6 Требования к реализации сервиса льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы должен обеспечивать подтверждение прав на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. Подтверждение личности (авторизация) студентов должна включать сведения, позволяющие однозначно идентифицировать гражданина: 1) фамилия, имя, отчество (при наличии) обучающегося; 2) пол обучающегося; 3) дата рождения обучающегося; 4) СНИЛС обучающегося; 5) серия, номер, дата выдачи документа, удостоверяющего личность гражданина Российской Федерации обучающегося. В качестве основного идентификатора должен использоваться СНИЛС

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

4.2.7 Требования к реализации сервиса учета данных Виртуальных социальных карт В целях реализации Постановления Правительства РФ от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами» в рамках АИС УЛСП необходимо разработать Сервис учета Виртуальных социальных карт для обеспечения обмена данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт. Под виртуальными социальными картами подразумеваются уникальные обезличенные идентификаторы, формируемые с применением национальных платежных инструментов, указанных в части 2 статьи 30 Федерального закона «О национальной платежной системе» (далее – национальные платежные инструменты), при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами.

4.2.1.1.1 Требования к обеспечению обмена данным с ГИС ЕЦП Текущее взаимодействие АИС УЛСП в части проверки данных пассажира и получения информации о наличии у него действующих льготных категорий производится с ИС СФР по ВС «О соответствии фамильно-именной группы, даты рождения, пола и СНИЛС», а также по ВС «Сведения об инвалиде, получаемые из ФГИС ФРИ, для оказания транспортных услуг» посредством СМЭВ-3 по приведенным в Таблице 5 параметрам запроса. Таблица 5 – Параметры запроса Параметр Описание FamilyName Фамилия пассажира FirstName Имя пассажира Patronymic Отчество пассажира Snils СНИЛС пассажира Gender Пол пассажира BirthDate Дата рождения пассажира DisabilityGroup Группа инвалидности инвалида/ребенка-инвалида Moving Степень способности к самостоятельному передвижению AvailabilityWheelChair Наличие рекомендаций в обеспечении креслом-коляской В связи с вступлением в силу Федерального закона от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации» вдобавок к ранее созданным механизмам информационного обмена необходимо провести модификацию Подсистемы информационного обмена АИС УЛСП с целью обеспечения обмена данными с создаваемой в рамках указанного Федерального закона ГИС «Единая цифровая платформа в социальной сфере» (ГИС ЕЦП)

4.3.5 Требования к контейнерам в платформе контейнеризации на базе Kubernetes 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.) 4) Каждый контейнер должен содержать следующие конфигурационные параметры a. securityContext.readOnlyRootFilesystem: true b. securityContext.runAsNonRoot: true 5) Каждый контейнер должен писать логи в stdout a. Допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки) b. Допускается запись логов в формате json c. Запрещается совмещение формата записи логов в рамках одного контейнера 6) Каждый pod должен быть снабжён network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера 10) Каждый контейнер должен содержать в себе liveliness и readiness probes a. Контейнер выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes 11) В контейнере не может запускаться более одного процесса 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.1.7 Требования по диагностированию Системы Компоненты АИС УЛСП должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности аппаратных средств, специального и общего ПО. АИС УЛСП должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы, а также мониторинга процесса выполнения программ. Система должна осуществлять ведение журналов инцидентов в электронном формате. При возникновении аварийных ситуаций либо ошибок в программном обеспечении, диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и решения проблемы системными администраторами либо разработчиками. Диагностирование АИС УЛСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. При подготовке к миграции на ЕЦП «ГосТех» диагностирование и мониторинг состояния Системы должны производиться базовыми сервисами Платформы «ГосТех». Диагностирование Системы должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности Системы. В процессе диагностирования должна быть обеспечена: – регистрация диагностических сообщений при работе специального программного обеспечения; – передача журналов и метрик в централизованную систему мониторинга платформы «ГосТех» (при подготовке к миграции), в том числе информации о появлении критических событий, а также логирования событий; – генерация оповещений о возможности появления критичных событий в работе Системы. Полный перечень параметров, подлежащих диагностике, определяется на стадии технического проектирования

4.1.8 Требования к транспортабельности Не предъявляются. 4.1.9 Требования к эксплуатации и техническому обслуживанию Требования к режимам функционирования Системы описаны в п. 4.1.4. При подготовке к миграции на ЕЦП «ГосТех» для обеспечения задач эксплуатирующего персонала по диагностированию состояния Системы и предотвращению аварийных состояний необходимо обеспечить постоянное диагностирование средствами Платформы «ГосТех». 4.1.10 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.11 Требования к возможностям развития Системы Архитектура Системы должна предусматривать возможность: – расширения состава внешних и смежных информационных систем-источников информации; – расширения состава внешних и смежных информационных систем-получателей информации; – расширения состава и наполнения БД АИС УЛСП, нормативно-справочной информации, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание Системы; – внедрения дополнительных функциональных подсистем; – расширения функциональных возможностей существующих подсистем. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем. Отказоустойчивость Системы должна обеспечиваться Заказчиком средствами действующего технологического стека АИС УЛСП, а также сервисами платформы ЕЦП «ГосТех» (при обеспечении технологической готовности платформы)

4.3.6 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом a. Покрытие кода unit-тестами должно быть не менее 95% 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования a. Если не указано иное, то нагрузочное тестирование проводится со следующими допущениями i. Одновременная работа 10 администраторов в интерфейсе администраторов ii. Одновременная работа 1 000 пользователей в интерфейсе пользователей iii. Одновременное чтение и запись данных пользователями iv. Под данными подразумеваются записи в системе, которые пользователи могут получать и редактировать. В случае наличия нескольких типов таковых записей, необходимо провести нагрузочное тестирование на каждый такой тип 3) Исполнитель должен предоставить тестовые данные для проведения функционального тестирования a. Тестовые данные не могу совпадать с данными, которые будут в системе при вводе её в эксплуатацию

Подсистема информационного обмена АИС УЛСП должна быть доработана с целью обеспечения межведомственного информационного взаимодействия с ГИС ЕЦП СФР посредством СМЭВ 4 с целью подключения к витринам Национальной системы управления данными и обеспечения информационного обмена по следующему перечню сведений: - Код категории получателя меры социальной защиты (поддержки); - Гражданство; - Сведения об отнесении граждан к категориям граждан, имеющим право на получение мер социальной защиты (поддержки): o Сведения о детях-сиротах и детях, оставшихся без попечения родителей, лицах из числа детей-сирот и детей, оставшихся без попечения родителей, лицах, потерявших в период обучения обоих родителей или единственного родителя: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о гражданах, пострадавших в результате радиационных или техногенных катастроф: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о ветеранах Великой Отечественной войны, инвалидах Великой Отечественной войны, членах семей погибших (умерших) инвалидов Великой Отечественной войны, участников Великой Отечественной войны § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о бывших несовершеннолетних узниках концлагерей, гетто, других мест принудительного содержания, созданных фашистами и их союзниками в период Второй мировой войны: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно)

- Сведения о медико-социальной экспертизе и установлении инвалидности и о лице, признанном инвалидом: o группа инвалидности; o причина инвалидности; o срок, на который установлена инвалидность; o дата установления инвалидности; o сведения о транспортном средстве, управляемом инвалидом, или транспортном средстве, перевозящем инвалида и (или) ребенка-инвалида, в том числе государственный регистрационный номер транспортного средства, марка и (или) модель (коммерческое наименование) транспортного средства (если они были присвоены изготовителем транспортного средства), дата и время размещения (изменения) сведений о транспортном средстве, дата подачи заявления о размещении сведений о транспортном средстве, дата и время начала фактической эксплуатации транспортного средства, дата и время окончания фактической эксплуатации транспортного средства. - Параметром для формирования запроса к витрине ГИС ЕЦП должен быть СНИЛС

В рамках сервиса учета Виртуальных социальных карт АИС УЛСП должна быть реализована возможность получения данных по гражданам, относящимся к категории получателей мер социальной поддержки (защиты) регионального уровня «Члены многодетной семьи», проживающих на территории регионов, внедряющих ВСК, и оформивших ВСК, для последующего использования этих данных при цифровом подтверждении права пассажира на оформление авиабилета по специальному тарифу согласно ПП РФ №215 от 02.03.2018 г., а также при оформлении проездного документа на железнодорожный транспорт пригородного сообщения путем передачи соответствующих цифровых подтверждений в ПСП и/или подключенные информационные системы перевозчиков. Информационное взаимодействие между Витринами данных ВСК и АИС УЛСП должно осуществляться посредством СМЭВ-4, а с ПСП и организациями железнодорожного транспорта – посредством REST API. Конкретный способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.2.8 Требования к выполнению работ по проработке механизмов и подготовке к миграции АИС УЛСП на ЕЦП «ГосТех» Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes на платформе «ГосТех» (при наличии технологической готовности платформы). При этом при подготовке к миграции обязательно использование базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При подготовке к миграции хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех». Текущий технологический стек АИС УЛСП включает в себя: 1. ОС АЛЬТ версии 8 СП; 2. ASP.NET(C#); 3. Blazor(server); 4. Entity Framework; 5. JavaScript; 6. HTML; 7. CSS; 8. PostgreSQL; 9. Kubernetes; 10. Docker; 11. SonarQube. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика. При реализации механизмов миграции АИС УЛСП на платформу «ГосТех» необходимо обеспечить подход к использованию технологического стека в соответствии с диаграммой развертывания, указанной на Рис. 4 – Диаграмма развертывания АИС УЛСП на платформе «ГосТех» (может быть изменено по согласованию с Заказчиком на этапе технического проектирования). Рис. 4 Диаграмма развертывания АИС УЛСП на платформе «ГосТех»

4.2.1.1.2 Требования к обеспечению обмена данными с ИС ФНС России В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - гражданин Российской Федерации, зарегистрированный по месту жительства на территории Калининградской области. В целях модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка новых типов пассажира: - «житель КГД». С целью поддержки предоставления цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу для нового типа пассажира «житель КГД» технологический процесс взаимодействия АИС УЛСП с ИС ФНС должен производиться по ВС «Предоставление из ЕРН по запросу сведений о физическом лице» посредством СМЭВ и должен включать в себя следующие задачи: 1) Получение запросов от ПСП, содержащих данные Пассажиров: - идентификатор Пассажира в запросе; - фамилия; - имя; - отчество (при наличии); - дата рождения; - тип документа, удостоверяющего личность; - серия и номер документа, удостоверяющего личность; - пол; - номер СНИЛС (необязательное поле запроса); - типы пассажира на подтверждение. 2) Формирование и отправка АИС УЛСП запроса для подтверждения личности пассажира в ИС ФНС. Данные пассажира, передаваемые в запросе к ИС ФНС: - фамилия, имя, отчество (далее – ФИО) (отдельными полями); - дата рождения; - пол; - тип документа, удостоверяющего личность пассажира; - серия и номер документа, удостоверяющего личность пассажира; - признак того, что в ответе нужны данные о регионе регистрации гражданина

3) В случае подтверждения гражданина по полному совпадению данных ИС ФНС необходимо обеспечить обработку ответа в сторону АИС УЛСП, содержащего положительный ответ о подтверждении личности, и дополнительно по подтвержденному пассажиру предоставление следующих данных: - сведения о регистрации гражданина Российской Федерации по месту жительства; - информация по другим документам, удостоверяющим личность (тип, серия и номер), имеющихся в системе данных федеральных органов исполнительной власти по данному гражданину. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «житель КГД», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «У пассажира отсутствует постоянная регистрация в субъекте РФ, входящем в Калининградскую область» (для типа пассажира «житель КГД»). Таким образом, общий порядок информационного обмена должен иметь следующий вид: 1) ПСП отправляет запрос в АИС УЛСП, посредством внешнего API, содержащий данные пассажира. 2) Внешний API передает запрос в scheduler (планировщик задач). Scheduler проверяет по хешу запроса наличие данных подтверждения личности и типа пассажира в БД АИС УЛСП. При наличии ответа: - возвращает его в ответе на запрос внешнего API. - внешний API отправляет ответ в ПСП, содержащий данные подтверждения личности и типов пассажира, а также найденные ДУЛ. При отсутствии ответа в БД: - возвращает в ответ во внешний API данные запроса от ПСП в составе: - идентификатор пассажира в запросе; - данные ДУЛ из запроса ПСП; - внешний API перенаправляет ответ в ПСП (переход к шагу 5)

4) Scheduler передает запрос в сервис взаимодействия с адаптером СМЭВ-3 smev-exchanger для формирования запросов в адаптер СМЭВ 3. 5) Адаптер СМЭВ-3 производит взаимодействие с инфраструктурой ИС поставщика (ФНС). 6) Полученный ответ от ИС поставщика Адаптер СМЭВ-3 передает в scheduler. 7) Scheduler осуществляет проверку осуществляет проверку на подтверждение личности и типов пассажира исходя из данных от ПСП и ИС поставщика и записывает результирующий ответ в БД

4.1.12 Требования к информационной безопасности 4.1.12.1 Подсистема обеспечения информационной безопасности АИС УЛСП Подсистема обеспечения информационной безопасности разработана в рамках контракта от 03.07.2023 № ОК/23_03 на развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу». Работы в рамках настоящего Технического задания не должны приводить к необходимости пересмотра или корректировки действующей ПОИБ АИС УЛСП. Система с учетом выполняемых по настоящему Техническому заданию работ должна соответствовать требованиям, предъявляемым к информационным системам не ниже класса защищенности «К2» и составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных не ниже 2-го уровня защищенности

4.1.13 Требования по сохранности информации при авариях Сохранность информации Системы должна обеспечиваться Заказчиком, а при выполнении миграции на ЕЦП «ГосТех» (при технологической готовности ЕЦП «ГосТех») – с применением технологии резервного копирования на основе сертифицированных ФСТЭК России решений и дублирования компонент Платформы «ГосТех». Сохранность информации Системы должна обеспечиваться: 1) при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; 2) при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий баз данных, программных файлов Системы, а также загружаемых файлов; 3) при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; 4) при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Сохранность информации Системы должна также быть обеспечена при возникновении следующих событий: 1) ошибки в работе пользователей; 2) прерывание связи сети Интернет; 3) сбой программного обеспечения Системы; 4) сбой программного обеспечения и/или компонентов, в т.ч. Платформы «ГосТех»; 5) отказ одиночного сервера; 6) отключение питания; 7) разрушение жестких дисков серверов

4.2.1.1.3 Требования к обеспечению обмена данными с информационными системами, обеспечивающими учет обучающихся на различных ступенях образования В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - учащийся высшего учебного заведения, расположенного на территории Калининградской области, имеющий документ, подтверждающий статус учащегося очной формы обучения в порядке, установленном нормативным правовым актом исполнительного органа государственной власти Калининградской области, осуществляющего на территории Калининградской области государственное управление в сфере образования, полномочия Российской Федерации в сфере образования, переданные для осуществления органам государственной власти субъектов Российской Федерации, а также полномочия в сфере организации отдыха и оздоровления детей. В рамках модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка нового типа пассажира: «Студент КГД». В рамках модификации АИС УЛСП должна быть реализована поддержка нового типа пассажира: «Студент»

В рамках модификации Подсистемы информационного обмена АИС УЛСП для получения сведений, необходимых для обработки типов пассажира «Студент» и «Студент КГД», и подтверждения права предоставления льготы требуется обеспечить информационное взаимодействие с информационными системами, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования с целью получения сведений о документах, подтверждающих обучение (при их наличии) граждан, обучающихся в образовательных организациях высшего образования и научных организациях по программам ординатуры, ассистентуры-стажировки, программам подготовки научных и научно-педагогических кадров в аспирантуре с последующей передачи подтверждения права пассажира категории «студент» на льготный проезд

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

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, развернутых на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов согласно п. 4.1.1: 1) сервис аудита (услуга 1.15); 2) сервис журналирования (услуга 1.14); 3) сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Для аутентификации пользователей при подготовке к миграции необходима интеграция с сервисом IAM (услуга 1.13)

В целях развития АИС УЛСП и подготовки к миграции на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, необходимо использовать следующие сервисы: 4) сервис управление развертыванием программного обеспечения (услуга 1.31); 5) сервисы интеграционного взаимодействия (услуга 1.19); 6) сервисы управления очередями сообщений (1.10). Для взаимодействия со смежными системами в среде СМЭВ в составе механизмов миграции и развертки должен быть компонент «Интеграция со СМЭВ Platform V SMEV Gateway» (услуга 1.12). При подготовке к миграции для каждой подсистемы, в зависимости от функционала, необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (Сервис транзакционной СУБД (услуга 1.1), Сервис СУБД аналитического хранилища данных (услуга 1.5)). Для управления очередями сообщений должен использоваться Сервис управления очередями сообщений (услуга 1.10). Требования к технологической архитектуре и перечень используемых базовых сервисов могут быть скорректированы на этапе технического проектирования по согласованию с Заказчиком, а также исходя из условий технологической готовности платформы «ГосТех»

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Требования к документации 1) Схема сетевого взаимодействия a. Должна содержать все порты, которые используются для установления сетевых соединений; b. Должна содержать указания на протокол соединения (TCP/UDP); c. Должна содержать указание о направлении трафика между компонентами системы вплоть до уровня контейнера. 2) Архитектура решения a. Требуется использование нотации С4. 3) Перечень сервисных учётных записей, который содержит: a. Имя учётной записи; b. Компонент решения, где она применяется; c. Систему, к которой она подключается; d. Перечень привилегий, предоставленных данной учётной записи, в формате той системы, к которой данная учётная запись подключается. 4) Руководство по резервному копированию a. Руководство по резервному копированию должно содержать пошаговую инструкцию, которая позволит создать резервную копию всей системы (каждого компонента системы, который подлежит резервному копированию); b. В случае, если какой-то компонент системы не подлежит резервному копированию, в данном руководстве необходимо предоставить основания, почему резервирование компонента не требуется; c. Отдельно в руководстве должны содержаться рекомендации по резервному копированию баз данных решения, а именно: i. Частота создания полной резервной копии; ii. Частота создания инкрементальной резервной копии; iii. Длительность хранения созданных резервных копий

4.1 Требования к развитию Системы в целом В процессе работ по созданию должны сохраниться основные требования к построению архитектуры в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (то есть представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на подэтапе Технического проектирования. Система должна быть разработана с учетом необходимости информационного обмена с сервисами цифровой платформы мониторинга осуществления перевозок пассажиров по межрегиональным и муниципальным маршрутам, в соответствии с требованиями Перечня Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023

4.1.1 Требования к использованию существующих сервисов Платформы ГосТех при развитии Системы В целях обеспечения совместимости программной архитектуры АИС УЛСП с операционными системами и системами управления базами данных, используемыми в составе платформы «ГосТех», в рамках подготовки Системы к миграции необходимо реализовать возможность использования следующих сервисов: – Сервис Key-value СУБД (услуга 1.3) (здесь и далее услуги ЕЦП «ГосТех» обозначены в соответствии с Методическими рекомендациями «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 г. № 30); – Сервис транзакционной СУБД (услуга 1.1); – Сервис СУБД полнотекстового индекса (услуга 1.4). Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

4.2.1.3 Требования к модификации Подсистемы визуализации В рамках модификации Подсистемы Визуализации должны быть изменены пользовательские интерфейсы АИС УЛСП в части обеспечения учета и отображения сведений по новым типам пассажиров на панели управления Системы, а также вывода данных по новым типам пассажиров и льгот в разделе «Визуализация данных»

При подготовке к миграции Платформа «ГосТех» должна обеспечить уровень сохранности информации, позволяющий восстановить данные с минимальной потерей информации: 1) в случае отказа на уровне компонентов Платформы «ГосТех» – без потери информации; 2) в иных случаях отказа – восстановление данных за период не более 24 часов для PROD-стендов и не более 48 часов для остальных стендов (DEV-, TEST-, HT-, ПСИ- стендов) до возникновения аварии (из последней резервной копии). Для обеспечения сохранности информации Системы должны быть реализованы следующие функции (при подготовке к миграции - посредством Платформы «ГосТех»): 1) резервное копирование баз данных, программных и загружаемых файлов; 2) восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключении электрического питания, сбоях операционной системы и других) вычислительно-операционной среды функционирования; 3) восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Резервное копирование осуществляется не реже одного раз в день. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.1.14 Требования к патентной чистоте и патентоспособности 4.1.14.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.14.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.14.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.14.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.14.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам

- форма обучения (очная, очно-заочная, заочная, получение образования в семье, самообразование, экстернат). В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры»; - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры на территории Калининградской области», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «Пассажир отсутствует в системе-источнике данных»; o «Пассажир не является студентом ВУЗа на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе» (для типа пассажира «Студент»). Также для нового типа пассажира «Студент» должен быть реализован информационный обмен с системами-потребителями организаций железнодорожного транспорта, согласно п. 4.2.1.1.4 настоящего Технического задания

4.2.1.1.4 Требования к обеспечению обмена данными с информационными системами организаций железнодорожного транспорта Обмен данными с информационными системами организаций железнодорожного транспорта должен осуществляться посредством REST API, а также файлового обмена с использованием протокола SFTP, с целью обеспечения передачи информации о наличии у пассажира права на проезд по льготному, сниженному или безденежному тарифу на железнодорожном транспорте пригородного сообщения и дальнего следования, а также наличия у него прав на специальное обслуживание (сопровождение инвалидов и маломобильных) и приобретения билетов на специальные места для инвалидов в поездах дальнего следования. Подсистема информационного обмена АИС УЛСП должна обеспечивать возможность взаимодействия с витринами продаж электронных билетов организаций железнодорожного транспорта, а также с интеграционными платформами ОАО «РЖД», его дочерних компаний и взаимозависимых лиц, предоставляющих гражданам возможность оформления электронных билетов на следующие виды транспорта: – Поезда дальнего следование; – Поезда пригородного сообщения; – Межрегиональные автобусы; – Авиасообщение; – Водный пассажирский транспорт; – Мультимодальные маршруты, а также заказ туристических услуг и оформления поездок, в том числе льготных, на основании данных геолокации при бесконтактной оплате проезда в пригородном железнодорожном сообщении. Способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования

5) Предоставить отдельный документ по каждой базе данных, входящей в состав решения, который содержит: a. Проектный объём базы данных на один год и предполагаемый объём роста баз данных на два года вперёд; b. Список из 10-и самых больших таблиц; c. Полученные в результате проведения нагрузочного тестирования данные по: i. Нагрузке на процессор; ii. Потреблению оперативной памяти; iii. Среднему количеству одновременно работающих пользователей; iv. Объёму упреждающей журнализации (write-ahead log; WAL); v. Указание самых нагруженных интервалов времени со следующим описанием: ? Время возникновения; ? Время окончания; ? Характер нагрузки. d. Перечень серверов и/или микросервисов, которые осуществляют подключение к базе данных; e. Перечень регламентных заданий, запускающихся для обслуживания БД, либо для обработки данных i. Дополнительно предоставить описание регламентного задания в формате: § Время запуска; § Проектное время работы; § Характер выполняемых действий; § Назначение данного задания. f. Перечень ролей и схем, участвующих в работе приложения, с пояснением о функциональном назначении каждой из них; g. Перечень ролей и схем, которые не задействованы в работе с пояснением о функциональном назначении каждой из них; h. Описание периодических заданий, выполняющихся со стороны приложения, в формате: i. На каком компоненте решения выполняется данное задание (сервер/микросервис); ii. Время начала; iii. Проектное время работы; iv. Характер выполняемых действий; v. Назначение данного задания. i. Описание структуры базы данных

6) Предоставить настройки обратного прокси сервера (reverse proxy), требуемые для публикации веб приложения 7) Инструкция по установке должна содержать: a. Пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; b. Исчерпывающий перечень команд для первичной настройки системы; c. Следующий дополнительный объём информации i. Перечень пакетов, необходимых для работы решения, с указанием их версий; ii. Перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; iii. Код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; iv. Перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника. 8) Руководство по устранению частых проблем 9) Руководство по мониторингу, которое содержит: a. Описание метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики и способа их сбора; b. Описание метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики и способа их сбора. 10) Руководство по восстановлению, которое содержит: a. План восстановления отдельных компонентов системы; i. Данные планы исходят из предположения, что из строя вышел один из компонентов системы, а все остальные компоненты продолжают функционировать b. План восстановления всей системы в целом; i. Данный план составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию c. Каждый из планов должен иметь: i. Время восстановления; ii. Пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов

11) Руководство по чтению журналов (логов) приложения, которое содержит: a. Описание формата журналов; b. Классификатор событий; c. Детальное описание событий. 12) Руководство по сборке приложения из исходного кода a. Должны быть предоставлена инструкция по сборке из исходного кода каждого компонента решения (контейнера, исполняемого файла, пакета, и т.д.); b. Сборка должна производиться без использования информационно-телекоммуникационной сети «Интернет»

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, разработанных на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов: – сервис аудита (услуга 1.15); – сервис журналирования (услуга 1.14); – сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Также необходимо осуществить интеграцию подсистемы аутентификации АИС УЛСП, обеспечивающей процесс входа со своими учетными данными и доступ к различным подсистемам, используя один идентификатор, с сервисом IAM (услуга 1.13) включающий в себя компонент «IAM Proxy», представляющий собой реверсивный прокси на основе nginx с поддержкой аутентификации и авторизации через IAM; компонент «Авторизация IAM», позволяющий создать ролевую модель и проводить динамический расчет полномочий пользователя; плагин для аутентификации пользователя через ЕСИА. В целях развития АИС УЛСП на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, при подготовке к миграции необходимо использовать следующие сервисы: – сервис управления развертыванием программного обеспечения (услуга 1.31); – сервисы интеграционного взаимодействия (услуга 1.19); – сервисы управления очередями сообщений (1.10)

Таким образом, при развитии Системы в части подготовки к миграции на ЕЦП «ГосТех» необходимо использовать следующие базовые сервисы платформы «ГосТех» (таблица 1): Таблица 1 № п/п Наименование необходимого Сервиса ID Сервиса Наименование и версия ПО 1 Сервис IAM 1.13 KeyClock версия 4.8 и выше 2 Сервис Key-value СУБД (in-memory) 1.3 Apache Ignite 2.12.0 3 Сервис аудита (услуга 1.15) 1.15 Инструменты аудита Platform V Audit 4 Сервис журналирования (услуга 1.14) 1.14 OpenSearch 2.5.0 Logstash 7.17.5 5 Сервис мониторинга (услуга 1.16) 1.16 Victoria Metrics 1.83.1 Grafana 7.4.16 6 Сервис транзакционной СУБД (услуга 1.1) 1.1 PostgreSQLPro / Pangolin 5 7 Сервис управление развертыванием ПО (услуга 1.31) 1.31 Jenkins 2.319.3 8 Сервисы управления очередями сообщений (услуга 1.10) 1.10 Apache Kafka 2.7.2 9 Сервис СУБД полнотекстового индекса (услуга 1.4) 1.4 OpenSearch 2.5.0 10 Сервис управления микросервисами (услуга 1.11) 1.11 Перечень используемых базовых сервисов может быть уточнен или дополнен в случае расширения перечня базовых сервисов платформы «ГосТех» на этапе технического проектирования

4.1.14.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое программное обеспечение со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом

4.1.14.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.14.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.14.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.14.9. Нарушение условий настоящего раздела Технического задания, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.14.10. В случае, если в соответствии с пунктом 4.1.14.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.14.11. В случае, если при выполнении Работ положения пунктов 4.1.14.5-4.1.14.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела Технического задания, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем

Этап №2: Работы по развитию АИС УЛСП и подготовка к миграции АИС УЛСП и её компонентов на ЕЦП «ГосТех» согласно раздела 4.2 Технического задания Идентификатор: 149130568 - 62.01.11.000 - - - - - 1 - Условная единица - 47029388.09 - 47029388.09

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АСОП Автоматизированная система оплаты проезда АРМ Автоматизированное рабочее место БД База данных ВС Вид сведений ВСК Виртуальная социальная карта Минцифры России ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГосСОПКА Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации Дашборд Информационная панель, которая получает данные из других систем и отображает их в визуализированном формате ДУЛ Документ, удостоверяющий личность ЕГИССО Единая государственная информационная система социального обеспечения ЕСИА Единая система идентификации и аутентификации Контракт Контракт, в рамках которого исполняется настоящее Техническое задание ИС Информационная система МСП Меры социальной поддержки МСЗ Меры социальной защиты НКЦКИ Национальный координационный центр по компьютерным инцидентам НПА Нормативный правовой акт НПБ Нормативно-правовая база НСИ Нормативно-справочная информация ОАО «РЖД» Открытое акционерное общество «Российские железные дороги» ООЗ Описание объекта закупки ОС Операционная система Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» - экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПМИ Программа и методика испытаний ПО Программное обеспечение ПОИБ Подсистема обеспечения информационной безопасности - - Значение характеристики не может изменяться участником закупки

ППК ЦР Президиум Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности ПСП Портал субсидированных перевозок РОИВ Региональный орган исполнительной власти РФ Российская Федерация СЗИ Средства защиты информации СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СПО Системное программное обеспечение СУБД Система управления базой данных СФР Фонд пенсионного и социального страхования Российской Федерации ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС ЕРН Федеральная государственная информационная система ведения Единого федерального информационного регистра, содержащего сведения о населении Российской Федерации ФГИС ФРИ Федеральная государственная информационная система «Федеральный реестр инвалидов» ФИО Фамилия, имя, отчество ФНС Федеральная налоговая служба Российской Федерации ФПСС Фонд пенсионного и социального страхования ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЭТТ Электронное транспортное требование ЭВМ Электронная вычислительная машина - комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Frontend Визуальная часть Системы, которую пользователь видит и с которой может взаимодействовать при помощи браузера HTTPS HyperText Transfer Protocol Secure - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности

1 ОБЩИЕ СВЕДЕНИЯ - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1. Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 2. Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 3. Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 4. Федеральный закон «О федеральном бюджете на 2024 год и на плановый период 2025 и 2026 годов» от 27.11.2023 № 540-ФЗ. 5. «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 6. Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 7. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 8. Постановление Правительства РФ от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 9. Постановление Правительства Российской Федерации от 28.11.2011 № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме». 10. Постановление правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

11. Постановление правительства Российской Федерации от 16.11.2015 № 1236 и «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 12. Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех». 13. Протокол стратегической сессии под председательством Председателя Правительства Российской Федерации М.В. Мишустина по созданию, развитию и эксплуатации единой цифровой платформы Российской Федерации «ГосТех» от 10.05.2023 № 2. 14. Методические рекомендации по проектированию и утверждению целевой архитектуры домена с использованием единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 13.07.2022 № 26. 15. Методические рекомендации «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 № 30. 16. Методические рекомендации по эксплуатации государственных информационных систем на Единой цифровой платформе «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54

17. Методические рекомендации «Стандарт по управлению динамической инфраструктурой Единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54. 18. Методические рекомендации по разработке разделов технического задания, составу и содержанию требований, включаемых в техническое задание на создание, развитие государственных информационных систем, создаваемых (развиваемых) на единой цифровой платформе Российской Федерации «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.12.2023 № 47пр. 19. Методические рекомендации по вопросам разработки государственных информационных систем с использованием платформы «ГосТех» и определения обязательности повторного использования цифровых продуктов платформы «ГосТех» при их создании и развитии, утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.10.2023 № 47пр. 20. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст

21. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 22. ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 23. ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226-ст. 24. ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с 01.06.2024 Окончание работ: по 13.12.2024 Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом-графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего Технического задания (далее – Календарный план)

1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определённом Контрактом в сроки, установленные п. 5.1 настоящего Технического задания, в соответствии с Календарным планом

1.1 Наименование системы Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП, Система. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками, включая подготовку к размещению на единой цифровой платформе Российской Федерации «ГосТех» (далее – Работы). Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения»

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры

1.3 Основания для выполнения работ 1. Указ Президента Российской Федерации «О создании, развитии и эксплуатации государственных информационных систем с использованием единой цифровой платформы Российской Федерации «ГосТех» от 31.03.2023 № 231. 2. Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023. 3. Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства РФ от 03.11.2023 г. № 3097-р. 4. Федеральный закон от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 5. Федеральный закон от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 6. Федеральный закон от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости. 7. Постановление Правительства РФ от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 8. Постановление Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»

10. Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555»

2 НАЗНАЧЕНИЕ И ЦЕЛИ РАЗВИТИЯ СИСТЕМЫ - 2.1 Назначение Системы АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социально поддержки (защиты) на транспорте в безбумажный формат - - Значение характеристики не может изменяться участником закупки

2.2 Цели развития Системы Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363 р. Обеспечение комфортных мультимодальных поездок, в т.ч. с использованием единого цифрового инструмента оплаты проезда и возможности применения цифровых льгот и субсидий. Недостаточное проникновение бесконтактных средств оплаты проезда, включая полностью цифровые инструменты, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенной на заседании Президиума Госсовета по развитию общественного транспорта 17.08.2023. Целями развития Системы является подготовка для ее размещения на ЕЦП «ГосТех», а также расширение видов обрабатываемых транспортных льгот, субсидий и компенсаций, а также типов перевозочных документов, видов транспорта, типов получателей мер социальной поддержки (защиты), регионов и перевозчиков, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками в межрегиональном и внутрирегиональном сообщении, в том числе в рамках мультимодального заказа

2.3 Состав выполняемых задач Для реализации указанных целей развитие Системы должно решать следующие задачи: 1. Развитие АИС УЛСП, проработку механизмов и подготовку к миграции Системы на ЕЦП «ГосТех», предусматривающее: – разработку сервиса сбора, обработки и хранения данных о региональных тарифах и льготах, представляющего собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан; – разработку сервиса «Личный кабинет региона», предназначенного для отображения статистических данных по тарифам (скидкам) на транспорт и льготам; – разработку сервиса «Маломобильные», предназначенного для обеспечения возможности маломобильным категориям населения оформлять запрос на сопровождение в объектах транспортной инфраструктуры, а также осуществлять заказ парковочного разрешения на объектах транспортной инфраструктуры; – разработку «Сервиса подтверждения льготных перевозок по электронным транспортным требованиям», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов и провоза багажа на железнодорожном транспорте в пригородном сообщении и дальнем следовании по служебным и личным надобностям; – разработку «Сервиса подтверждения льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов на железнодорожный транспорт в пригородном сообщении и дальнем следовании лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры и в соответствии с нормативными правовыми актами РФ имеющим право на льготный проезд;

2. Модификация функционала сервисов АИС УЛСП с целью обеспечения автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область («житель КГД» и «Студент КГД»);

3. Обеспечение возможности информационного взаимодействия: – с цифровыми сервисами, обеспечивающими функционирование виртуальной социальной карты (далее – ВСК) с целью обеспечения межведомственного взаимодействия и обмена данными по федеральным и региональным мерам социальной поддержки (защиты) на транспорте для разных видов транспорта и типов сообщения с целью реализации положений Постановления Правительства Российской Федерации от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами»; – с информационными системами, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня;

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

3 СВЕДЕНИЯ ОБ ОБЪЕКТАХ АВТОМАТИЗАЦИИ - 3.2 Текущее состояние объекта автоматизации Система состоит из двух сегментов: Федерального, Регионального. Федеральный сегмент реализован в единственном числе, региональный сегмент представляет собой типовое, тиражируемое решение, подлежащее доработке под конкретный регион внедрения в случае возникновения подобной необходимости - - Значение характеристики не может изменяться участником закупки

Перечень функциональных подсистем федерального сегмента: Функция Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот - иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. «Администрирование» Управление учётными записями пользователей федерального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи (ролевая модель). Управление таксономией льгот, включая блок нормативно-справочной информации по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы. «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.)

Перечень функциональных подсистем регионального сегмента: Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной либо субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе. «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах - иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учётными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи. Управление составом и содержанием справочников и классификаторов. «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платёжных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: – сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) уровне; – информационное взаимодействие с общегосударственными информационными системами, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи, а также об указанных мерах, доступных тому или иному гражданину; – подтверждение наличия у гражданина РФ права на приобретение авиабилетов по специальным тарифам согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Постановлении Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» (с изменениями и дополнениями); АИС УЛСП соответствует Требованиям о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены приказом ФСТЭК России от 11.02.2013 № 17), предъявляемым к информационным системам класса защищенности «К2» и Составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных 2-го уровня защищенности (утверждены приказом ФСТЭК России от 18.02.2013 № 21). Текущая архитектура АИС УЛСП приведена на рисунке Рис. 1

3.3 Объект автоматизации в рамках настоящего Технического задания Объектом автоматизации в рамках выполнения работ по настоящему Техническому заданию являются процессы: – определения и разработки механизмов для подготовки к переводу функционала Системы на платформу «ГосТех»; – цифрового подтверждения права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); – цифрового подтверждения права пассажира на приобретение билета на воздушный транспорт по специальному тарифу для жителей Калининградской области; – цифрового подтверждения наличия права на приобретение билета на воздушный транспорт по специальному тарифу у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры в учебных заведениях на территории Калининградской области; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда на основании данных геолокации;

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

Перечень функциональных подсистем, разрабатываемых в рамках настоящего Технического задания: Функция Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов «Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы

«Сервис учета данных Виртуальных социальных карт» Обмен данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт Требования к целевой архитектуре и схеме внешних взаимодействий приведена на Рис. 2

3.1 Описание объектов автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу по Контракту ОК/23_03 от 03.07.2023 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770411620523000022). АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р. в части создания «единого сервиса предоставления льгот и субсидий»

8 ИСТОЧНИКИ РАЗРАБОТКИ - Разработка Технического производилась с учётом положений следующих нормативно-технические документов: 1. ГОСТ 2.105-95 «Общие требования к текстовым документам». 2. ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом». 3. ГОСТ 19.105-78 «Общие требования к программным документам». 4. ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». 5. ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки

5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ АИС УЛСП - В соответствии с настоящим Техническим заданием Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку, проведение опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения Этапа 1 Подрядчик должен выполнить Техническое проектирование АИС УЛСП и модификацию существующих подсистем АИС УЛСП, включая: – Техническое проектирование в соответствии с ГОСТ 34.602-2020. Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы; – Обеспечение поддержки новых типов мер социальной поддержки (защиты) пассажиров согласно п. 4.2.1 настоящего Технического задания. В рамках исполнения Этапа 2 Подрядчик должен выполнить работы по разработке новых сервисов, согласно п. 4.2.2 – 4.2.8 настоящего Технического задания и разработке механизмов и порядка миграции АИС УЛСП и ее компонентов на ЕЦП «ГосТех» (при условии технологической готовности ЕЦП «ГосТех»), включая выполнение работ по разворачиванию существующих компонентов Системы в тестовом контуре ЕЦП «ГосТех»: – Выполнение работ реализации сервисов согласно в п. 4.2.2 – 4.2.8 Технического задания; – Выполнение работ по разворачиванию и тестированию разработанных сервисов в тестовом контуре ЕЦП «ГосТех» согласно п. 4.2.8 Технического задания; В рамках исполнения Этапа 3 Подрядчик должен выполнить работы по проведению предварительных испытаний АИС УЛСП, ее опытной эксплуатации и приемочных испытаний в соответствии с «ГОСТ Р 59792-2021. «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». – Проведение предварительных испытаний; – Проведение опытной эксплуатации АИС УЛСП; – Проведение приемочных испытаний АИС УЛСП. Опытная эксплуатация АИС УЛСП и ее приемочные испытания должны проводиться на мощностях Заказчика или на ЕЦП «ГосТех» по решению Заказчика в зависимости от уровня технологической готовности ЕЦП «ГосТех» - - Значение характеристики не может изменяться участником закупки

5.1 Состав работ и график их выполнения (календарный план) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке

№ этапа 1 Техническое проектирование АИС УЛСП и модификация существующих подсистем АИС УЛСП 1.1. Техническое проектирование Начало: 01.06.2024; Окончание: не позднее 01.07.2024 1. Технический проект на АИС УЛСП в составе Пояснительной записки к техническому проекту, включая (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Схема структурная комплекса технических средств, – Описание автоматизируемых функций (детальное описание функциональных требований по автоматизируемым процессам, включая межведомственный информационный обмен), – Описание информационного обеспечения системы, – Описание организации информационной базы, – Описание программного обеспечения; – Описание организационного обеспечения; – Ведомость технического проекта; – Ведомость машинных носителей информации. 1.2. Обеспечение поддержки новых типов мер социальной поддержки (защиты) пассажиров согласно п. 4.2.1 настоящего Технического задания Начало: 01.06.2024; Окончание: не позднее 18.07.2024 1. Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.1. настоящего Технического задания. 2. Комплект рабочей документации в составе (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Начало: с 01.06.2024; Окончание: не позднее 18.07.2024

№ этапа 2 Работы по развитию АИС УЛСП и подготовка к миграции АИС УЛСП и её компонентов на ЕЦП «ГосТех» согласно раздела 4.2 Технического задания 2.1 Выполнение работ реализации сервисов согласно в п. 4.2.2 – 4.2.8 Технического задания Начало: 19.07.2024; Окончание: не позднее 07.11.2024 Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.2. – 4.2.8 настоящего Технического задания настоящего Технического задания Комплект рабочей документации в составе (в срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом): – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Системы; – Отчёт о проведении тестовых испытаний; – Акт о готовности Системы к проведению нагрузочного испытания; – Отчёт о подготовке к развёртыванию Системы в тестовом контуре ЕЦП «ГосТех»; – Программа и методика предварительных испытаний; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации; – Руководство по установке (развертыванию) всех компонентов Системы с учетом доработок по настоящему Техническому заданию Начало: 19.07.2024 Окончание: не позднее 07.11.2024

№ этапа 3 Предварительные испытания, опытная эксплуатация, приемочные испытания 3.1. Проведение предварительных испытаний в соответствии с п.6.3.1. ТЗ Начало: 08.11.2024; Окончание: не позднее 18.11.2024 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Протокол предварительных испытаний Системы; – Акт о приемке Системы в опытную эксплуатацию; – Руководство пользователя системы; – Руководство администратора системы; – Программа и методика опытной эксплуатации. 3.2. Проведение опытной эксплуатации в соответствии с п. 6.3.3, 6.3.4 ТЗ Начало: 19.11.2024; Окончание: не позднее 05.12.2024 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Исходные коды и дистрибутивы на электронных носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке программного обеспечения); – Протокол пуско-наладочных работ; – Протокол опытной эксплуатации Системы; – Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатации; – Программа инструктажа пользователей; – Протокол инструктажа пользователей; – Акт о завершении опытной эксплуатации Системы – Программа и методика приемочных испытаний; – Актуальные версии документов, предоставленных Заказчику при исполнении Контракта (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Систему). 3.3. Проведение приемочных испытаний АИС УЛСП в соответствии с п. 6.3.5, 6.3.6 ТЗ. Начало: 06.12.2024; Окончание: не позднее 13.12.2024 – Протокол приемочных испытаний Системы; – Акт передачи исключительных прав; – Акт о готовности ввода Системы в эксплуатацию – Документы в соответствии с разделами 4.3.1, 4.1.14 ТТЗ – Обеспечение исп. гарант. обязательств в соответствии с усл. Контракта Начало: 08.11.2024; Окончание: не позднее 13.12.2024

6 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ, ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ - 6.1 Результаты работ В рамках выполнения работ по Этапу 1: 1) Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.1. настоящего Технического задания. 2) Комплект рабочей документации в составе: – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения. 3) Технический проект на АИС УЛСП в составе Пояснительной записки к техническому проекту, включая: – Схема структурная комплекса технических средств, – Описание автоматизируемых функций (детальное описание функциональных требований по автоматизируемым процессам, включая межведомственный информационный обмен), – Описание информационного обеспечения системы, – Описание организации информационной базы, – Описание программного обеспечения; – Описание организационного обеспечения; – Ведомость технического проекта; – Ведомость машинных носителей информации. В рамках выполнения работ по Этапу 2: 1) Работающая информационная Система, развернутая на технических средствах Заказчика, соответствующая требованиям п. 4.2.2. – 4.2.8 настоящего Технического задания настоящего Технического задания – Комплект рабочей документации в составе: – Ведомость эксплуатационных документов, – Ведомость машинных носителей информации; – Паспорт Системы; – Спецификация Системы; – Спецификация программного обеспечения Системы; – Отчёт о проведении тестовых испытаний; – Акт о готовности Системы к проведению нагрузочного испытания; – Отчёт о подготовке к развёртыванию Системы в тестовом контуре ЕЦП «ГосТех»; – Программа и методика предварительных испытаний; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации; – Руководство по установке (развертыванию) всех компонентов Системы (с учетом доработок по настоящему Техническому заданию) - - Значение характеристики не может изменяться участником закупки

В рамках выполнения работ по Этапу 3: – Протокол предварительных испытаний Системы; – Акт о приемке Системы в опытную эксплуатацию; – Исходные коды и дистрибутивы актуальной версии Системы с учетом доработок по настоящему техническому заданию на электронных носителях информации (в случае, если по результатам проведения опытной эксплуатации возникла необходимость в корректировке программного обеспечения); – Программа и методика опытной эксплуатации; – Протокол пуско-наладочных работ; – Протокол опытной эксплуатации Системы; – Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатации; – Руководство пользователя системы; – Руководство администратора системы; – Программа инструктажа пользователей; – Протокол инструктажа пользователей; – Акт о завершении опытной эксплуатации Системы – Программа и методика приемочных испытаний; – Протокол приемочных испытаний Системы; – Акт передачи исключительных прав; – Акт о готовности ввода Системы в эксплуатацию; – Актуальные версии документов, предоставленных Заказчику при исполнении Контракта (в случае, если при проведении опытной эксплуатации возникла необходимость в корректировке документов на Систему); – Документы в соответствии с разделами 4.3.1, 4.1.14 Технического задания

6.2 Виды, состав, объем и методы испытаний системы и ее составных частей Работоспособность Системы должна определяться по результатам испытаний, проводимым по утверждённой программе и методике испытаний. Виды, состав, объём и методы испытаний должны соответствовать требованиям ГОСТ Р 59792-2021 «Виды испытаний автоматизированных систем». Формат и сроки проведения испытаний должны соответствовать последовательности работ, указанной в п. 5.1. настоящего Технического задания «Состав работ и график их выполнения». Объем и методы приемочных испытаний определяются единой программой и методикой испытаний. Порядок проверки устранения замечаний должен быть указан в программе и методике для соответствующего вида испытаний

6.3 Порядок контроля и приемки 6.3.1 Общие требования к выполнению работ по обеспечению проведения предварительных испытаний До начала испытаний Подрядчик совместно с Заказчиком должен произвести пуско-наладочные работы доработанной Системы в тестовом контуре на выделенных ресурсах Заказчика или на ЕЦП «ГосТех». Монтажные и пуско-наладочные работы осуществляются (при необходимости) Заказчиком. В ходе выполнения работ по доработке АИС УЛСП и ее компонентов должны быть проведены следующие виды испытаний: - предварительные испытания; - опытная эксплуатация; - приемочные испытания. Испытания проводятся на основании разработанных и утвержденных Подрядчиком и согласованных Заказчиком соответственно Программы и методики предварительных испытаний, Программы и методики опытной эксплуатации и Программы и методики приемочных испытаний. Предварительные и приемочные испытания проводятся комиссией, формируемой Заказчиком на основании распорядительного документа, который определяет состав комиссии по проведению испытаний (предварительных и приемочных), порядок ее работы, место и сроки проведения испытаний. Заказчик имеет право привлекать к участию в испытаниях внешних экспертов. Опытная эксплуатация проводится на вычислительных ресурсах, предоставленных Заказчиком, или на ЕЦП «ГосТех» по решению Заказчика. Во время опытной эксплуатации ведут журнал опытной эксплуатации, в который заносят сведения о продолжительности функционирования, отказах, сбоях, аварийных ситуациях, изменениях параметров объектов автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируются в журнале с указанием даты и ответственного лица. По результатам опытной эксплуатации Заказчиком принимается решение о возможности (или невозможности) предъявления доработанной Системы на приемочные испытания. Опытная эксплуатация завершается оформлением акта о завершении опытной эксплуатации и допуске доработанной Системы к приемочным испытаниям

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

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

6.3.2 Требования к предварительным испытаниям Предварительные испытания АИС УЛСП должны предусматривать проверки соответствия АИС УЛСП требованиям данного технического задания, проверки ее работоспособности, а также должна оцениваться возможность приемки АИС УЛСП в опытную эксплуатацию. При предварительных испытаниях АИС УЛСП должно проверяться: - соответствие АИС УЛСП требованиям, установленным в настоящем Техническом задании; - комплектность, качество и полнота проектной и эксплуатационной документации. Объем и методы испытаний АИС УЛСП должны быть изложены в Программе и методике предварительных испытаний АИС УЛСП. По итогам предварительных испытаний АИС УЛСП должны составляться протокол предварительных испытаний и акт приемки в опытную эксплуатацию АИС УЛСП. Протокол предварительных испытаний АИС УЛСП должен содержать заключение о готовности (неготовности) АИС УЛСП или ее соответствующей очереди к опытной эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки их выполнения

6.3.3 Общие требования к проведению опытной эксплуатации По результатам предварительных испытаний с целью проведения опытной эксплуатации Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику опытной эксплуатации, производит доработку программы и методики испытаний при наличии замечаний Заказчика. Подрядчик, при участии Заказчика, должен провести опытную эксплуатацию реализованного программного обеспечения в соответствии с согласованной программой и методикой испытаний. В процессе опытной эксплуатации ведется журнал опытной эксплуатации, в котором фиксируются весь объем мероприятий опытной эксплуатации и результаты выполнения пунктов программы и методики опытной эксплуатации, выявленные ошибки, сбои в работе АИС УЛСП, а также предложения по исправлению указанных ошибок (при необходимости). Журнал опытной эксплуатации разрабатывается Подрядчиком, согласовывается Заказчиком. Ведение журнала осуществляется обеими сторонами. Работы по опытной эксплуатации должны включать в себя устранение замечаний и ошибок, возникающих в процессе опытной эксплуатации и зафиксированных в журнале опытной эксплуатации. По результатам проведения опытной эксплуатации оформляются Протокол опытной эксплуатации с приложением Журнала опытной эксплуатации, а также Акт о завершении опытной эксплуатации, включающего перечень недостатков, которые необходимо устранить до начала приемочных испытаний

Опытная эксплуатация АИС УЛСП должна проводиться в срок, установленный программой опытной эксплуатации АИС УЛСП. Целями опытной эксплуатации АИС УЛСП являются: – определение полноты реализации требований технического задания; – определение фактических функциональных характеристик АИС УЛСП; – определение готовности персонала к работе в условиях функционирования АИС УЛСП; – определение фактической эффективности АИС УЛСП, корректировке (при необходимости) технической документации. В ходе опытной эксплуатации АИС УЛСП должны определяться эксплуатационные характеристики АИС УЛСП, дополнительно отлаживаться программы и устройства, уточняться техническая и программная документация. Опытную эксплуатацию АИС УЛСП проводят в соответствии с программой опытной эксплуатации АИС УЛСП. Данные опытной эксплуатации АИС УЛСП должны заноситься в журнал опытной эксплуатации АИС УЛСП. По окончании опытной эксплуатации должен составляться акт о завершении опытной эксплуатации АИС УЛСП. По результатам опытной эксплуатации принимают решение о готовности предъявления частей АИС УЛСП на приемочные испытания, или о неготовности предъявления частей АИС УЛСП на приемочные испытания АИС УЛСП и необходимости ее доработки. Опытная эксплуатация АИС УЛСП завершается оформлением и утверждением акта о завершении опытной эксплуатации АИС УЛСП

6.3.4 Общие требования к проведению приемочных испытаний Приемочные испытания проводятся по результатам проведения опытной эксплуатации реализованного программного обеспечения. С целью проведения приемочных испытаний Подрядчик разрабатывает и согласовывает с Заказчиком программу и методику приемочных испытаний. Приемочные испытания организуются и проводятся Подрядчиком в сроки, установленные Календарным планом настоящего Технического задания и по согласованию с Заказчиком. До начала испытаний Подрядчик совместно с Заказчиком должен произвести пуско-наладочные работы доработанной Системы в продуктовом контуре Заказчика или на ЕЦП «ГосТех» по решению Заказчика. На приемочные испытания Подрядчиком должны быть предъявлены программа и методика испытаний, комплект эксплуатационной документации и программное обеспечение, доработанное по результатам предварительных испытаний и опытной эксплуатации, а также обеспечена проверка выполнения требований Технического задания в полном объеме, включая требования к методологическому, информационному и организационному обеспечению, программной реализации, информационному наполнению и комплектности отчетной и программной документации. По результатам приемочных испытаний АИС УЛСП принимается решение о возможности ввода Системы в эксплуатацию. Документы приемочных испытаний должны быть разработаны в соответствии с требованиями ГОСТ Р 59795-2021, п. 3 и п. 6 ГОСТ Р 59792-2021 и в соответствии с положениями программы и методики приемочных испытаний. Результаты контроля и приемки Системы после приемочных испытаний оформляются Протоколом приемочных испытаний и Актом о передаче Системы в промышленную эксплуатацию, который согласуется между Подрядчиком и Заказчиком

После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию. Работы по обеспечению проведения приемочных испытаний Системы считаются завершенными с даты подписания со стороны Заказчика Протокола приемочных испытаний. Приемочные испытания АИС УЛСП должны проводиться в соответствии с программой и методикой приемочных испытаний АИС УЛСП. На приемочных испытаниях АИС УЛСП комиссией Заказчика должны оцениваться результаты опытной эксплуатации АИС УЛСП, а также возможность приемки АИС УЛСП в промышленную эксплуатацию. В процессе приемочных испытаний АИС УЛСП должно быть проверено выполнение работ по замечаниям, полученным в ходе опытной эксплуатации, устранения всех выявленных недостатков, а также соответствие АИС УЛСП требованиям данного технического задания и Технического задания на развитие на АИС УЛСП. Результаты приемочных испытаний АИС УЛСП должны заноситься в протокол приемочных испытаний АИС УЛСП. По окончании приемочных испытаний АИС УЛСП должен составляться акт приемки АИС УЛСП в постоянную эксплуатацию, который должен утверждаться с момента выдачи аттестата соответствия на АИС УЛСП

6.4 Порядок приёмки работ по развитию Системы В целях обеспечения приемки работ по развитию Системы Заказчиком должна быть создана Комиссия по приемке Системы (далее – Комиссия), в состав которой должны войти ответственные работники Заказчика, представители Подрядчика (без права подписи) и иных организаций при необходимости. Испытания должны проводиться на выделенных мощностях технологического стека Заказчика и/или Платформы «ГосТех» (при технологической готовности платформы). В случае необходимости и в случае технологической готовности платформы ЕЦП «ГосТех» Заказчик может организовать включение в комиссию представителей Оператора Платформы «ГосТех». Приёмка Системы осуществляется на основании результатов приёмочных испытаний. Приемочные испытания должны проходить только после завершения согласования полного набора документов, предоставляемых Подрядчиком. Приёмочные испытания должны проводиться в соответствии с Программой и методикой испытаний, подготовленной в ходе выполнения работ по договору и утвержденной Заказчиком до начала испытаний на техническом стенде Подрядчика. Приёмочные испытания должны выполняться Комиссией. На приемочные испытания должны быть предъявлены: 1. Дистрибутивный комплект Системы на носителе данных. 2. Программа и методика испытаний. Устранение всех отклонений производится исключительно силами и за счет Подрядчика. После устранения замечаний Подрядчик передает Заказчику Систему в порядке, предусмотренном Государственным контрактом. После проведения приёмки Заказчиком, Подрядчиком должен быть подготовлен и подписан соответствующий акт. К данному акту должны быть приложены замечания к реализации требуемого набора функций при их наличии

7 ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ - Подрядчиком должен быть подготовлен и передан полный комплект документов, предусмотренный в п. 6.1 Технического задания. Вышеперечисленные документы должны быть разработаны на русском языке и должны содержать описание последовательности выполнения операций (действий), совершаемых пользователями из соответствующей функциональной группы. Описание должно строиться на основе технологических задач, выполняемых пользователями из соответствующей категории, с использованием возможностей Системы и не должно сводиться к простому перечислению функций Системы. Документы должны быть оформлены в соответствии с требованиями ЕСПД и ГОСТ 2.105-95 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается использование листов формата А3 с подшивкой по короткой стороне листа для размещения рисунков и таблиц. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документация должна быть предоставлена Заказчику в электронном виде в формате PDF на отдельном носителе данных (CD/DVD, жёсткий диск, либо USB-накопитель). Также Подрядчик должен предоставить 2 экземпляра документов «Программа и методика испытаний» на бумажном носителе - - Значение характеристики не может изменяться участником закупки

4 ТРЕБОВАНИЯ К СИСТЕМЕ - 5) Предоставить отдельный документ по каждой базе данных, входящей в состав решения, который содержит: a. Проектный объём базы данных на один год и предполагаемый объём роста баз данных на два года вперёд; b. Список из 10-и самых больших таблиц; c. Полученные в результате проведения нагрузочного тестирования данные по: i. Нагрузке на процессор; ii. Потреблению оперативной памяти; iii. Среднему количеству одновременно работающих пользователей; iv. Объёму упреждающей журнализации (write-ahead log; WAL); v. Указание самых нагруженных интервалов времени со следующим описанием: ? Время возникновения; ? Время окончания; ? Характер нагрузки. d. Перечень серверов и/или микросервисов, которые осуществляют подключение к базе данных; e. Перечень регламентных заданий, запускающихся для обслуживания БД, либо для обработки данных i. Дополнительно предоставить описание регламентного задания в формате: § Время запуска; § Проектное время работы; § Характер выполняемых действий; § Назначение данного задания. f. Перечень ролей и схем, участвующих в работе приложения, с пояснением о функциональном назначении каждой из них; g. Перечень ролей и схем, которые не задействованы в работе с пояснением о функциональном назначении каждой из них; h. Описание периодических заданий, выполняющихся со стороны приложения, в формате: i. На каком компоненте решения выполняется данное задание (сервер/микросервис); ii. Время начала; iii. Проектное время работы; iv. Характер выполняемых действий; v. Назначение данного задания. i. Описание структуры базы данных - - Значение характеристики не может изменяться участником закупки

6) Предоставить настройки обратного прокси сервера (reverse proxy), требуемые для публикации веб приложения 7) Инструкция по установке должна содержать: a. Пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; b. Исчерпывающий перечень команд для первичной настройки системы; c. Следующий дополнительный объём информации i. Перечень пакетов, необходимых для работы решения, с указанием их версий; ii. Перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; iii. Код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; iv. Перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника. 8) Руководство по устранению частых проблем 9) Руководство по мониторингу, которое содержит: a. Описание метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики и способа их сбора; b. Описание метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики и способа их сбора. 10) Руководство по восстановлению, которое содержит: a. План восстановления отдельных компонентов системы; i. Данные планы исходят из предположения, что из строя вышел один из компонентов системы, а все остальные компоненты продолжают функционировать b. План восстановления всей системы в целом; i. Данный план составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию c. Каждый из планов должен иметь: i. Время восстановления; ii. Пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов

4.2.6 Требования к реализации сервиса льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы должен обеспечивать подтверждение прав на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. Подтверждение личности (авторизация) студентов должна включать сведения, позволяющие однозначно идентифицировать гражданина: 1) фамилия, имя, отчество (при наличии) обучающегося; 2) пол обучающегося; 3) дата рождения обучающегося; 4) СНИЛС обучающегося; 5) серия, номер, дата выдачи документа, удостоверяющего личность гражданина Российской Федерации обучающегося. В качестве основного идентификатора должен использоваться СНИЛС

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

4.2.7 Требования к реализации сервиса учета данных Виртуальных социальных карт В целях реализации Постановления Правительства РФ от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами» в рамках АИС УЛСП необходимо разработать Сервис учета Виртуальных социальных карт для обеспечения обмена данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт. Под виртуальными социальными картами подразумеваются уникальные обезличенные идентификаторы, формируемые с применением национальных платежных инструментов, указанных в части 2 статьи 30 Федерального закона «О национальной платежной системе» (далее – национальные платежные инструменты), при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, разработанных на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов: – сервис аудита (услуга 1.15); – сервис журналирования (услуга 1.14); – сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Также необходимо осуществить интеграцию подсистемы аутентификации АИС УЛСП, обеспечивающей процесс входа со своими учетными данными и доступ к различным подсистемам, используя один идентификатор, с сервисом IAM (услуга 1.13) включающий в себя компонент «IAM Proxy», представляющий собой реверсивный прокси на основе nginx с поддержкой аутентификации и авторизации через IAM; компонент «Авторизация IAM», позволяющий создать ролевую модель и проводить динамический расчет полномочий пользователя; плагин для аутентификации пользователя через ЕСИА. В целях развития АИС УЛСП на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, при подготовке к миграции необходимо использовать следующие сервисы: – сервис управления развертыванием программного обеспечения (услуга 1.31); – сервисы интеграционного взаимодействия (услуга 1.19); – сервисы управления очередями сообщений (1.10)

Таким образом, при развитии Системы в части подготовки к миграции на ЕЦП «ГосТех» необходимо использовать следующие базовые сервисы платформы «ГосТех» (таблица 1): Таблица 1 № п/п Наименование необходимого Сервиса ID Сервиса Наименование и версия ПО 1 Сервис IAM 1.13 KeyClock версия 4.8 и выше 2 Сервис Key-value СУБД (in-memory) 1.3 Apache Ignite 2.12.0 3 Сервис аудита (услуга 1.15) 1.15 Инструменты аудита Platform V Audit 4 Сервис журналирования (услуга 1.14) 1.14 OpenSearch 2.5.0 Logstash 7.17.5 5 Сервис мониторинга (услуга 1.16) 1.16 Victoria Metrics 1.83.1 Grafana 7.4.16 6 Сервис транзакционной СУБД (услуга 1.1) 1.1 PostgreSQLPro / Pangolin 5 7 Сервис управление развертыванием ПО (услуга 1.31) 1.31 Jenkins 2.319.3 8 Сервисы управления очередями сообщений (услуга 1.10) 1.10 Apache Kafka 2.7.2 9 Сервис СУБД полнотекстового индекса (услуга 1.4) 1.4 OpenSearch 2.5.0 10 Сервис управления микросервисами (услуга 1.11) 1.11 Перечень используемых базовых сервисов может быть уточнен или дополнен в случае расширения перечня базовых сервисов платформы «ГосТех» на этапе технического проектирования

4.2.1.1.1 Требования к обеспечению обмена данным с ГИС ЕЦП Текущее взаимодействие АИС УЛСП в части проверки данных пассажира и получения информации о наличии у него действующих льготных категорий производится с ИС СФР по ВС «О соответствии фамильно-именной группы, даты рождения, пола и СНИЛС», а также по ВС «Сведения об инвалиде, получаемые из ФГИС ФРИ, для оказания транспортных услуг» посредством СМЭВ-3 по приведенным в Таблице 5 параметрам запроса. Таблица 5 – Параметры запроса Параметр Описание FamilyName Фамилия пассажира FirstName Имя пассажира Patronymic Отчество пассажира Snils СНИЛС пассажира Gender Пол пассажира BirthDate Дата рождения пассажира DisabilityGroup Группа инвалидности инвалида/ребенка-инвалида Moving Степень способности к самостоятельному передвижению AvailabilityWheelChair Наличие рекомендаций в обеспечении креслом-коляской В связи с вступлением в силу Федерального закона от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации» вдобавок к ранее созданным механизмам информационного обмена необходимо провести модификацию Подсистемы информационного обмена АИС УЛСП с целью обеспечения обмена данными с создаваемой в рамках указанного Федерального закона ГИС «Единая цифровая платформа в социальной сфере» (ГИС ЕЦП)

4.3.5 Требования к контейнерам в платформе контейнеризации на базе Kubernetes 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.) 4) Каждый контейнер должен содержать следующие конфигурационные параметры a. securityContext.readOnlyRootFilesystem: true b. securityContext.runAsNonRoot: true 5) Каждый контейнер должен писать логи в stdout a. Допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки) b. Допускается запись логов в формате json c. Запрещается совмещение формата записи логов в рамках одного контейнера 6) Каждый pod должен быть снабжён network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера 10) Каждый контейнер должен содержать в себе liveliness и readiness probes a. Контейнер выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes 11) В контейнере не может запускаться более одного процесса 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.1.14.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке), или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое программное обеспечение со следующими возможностями: - права передаются бессрочно (на весь срок действия исключительных прав); - территория действия Российская Федерация; - должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом

4.1.14.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.14.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.14.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.14.9. Нарушение условий настоящего раздела Технического задания, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.14.10. В случае, если в соответствии с пунктом 4.1.14.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.14.11. В случае, если при выполнении Работ положения пунктов 4.1.14.5-4.1.14.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела Технического задания, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем

4.1.7 Требования по диагностированию Системы Компоненты АИС УЛСП должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности аппаратных средств, специального и общего ПО. АИС УЛСП должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы, а также мониторинга процесса выполнения программ. Система должна осуществлять ведение журналов инцидентов в электронном формате. При возникновении аварийных ситуаций либо ошибок в программном обеспечении, диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и решения проблемы системными администраторами либо разработчиками. Диагностирование АИС УЛСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. При подготовке к миграции на ЕЦП «ГосТех» диагностирование и мониторинг состояния Системы должны производиться базовыми сервисами Платформы «ГосТех». Диагностирование Системы должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности Системы. В процессе диагностирования должна быть обеспечена: – регистрация диагностических сообщений при работе специального программного обеспечения; – передача журналов и метрик в централизованную систему мониторинга платформы «ГосТех» (при подготовке к миграции), в том числе информации о появлении критических событий, а также логирования событий; – генерация оповещений о возможности появления критичных событий в работе Системы. Полный перечень параметров, подлежащих диагностике, определяется на стадии технического проектирования

4.1.8 Требования к транспортабельности Не предъявляются. 4.1.9 Требования к эксплуатации и техническому обслуживанию Требования к режимам функционирования Системы описаны в п. 4.1.4. При подготовке к миграции на ЕЦП «ГосТех» для обеспечения задач эксплуатирующего персонала по диагностированию состояния Системы и предотвращению аварийных состояний необходимо обеспечить постоянное диагностирование средствами Платформы «ГосТех». 4.1.10 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.11 Требования к возможностям развития Системы Архитектура Системы должна предусматривать возможность: – расширения состава внешних и смежных информационных систем-источников информации; – расширения состава внешних и смежных информационных систем-получателей информации; – расширения состава и наполнения БД АИС УЛСП, нормативно-справочной информации, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание Системы; – внедрения дополнительных функциональных подсистем; – расширения функциональных возможностей существующих подсистем. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем. Отказоустойчивость Системы должна обеспечиваться Заказчиком средствами действующего технологического стека АИС УЛСП, а также сервисами платформы ЕЦП «ГосТех» (при обеспечении технологической готовности платформы)

4.2.1.2 Требования к модификации Подсистемы хранения и обработки информации С целью обработки и хранения полученных от систем-источников новых типов сведений должна быть выполнена модификации внутримашинной информационной базы в части подтверждения личности и типа пассажира, включая следующие таблицы: – PassengersRequests – таблица данных запроса от ПСП по пассажиру; – Passengers – таблица данных пассажира; – IdentityConfirmations – таблица данных результатов подтверждения личности пассажиров; – PassengerTypeConfirmations – таблица данных результатов подтверждения типов пассажиров; – Document – таблица данных документов удостоверяющих личность пассажиров. Дополнительно со стороны внутренней логики подтверждения личности и типа пассажира должна быть выполнена модификация в части: 1) обеспечения подтверждения типа пассажира «житель КГД» по следующим маркерам: - личность подтверждена во ФГИС ЕРН; - запрошенный во ФГИС ЕРН код региона постоянной регистрации пассажира совпадает с кодом региона Калининградской области. Возрастные ограничения на новые типы пассажира не должны применяться; 2) обеспечения подтверждения типа пассажира «студент КГД» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования, сведения подтверждают обучение пассажира в ВУЗе, расположенном на территории Калининградской области; - на пассажира с типом «Студент КГД» не должно накладываться требование о наличии постоянной регистрации в субъекте РФ «Калининградская область». 3) обеспечения подтверждения типа пассажира «Студент» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования сведения подтверждают обучение пассажира в ВУЗе, имеющем государственную аккредитацию на территории РФ на очной форме обучения. - на пассажира с типом «Студент» должно накладываться требование о наличии постоянной регистрации на территории РФ

4.2.2 Требования к реализации сервиса сбора, обработки и хранения данных о региональных тарифах и льготах Сервис сбора, обработки и хранения данных о региональных тарифах и льготах должен представлять собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан пилотных регионов, которое должно обеспечивать выполнение следующих функций: 1) предоставления региональным органам исполнительной власти, являющихся держателями реестров льготных категорий граждан, а также отвечающих за организацию транспортного обслуживания населения, программного интерфейса для консолидации данных по категориям получателей транспортных льгот; 2) унификации различных форматов данных о льготных категориях граждан и льготах в соответствии с реестрами и региональными нормативными правовыми актами для обеспечения единой таксономии региональных льгот; 3) отображения информации по видам, типам, форматам предоставления мер социальной поддержки (защиты) на разных видах транспорта и типах сообщения; 4) отображения информации о государственных информационных системах, обрабатывающих данных по мерам социальной защиты (поддержки) на транспорте, а также информационных системах перевозчиков разных видов транспорта, задействованных в процессах информационного обмена с целью перехода к безбумажному оформлению льготного проезда;

4.3.6 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом a. Покрытие кода unit-тестами должно быть не менее 95% 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования a. Если не указано иное, то нагрузочное тестирование проводится со следующими допущениями i. Одновременная работа 10 администраторов в интерфейсе администраторов ii. Одновременная работа 1 000 пользователей в интерфейсе пользователей iii. Одновременное чтение и запись данных пользователями iv. Под данными подразумеваются записи в системе, которые пользователи могут получать и редактировать. В случае наличия нескольких типов таковых записей, необходимо провести нагрузочное тестирование на каждый такой тип 3) Исполнитель должен предоставить тестовые данные для проведения функционального тестирования a. Тестовые данные не могу совпадать с данными, которые будут в системе при вводе её в эксплуатацию

Подсистема информационного обмена АИС УЛСП должна быть доработана с целью обеспечения межведомственного информационного взаимодействия с ГИС ЕЦП СФР посредством СМЭВ 4 с целью подключения к витринам Национальной системы управления данными и обеспечения информационного обмена по следующему перечню сведений: - Код категории получателя меры социальной защиты (поддержки); - Гражданство; - Сведения об отнесении граждан к категориям граждан, имеющим право на получение мер социальной защиты (поддержки): o Сведения о детях-сиротах и детях, оставшихся без попечения родителей, лицах из числа детей-сирот и детей, оставшихся без попечения родителей, лицах, потерявших в период обучения обоих родителей или единственного родителя: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о гражданах, пострадавших в результате радиационных или техногенных катастроф: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о ветеранах Великой Отечественной войны, инвалидах Великой Отечественной войны, членах семей погибших (умерших) инвалидов Великой Отечественной войны, участников Великой Отечественной войны § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о бывших несовершеннолетних узниках концлагерей, гетто, других мест принудительного содержания, созданных фашистами и их союзниками в период Второй мировой войны: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно)

- Сведения о медико-социальной экспертизе и установлении инвалидности и о лице, признанном инвалидом: o группа инвалидности; o причина инвалидности; o срок, на который установлена инвалидность; o дата установления инвалидности; o сведения о транспортном средстве, управляемом инвалидом, или транспортном средстве, перевозящем инвалида и (или) ребенка-инвалида, в том числе государственный регистрационный номер транспортного средства, марка и (или) модель (коммерческое наименование) транспортного средства (если они были присвоены изготовителем транспортного средства), дата и время размещения (изменения) сведений о транспортном средстве, дата подачи заявления о размещении сведений о транспортном средстве, дата и время начала фактической эксплуатации транспортного средства, дата и время окончания фактической эксплуатации транспортного средства. - Параметром для формирования запроса к витрине ГИС ЕЦП должен быть СНИЛС

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологическом стеке (п. 4.2.8 настоящего Технического задания) в инфраструктуре Заказчика a. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика 2) Решение должно работать в изолированной сети (без доступа информационно-телекоммуникационной сети «Интернет») 3) Должна быть возможность редактировать список доверенных корневых сертификатов для решения a. По умолчанию список доверенных сертификатов должен быть пустым 4) Должна быть возможность редактировать список допустимых EKU (связано с п.п. 9) пункта 4.3.4.) a. По умолчанию список допустимых EKU должен быть пустым b. Список допустимых EKU должен вестись отдельно для каждого защищённого подключения 5) Допускается использование только кластеризованных баз данных a. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика 6) Решение должно быть отказоустойчивым a. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов b. Использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо 7) Любые соединения, устанавливаемые решением, должны быть защищёнными a. Защищёнными считаются соединения, устанавливаемые по протоколу HTTPS, либо с использованием протокола TLS b. Соединения, устанавливаемые в рамках одного пространства имён (namespace) и в рамках одной контейнерной платформы, могут использовать протокол HTTP, либо подключаться без использования протокола TLS c. План восстановления d. Допустимо только по согласованию с техническими специалистами Заказчика 8) Любая сервисная учётная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на неё задач a. Использование учётных записей с административными полномочиями не допускается

9) Реляционные базы данных решения должны соответствовать четвёртой нормальной форме или выше; 10) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy) 11) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity Access Management, IAM), имеющих сертификат ФСТЭК по 4-ому классу доверия и имеющимися у Заказчика 12) Контейнеры, разворачиваемые вне Kubernetes, должны разворачиваться с использованием docker compose a. Допустимо только по согласованию с техническими специалистами Заказчика 13) Разворачивание в платформу контейнеризации на базе Kubernetes должно производиться с использованием helm chart версии 3 a. Не допускается использование нескольких helm chart для разворачивания одного решения b. Допускается использование «зонтичного» helm chart (helm chart который запускает другие helm chart) c. Запрещается использование любого метода кодирования в файлах helm chart 14) Передать Заказчику в момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика: a. Пакеты, требуемые для работы решения b. Исходный код решения c. Контейнеры, требуемые для работы решения 15) Установка решения в продуктивный контур производится силами и сотрудниками Заказчика 16) Подрядчик не имеет доступа в продуктивный контур a. Запрещается передача данных из тестового контура в продуктивный

В рамках сервиса учета Виртуальных социальных карт АИС УЛСП должна быть реализована возможность получения данных по гражданам, относящимся к категории получателей мер социальной поддержки (защиты) регионального уровня «Члены многодетной семьи», проживающих на территории регионов, внедряющих ВСК, и оформивших ВСК, для последующего использования этих данных при цифровом подтверждении права пассажира на оформление авиабилета по специальному тарифу согласно ПП РФ №215 от 02.03.2018 г., а также при оформлении проездного документа на железнодорожный транспорт пригородного сообщения путем передачи соответствующих цифровых подтверждений в ПСП и/или подключенные информационные системы перевозчиков. Информационное взаимодействие между Витринами данных ВСК и АИС УЛСП должно осуществляться посредством СМЭВ-4, а с ПСП и организациями железнодорожного транспорта – посредством REST API. Конкретный способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.2.8 Требования к выполнению работ по проработке механизмов и подготовке к миграции АИС УЛСП на ЕЦП «ГосТех» Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes на платформе «ГосТех» (при наличии технологической готовности платформы). При этом при подготовке к миграции обязательно использование базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При подготовке к миграции хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех». Текущий технологический стек АИС УЛСП включает в себя: 1. ОС АЛЬТ версии 8 СП; 2. ASP.NET(C#); 3. Blazor(server); 4. Entity Framework; 5. JavaScript; 6. HTML; 7. CSS; 8. PostgreSQL; 9. Kubernetes; 10. Docker; 11. SonarQube. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика. При реализации механизмов миграции АИС УЛСП на платформу «ГосТех» необходимо обеспечить подход к использованию технологического стека в соответствии с диаграммой развертывания, указанной на Рис. 4 – Диаграмма развертывания АИС УЛСП на платформе «ГосТех» (может быть изменено по согласованию с Заказчиком на этапе технического проектирования). Рис. 4 Диаграмма развертывания АИС УЛСП на платформе «ГосТех»

4.1.2 Требования к технологической архитектуре Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes в тестовом контуре на платформе «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом обязательна подготовка к использованию базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При осуществлении разработки и развития Подсистем, а также их подготовки к миграции на ЕЦП «ГосТех», следует использовать не только инструменты управления планированием, требованиями, релизами, дефектами, тестированием и отслеживанием версионности (услуги: управление планированием (1.20), управление требованиями (1.21), управление релизами (1.22), управление дефектами (1.23), управление тестированием (1.24)), но и инструменты управления сборкой программного обеспечения, а также аналитики и мониторинга производственного процесса. Результаты разработки, перед сборкой программного обеспечения, должны проходить анализ качества кода с использованием базового сервиса платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). В подсистемах, предусматривающих взаимодействие с пользователями Системы, веб серверы должны размещаться в рамках соответствующих пространств имен кластеров Kubernetes. Хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). Реализация хранения вложений в базах данных подсистем не допускается

Для каждой подсистемы, в зависимости от функционала, при подготовке к миграции на ЕЦП «ГосТех» необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом не допускается использование одной инсталляции СУБД для использования разными подсистемами. Для аутентификации всех уровней пользователей необходима интеграция подготовленных к миграции подсистем с сервисом IAM (при наличии технологической готовности ЕЦП «ГосТех») (услуга 1.13). Должна быть обеспечена возможность взаимодействия подсистем друг с другом для обеспечения сквозной передачи данных. В случае обоснованного использования ЦОД, не относящегося к платформе «ГосТех», параметры ЦОД, в котором размещается ГИС, должны соответствовать требованиям ГОСТ Р 70139-2022 для ЦОД класса ГИС-3, а также параметрам отказоустойчивости и катастрофоустойчивости с учетом требований Приказа Минцифры России от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех», а также иметь действующие аттестаты соответствия требованиям по защите информации уровня защищенности персональных данных не ниже УЗ-2 и классу защищенности К2. При проработке механизмов и порядка миграции существующих подсистем АИС УЛСП на платформу «ГосТех» необходимо обеспечить переход на использование соответствующего технологического стека, в частности: 1. Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

4.2.1.1.2 Требования к обеспечению обмена данными с ИС ФНС России В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - гражданин Российской Федерации, зарегистрированный по месту жительства на территории Калининградской области. В целях модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка новых типов пассажира: - «житель КГД». С целью поддержки предоставления цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу для нового типа пассажира «житель КГД» технологический процесс взаимодействия АИС УЛСП с ИС ФНС должен производиться по ВС «Предоставление из ЕРН по запросу сведений о физическом лице» посредством СМЭВ и должен включать в себя следующие задачи: 1) Получение запросов от ПСП, содержащих данные Пассажиров: - идентификатор Пассажира в запросе; - фамилия; - имя; - отчество (при наличии); - дата рождения; - тип документа, удостоверяющего личность; - серия и номер документа, удостоверяющего личность; - пол; - номер СНИЛС (необязательное поле запроса); - типы пассажира на подтверждение. 2) Формирование и отправка АИС УЛСП запроса для подтверждения личности пассажира в ИС ФНС. Данные пассажира, передаваемые в запросе к ИС ФНС: - фамилия, имя, отчество (далее – ФИО) (отдельными полями); - дата рождения; - пол; - тип документа, удостоверяющего личность пассажира; - серия и номер документа, удостоверяющего личность пассажира; - признак того, что в ответе нужны данные о регионе регистрации гражданина

3) В случае подтверждения гражданина по полному совпадению данных ИС ФНС необходимо обеспечить обработку ответа в сторону АИС УЛСП, содержащего положительный ответ о подтверждении личности, и дополнительно по подтвержденному пассажиру предоставление следующих данных: - сведения о регистрации гражданина Российской Федерации по месту жительства; - информация по другим документам, удостоверяющим личность (тип, серия и номер), имеющихся в системе данных федеральных органов исполнительной власти по данному гражданину. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «житель КГД», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «У пассажира отсутствует постоянная регистрация в субъекте РФ, входящем в Калининградскую область» (для типа пассажира «житель КГД»). Таким образом, общий порядок информационного обмена должен иметь следующий вид: 1) ПСП отправляет запрос в АИС УЛСП, посредством внешнего API, содержащий данные пассажира. 2) Внешний API передает запрос в scheduler (планировщик задач). Scheduler проверяет по хешу запроса наличие данных подтверждения личности и типа пассажира в БД АИС УЛСП. При наличии ответа: - возвращает его в ответе на запрос внешнего API. - внешний API отправляет ответ в ПСП, содержащий данные подтверждения личности и типов пассажира, а также найденные ДУЛ. При отсутствии ответа в БД: - возвращает в ответ во внешний API данные запроса от ПСП в составе: - идентификатор пассажира в запросе; - данные ДУЛ из запроса ПСП; - внешний API перенаправляет ответ в ПСП (переход к шагу 5)

4) Scheduler передает запрос в сервис взаимодействия с адаптером СМЭВ-3 smev-exchanger для формирования запросов в адаптер СМЭВ 3. 5) Адаптер СМЭВ-3 производит взаимодействие с инфраструктурой ИС поставщика (ФНС). 6) Полученный ответ от ИС поставщика Адаптер СМЭВ-3 передает в scheduler. 7) Scheduler осуществляет проверку осуществляет проверку на подтверждение личности и типов пассажира исходя из данных от ПСП и ИС поставщика и записывает результирующий ответ в БД

5) самостоятельного ввода, редактирования и удаления информации, хранящейся в сервисе, с помощью инструментов Личного кабинета региона согласно п. 4.2.3. Технического задания; 6) формирования и хранения статистических данных для их отображения в сервисе «Личный кабинет региона». С целью реализации функциональности сбора реестров в Сервисе должен быть реализован модуль Подсистемы информационного обмена, который должен поддерживать импорт данных в файловом формате, обмен данными с использованием API и осуществлять информационный обмен с использованием СМЭВ. Выбор формата обмена данными зависит от технологической готовности на стороне системы РОИВ. Обязательный набор сведений регионального реестра должен включать в себя: – СНИЛС; – код льготы согласно классификатору СФР (ЕГИССО); – дата начала действия льготы; – дата окончания действия льготы. В качестве дополнительной НСИ от РОИВ должна передаваться и своевременно обновляться справочная информация, содержащая перечень кодов и описаний льготных категорий граждан. Блок-схема сервиса «Сбора, обработки и хранения данных о региональных тарифах и льготах» представлена на Рис. 3

4.2.3 Требования к реализации сервиса «Личный кабинет региона» Сервис «Личный кабинет региона» должен представлять собой инструмент, позволяющий РОИВ управлять данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании и пр. Сервис должен представлять собой web интерфейс, являющийся Frontend-компонентом сервиса сбора, обработки и хранения данных о региональных тарифах и льготах (требования приведены в п. 4.2.2 Технического задания), позволяющий управлять таксономией транспортных льгот региона, и иметь следующую функциональность: 1) заведение и изменение региональных нормативных правовых актов (далее - НПА), регламентирующих меры социальной защиты (поддержки) на транспорте, предоставляемые отдельным категориям граждан на территории субъекта РФ; 2) заведение и изменение перечня транспортных мер социальной защиты (поддержки) граждан, регламентированными НПА, действующими на территории субъекта, включая вид, тип, формат предоставления льгот на различных видах транспорта; 3) получение данных льготных категорий граждан региона путем импорта реестров, а также информационного обмена через API или СМЭВ; 4) отображение дашборда со статистическими данными о льготах региона с разделением по видам транспорта и категориям получателей льгот. Перечень отображаемых данных и формат их отображения должен быть согласован с Заказчиком на этапе технического проектирования

4.1.12 Требования к информационной безопасности 4.1.12.1 Подсистема обеспечения информационной безопасности АИС УЛСП Подсистема обеспечения информационной безопасности разработана в рамках контракта от 03.07.2023 № ОК/23_03 на развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу». Работы в рамках настоящего Технического задания не должны приводить к необходимости пересмотра или корректировки действующей ПОИБ АИС УЛСП. Система с учетом выполняемых по настоящему Техническому заданию работ должна соответствовать требованиям, предъявляемым к информационным системам не ниже класса защищенности «К2» и составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных не ниже 2-го уровня защищенности

4.1.13 Требования по сохранности информации при авариях Сохранность информации Системы должна обеспечиваться Заказчиком, а при выполнении миграции на ЕЦП «ГосТех» (при технологической готовности ЕЦП «ГосТех») – с применением технологии резервного копирования на основе сертифицированных ФСТЭК России решений и дублирования компонент Платформы «ГосТех». Сохранность информации Системы должна обеспечиваться: 1) при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; 2) при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий баз данных, программных файлов Системы, а также загружаемых файлов; 3) при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; 4) при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Сохранность информации Системы должна также быть обеспечена при возникновении следующих событий: 1) ошибки в работе пользователей; 2) прерывание связи сети Интернет; 3) сбой программного обеспечения Системы; 4) сбой программного обеспечения и/или компонентов, в т.ч. Платформы «ГосТех»; 5) отказ одиночного сервера; 6) отключение питания; 7) разрушение жестких дисков серверов

2. В качестве системы управления базами данных необходимо использовать базовые сервисы платформы «Гостех» указанные в п. 4.1.1 Технического задания. 3. В качестве объектного хранилища необходимо обеспечить переход на сервис объектное хранилище платформы «ГосТех» (услуга 1.8). При доработке подсистем АИС УЛСП необходимо использовать языки программирования, позволяющие проводить анализ исходного кода на наличие уязвимостей и незадекларированных возможностей, применяемых на платформе «ГосТех». Для разработки могут быть использованы один или несколько языков программирования из списка: Python; Golang (Go); Node.js; Java; Ruby; .net; C#; HTML, CSS, JavaScript, JSF, TypeScript; React.js; VueJS. При необходимости допускается использование иных языков программирования по согласованию с Заказчиком. Использование выбранного языка не должно приводить к обязательности использования программного обеспечения (средств компиляции и прочего) иностранного производства. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика

4.1.3 Требования к интеграционной архитектуре Взаимодействие со сторонними и смежными информационными системами и сервисами при развитии Системы должно осуществляться с использованием процедур и методов, поддерживаемых тем или иным решением. Определение соответствия структуры информации внешних и смежных систем со структурой информации АИС УЛСП должно осуществляться по заранее определенным правилам соответствия с возможностью настройки сопоставления. Правила определения соответствия должны использоваться для автоматического преобразования входящей и исходящей информации. Информационная совместимость должна обеспечиваться согласованием общих справочников и общих классификаторов. Хранение идентификаторов элементов НСИ и основных данных, используемых внешними и смежными системами, должно осуществляться с возможностью настройки сопоставления с аналогичными идентификаторами Систем, с последующим автоматическим преобразованием идентификаторов при обработке входящих и формировании исходящих сообщений. В рамках реализации программных сервисов, обеспечивающих взаимодействие внутренних компонентов Системы между собой при подготовке к миграции необходимо обеспечить использование базового компонента платформы «ГосТех» «Сервис управления очередями сообщений» в целях снижения связности между компонентами ПО при их взаимодействии, а также созданию высокодоступной и высоконадежной системы обмена сообщениями. Взаимодействие внутренних компонентов системы должно быть документировано в рамках технического проектирования

4.2.1.1.3 Требования к обеспечению обмена данными с информационными системами, обеспечивающими учет обучающихся на различных ступенях образования В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - учащийся высшего учебного заведения, расположенного на территории Калининградской области, имеющий документ, подтверждающий статус учащегося очной формы обучения в порядке, установленном нормативным правовым актом исполнительного органа государственной власти Калининградской области, осуществляющего на территории Калининградской области государственное управление в сфере образования, полномочия Российской Федерации в сфере образования, переданные для осуществления органам государственной власти субъектов Российской Федерации, а также полномочия в сфере организации отдыха и оздоровления детей. В рамках модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка нового типа пассажира: «Студент КГД». В рамках модификации АИС УЛСП должна быть реализована поддержка нового типа пассажира: «Студент»

В рамках модификации Подсистемы информационного обмена АИС УЛСП для получения сведений, необходимых для обработки типов пассажира «Студент» и «Студент КГД», и подтверждения права предоставления льготы требуется обеспечить информационное взаимодействие с информационными системами, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования с целью получения сведений о документах, подтверждающих обучение (при их наличии) граждан, обучающихся в образовательных организациях высшего образования и научных организациях по программам ординатуры, ассистентуры-стажировки, программам подготовки научных и научно-педагогических кадров в аспирантуре с последующей передачи подтверждения права пассажира категории «студент» на льготный проезд

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

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

4.2.4 Требования к реализации сервиса «Маломобильные» Сервис «Маломобильные» предназначен для подтверждения принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом. Сервис должен предоставлять функциональность подтверждения группы инвалидности: – инвалид 1 группы, – инвалид 2 группы, – инвалид 3 группы, – ребенок-инвалид посредством отправки запроса, содержащего СНИЛС пассажира, полученный из информационных систем перевозчиков, в ГИС ЕЦП (требования к интеграции с ГИС ЕЦП описаны в п. 4.2.1.1.1 настоящего Технического задания). Получение сервисом «Маломобильные» номера СНИЛС для последующего подтверждения группы инвалидности должно быть предусмотрено для следующих сценариев: 1) создание заявки на сопровождение в выбранных объектах транспортной инфраструктуры железнодорожного транспорта, осуществляющих деятельность по обслуживанию пассажиров при покупке билета, посадке/высадке на поезд; 2) содействие резервированию специальных мест для инвалидов в поездах дальнего следования в дополнение к имеющимся цифровым сервисам перевозчиков; 3) заказ парковочного разрешения для инвалидов в выбранных объектах транспортной инфраструктуры железнодорожного транспорта. Порядок создания заявки, в рамках вышеуказанных сценариев предусматривает ввод соответствующих сведений в информационных системах перевозчиков, в связи с чем для Сервиса «Маломобильные» собственного интерфейса для ввода данных и функциональности валидации личности не предусматривается

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, развернутых на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов согласно п. 4.1.1: 1) сервис аудита (услуга 1.15); 2) сервис журналирования (услуга 1.14); 3) сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Для аутентификации пользователей при подготовке к миграции необходима интеграция с сервисом IAM (услуга 1.13)

В целях развития АИС УЛСП и подготовки к миграции на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, необходимо использовать следующие сервисы: 4) сервис управление развертыванием программного обеспечения (услуга 1.31); 5) сервисы интеграционного взаимодействия (услуга 1.19); 6) сервисы управления очередями сообщений (1.10). Для взаимодействия со смежными системами в среде СМЭВ в составе механизмов миграции и развертки должен быть компонент «Интеграция со СМЭВ Platform V SMEV Gateway» (услуга 1.12). При подготовке к миграции для каждой подсистемы, в зависимости от функционала, необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (Сервис транзакционной СУБД (услуга 1.1), Сервис СУБД аналитического хранилища данных (услуга 1.5)). Для управления очередями сообщений должен использоваться Сервис управления очередями сообщений (услуга 1.10). Требования к технологической архитектуре и перечень используемых базовых сервисов могут быть скорректированы на этапе технического проектирования по согласованию с Заказчиком, а также исходя из условий технологической готовности платформы «ГосТех»

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Требования к документации 1) Схема сетевого взаимодействия a. Должна содержать все порты, которые используются для установления сетевых соединений; b. Должна содержать указания на протокол соединения (TCP/UDP); c. Должна содержать указание о направлении трафика между компонентами системы вплоть до уровня контейнера. 2) Архитектура решения a. Требуется использование нотации С4. 3) Перечень сервисных учётных записей, который содержит: a. Имя учётной записи; b. Компонент решения, где она применяется; c. Систему, к которой она подключается; d. Перечень привилегий, предоставленных данной учётной записи, в формате той системы, к которой данная учётная запись подключается. 4) Руководство по резервному копированию a. Руководство по резервному копированию должно содержать пошаговую инструкцию, которая позволит создать резервную копию всей системы (каждого компонента системы, который подлежит резервному копированию); b. В случае, если какой-то компонент системы не подлежит резервному копированию, в данном руководстве необходимо предоставить основания, почему резервирование компонента не требуется; c. Отдельно в руководстве должны содержаться рекомендации по резервному копированию баз данных решения, а именно: i. Частота создания полной резервной копии; ii. Частота создания инкрементальной резервной копии; iii. Длительность хранения созданных резервных копий

Для организации информационного обмена данными по маломобильным категориям граждан между АИС УЛСП и информационными системами перевозчиков и организаций железнодорожного транспорта, должна быть предусмотрена возможность реализации интеграционного взаимодействия посредством REST API. В сервисе должны быть предусмотрены возможности развития его функционала, в частности перспективное расширение на все виды транспорта, а также отработка сценариев подтверждения сведений об управлении транспортным средством инвалидом или перевозке транспортным средством инвалида, посредством запроса в ГИС ЕЦП по государственному номеру транспортного средства при создании заявки на реализацию права на бесплатное использование мест для парковки транспортных средств, в случае реализации смежными системами такой функциональности. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.1.15 Требования к персоналу Численность персонала Системы должна определяться с учетом следующих требований: – структура Системы должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности. – системное и прикладное программное обеспечение Системы должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП утверждается штатным расписанием Оператора АИС УЛСП. Численность персонала АИС УЛСП должна уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы. Система должна быть спроектирована и реализована с учетом её эксплуатации функциональными группами пользователей: – системный администратор: доступ на уровне системного и прикладного ПО без непосредственного доступа к функциям подсистем федерального сегмента и регионального сервиса; – администратор Системы: доступа к функциям подсистем федерального сегмента и регионального сервиса через графический интерфейс; – оператор федерального сегмента: доступ к подсистемам федерального сегмента и регионального сервиса через графический интерфейс; – оператор регионального сервиса: доступ к подсистемам регионального сервиса через графический интерфейс

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

4.1 Требования к развитию Системы в целом В процессе работ по созданию должны сохраниться основные требования к построению архитектуры в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (то есть представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на подэтапе Технического проектирования. Система должна быть разработана с учетом необходимости информационного обмена с сервисами цифровой платформы мониторинга осуществления перевозок пассажиров по межрегиональным и муниципальным маршрутам, в соответствии с требованиями Перечня Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023

4.1.1 Требования к использованию существующих сервисов Платформы ГосТех при развитии Системы В целях обеспечения совместимости программной архитектуры АИС УЛСП с операционными системами и системами управления базами данных, используемыми в составе платформы «ГосТех», в рамках подготовки Системы к миграции необходимо реализовать возможность использования следующих сервисов: – Сервис Key-value СУБД (услуга 1.3) (здесь и далее услуги ЕЦП «ГосТех» обозначены в соответствии с Методическими рекомендациями «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 г. № 30); – Сервис транзакционной СУБД (услуга 1.1); – Сервис СУБД полнотекстового индекса (услуга 1.4). Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

4.2.1.3 Требования к модификации Подсистемы визуализации В рамках модификации Подсистемы Визуализации должны быть изменены пользовательские интерфейсы АИС УЛСП в части обеспечения учета и отображения сведений по новым типам пассажиров на панели управления Системы, а также вывода данных по новым типам пассажиров и льгот в разделе «Визуализация данных»

4.3.3 Требования к защищённым соединениям и шифрованию 1) Решение должно содержать запрет на применение протокола HTTP в явном виде 2) При подключении к решению с использование протокола HTTP должно происходить перенаправление на HTTPS 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 5) Допустимо использовать только эллиптические кривые из списка a. X25519 b. prime256v1 c. secp521r1 d. secp384r1 6) Допустимо использовать только алгоритмы шифрования из списка a. ECDHE-ECDSA-AES128-GCM-SHA256 b. ECDHE-RSA-AES128-GCM-SHA256 c. ECDHE-ECDSA-AES256-GCM-SHA384 d. ECDHE-RSA-AES256-GCM-SHA384 e. ECDHE-ECDSA-CHACHA20-POLY1305 f. ECDHE-RSA-CHACHA20-POLY1305 g. DHE-RSA-AES128-GCM-SHA256 h. DHE-RSA-AES256-GCM-SHA384 7) Решение должно содержать явный запрет на использование алгоритмов шифрования, не входящих в пункт 6) п.п. 4.3.3 8) Решение должно содержать явный запрет на использование режима сцепления блоков шифротекста (CBC) при шифровании 9) Решение должно содержать явный запрет на использование следующих алгоритмов хеширования данных: a. MD5 b. SHA1 10) Запрещено использовать алгоритм RSA с длинной ключа менее 4096 бит

4.1.4 Требования к режимам функционирования Функционирование Системы должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Система должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме АИС УЛСП обеспечивает возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Системы, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Системы с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Системы и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Системы

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

При подготовке к миграции Платформа «ГосТех» должна обеспечить уровень сохранности информации, позволяющий восстановить данные с минимальной потерей информации: 1) в случае отказа на уровне компонентов Платформы «ГосТех» – без потери информации; 2) в иных случаях отказа – восстановление данных за период не более 24 часов для PROD-стендов и не более 48 часов для остальных стендов (DEV-, TEST-, HT-, ПСИ- стендов) до возникновения аварии (из последней резервной копии). Для обеспечения сохранности информации Системы должны быть реализованы следующие функции (при подготовке к миграции - посредством Платформы «ГосТех»): 1) резервное копирование баз данных, программных и загружаемых файлов; 2) восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключении электрического питания, сбоях операционной системы и других) вычислительно-операционной среды функционирования; 3) восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Резервное копирование осуществляется не реже одного раз в день. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.1.14 Требования к патентной чистоте и патентоспособности 4.1.14.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.14.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.14.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.14.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.14.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам

4.3.4 Требования к использованию и работе с сертификатами Все алгоритмы проверки, требования, наименование полей и иные технические термины применяются здесь и далее в соответствии со следующими стандартами: 1) RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» 2) RFC 8399 «Internationalization Updates to RFC 5280» 3) RFC 6818 «Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» Список применяемых терминов: Термин в документе Термин по RFC Самозаверенный сертификат Self-signed certificate Самоподписанный сертификат Self-signed certificate Отзыв Revocation Центр сертификации Certification Authority Субъект сертификата Subject Альтернативное имя субъекта сертификата Subject Alternative Name Период действия Validity 1) При подключении по защищённому каналу решение должно проверять предоставляемый сертификат на доверие, отзыв и соответствие его параметров дополнительным требованиям 2) В случае, если сертификат признан недоверенным, подключение не может быть установлено a. В случае, если сертификат перестал быть доверенным в момент, когда подключение уже было установлено, подключение должно быть прервано 3) Сертификат, предъявляемый при установлении соединения не может быть самоподписанным a. В противном случае выдать ошибку следующего содержания «End entity certificate is self-signed» и не устанавливать/разорвать защищённое соединение 4) Проверка сертификата должна происходить не реже, чем раз в час, даже если подключение установлено

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

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

4.2.5 Требования к реализации сервиса льготных перевозок по электронным транспортным требованиям Под электронным транспортным требованием должен подразумеваться электронный документ, наличие которого является основанием для пассажира на получение проездного документа, а для перевозчика – на компенсацию за перевозку. Сервис льготных перевозок по электронным транспортным требованиям должен быть предназначен для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании. Сервис должен предоставлять следующую функциональность: – Получение идентификатора ЭТТ из подключаемой внешней информационной системы; – формирование и передача запроса на цифровую проверку; – проведение проверки и формирование результата; – предоставление (отказ в предоставлении) услуги по продаже билета на железнодорожный транспорт пригородного и дальнего сообщения по ЭТТ. Сервис должен поддерживать следующий порядок информационного обмена: 1) оформление ЭТТ во внешней информационной системе организации, включающее в себя: a. создание заявки с заполнением сведений: i. личные данные пассажира; ii. данные поездки; iii. данные о перевозимых членах семьи; iv. цель; v. дата выдачи; vi. тип требования. b. согласование заявки и формирование ЭТТ; c. сохранение данных ЭТТ во внешней информационной системе организации; d. генерацию уникального идентификатора ЭТТ, позволяющего однозначно определить запись в системе; e. передачу пользователю идентификатора ЭТТ

2) передачу уникального идентификатора ЭТТ из внешней информационной системы в АИС УЛСП с последующим сохранением идентификатора в архиве Сервиса перевозок по ЭТТ; 3) ввод пассажиром на официальном ресурсе организации железнодорожного транспорта параметров поездки с указанием наличия права на льготу; 4) ввод пассажиром уникального кода ЭТТ на веб-странице авторизации АИС УЛСП, куда он был переадресован с официального ресурса организации железнодорожного транспорта; 5) сопоставление в АИС УЛСП уникального идентификатора ЭТТ, полученных из внешней информационной системы на шаге 2 с уникальным идентификаторам ЭТТ, полученным от пассажира и информационной системы организации железнодорожного транспорта на шаге 4; 6) передача результирующих сведений в информационную систему перевозчика для оформления билета / отказа в оформлении билета. Для обеспечения вышеуказанного взаимодействия АИС УЛСП должна быть интегрирована с ИС, хранящей данные по ЭТТ и с системами интернет-продаж перевозчиков. Все операции, совершенные с ЭТТ, должны протоколироваться в АИС УЛСП. Взаимодействие АИС УЛСП с информационными системами организаций и предприятий, осуществляющих оформление ЭТТ, должно происходить по каналам связи, защищенным с использованием шифровальных (криптографических) средств, сертифицированных ФСБ России. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АИС УЛСП должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АИС УЛСП. Интерфейс АИС УЛСП должен обеспечивать возможность масштабирования под любую ширину экрана и отображение на мобильных устройствах. Указанное действие должно происходить за счёт изменения ширины колонок сайта, их переноса вниз предыдущей колонки или отключения второстепенных элементов сайта для малых разрешений экранов (адаптивная верстка). Визуальное представление элементов пользовательского интерфейса разрабатываемой АИС УЛСП, адаптивная верстка интерфейса Системы, состав отображаемой информации подлежит согласованию Заказчиком в процессе выполнения работ по созданию Системы

5) Система должна проводить проверку имени субъекта сертификата и проверку альтернативного имени субъекта сертификата a. Имя, к которому осуществляется подключение, должно совпадать с субъектом сертификата b. Имя, к которому осуществляется подключение, должно совпадать с альтернативным именем субъекта сертификата c. В случае, если имя, к которому осуществляется подключение, совпадает с альтернативным именем субъекта сертификата, но не совпадает с субъектом сертификата, считать проверку успешной d. В любом другом случае выдать ошибку следующего содержания «Subject name or SAN does not match the connection» и не устанавливать/разорвать защищённое соединение 6) Система должна проверять, что период действия сертификата уже начался и ещё не истёк a. Значение в секции notBefore должно быть меньше, чем текущая дата b. Значение в секции notAfter должно быть больше, чем текущая дата c. В противном случае выдать ошибку следующего содержания «Certificate expired or not yet valid» и не устанавливать/разорвать защищённое соединение 7) Система должна проверять цепочку доверия вплоть до корневого сертификата a. Предоставленный при подключении исходный сертификат (Сертификат А) должен содержать поле «Authority Information Access» i. В противном случае выдать ошибку следующего содержания «No AIA field available» и не устанавливать/разорвать защищённое соединение b. Сертификат, представленный в данном поле (Сертификат Б), должен быть тем сертификатом, который подписал Сертификат А i. В противном случае выдать ошибку следующего содержания «Certificate signed not by CA in AIA» и не устанавливать/разорвать защищённое соединение c. Если сертификат Б является самоподписанным, то проверить, что сертификат находится в списке доверия i. В противном случае выдать ошибку следующего содержания «Root CA is not trusted» и не устанавливать/разорвать защищённое соединение d. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а

4.1.5 Показатели назначения Ключевым показателем назначения Системы является выполнение действующих, а также функциональных требований, перечисленных в разделе 4.2 настоящего документа. Архитектура Системы должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание: изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Система должна обеспечивать возможность одновременного доступа пользователей в соответствии с Таблицей 3 – Показатели производительности, при условии использования разных учётных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Система должна обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Системы. Показатели назначения в части использования инфраструктурных технологических сервисов, базовых сервисов и типовых решений платформы «ГосТех»: ? использование не менее 10 базовых сервисов в составе Системы; ? обеспечение совместимости уровня «Compatible» мигрируемых подсистем Системы с платформой «ГосТех»

Иные показатели назначения представлены в таблицах 2, 3 и 4 ниже. Таблица 2 – Показатели назначения № Параметр Значение 1 Количество профилей пассажиров не менее 1 млн. человек 2 Система должна обеспечивать сохранение производительности при ежемесячном приросте данных в хранилище не менее 350 Mб 3 Период хранения данных не менее 3 лет Таблица 3 – Показатели производительности № Показатель Штатный режим Пиковый режим 1 Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 100 2 Количество одновременно подключенных смежных систем 30 100 Таблица 4 – Целевое время отклика № Показатель Средняя величина не более, с Максимальная величина не более, с Время отклика на запрос в API 1 при получении данных от одного источника 0,2 1 2 при обновлении данных от одного источника 0,2 1 Время отклика на запрос в Административной панели 3 при выполнении операций поиска информации 3 10 4 при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП не учитывает задержку формирования ответа на запрос на стороне системы источника. Показатели назначения АИС УЛСП могут быть уточнены на этапе технического проектирования

4.1.6 Требования к надежности функционирования и доступности для пользователей Показатели надежности Системы должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Система должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций. В целях обеспечения надежности и сохранности информации при подготовке к миграции должны использоваться сервисы и средства платформы «ГосТех». Должно быть предусмотрено резервное копирование (в т.ч. средствами Платформы «ГосТех» при осуществлении миграции) как по команде администратора, так и по заранее составленному расписанию, что должно определяться соглашением, заключенным между Оператором АИС УЛСП и Оператором платформы «ГосТех»

- форма обучения (очная, очно-заочная, заочная, получение образования в семье, самообразование, экстернат). В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры»; - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры на территории Калининградской области», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «Пассажир отсутствует в системе-источнике данных»; o «Пассажир не является студентом ВУЗа на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе» (для типа пассажира «Студент»). Также для нового типа пассажира «Студент» должен быть реализован информационный обмен с системами-потребителями организаций железнодорожного транспорта, согласно п. 4.2.1.1.4 настоящего Технического задания

4.2.1.1.4 Требования к обеспечению обмена данными с информационными системами организаций железнодорожного транспорта Обмен данными с информационными системами организаций железнодорожного транспорта должен осуществляться посредством REST API, а также файлового обмена с использованием протокола SFTP, с целью обеспечения передачи информации о наличии у пассажира права на проезд по льготному, сниженному или безденежному тарифу на железнодорожном транспорте пригородного сообщения и дальнего следования, а также наличия у него прав на специальное обслуживание (сопровождение инвалидов и маломобильных) и приобретения билетов на специальные места для инвалидов в поездах дальнего следования. Подсистема информационного обмена АИС УЛСП должна обеспечивать возможность взаимодействия с витринами продаж электронных билетов организаций железнодорожного транспорта, а также с интеграционными платформами ОАО «РЖД», его дочерних компаний и взаимозависимых лиц, предоставляющих гражданам возможность оформления электронных билетов на следующие виды транспорта: – Поезда дальнего следование; – Поезда пригородного сообщения; – Межрегиональные автобусы; – Авиасообщение; – Водный пассажирский транспорт; – Мультимодальные маршруты, а также заказ туристических услуг и оформления поездок, в том числе льготных, на основании данных геолокации при бесконтактной оплате проезда в пригородном железнодорожном сообщении. Способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования

11) Руководство по чтению журналов (логов) приложения, которое содержит: a. Описание формата журналов; b. Классификатор событий; c. Детальное описание событий. 12) Руководство по сборке приложения из исходного кода a. Должны быть предоставлена инструкция по сборке из исходного кода каждого компонента решения (контейнера, исполняемого файла, пакета, и т.д.); b. Сборка должна производиться без использования информационно-телекоммуникационной сети «Интернет»

8) Система должна проверять сертификат на отзыв с использованием CRL или OCSP a. Предоставленный при подключении исходный сертификат (Сертификат А) НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Сертификат, взятый из поля «Authority Information Access» (Сертификат Б), НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Если сертификат Б является самоподписанным, то проверка отзыва не проводится и цикл завершается b. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а. 9) Система должна проверять, что значения в поле «Extended Key Usage» присутствуют в списке разрешённых EKU для конкретного подключения a. В противном случае выдать ошибку следующего содержания «Certificate’s EKU does not match approved ones» и не устанавливать/разорвать защищённое соединение 10) Система должна проверять поле «Basic Constraints» a. В случае, если поле отсутствует, выдать ошибку следующего содержания «Basic Constraints filed is empty» и не устанавливать/разорвать защищённое соединение b. В случае, если сертификат, предоставленный при подключении содержит значение TRUE в секции «CA», выдать ошибку следующего содержания «End entity certificate is CA certificate» и не устанавливать/разорвать защищённое соединение c. При проведении проверки согласно п.п. 7) пункта 4.3.4 проверять поле Basic Constraints согласно требованиям RFC 5280 (секция 4.2.1.9. Basic Constraints)

4.2 Функциональные требования к развитию АИС УЛСП 4.2.1 Требования к модификации существующих подсистем АИС УЛСП в рамках обеспечения поддержки новых типов мер социальной поддержки (защиты) пассажиров В связи с изменением нормативно-правовой базы, а также вводом в действие новых информационных систем федеральных органов исполнительной власти, участвующих в информационном обмене с АИС УЛСП, необходимо провести модификацию и доработку Системы с целью обеспечения цифрового подтверждения права на проезд по льготному, сниженному, специальному или безденежному тарифу для новых категорий пассажиров на разных видах транспорта, а также доработать подсистему информационного обмена АИС УЛСП с целью обеспечить устойчивый обмен данными с новыми системами-источниками и системами-потребителями. Модификация системы производится на мощностях Заказчика, разработанная Система запускается в опытную эксплуатацию в рамках продуктивного контура ФГБУ «СИЦ Минтранса России». 4.2.1.1 Требования к модификации Подсистемы информационного обмена Подсистема информационного обмена АИС УЛСП обеспечивает взаимодействие с системами-источниками и системами-потребителями, в частности с информационными системами Федеральной Налоговой службы России (ИС ФНС) и Социального Фонда России (ИС СФР), Министерства труда и социальной защиты Российской Федерации с целью проверки данных пассажира, получения данных о месте жительства и действующих льготных категориях гражданина

Этап №3: Предварительные испытания, опытная эксплуатация, приемочные испытания Идентификатор: 149130657 - 62.01.11.000 - - - - - 1 - Условная единица - 9853333.95 - 9853333.95

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин/сокращение Определение АИС УЛСП, Система Автоматизированная информационная система управления льготными и субсидированными перевозками АСОП Автоматизированная система оплаты проезда АРМ Автоматизированное рабочее место БД База данных ВС Вид сведений ВСК Виртуальная социальная карта Минцифры России ВУЗ Высшее учебное заведение ГИС ЕЦП Государственная информационная система «Единая централизованная цифровая платформа в социальной сфере» ГосСОПКА Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации Дашборд Информационная панель, которая получает данные из других систем и отображает их в визуализированном формате ДУЛ Документ, удостоверяющий личность ЕГИССО Единая государственная информационная система социального обеспечения ЕСИА Единая система идентификации и аутентификации Контракт Контракт, в рамках которого исполняется настоящее Техническое задание ИС Информационная система МСП Меры социальной поддержки МСЗ Меры социальной защиты НКЦКИ Национальный координационный центр по компьютерным инцидентам НПА Нормативный правовой акт НПБ Нормативно-правовая база НСИ Нормативно-справочная информация ОАО «РЖД» Открытое акционерное общество «Российские железные дороги» ООЗ Описание объекта закупки ОС Операционная система Платформа «ГосТех», ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» - экосистема создания, развития и эксплуатации государственных информационных систем, включающая в себя единую программно-аппаратную среду и методологию, поддерживающая взаимоотношения граждан, государственных органов и коммерческих организаций на базе современных информационных технологий с целью повышения доступности государственных услуг и функций, а также направленная на снижение расходов участников на использование государственных услуг ПМИ Программа и методика испытаний ПО Программное обеспечение ПОИБ Подсистема обеспечения информационной безопасности - - Значение характеристики не может изменяться участником закупки

ППК ЦР Президиум Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности ПСП Портал субсидированных перевозок РОИВ Региональный орган исполнительной власти РФ Российская Федерация СЗИ Средства защиты информации СКЗИ Средства криптографической защиты информации СМЭВ Система межведомственного электронного взаимодействия СНИЛС Страховой номер индивидуального лицевого счета СПО Системное программное обеспечение СУБД Система управления базой данных СФР Фонд пенсионного и социального страхования Российской Федерации ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ФГИС ЕРН Федеральная государственная информационная система ведения Единого федерального информационного регистра, содержащего сведения о населении Российской Федерации ФГИС ФРИ Федеральная государственная информационная система «Федеральный реестр инвалидов» ФИО Фамилия, имя, отчество ФНС Федеральная налоговая служба Российской Федерации ФПСС Фонд пенсионного и социального страхования ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЭТТ Электронное транспортное требование ЭВМ Электронная вычислительная машина - комплекс технических (аппаратных) и программных средств для обработки информации, вычислений, автоматического управления. API Application Programming Interface – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Frontend Визуальная часть Системы, которую пользователь видит и с которой может взаимодействовать при помощи браузера HTTPS HyperText Transfer Protocol Secure - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности

1 ОБЩИЕ СВЕДЕНИЯ - 17. Методические рекомендации «Стандарт по управлению динамической инфраструктурой Единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54. 18. Методические рекомендации по разработке разделов технического задания, составу и содержанию требований, включаемых в техническое задание на создание, развитие государственных информационных систем, создаваемых (развиваемых) на единой цифровой платформе Российской Федерации «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.12.2023 № 47пр. 19. Методические рекомендации по вопросам разработки государственных информационных систем с использованием платформы «ГосТех» и определения обязательности повторного использования цифровых продуктов платформы «ГосТех» при их создании и развитии, утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 20.10.2023 № 47пр. 20. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2010 № 631-ст - - Значение характеристики не может изменяться участником закупки

21. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств. Принят и введен в действие постановлением Госстандарта России от 25.06.2002 № 248-ст. 22. ГОСТ Р ИСО/МЭК ТО 15271-2002. Государственный стандарт Российской Федерации. Информационная технология. Процессы жизненного цикла программных средств. Руководство по применению ГОСТ Р ИСО/МЭК 12207 принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 227-ст. 23. ГОСТ Р ИСО/МЭК ТО 16326-2002. Государственный стандарт Российской Федерации. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом принят и введен в действие постановлением Госстандарта России от 05.06.2002 № 226-ст. 24. ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования» утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30.11.2021 № 1653-ст

1.5 Сроки начала и окончания работ Начало работ: с 01.06.2024 Окончание работ: по 13.12.2024 Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются планом-графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего Технического задания (далее – Календарный план)

1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определённом Контрактом в сроки, установленные п. 5.1 настоящего Технического задания, в соответствии с Календарным планом

1.1 Наименование системы Автоматизированная информационная система управления льготными и субсидированными перевозками. Условное обозначение: АИС УЛСП, Система. Наименование работ: развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками, включая подготовку к размещению на единой цифровой платформе Российской Федерации «ГосТех» (далее – Работы). Код по ОКПД2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения»

1.2 Наименование заказчика и подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры

1.3 Основания для выполнения работ 1. Указ Президента Российской Федерации «О создании, развитии и эксплуатации государственных информационных систем с использованием единой цифровой платформы Российской Федерации «ГосТех» от 31.03.2023 № 231. 2. Перечень Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023. 3. Стратегическое направление в области цифровой трансформации транспортной отрасли Российской Федерации до 2030 года, утвержденное распоряжением Правительства РФ от 03.11.2023 г. № 3097-р. 4. Федеральный закон от 17.07.1999 № 178-ФЗ «О государственной социальной помощи». 5. Федеральный закон от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации». 6. Федеральный закон от 29.12.2015 № 388-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части учета и совершенствования предоставления мер социальной поддержки исходя из обязанности соблюдения принципа адресности и применения критериев нуждаемости. 7. Постановление Правительства РФ от 27.03.2019 № 320 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям железнодорожного транспорта на компенсацию части потерь в доходах, возникающих в результате предоставления гражданам государственной социальной услуги в виде бесплатного проезда на железнодорожном транспорте в пригородном сообщении при условии ведения персонифицированного учета поездок». 8. Постановление Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации»

10. Постановление Правительства Российской Федерации от 16.12.2022 № 2338 «Об утверждении Положения о единой цифровой платформе Российской Федерации «ГосТех», о внесении изменений в постановление Правительства Российской Федерации от 06.07.2015 № 676 и признании утратившим силу пункта 6 изменений, которые вносятся в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации, утвержденных постановлением Правительства Российской Федерации от 11.05.2017 № 555»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1. Указ Президента Российской Федерации от 21.07.2020 № 474 «О национальных целях развития Российской Федерации на период до 2030 года». 2. Перечень инициатив социально-экономического развития до 2030 года, утвержденный Распоряжением Правительства Российской Федерации от 06.10.2021 № 2816-р. 3. Транспортная стратегия Российской Федерации до 2030 года с прогнозом на период до 2035 года, утвержденная Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р. 4. Федеральный закон «О федеральном бюджете на 2024 год и на плановый период 2025 и 2026 годов» от 27.11.2023 № 540-ФЗ. 5. «Классификатор мер социальной защиты (поддержки)», утвержденный Министерством труда и Социальной защиты Российской Федерации 02.06.2017. 6. Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 7. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия». 8. Постановление Правительства РФ от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия». 9. Постановление Правительства Российской Федерации от 28.11.2011 № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме». 10. Постановление правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»

11. Постановление правительства Российской Федерации от 16.11.2015 № 1236 и «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». 12. Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех». 13. Протокол стратегической сессии под председательством Председателя Правительства Российской Федерации М.В. Мишустина по созданию, развитию и эксплуатации единой цифровой платформы Российской Федерации «ГосТех» от 10.05.2023 № 2. 14. Методические рекомендации по проектированию и утверждению целевой архитектуры домена с использованием единой цифровой платформы «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 13.07.2022 № 26. 15. Методические рекомендации «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 № 30. 16. Методические рекомендации по эксплуатации государственных информационных систем на Единой цифровой платформе «ГосТех», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 08.12.2022 № 54

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

4.1.14.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.14.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.14.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.14.9. Нарушение условий настоящего раздела Технического задания, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.14.10. В случае, если в соответствии с пунктом 4.1.14.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.14.11. В случае, если при выполнении Работ положения пунктов 4.1.14.5-4.1.14.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела Технического задания, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Систем

4.1.7 Требования по диагностированию Системы Компоненты АИС УЛСП должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности аппаратных средств, специального и общего ПО. АИС УЛСП должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы, а также мониторинга процесса выполнения программ. Система должна осуществлять ведение журналов инцидентов в электронном формате. При возникновении аварийных ситуаций либо ошибок в программном обеспечении, диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и решения проблемы системными администраторами либо разработчиками. Диагностирование АИС УЛСП должно базироваться на анализе данных мониторинга. Сбор данных мониторинга должен предусматривать возможность организации уведомлений о выходе отслеживаемых параметров за пороговые значения. При подготовке к миграции на ЕЦП «ГосТех» диагностирование и мониторинг состояния Системы должны производиться базовыми сервисами Платформы «ГосТех». Диагностирование Системы должно выполняться с целью своевременного предупреждения возникновения аварийных ситуаций и обеспечивать выявление неработоспособности Системы. В процессе диагностирования должна быть обеспечена: – регистрация диагностических сообщений при работе специального программного обеспечения; – передача журналов и метрик в централизованную систему мониторинга платформы «ГосТех» (при подготовке к миграции), в том числе информации о появлении критических событий, а также логирования событий; – генерация оповещений о возможности появления критичных событий в работе Системы. Полный перечень параметров, подлежащих диагностике, определяется на стадии технического проектирования

4.1.8 Требования к транспортабельности Не предъявляются. 4.1.9 Требования к эксплуатации и техническому обслуживанию Требования к режимам функционирования Системы описаны в п. 4.1.4. При подготовке к миграции на ЕЦП «ГосТех» для обеспечения задач эксплуатирующего персонала по диагностированию состояния Системы и предотвращению аварийных состояний необходимо обеспечить постоянное диагностирование средствами Платформы «ГосТех». 4.1.10 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется

4.1.11 Требования к возможностям развития Системы Архитектура Системы должна предусматривать возможность: – расширения состава внешних и смежных информационных систем-источников информации; – расширения состава внешних и смежных информационных систем-получателей информации; – расширения состава и наполнения БД АИС УЛСП, нормативно-справочной информации, в том числе при изменении положений нормативных правовых актов, затрагивающих информационное содержание Системы; – внедрения дополнительных функциональных подсистем; – расширения функциональных возможностей существующих подсистем. При этом вышеуказанные доработки не должны препятствовать работе существующих подсистем. Отказоустойчивость Системы должна обеспечиваться Заказчиком средствами действующего технологического стека АИС УЛСП, а также сервисами платформы ЕЦП «ГосТех» (при обеспечении технологической готовности платформы)

4.1.2 Требования к технологической архитектуре Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes в тестовом контуре на платформе «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом обязательна подготовка к использованию базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При осуществлении разработки и развития Подсистем, а также их подготовки к миграции на ЕЦП «ГосТех», следует использовать не только инструменты управления планированием, требованиями, релизами, дефектами, тестированием и отслеживанием версионности (услуги: управление планированием (1.20), управление требованиями (1.21), управление релизами (1.22), управление дефектами (1.23), управление тестированием (1.24)), но и инструменты управления сборкой программного обеспечения, а также аналитики и мониторинга производственного процесса. Результаты разработки, перед сборкой программного обеспечения, должны проходить анализ качества кода с использованием базового сервиса платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). В подсистемах, предусматривающих взаимодействие с пользователями Системы, веб серверы должны размещаться в рамках соответствующих пространств имен кластеров Kubernetes. Хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). Реализация хранения вложений в базах данных подсистем не допускается

Для каждой подсистемы, в зависимости от функционала, при подготовке к миграции на ЕЦП «ГосТех» необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (при наличии технологической готовности ЕЦП «ГосТех»). При этом не допускается использование одной инсталляции СУБД для использования разными подсистемами. Для аутентификации всех уровней пользователей необходима интеграция подготовленных к миграции подсистем с сервисом IAM (при наличии технологической готовности ЕЦП «ГосТех») (услуга 1.13). Должна быть обеспечена возможность взаимодействия подсистем друг с другом для обеспечения сквозной передачи данных. В случае обоснованного использования ЦОД, не относящегося к платформе «ГосТех», параметры ЦОД, в котором размещается ГИС, должны соответствовать требованиям ГОСТ Р 70139-2022 для ЦОД класса ГИС-3, а также параметрам отказоустойчивости и катастрофоустойчивости с учетом требований Приказа Минцифры России от 01.06.2023 № 500 «Об утверждении критериев оценки отказоустойчивости и катастрофоустойчивости инфраструктуры платформы «ГосТех», а также иметь действующие аттестаты соответствия требованиям по защите информации уровня защищенности персональных данных не ниже УЗ-2 и классу защищенности К2. При проработке механизмов и порядка миграции существующих подсистем АИС УЛСП на платформу «ГосТех» необходимо обеспечить переход на использование соответствующего технологического стека, в частности: 1. Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

4.2.1.1.2 Требования к обеспечению обмена данными с ИС ФНС России В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - гражданин Российской Федерации, зарегистрированный по месту жительства на территории Калининградской области. В целях модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка новых типов пассажира: - «житель КГД». С целью поддержки предоставления цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу для нового типа пассажира «житель КГД» технологический процесс взаимодействия АИС УЛСП с ИС ФНС должен производиться по ВС «Предоставление из ЕРН по запросу сведений о физическом лице» посредством СМЭВ и должен включать в себя следующие задачи: 1) Получение запросов от ПСП, содержащих данные Пассажиров: - идентификатор Пассажира в запросе; - фамилия; - имя; - отчество (при наличии); - дата рождения; - тип документа, удостоверяющего личность; - серия и номер документа, удостоверяющего личность; - пол; - номер СНИЛС (необязательное поле запроса); - типы пассажира на подтверждение. 2) Формирование и отправка АИС УЛСП запроса для подтверждения личности пассажира в ИС ФНС. Данные пассажира, передаваемые в запросе к ИС ФНС: - фамилия, имя, отчество (далее – ФИО) (отдельными полями); - дата рождения; - пол; - тип документа, удостоверяющего личность пассажира; - серия и номер документа, удостоверяющего личность пассажира; - признак того, что в ответе нужны данные о регионе регистрации гражданина

3) В случае подтверждения гражданина по полному совпадению данных ИС ФНС необходимо обеспечить обработку ответа в сторону АИС УЛСП, содержащего положительный ответ о подтверждении личности, и дополнительно по подтвержденному пассажиру предоставление следующих данных: - сведения о регистрации гражданина Российской Федерации по месту жительства; - информация по другим документам, удостоверяющим личность (тип, серия и номер), имеющихся в системе данных федеральных органов исполнительной власти по данному гражданину. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «житель КГД», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «У пассажира отсутствует постоянная регистрация в субъекте РФ, входящем в Калининградскую область» (для типа пассажира «житель КГД»). Таким образом, общий порядок информационного обмена должен иметь следующий вид: 1) ПСП отправляет запрос в АИС УЛСП, посредством внешнего API, содержащий данные пассажира. 2) Внешний API передает запрос в scheduler (планировщик задач). Scheduler проверяет по хешу запроса наличие данных подтверждения личности и типа пассажира в БД АИС УЛСП. При наличии ответа: - возвращает его в ответе на запрос внешнего API. - внешний API отправляет ответ в ПСП, содержащий данные подтверждения личности и типов пассажира, а также найденные ДУЛ. При отсутствии ответа в БД: - возвращает в ответ во внешний API данные запроса от ПСП в составе: - идентификатор пассажира в запросе; - данные ДУЛ из запроса ПСП; - внешний API перенаправляет ответ в ПСП (переход к шагу 5)

4) Scheduler передает запрос в сервис взаимодействия с адаптером СМЭВ-3 smev-exchanger для формирования запросов в адаптер СМЭВ 3. 5) Адаптер СМЭВ-3 производит взаимодействие с инфраструктурой ИС поставщика (ФНС). 6) Полученный ответ от ИС поставщика Адаптер СМЭВ-3 передает в scheduler. 7) Scheduler осуществляет проверку осуществляет проверку на подтверждение личности и типов пассажира исходя из данных от ПСП и ИС поставщика и записывает результирующий ответ в БД

4.3.2 Общие требования 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологическом стеке (п. 4.2.8 настоящего Технического задания) в инфраструктуре Заказчика a. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика 2) Решение должно работать в изолированной сети (без доступа информационно-телекоммуникационной сети «Интернет») 3) Должна быть возможность редактировать список доверенных корневых сертификатов для решения a. По умолчанию список доверенных сертификатов должен быть пустым 4) Должна быть возможность редактировать список допустимых EKU (связано с п.п. 9) пункта 4.3.4.) a. По умолчанию список допустимых EKU должен быть пустым b. Список допустимых EKU должен вестись отдельно для каждого защищённого подключения 5) Допускается использование только кластеризованных баз данных a. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре заказчика 6) Решение должно быть отказоустойчивым a. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов b. Использование механизмов виртуализации и контейнеризации по перезапуску виртуальных машин/контейнеров для реализации этого пункта недопустимо 7) Любые соединения, устанавливаемые решением, должны быть защищёнными a. Защищёнными считаются соединения, устанавливаемые по протоколу HTTPS, либо с использованием протокола TLS b. Соединения, устанавливаемые в рамках одного пространства имён (namespace) и в рамках одной контейнерной платформы, могут использовать протокол HTTP, либо подключаться без использования протокола TLS c. План восстановления d. Допустимо только по согласованию с техническими специалистами Заказчика 8) Любая сервисная учётная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на неё задач a. Использование учётных записей с административными полномочиями не допускается

9) Реляционные базы данных решения должны соответствовать четвёртой нормальной форме или выше; 10) Любые предоставляемые веб приложения обязаны поддерживать публикацию через обратный прокси-сервер (reverse-proxy) 11) Аутентификация и авторизация должны проходить только на сервисах управления идентификацией и контролем доступа (Identity Access Management, IAM), имеющих сертификат ФСТЭК по 4-ому классу доверия и имеющимися у Заказчика 12) Контейнеры, разворачиваемые вне Kubernetes, должны разворачиваться с использованием docker compose a. Допустимо только по согласованию с техническими специалистами Заказчика 13) Разворачивание в платформу контейнеризации на базе Kubernetes должно производиться с использованием helm chart версии 3 a. Не допускается использование нескольких helm chart для разворачивания одного решения b. Допускается использование «зонтичного» helm chart (helm chart который запускает другие helm chart) c. Запрещается использование любого метода кодирования в файлах helm chart 14) Передать Заказчику в момент сдачи решения и при любом внесении изменений в решение со стороны Подрядчика: a. Пакеты, требуемые для работы решения b. Исходный код решения c. Контейнеры, требуемые для работы решения 15) Установка решения в продуктивный контур производится силами и сотрудниками Заказчика 16) Подрядчик не имеет доступа в продуктивный контур a. Запрещается передача данных из тестового контура в продуктивный

В рамках сервиса учета Виртуальных социальных карт АИС УЛСП должна быть реализована возможность получения данных по гражданам, относящимся к категории получателей мер социальной поддержки (защиты) регионального уровня «Члены многодетной семьи», проживающих на территории регионов, внедряющих ВСК, и оформивших ВСК, для последующего использования этих данных при цифровом подтверждении права пассажира на оформление авиабилета по специальному тарифу согласно ПП РФ №215 от 02.03.2018 г., а также при оформлении проездного документа на железнодорожный транспорт пригородного сообщения путем передачи соответствующих цифровых подтверждений в ПСП и/или подключенные информационные системы перевозчиков. Информационное взаимодействие между Витринами данных ВСК и АИС УЛСП должно осуществляться посредством СМЭВ-4, а с ПСП и организациями железнодорожного транспорта – посредством REST API. Конкретный способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.2.8 Требования к выполнению работ по проработке механизмов и подготовке к миграции АИС УЛСП на ЕЦП «ГосТех» Развиваемые и мигрируемые сервисы и подсистемы должны быть готовы к развёртыванию в имеющейся технологической среде Заказчика, а также в рамках изолированных пространств имен кластеров Kubernetes на платформе «ГосТех» (при наличии технологической готовности платформы). При этом при подготовке к миграции обязательно использование базовых компонентов платформы «ГосТех» для регистрации и протоколирования в формализованном виде действий пользователей, а также сбор и хранение метрик приложений. При подготовке к миграции хранение данных должно осуществляться с использованием базового сервиса «Хранение данных» платформы «ГосТех». Текущий технологический стек АИС УЛСП включает в себя: 1. ОС АЛЬТ версии 8 СП; 2. ASP.NET(C#); 3. Blazor(server); 4. Entity Framework; 5. JavaScript; 6. HTML; 7. CSS; 8. PostgreSQL; 9. Kubernetes; 10. Docker; 11. SonarQube. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика. При реализации механизмов миграции АИС УЛСП на платформу «ГосТех» необходимо обеспечить подход к использованию технологического стека в соответствии с диаграммой развертывания, указанной на Рис. 4 – Диаграмма развертывания АИС УЛСП на платформе «ГосТех» (может быть изменено по согласованию с Заказчиком на этапе технического проектирования). Рис. 4 Диаграмма развертывания АИС УЛСП на платформе «ГосТех»

5) самостоятельного ввода, редактирования и удаления информации, хранящейся в сервисе, с помощью инструментов Личного кабинета региона согласно п. 4.2.3. Технического задания; 6) формирования и хранения статистических данных для их отображения в сервисе «Личный кабинет региона». С целью реализации функциональности сбора реестров в Сервисе должен быть реализован модуль Подсистемы информационного обмена, который должен поддерживать импорт данных в файловом формате, обмен данными с использованием API и осуществлять информационный обмен с использованием СМЭВ. Выбор формата обмена данными зависит от технологической готовности на стороне системы РОИВ. Обязательный набор сведений регионального реестра должен включать в себя: – СНИЛС; – код льготы согласно классификатору СФР (ЕГИССО); – дата начала действия льготы; – дата окончания действия льготы. В качестве дополнительной НСИ от РОИВ должна передаваться и своевременно обновляться справочная информация, содержащая перечень кодов и описаний льготных категорий граждан. Блок-схема сервиса «Сбора, обработки и хранения данных о региональных тарифах и льготах» представлена на Рис. 3

4.2.3 Требования к реализации сервиса «Личный кабинет региона» Сервис «Личный кабинет региона» должен представлять собой инструмент, позволяющий РОИВ управлять данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании и пр. Сервис должен представлять собой web интерфейс, являющийся Frontend-компонентом сервиса сбора, обработки и хранения данных о региональных тарифах и льготах (требования приведены в п. 4.2.2 Технического задания), позволяющий управлять таксономией транспортных льгот региона, и иметь следующую функциональность: 1) заведение и изменение региональных нормативных правовых актов (далее - НПА), регламентирующих меры социальной защиты (поддержки) на транспорте, предоставляемые отдельным категориям граждан на территории субъекта РФ; 2) заведение и изменение перечня транспортных мер социальной защиты (поддержки) граждан, регламентированными НПА, действующими на территории субъекта, включая вид, тип, формат предоставления льгот на различных видах транспорта; 3) получение данных льготных категорий граждан региона путем импорта реестров, а также информационного обмена через API или СМЭВ; 4) отображение дашборда со статистическими данными о льготах региона с разделением по видам транспорта и категориям получателей льгот. Перечень отображаемых данных и формат их отображения должен быть согласован с Заказчиком на этапе технического проектирования

4.2.1.1.3 Требования к обеспечению обмена данными с информационными системами, обеспечивающими учет обучающихся на различных ступенях образования В связи с внесением изменений в порядок предоставления субсидий из федерального бюджета организациям воздушного транспорта в АИС УЛСП должен быть добавлен новый тип «пассажира» - учащийся высшего учебного заведения, расположенного на территории Калининградской области, имеющий документ, подтверждающий статус учащегося очной формы обучения в порядке, установленном нормативным правовым актом исполнительного органа государственной власти Калининградской области, осуществляющего на территории Калининградской области государственное управление в сфере образования, полномочия Российской Федерации в сфере образования, переданные для осуществления органам государственной власти субъектов Российской Федерации, а также полномочия в сфере организации отдыха и оздоровления детей. В рамках модификации модуля АИС УЛСП, реализующего функционал подтверждения права пассажира на приобретение авиабилета по специальному тарифу, должна быть реализована поддержка нового типа пассажира: «Студент КГД». В рамках модификации АИС УЛСП должна быть реализована поддержка нового типа пассажира: «Студент»

В рамках модификации Подсистемы информационного обмена АИС УЛСП для получения сведений, необходимых для обработки типов пассажира «Студент» и «Студент КГД», и подтверждения права предоставления льготы требуется обеспечить информационное взаимодействие с информационными системами, обеспечивающими учет и прием граждан в образовательные организации для получения среднего профессионального и высшего образования с целью получения сведений о документах, подтверждающих обучение (при их наличии) граждан, обучающихся в образовательных организациях высшего образования и научных организациях по программам ординатуры, ассистентуры-стажировки, программам подготовки научных и научно-педагогических кадров в аспирантуре с последующей передачи подтверждения права пассажира категории «студент» на льготный проезд

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

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

2. В качестве системы управления базами данных необходимо использовать базовые сервисы платформы «Гостех» указанные в п. 4.1.1 Технического задания. 3. В качестве объектного хранилища необходимо обеспечить переход на сервис объектное хранилище платформы «ГосТех» (услуга 1.8). При доработке подсистем АИС УЛСП необходимо использовать языки программирования, позволяющие проводить анализ исходного кода на наличие уязвимостей и незадекларированных возможностей, применяемых на платформе «ГосТех». Для разработки могут быть использованы один или несколько языков программирования из списка: Python; Golang (Go); Node.js; Java; Ruby; .net; C#; HTML, CSS, JavaScript, JSF, TypeScript; React.js; VueJS. При необходимости допускается использование иных языков программирования по согласованию с Заказчиком. Использование выбранного языка не должно приводить к обязательности использования программного обеспечения (средств компиляции и прочего) иностранного производства. Требования к технологической архитектуре могут быть скорректированы на этапе разработки Технического проекта по согласованию с Заказчиком. Проработка механизмов и порядка миграции Системы на платформу «ГосТех» не должна исключать функционирования текущего технологического стека АИС УЛСП в технологическом контуре Заказчика

4.1.12 Требования к информационной безопасности 4.1.12.1 Подсистема обеспечения информационной безопасности АИС УЛСП Подсистема обеспечения информационной безопасности разработана в рамках контракта от 03.07.2023 № ОК/23_03 на развитие Системы «Портал субсидированных перевозок» цифровой платформы транспортного комплекса и Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу». Работы в рамках настоящего Технического задания не должны приводить к необходимости пересмотра или корректировки действующей ПОИБ АИС УЛСП. Система с учетом выполняемых по настоящему Техническому заданию работ должна соответствовать требованиям, предъявляемым к информационным системам не ниже класса защищенности «К2» и составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных не ниже 2-го уровня защищенности

4.1.13 Требования по сохранности информации при авариях Сохранность информации Системы должна обеспечиваться Заказчиком, а при выполнении миграции на ЕЦП «ГосТех» (при технологической готовности ЕЦП «ГосТех») – с применением технологии резервного копирования на основе сертифицированных ФСТЭК России решений и дублирования компонент Платформы «ГосТех». Сохранность информации Системы должна обеспечиваться: 1) при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях; 2) при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий баз данных, программных файлов Системы, а также загружаемых файлов; 3) при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы; 4) при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала. Сохранность информации Системы должна также быть обеспечена при возникновении следующих событий: 1) ошибки в работе пользователей; 2) прерывание связи сети Интернет; 3) сбой программного обеспечения Системы; 4) сбой программного обеспечения и/или компонентов, в т.ч. Платформы «ГосТех»; 5) отказ одиночного сервера; 6) отключение питания; 7) разрушение жестких дисков серверов

4.1.3 Требования к интеграционной архитектуре Взаимодействие со сторонними и смежными информационными системами и сервисами при развитии Системы должно осуществляться с использованием процедур и методов, поддерживаемых тем или иным решением. Определение соответствия структуры информации внешних и смежных систем со структурой информации АИС УЛСП должно осуществляться по заранее определенным правилам соответствия с возможностью настройки сопоставления. Правила определения соответствия должны использоваться для автоматического преобразования входящей и исходящей информации. Информационная совместимость должна обеспечиваться согласованием общих справочников и общих классификаторов. Хранение идентификаторов элементов НСИ и основных данных, используемых внешними и смежными системами, должно осуществляться с возможностью настройки сопоставления с аналогичными идентификаторами Систем, с последующим автоматическим преобразованием идентификаторов при обработке входящих и формировании исходящих сообщений. В рамках реализации программных сервисов, обеспечивающих взаимодействие внутренних компонентов Системы между собой при подготовке к миграции необходимо обеспечить использование базового компонента платформы «ГосТех» «Сервис управления очередями сообщений» в целях снижения связности между компонентами ПО при их взаимодействии, а также созданию высокодоступной и высоконадежной системы обмена сообщениями. Взаимодействие внутренних компонентов системы должно быть документировано в рамках технического проектирования

4.1.15 Требования к персоналу Численность персонала Системы должна определяться с учетом следующих требований: – структура Системы должна обеспечивать возможность управления всем доступным функциям как одному администратору, так и несколькими администраторами посредством распределения зон ответственности. – системное и прикладное программное обеспечение Системы должно функционировать в автономном режиме и не должно требовать круглосуточного обслуживания и управления администратором. Взаимодействие с администратором должно выполняться в рамках проведения плановых работ по созданию резервных копирований или внесений изменений в системные настройки. Численность персонала должна определяться исходя из необходимых и достаточных требований к распределению функций по выполнению штатных обязанностей персонала, а также функций администрирования. Численность внутренних пользователей, эксплуатирующих АИС УЛСП утверждается штатным расписанием Оператора АИС УЛСП. Численность персонала АИС УЛСП должна уточняться и согласовываться ежегодно, исходя из объемов выполняемой работы. Система должна быть спроектирована и реализована с учетом её эксплуатации функциональными группами пользователей: – системный администратор: доступ на уровне системного и прикладного ПО без непосредственного доступа к функциям подсистем федерального сегмента и регионального сервиса; – администратор Системы: доступа к функциям подсистем федерального сегмента и регионального сервиса через графический интерфейс; – оператор федерального сегмента: доступ к подсистемам федерального сегмента и регионального сервиса через графический интерфейс; – оператор регионального сервиса: доступ к подсистемам регионального сервиса через графический интерфейс

4.1 Требования к развитию Системы в целом В процессе работ по созданию должны сохраниться основные требования к построению архитектуры в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (то есть представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Детальные функциональные и технические требования к реализации разрабатываются Подрядчиком и согласовываются Заказчиком на подэтапе Технического проектирования. Система должна быть разработана с учетом необходимости информационного обмена с сервисами цифровой платформы мониторинга осуществления перевозок пассажиров по межрегиональным и муниципальным маршрутам, в соответствии с требованиями Перечня Поручений Президента Российской Федерации по результатам заседания Президиума Госсовета №1855ГС от 17.09.2023

4.1.1 Требования к использованию существующих сервисов Платформы ГосТех при развитии Системы В целях обеспечения совместимости программной архитектуры АИС УЛСП с операционными системами и системами управления базами данных, используемыми в составе платформы «ГосТех», в рамках подготовки Системы к миграции необходимо реализовать возможность использования следующих сервисов: – Сервис Key-value СУБД (услуга 1.3) (здесь и далее услуги ЕЦП «ГосТех» обозначены в соответствии с Методическими рекомендациями «Базовые сервисы Единой цифровой платформы Российской Федерации «ГосТех». Основные требования к составу и функциям», утвержденные протоколом Президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 05.08.2022 г. № 30); – Сервис транзакционной СУБД (услуга 1.1); – Сервис СУБД полнотекстового индекса (услуга 1.4). Должно быть обеспечено использование операционной системы, включенной в единый реестр российских программ для электронных вычислительных машин и баз данных или в единый реестр программ для электронных вычислительных машин и баз данных из государств - членов Евразийского экономического союза, за исключением Российской Федерации, имеющей сертификат безопасности ФСТЭК, совместимой с технологическим стеком платформы «Гостех»

4.2.1.3 Требования к модификации Подсистемы визуализации В рамках модификации Подсистемы Визуализации должны быть изменены пользовательские интерфейсы АИС УЛСП в части обеспечения учета и отображения сведений по новым типам пассажиров на панели управления Системы, а также вывода данных по новым типам пассажиров и льгот в разделе «Визуализация данных»

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

4.3.3 Требования к защищённым соединениям и шифрованию 1) Решение должно содержать запрет на применение протокола HTTP в явном виде 2) При подключении к решению с использование протокола HTTP должно происходить перенаправление на HTTPS 3) Решение должно содержать явный запрет на применение протокола TLS 1.1 и ниже 4) Решение должно содержать явный запрет на применение всех версий протокола SSL 5) Допустимо использовать только эллиптические кривые из списка a. X25519 b. prime256v1 c. secp521r1 d. secp384r1 6) Допустимо использовать только алгоритмы шифрования из списка a. ECDHE-ECDSA-AES128-GCM-SHA256 b. ECDHE-RSA-AES128-GCM-SHA256 c. ECDHE-ECDSA-AES256-GCM-SHA384 d. ECDHE-RSA-AES256-GCM-SHA384 e. ECDHE-ECDSA-CHACHA20-POLY1305 f. ECDHE-RSA-CHACHA20-POLY1305 g. DHE-RSA-AES128-GCM-SHA256 h. DHE-RSA-AES256-GCM-SHA384 7) Решение должно содержать явный запрет на использование алгоритмов шифрования, не входящих в пункт 6) п.п. 4.3.3 8) Решение должно содержать явный запрет на использование режима сцепления блоков шифротекста (CBC) при шифровании 9) Решение должно содержать явный запрет на использование следующих алгоритмов хеширования данных: a. MD5 b. SHA1 10) Запрещено использовать алгоритм RSA с длинной ключа менее 4096 бит

4.2.4 Требования к реализации сервиса «Маломобильные» Сервис «Маломобильные» предназначен для подтверждения принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом. Сервис должен предоставлять функциональность подтверждения группы инвалидности: – инвалид 1 группы, – инвалид 2 группы, – инвалид 3 группы, – ребенок-инвалид посредством отправки запроса, содержащего СНИЛС пассажира, полученный из информационных систем перевозчиков, в ГИС ЕЦП (требования к интеграции с ГИС ЕЦП описаны в п. 4.2.1.1.1 настоящего Технического задания). Получение сервисом «Маломобильные» номера СНИЛС для последующего подтверждения группы инвалидности должно быть предусмотрено для следующих сценариев: 1) создание заявки на сопровождение в выбранных объектах транспортной инфраструктуры железнодорожного транспорта, осуществляющих деятельность по обслуживанию пассажиров при покупке билета, посадке/высадке на поезд; 2) содействие резервированию специальных мест для инвалидов в поездах дальнего следования в дополнение к имеющимся цифровым сервисам перевозчиков; 3) заказ парковочного разрешения для инвалидов в выбранных объектах транспортной инфраструктуры железнодорожного транспорта. Порядок создания заявки, в рамках вышеуказанных сценариев предусматривает ввод соответствующих сведений в информационных системах перевозчиков, в связи с чем для Сервиса «Маломобильные» собственного интерфейса для ввода данных и функциональности валидации личности не предусматривается

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, развернутых на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов согласно п. 4.1.1: 1) сервис аудита (услуга 1.15); 2) сервис журналирования (услуга 1.14); 3) сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Для аутентификации пользователей при подготовке к миграции необходима интеграция с сервисом IAM (услуга 1.13)

В целях развития АИС УЛСП и подготовки к миграции на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, необходимо использовать следующие сервисы: 4) сервис управление развертыванием программного обеспечения (услуга 1.31); 5) сервисы интеграционного взаимодействия (услуга 1.19); 6) сервисы управления очередями сообщений (1.10). Для взаимодействия со смежными системами в среде СМЭВ в составе механизмов миграции и развертки должен быть компонент «Интеграция со СМЭВ Platform V SMEV Gateway» (услуга 1.12). При подготовке к миграции для каждой подсистемы, в зависимости от функционала, необходимо использовать соответствующую систему управления базами данных из состава базовых компонентов платформы «ГосТех» (Сервис транзакционной СУБД (услуга 1.1), Сервис СУБД аналитического хранилища данных (услуга 1.5)). Для управления очередями сообщений должен использоваться Сервис управления очередями сообщений (услуга 1.10). Требования к технологической архитектуре и перечень используемых базовых сервисов могут быть скорректированы на этапе технического проектирования по согласованию с Заказчиком, а также исходя из условий технологической готовности платформы «ГосТех»

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Требования к документации 1) Схема сетевого взаимодействия a. Должна содержать все порты, которые используются для установления сетевых соединений; b. Должна содержать указания на протокол соединения (TCP/UDP); c. Должна содержать указание о направлении трафика между компонентами системы вплоть до уровня контейнера. 2) Архитектура решения a. Требуется использование нотации С4. 3) Перечень сервисных учётных записей, который содержит: a. Имя учётной записи; b. Компонент решения, где она применяется; c. Систему, к которой она подключается; d. Перечень привилегий, предоставленных данной учётной записи, в формате той системы, к которой данная учётная запись подключается. 4) Руководство по резервному копированию a. Руководство по резервному копированию должно содержать пошаговую инструкцию, которая позволит создать резервную копию всей системы (каждого компонента системы, который подлежит резервному копированию); b. В случае, если какой-то компонент системы не подлежит резервному копированию, в данном руководстве необходимо предоставить основания, почему резервирование компонента не требуется; c. Отдельно в руководстве должны содержаться рекомендации по резервному копированию баз данных решения, а именно: i. Частота создания полной резервной копии; ii. Частота создания инкрементальной резервной копии; iii. Длительность хранения созданных резервных копий

Для организации информационного обмена данными по маломобильным категориям граждан между АИС УЛСП и информационными системами перевозчиков и организаций железнодорожного транспорта, должна быть предусмотрена возможность реализации интеграционного взаимодействия посредством REST API. В сервисе должны быть предусмотрены возможности развития его функционала, в частности перспективное расширение на все виды транспорта, а также отработка сценариев подтверждения сведений об управлении транспортным средством инвалидом или перевозке транспортным средством инвалида, посредством запроса в ГИС ЕЦП по государственному номеру транспортного средства при создании заявки на реализацию права на бесплатное использование мест для парковки транспортных средств, в случае реализации смежными системами такой функциональности. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

4.3.4 Требования к использованию и работе с сертификатами Все алгоритмы проверки, требования, наименование полей и иные технические термины применяются здесь и далее в соответствии со следующими стандартами: 1) RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» 2) RFC 8399 «Internationalization Updates to RFC 5280» 3) RFC 6818 «Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» Список применяемых терминов: Термин в документе Термин по RFC Самозаверенный сертификат Self-signed certificate Самоподписанный сертификат Self-signed certificate Отзыв Revocation Центр сертификации Certification Authority Субъект сертификата Subject Альтернативное имя субъекта сертификата Subject Alternative Name Период действия Validity 1) При подключении по защищённому каналу решение должно проверять предоставляемый сертификат на доверие, отзыв и соответствие его параметров дополнительным требованиям 2) В случае, если сертификат признан недоверенным, подключение не может быть установлено a. В случае, если сертификат перестал быть доверенным в момент, когда подключение уже было установлено, подключение должно быть прервано 3) Сертификат, предъявляемый при установлении соединения не может быть самоподписанным a. В противном случае выдать ошибку следующего содержания «End entity certificate is self-signed» и не устанавливать/разорвать защищённое соединение 4) Проверка сертификата должна происходить не реже, чем раз в час, даже если подключение установлено

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

- форма обучения (очная, очно-заочная, заочная, получение образования в семье, самообразование, экстернат). В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений. Со стороны API АИС УЛСП должен быть модифицирован метод /v3/SELECT, в части: - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры»; - поддержка нового типа пассажира «гражданин, обучающийся в образовательных организациях высшего образования и научных организациях по программам среднего профессионального образования, бакалавриата, специалитета, магистратуры на территории Калининградской области», включая согласование с ПСП их наименований в блоке «types» при информационном обмене; - обработка новых негативных сценариев для новых типов пассажира (включая отправку ответов): o «Пассажир отсутствует в системе-источнике данных»; o «Пассажир не является студентом ВУЗа на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе на территории Калининградской области» (для типа пассажира «Студент КГД»); o «В системе-источнике данных отсутствуют сведения об обучении пассажира в ВУЗе» (для типа пассажира «Студент»). Также для нового типа пассажира «Студент» должен быть реализован информационный обмен с системами-потребителями организаций железнодорожного транспорта, согласно п. 4.2.1.1.4 настоящего Технического задания

4.2.1.1.4 Требования к обеспечению обмена данными с информационными системами организаций железнодорожного транспорта Обмен данными с информационными системами организаций железнодорожного транспорта должен осуществляться посредством REST API, а также файлового обмена с использованием протокола SFTP, с целью обеспечения передачи информации о наличии у пассажира права на проезд по льготному, сниженному или безденежному тарифу на железнодорожном транспорте пригородного сообщения и дальнего следования, а также наличия у него прав на специальное обслуживание (сопровождение инвалидов и маломобильных) и приобретения билетов на специальные места для инвалидов в поездах дальнего следования. Подсистема информационного обмена АИС УЛСП должна обеспечивать возможность взаимодействия с витринами продаж электронных билетов организаций железнодорожного транспорта, а также с интеграционными платформами ОАО «РЖД», его дочерних компаний и взаимозависимых лиц, предоставляющих гражданам возможность оформления электронных билетов на следующие виды транспорта: – Поезда дальнего следование; – Поезда пригородного сообщения; – Межрегиональные автобусы; – Авиасообщение; – Водный пассажирский транспорт; – Мультимодальные маршруты, а также заказ туристических услуг и оформления поездок, в том числе льготных, на основании данных геолокации при бесконтактной оплате проезда в пригородном железнодорожном сообщении. Способ информационного взаимодействия, а также перечень получаемых и передаваемых данных должен быть уточнен на этапе технического проектирования

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

4.1.4 Требования к режимам функционирования Функционирование Системы должно осуществляться в круглосуточном непрерывном режиме 365 (366) дней в году, степень доступности 97%. Система должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все подсистемы корректно и полностью выполняют свои функции. Перерывов в работе как Системы в целом, так и одной, либо нескольких подсистем не предусмотрено. В данном режиме АИС УЛСП обеспечивает возможность выполнения всех функций в соответствии с настоящим техническим заданием с уровнем отказоустойчивости 97%. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Системы, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Системы с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию Системы и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Системы

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

При подготовке к миграции Платформа «ГосТех» должна обеспечить уровень сохранности информации, позволяющий восстановить данные с минимальной потерей информации: 1) в случае отказа на уровне компонентов Платформы «ГосТех» – без потери информации; 2) в иных случаях отказа – восстановление данных за период не более 24 часов для PROD-стендов и не более 48 часов для остальных стендов (DEV-, TEST-, HT-, ПСИ- стендов) до возникновения аварии (из последней резервной копии). Для обеспечения сохранности информации Системы должны быть реализованы следующие функции (при подготовке к миграции - посредством Платформы «ГосТех»): 1) резервное копирование баз данных, программных и загружаемых файлов; 2) восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключении электрического питания, сбоях операционной системы и других) вычислительно-операционной среды функционирования; 3) восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения. Технические средства слоя виртуализации должны поддерживать механизмы архивирования данных без прерывания работы. Резервное копирование осуществляется не реже одного раз в день. Ответственность за резервное копирование и восстановление информации определяется в соответствии с регламентом по эксплуатации

4.1.14 Требования к патентной чистоте и патентоспособности 4.1.14.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.14.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободным от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.14.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком

4.1.14.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.14.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам

Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АИС УЛСП должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АИС УЛСП. Интерфейс АИС УЛСП должен обеспечивать возможность масштабирования под любую ширину экрана и отображение на мобильных устройствах. Указанное действие должно происходить за счёт изменения ширины колонок сайта, их переноса вниз предыдущей колонки или отключения второстепенных элементов сайта для малых разрешений экранов (адаптивная верстка). Визуальное представление элементов пользовательского интерфейса разрабатываемой АИС УЛСП, адаптивная верстка интерфейса Системы, состав отображаемой информации подлежит согласованию Заказчиком в процессе выполнения работ по созданию Системы

5) Система должна проводить проверку имени субъекта сертификата и проверку альтернативного имени субъекта сертификата a. Имя, к которому осуществляется подключение, должно совпадать с субъектом сертификата b. Имя, к которому осуществляется подключение, должно совпадать с альтернативным именем субъекта сертификата c. В случае, если имя, к которому осуществляется подключение, совпадает с альтернативным именем субъекта сертификата, но не совпадает с субъектом сертификата, считать проверку успешной d. В любом другом случае выдать ошибку следующего содержания «Subject name or SAN does not match the connection» и не устанавливать/разорвать защищённое соединение 6) Система должна проверять, что период действия сертификата уже начался и ещё не истёк a. Значение в секции notBefore должно быть меньше, чем текущая дата b. Значение в секции notAfter должно быть больше, чем текущая дата c. В противном случае выдать ошибку следующего содержания «Certificate expired or not yet valid» и не устанавливать/разорвать защищённое соединение 7) Система должна проверять цепочку доверия вплоть до корневого сертификата a. Предоставленный при подключении исходный сертификат (Сертификат А) должен содержать поле «Authority Information Access» i. В противном случае выдать ошибку следующего содержания «No AIA field available» и не устанавливать/разорвать защищённое соединение b. Сертификат, представленный в данном поле (Сертификат Б), должен быть тем сертификатом, который подписал Сертификат А i. В противном случае выдать ошибку следующего содержания «Certificate signed not by CA in AIA» и не устанавливать/разорвать защищённое соединение c. Если сертификат Б является самоподписанным, то проверить, что сертификат находится в списке доверия i. В противном случае выдать ошибку следующего содержания «Root CA is not trusted» и не устанавливать/разорвать защищённое соединение d. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а

В целях подготовки к миграции и автоматизации технологических аспектов жизненного цикла приложений, разработанных на платформе «Гостех» (непрерывное внедрение изменений без приостановки обслуживания, защита от сбоев вследствие влияния человеческого фактора; мониторинг состояния системы, локализация корневых причин проблем и инцидентов; корректная работа и целостность данных при отказе инфраструктурных элементов, отказе интеграций, аномальных всплесках нагрузки; линейное масштабирование приложений; изоляция разных потребителей по взаимовлиянию; централизованное управление поведением приложений; набор инструментов, автоматизирующих штатные операции разработчиков приложений на платформе) необходимо использование следующих сервисов: – сервис аудита (услуга 1.15); – сервис журналирования (услуга 1.14); – сервис мониторинга (услуга 1.16). Указанные сервисы мониторинга должны быть использованы в качестве готового решения для сбора метрик с приложений. Также необходимо осуществить интеграцию подсистемы аутентификации АИС УЛСП, обеспечивающей процесс входа со своими учетными данными и доступ к различным подсистемам, используя один идентификатор, с сервисом IAM (услуга 1.13) включающий в себя компонент «IAM Proxy», представляющий собой реверсивный прокси на основе nginx с поддержкой аутентификации и авторизации через IAM; компонент «Авторизация IAM», позволяющий создать ролевую модель и проводить динамический расчет полномочий пользователя; плагин для аутентификации пользователя через ЕСИА. В целях развития АИС УЛСП на основе технологий виртуализации и микросервисной архитектуры, используемых в составе платформы «ГосТех», работающей в среде контейнеризации, при подготовке к миграции необходимо использовать следующие сервисы: – сервис управления развертыванием программного обеспечения (услуга 1.31); – сервисы интеграционного взаимодействия (услуга 1.19); – сервисы управления очередями сообщений (1.10)

Таким образом, при развитии Системы в части подготовки к миграции на ЕЦП «ГосТех» необходимо использовать следующие базовые сервисы платформы «ГосТех» (таблица 1): Таблица 1 № п/п Наименование необходимого Сервиса ID Сервиса Наименование и версия ПО 1 Сервис IAM 1.13 KeyClock версия 4.8 и выше 2 Сервис Key-value СУБД (in-memory) 1.3 Apache Ignite 2.12.0 3 Сервис аудита (услуга 1.15) 1.15 Инструменты аудита Platform V Audit 4 Сервис журналирования (услуга 1.14) 1.14 OpenSearch 2.5.0 Logstash 7.17.5 5 Сервис мониторинга (услуга 1.16) 1.16 Victoria Metrics 1.83.1 Grafana 7.4.16 6 Сервис транзакционной СУБД (услуга 1.1) 1.1 PostgreSQLPro / Pangolin 5 7 Сервис управление развертыванием ПО (услуга 1.31) 1.31 Jenkins 2.319.3 8 Сервисы управления очередями сообщений (услуга 1.10) 1.10 Apache Kafka 2.7.2 9 Сервис СУБД полнотекстового индекса (услуга 1.4) 1.4 OpenSearch 2.5.0 10 Сервис управления микросервисами (услуга 1.11) 1.11 Перечень используемых базовых сервисов может быть уточнен или дополнен в случае расширения перечня базовых сервисов платформы «ГосТех» на этапе технического проектирования

4.2.5 Требования к реализации сервиса льготных перевозок по электронным транспортным требованиям Под электронным транспортным требованием должен подразумеваться электронный документ, наличие которого является основанием для пассажира на получение проездного документа, а для перевозчика – на компенсацию за перевозку. Сервис льготных перевозок по электронным транспортным требованиям должен быть предназначен для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании. Сервис должен предоставлять следующую функциональность: – Получение идентификатора ЭТТ из подключаемой внешней информационной системы; – формирование и передача запроса на цифровую проверку; – проведение проверки и формирование результата; – предоставление (отказ в предоставлении) услуги по продаже билета на железнодорожный транспорт пригородного и дальнего сообщения по ЭТТ. Сервис должен поддерживать следующий порядок информационного обмена: 1) оформление ЭТТ во внешней информационной системе организации, включающее в себя: a. создание заявки с заполнением сведений: i. личные данные пассажира; ii. данные поездки; iii. данные о перевозимых членах семьи; iv. цель; v. дата выдачи; vi. тип требования. b. согласование заявки и формирование ЭТТ; c. сохранение данных ЭТТ во внешней информационной системе организации; d. генерацию уникального идентификатора ЭТТ, позволяющего однозначно определить запись в системе; e. передачу пользователю идентификатора ЭТТ

2) передачу уникального идентификатора ЭТТ из внешней информационной системы в АИС УЛСП с последующим сохранением идентификатора в архиве Сервиса перевозок по ЭТТ; 3) ввод пассажиром на официальном ресурсе организации железнодорожного транспорта параметров поездки с указанием наличия права на льготу; 4) ввод пассажиром уникального кода ЭТТ на веб-странице авторизации АИС УЛСП, куда он был переадресован с официального ресурса организации железнодорожного транспорта; 5) сопоставление в АИС УЛСП уникального идентификатора ЭТТ, полученных из внешней информационной системы на шаге 2 с уникальным идентификаторам ЭТТ, полученным от пассажира и информационной системы организации железнодорожного транспорта на шаге 4; 6) передача результирующих сведений в информационную систему перевозчика для оформления билета / отказа в оформлении билета. Для обеспечения вышеуказанного взаимодействия АИС УЛСП должна быть интегрирована с ИС, хранящей данные по ЭТТ и с системами интернет-продаж перевозчиков. Все операции, совершенные с ЭТТ, должны протоколироваться в АИС УЛСП. Взаимодействие АИС УЛСП с информационными системами организаций и предприятий, осуществляющих оформление ЭТТ, должно происходить по каналам связи, защищенным с использованием шифровальных (криптографических) средств, сертифицированных ФСБ России. В случае отсутствия технологической и/или нормативной готовности к обмену данными на стороне смежных систем по согласованию с Заказчиком компоненты сервиса могут быть реализованы с использованием тестовых данных и тестовых окружений

5) Предоставить отдельный документ по каждой базе данных, входящей в состав решения, который содержит: a. Проектный объём базы данных на один год и предполагаемый объём роста баз данных на два года вперёд; b. Список из 10-и самых больших таблиц; c. Полученные в результате проведения нагрузочного тестирования данные по: i. Нагрузке на процессор; ii. Потреблению оперативной памяти; iii. Среднему количеству одновременно работающих пользователей; iv. Объёму упреждающей журнализации (write-ahead log; WAL); v. Указание самых нагруженных интервалов времени со следующим описанием: ? Время возникновения; ? Время окончания; ? Характер нагрузки. d. Перечень серверов и/или микросервисов, которые осуществляют подключение к базе данных; e. Перечень регламентных заданий, запускающихся для обслуживания БД, либо для обработки данных i. Дополнительно предоставить описание регламентного задания в формате: § Время запуска; § Проектное время работы; § Характер выполняемых действий; § Назначение данного задания. f. Перечень ролей и схем, участвующих в работе приложения, с пояснением о функциональном назначении каждой из них; g. Перечень ролей и схем, которые не задействованы в работе с пояснением о функциональном назначении каждой из них; h. Описание периодических заданий, выполняющихся со стороны приложения, в формате: i. На каком компоненте решения выполняется данное задание (сервер/микросервис); ii. Время начала; iii. Проектное время работы; iv. Характер выполняемых действий; v. Назначение данного задания. i. Описание структуры базы данных

6) Предоставить настройки обратного прокси сервера (reverse proxy), требуемые для публикации веб приложения 7) Инструкция по установке должна содержать: a. Пошаговую инструкцию с исчерпывающим перечнем команд для установки всех компонентов системы; b. Исчерпывающий перечень команд для первичной настройки системы; c. Следующий дополнительный объём информации i. Перечень пакетов, необходимых для работы решения, с указанием их версий; ii. Перечень контейнеров, необходимых для работы решения, с указанием их тэгов и источника; iii. Код всех скриптов, необходимых для работы решения, вынесенных в отдельное приложение; iv. Перечень всех библиотек, и прочих артефактов, необходимых для работы решения, с указанием их версий и источника. 8) Руководство по устранению частых проблем 9) Руководство по мониторингу, которое содержит: a. Описание метрик, требуемых для оценки работоспособности и текущего состояния приложения, с описанием для каждой метрики и способа их сбора; b. Описание метрик бизнес-функций (функциональных требований) приложения с описанием для каждой метрики и способа их сбора. 10) Руководство по восстановлению, которое содержит: a. План восстановления отдельных компонентов системы; i. Данные планы исходят из предположения, что из строя вышел один из компонентов системы, а все остальные компоненты продолжают функционировать b. План восстановления всей системы в целом; i. Данный план составляется из предположения, что утеряна вся система, за исключением резервных копий, собранных согласно Руководству по резервному копированию c. Каждый из планов должен иметь: i. Время восстановления; ii. Пошаговый порядок восстановления и действий для возобновления работы системы и/или ее компонентов

11) Руководство по чтению журналов (логов) приложения, которое содержит: a. Описание формата журналов; b. Классификатор событий; c. Детальное описание событий. 12) Руководство по сборке приложения из исходного кода a. Должны быть предоставлена инструкция по сборке из исходного кода каждого компонента решения (контейнера, исполняемого файла, пакета, и т.д.); b. Сборка должна производиться без использования информационно-телекоммуникационной сети «Интернет»

8) Система должна проверять сертификат на отзыв с использованием CRL или OCSP a. Предоставленный при подключении исходный сертификат (Сертификат А) НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Сертификат, взятый из поля «Authority Information Access» (Сертификат Б), НЕ должен быть отозван i. В противном случае выдать ошибку следующего содержания «Certificate ID revoked» (заменить ID на значение из поля Serial Number) и не устанавливать/разорвать защищённое соединение a. Если сертификат Б является самоподписанным, то проверка отзыва не проводится и цикл завершается b. Если Сертификат Б не является самоподписанным, то принять Сертификат Б за сертификат А и вернуться к пункту а. 9) Система должна проверять, что значения в поле «Extended Key Usage» присутствуют в списке разрешённых EKU для конкретного подключения a. В противном случае выдать ошибку следующего содержания «Certificate’s EKU does not match approved ones» и не устанавливать/разорвать защищённое соединение 10) Система должна проверять поле «Basic Constraints» a. В случае, если поле отсутствует, выдать ошибку следующего содержания «Basic Constraints filed is empty» и не устанавливать/разорвать защищённое соединение b. В случае, если сертификат, предоставленный при подключении содержит значение TRUE в секции «CA», выдать ошибку следующего содержания «End entity certificate is CA certificate» и не устанавливать/разорвать защищённое соединение c. При проведении проверки согласно п.п. 7) пункта 4.3.4 проверять поле Basic Constraints согласно требованиям RFC 5280 (секция 4.2.1.9. Basic Constraints)

4.2 Функциональные требования к развитию АИС УЛСП 4.2.1 Требования к модификации существующих подсистем АИС УЛСП в рамках обеспечения поддержки новых типов мер социальной поддержки (защиты) пассажиров В связи с изменением нормативно-правовой базы, а также вводом в действие новых информационных систем федеральных органов исполнительной власти, участвующих в информационном обмене с АИС УЛСП, необходимо провести модификацию и доработку Системы с целью обеспечения цифрового подтверждения права на проезд по льготному, сниженному, специальному или безденежному тарифу для новых категорий пассажиров на разных видах транспорта, а также доработать подсистему информационного обмена АИС УЛСП с целью обеспечить устойчивый обмен данными с новыми системами-источниками и системами-потребителями. Модификация системы производится на мощностях Заказчика, разработанная Система запускается в опытную эксплуатацию в рамках продуктивного контура ФГБУ «СИЦ Минтранса России». 4.2.1.1 Требования к модификации Подсистемы информационного обмена Подсистема информационного обмена АИС УЛСП обеспечивает взаимодействие с системами-источниками и системами-потребителями, в частности с информационными системами Федеральной Налоговой службы России (ИС ФНС) и Социального Фонда России (ИС СФР), Министерства труда и социальной защиты Российской Федерации с целью проверки данных пассажира, получения данных о месте жительства и действующих льготных категориях гражданина

4.1.5 Показатели назначения Ключевым показателем назначения Системы является выполнение действующих, а также функциональных требований, перечисленных в разделе 4.2 настоящего документа. Архитектура Системы должна предусматривать возможность увеличения допустимой нагрузки посредством горизонтального масштабирования без кардинального изменения программного кода. Примечание: изменения программного кода допускаются при внедрении новых функциональных возможностей, изменении состава подсистем, а также выполнении оптимизации производительности существующих технических решений. Система должна обеспечивать возможность одновременного доступа пользователей в соответствии с Таблицей 3 – Показатели производительности, при условии использования разных учётных записей. Под одновременной работой подразумевается возможность одновременного использования полного набора функций. Система должна обладать свойствами масштабируемости по отношению к изменениям, не связанным с коренным изменением автоматизируемых процессов, в том числе на основании нормативных документов, регулирующих деятельность Системы. Показатели назначения в части использования инфраструктурных технологических сервисов, базовых сервисов и типовых решений платформы «ГосТех»: ? использование не менее 10 базовых сервисов в составе Системы; ? обеспечение совместимости уровня «Compatible» мигрируемых подсистем Системы с платформой «ГосТех»

Иные показатели назначения представлены в таблицах 2, 3 и 4 ниже. Таблица 2 – Показатели назначения № Параметр Значение 1 Количество профилей пассажиров не менее 1 млн. человек 2 Система должна обеспечивать сохранение производительности при ежемесячном приросте данных в хранилище не менее 350 Mб 3 Период хранения данных не менее 3 лет Таблица 3 – Показатели производительности № Показатель Штатный режим Пиковый режим 1 Количество одновременно работающих зарегистрированных пользователей в Административной панели 20 100 2 Количество одновременно подключенных смежных систем 30 100 Таблица 4 – Целевое время отклика № Показатель Средняя величина не более, с Максимальная величина не более, с Время отклика на запрос в API 1 при получении данных от одного источника 0,2 1 2 при обновлении данных от одного источника 0,2 1 Время отклика на запрос в Административной панели 3 при выполнении операций поиска информации 3 10 4 при выполнении других функций 1 15 Показатели времени отклика на запрос в API АИС УЛСП не учитывает задержку формирования ответа на запрос на стороне системы источника. Показатели назначения АИС УЛСП могут быть уточнены на этапе технического проектирования

4.1.6 Требования к надежности функционирования и доступности для пользователей Показатели надежности Системы должны определяться характеристиками технических и программных средств, обеспечивающих надежность функционирования Системы. Система должна сохранять работоспособность и обеспечивать автоматическое восстановление своих функций при возникновении внештатных ситуаций. В целях обеспечения надежности и сохранности информации при подготовке к миграции должны использоваться сервисы и средства платформы «ГосТех». Должно быть предусмотрено резервное копирование (в т.ч. средствами Платформы «ГосТех» при осуществлении миграции) как по команде администратора, так и по заранее составленному расписанию, что должно определяться соглашением, заключенным между Оператором АИС УЛСП и Оператором платформы «ГосТех»

4.2.1.1.1 Требования к обеспечению обмена данным с ГИС ЕЦП Текущее взаимодействие АИС УЛСП в части проверки данных пассажира и получения информации о наличии у него действующих льготных категорий производится с ИС СФР по ВС «О соответствии фамильно-именной группы, даты рождения, пола и СНИЛС», а также по ВС «Сведения об инвалиде, получаемые из ФГИС ФРИ, для оказания транспортных услуг» посредством СМЭВ-3 по приведенным в Таблице 5 параметрам запроса. Таблица 5 – Параметры запроса Параметр Описание FamilyName Фамилия пассажира FirstName Имя пассажира Patronymic Отчество пассажира Snils СНИЛС пассажира Gender Пол пассажира BirthDate Дата рождения пассажира DisabilityGroup Группа инвалидности инвалида/ребенка-инвалида Moving Степень способности к самостоятельному передвижению AvailabilityWheelChair Наличие рекомендаций в обеспечении креслом-коляской В связи с вступлением в силу Федерального закона от 10.07.2023 г. № 293-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных законодательных актов (положений законодательных актов) Российской Федерации» вдобавок к ранее созданным механизмам информационного обмена необходимо провести модификацию Подсистемы информационного обмена АИС УЛСП с целью обеспечения обмена данными с создаваемой в рамках указанного Федерального закона ГИС «Единая цифровая платформа в социальной сфере» (ГИС ЕЦП)

4.3.5 Требования к контейнерам в платформе контейнеризации на базе Kubernetes 1) Контейнер не должен запускаться от пользователя с идентификатором (id) меньше 1025 2) Прямое указание id пользователя, от которого производится запуск контейнера, запрещено 3) Любой pod должен находиться под контролем родительской сущности (deployment, deploymentConfig, DaemonSet и т.д.) 4) Каждый контейнер должен содержать следующие конфигурационные параметры a. securityContext.readOnlyRootFilesystem: true b. securityContext.runAsNonRoot: true 5) Каждый контейнер должен писать логи в stdout a. Допускается запись логов в формате «plain text» при условии отсутствия многострочных логов (один лог состоит из более чем одной строки) b. Допускается запись логов в формате json c. Запрещается совмещение формата записи логов в рамках одного контейнера 6) Каждый pod должен быть снабжён network policy, которое разрешает только необходимые соединения (network policy должна совпадать с архитектурой решения и схемой сетевого взаимодействия) и запрещает все остальные 7) Файлы конфигураций, которые могут быть изменены, должны предоставляться в контейнер с помощью configMap 8) Пароли, секреты и иные идентификационные данные должны предоставляться в контейнер с помощью Secret 9) Требуется передать манифест, все артефакты и базовый образ для сборки каждого контейнера 10) Каждый контейнер должен содержать в себе liveliness и readiness probes a. Контейнер выдавать ошибку и останавливать свою работу в случае провала liveliness и/или readiness probes 11) В контейнере не может запускаться более одного процесса 12) Запрещается использование неуникальных тегов для контейнеров (пример: latest, preprod и т.д.)

4.2.6 Требования к реализации сервиса льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы должен обеспечивать подтверждение прав на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры. Подтверждение личности (авторизация) студентов должна включать сведения, позволяющие однозначно идентифицировать гражданина: 1) фамилия, имя, отчество (при наличии) обучающегося; 2) пол обучающегося; 3) дата рождения обучающегося; 4) СНИЛС обучающегося; 5) серия, номер, дата выдачи документа, удостоверяющего личность гражданина Российской Федерации обучающегося. В качестве основного идентификатора должен использоваться СНИЛС

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

4.2.7 Требования к реализации сервиса учета данных Виртуальных социальных карт В целях реализации Постановления Правительства РФ от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами» в рамках АИС УЛСП необходимо разработать Сервис учета Виртуальных социальных карт для обеспечения обмена данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт. Под виртуальными социальными картами подразумеваются уникальные обезличенные идентификаторы, формируемые с применением национальных платежных инструментов, указанных в части 2 статьи 30 Федерального закона «О национальной платежной системе» (далее – национальные платежные инструменты), при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами

4.2.1.2 Требования к модификации Подсистемы хранения и обработки информации С целью обработки и хранения полученных от систем-источников новых типов сведений должна быть выполнена модификации внутримашинной информационной базы в части подтверждения личности и типа пассажира, включая следующие таблицы: – PassengersRequests – таблица данных запроса от ПСП по пассажиру; – Passengers – таблица данных пассажира; – IdentityConfirmations – таблица данных результатов подтверждения личности пассажиров; – PassengerTypeConfirmations – таблица данных результатов подтверждения типов пассажиров; – Document – таблица данных документов удостоверяющих личность пассажиров. Дополнительно со стороны внутренней логики подтверждения личности и типа пассажира должна быть выполнена модификация в части: 1) обеспечения подтверждения типа пассажира «житель КГД» по следующим маркерам: - личность подтверждена во ФГИС ЕРН; - запрошенный во ФГИС ЕРН код региона постоянной регистрации пассажира совпадает с кодом региона Калининградской области. Возрастные ограничения на новые типы пассажира не должны применяться; 2) обеспечения подтверждения типа пассажира «студент КГД» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования, сведения подтверждают обучение пассажира в ВУЗе, расположенном на территории Калининградской области; - на пассажира с типом «Студент КГД» не должно накладываться требование о наличии постоянной регистрации в субъекте РФ «Калининградская область». 3) обеспечения подтверждения типа пассажира «Студент» по следующим маркерам: - полученные из информационных систем, обеспечивающими учет обучающихся на различных ступенях образования сведения подтверждают обучение пассажира в ВУЗе, имеющем государственную аккредитацию на территории РФ на очной форме обучения. - на пассажира с типом «Студент» должно накладываться требование о наличии постоянной регистрации на территории РФ

4.2.2 Требования к реализации сервиса сбора, обработки и хранения данных о региональных тарифах и льготах Сервис сбора, обработки и хранения данных о региональных тарифах и льготах должен представлять собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан пилотных регионов, которое должно обеспечивать выполнение следующих функций: 1) предоставления региональным органам исполнительной власти, являющихся держателями реестров льготных категорий граждан, а также отвечающих за организацию транспортного обслуживания населения, программного интерфейса для консолидации данных по категориям получателей транспортных льгот; 2) унификации различных форматов данных о льготных категориях граждан и льготах в соответствии с реестрами и региональными нормативными правовыми актами для обеспечения единой таксономии региональных льгот; 3) отображения информации по видам, типам, форматам предоставления мер социальной поддержки (защиты) на разных видах транспорта и типах сообщения; 4) отображения информации о государственных информационных системах, обрабатывающих данных по мерам социальной защиты (поддержки) на транспорте, а также информационных системах перевозчиков разных видов транспорта, задействованных в процессах информационного обмена с целью перехода к безбумажному оформлению льготного проезда;

4.3.6 Требования к тестированию решения 1) Подрядчик должен передать заказчику unit-тесты вместе с исходным кодом a. Покрытие кода unit-тестами должно быть не менее 95% 2) Подрядчик должен провести нагрузочное тестирование своими силами и продемонстрировать Заказчику не только результат, но и сам процесс тестирования a. Если не указано иное, то нагрузочное тестирование проводится со следующими допущениями i. Одновременная работа 10 администраторов в интерфейсе администраторов ii. Одновременная работа 1 000 пользователей в интерфейсе пользователей iii. Одновременное чтение и запись данных пользователями iv. Под данными подразумеваются записи в системе, которые пользователи могут получать и редактировать. В случае наличия нескольких типов таковых записей, необходимо провести нагрузочное тестирование на каждый такой тип 3) Исполнитель должен предоставить тестовые данные для проведения функционального тестирования a. Тестовые данные не могу совпадать с данными, которые будут в системе при вводе её в эксплуатацию

Подсистема информационного обмена АИС УЛСП должна быть доработана с целью обеспечения межведомственного информационного взаимодействия с ГИС ЕЦП СФР посредством СМЭВ 4 с целью подключения к витринам Национальной системы управления данными и обеспечения информационного обмена по следующему перечню сведений: - Код категории получателя меры социальной защиты (поддержки); - Гражданство; - Сведения об отнесении граждан к категориям граждан, имеющим право на получение мер социальной защиты (поддержки): o Сведения о детях-сиротах и детях, оставшихся без попечения родителей, лицах из числа детей-сирот и детей, оставшихся без попечения родителей, лицах, потерявших в период обучения обоих родителей или единственного родителя: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о гражданах, пострадавших в результате радиационных или техногенных катастроф: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о многодетных семьях, признанных таковыми в соответствии с законодательством субъекта Российской Федерации: § Сведения о категории (наименование, дата начала действия и дата фактического окончания). o Сведения о ветеранах Великой Отечественной войны, инвалидах Великой Отечественной войны, членах семей погибших (умерших) инвалидов Великой Отечественной войны, участников Великой Отечественной войны § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно). o Сведения о бывших несовершеннолетних узниках концлагерей, гетто, других мест принудительного содержания, созданных фашистами и их союзниками в период Второй мировой войны: § Сведения о категории (наименование, дата начала действия и дата окончания (бессрочно)

- Сведения о медико-социальной экспертизе и установлении инвалидности и о лице, признанном инвалидом: o группа инвалидности; o причина инвалидности; o срок, на который установлена инвалидность; o дата установления инвалидности; o сведения о транспортном средстве, управляемом инвалидом, или транспортном средстве, перевозящем инвалида и (или) ребенка-инвалида, в том числе государственный регистрационный номер транспортного средства, марка и (или) модель (коммерческое наименование) транспортного средства (если они были присвоены изготовителем транспортного средства), дата и время размещения (изменения) сведений о транспортном средстве, дата подачи заявления о размещении сведений о транспортном средстве, дата и время начала фактической эксплуатации транспортного средства, дата и время окончания фактической эксплуатации транспортного средства. - Параметром для формирования запроса к витрине ГИС ЕЦП должен быть СНИЛС

3 СВЕДЕНИЯ ОБ ОБЪЕКТАХ АВТОМАТИЗАЦИИ - 3.1 Описание объектов автоматизации АИС УЛСП разработана по Государственному контракту № 11422211 от 11.10.2022 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770236142722000070). В 2023 году выполнено развитие Автоматизированной информационной системы управления льготными и субсидированными перевозками в части реализации автоматизированного цифрового подтверждения прав пассажиров на покупку авиабилета по специальному тарифу по Контракту ОК/23_03 от 03.07.2023 (реестровый номер контракта в Реестре контрактов Единой информационной системы в сфере закупок – 1770411620523000022). АИС УЛСП обеспечивает возможность централизованного получения информации о доступных гражданину мерах социальной поддержки в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках с целью достижения задач Транспортной стратегии, утвержденной Распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р в части развития сервисных моделей в формате «мобильность как услуга» для цифровизации приобретения льготных билетов на всей территории Российской Федерации соответствующими категориями граждан, а также служит достижению целей Стратегического направления Цифровой трансформации транспортной отрасли Российской Федерации, утвержденного Распоряжением Правительства Российской Федерации от 21.12.2021 № 3744-р. в части создания «единого сервиса предоставления льгот и субсидий» - - Значение характеристики не может изменяться участником закупки

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

Перечень функциональных подсистем федерального сегмента: Функция Основное назначение «Хранилище данных» Хранение информации, содержащейся в федеральном сегменте АИС УЛСП, включая таксономию льгот - иерархическое отображение структуры общегосударственных транспортных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров. «Администрирование» Управление учётными записями пользователей федерального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи (ролевая модель). Управление таксономией льгот, включая блок нормативно-справочной информации по общегосударственным льготам, предоставляемым на межрегиональном и внутрирегиональном сообщении. «Визуализация данных» Визуализация агрегированных данных по льготам федерального и регионального уровня в разрезе типа льготы, вида транспорта, формата предоставления и размера льготы. «Информационный обмен» Получение запросов и передача данных в региональный сегмент. В рамках информационного обмена федеральный сегмент получает от регионального сегмента запрос данных по федеральным транспортным льготам, положенным пассажиру. Федеральный сегмент передает данные, хранящиеся в его таксономии и полученные из внешних источников, в установленном формате (код льготы, вид льготы, краткое наименование льготы, срок действия льготы и пр.)

Перечень функциональных подсистем регионального сегмента: Функция Основное назначение «Реестр получателей услуг» Ведение получателей услуг льготных и субсидированных пассажирских перевозок, зарегистрированных в Системе «Фиксация факта оказания услуг пассажирских перевозок» Обработка и хранение информации об услугах льготной либо субсидированной перевозки пассажиров, оказанных на территории региона внедрения получателям льгот, зарегистрированным в Системе. «Хранилище данных» Хранение информации, содержащейся в региональном сегменте АИС УЛСП, включая информацию о льготах - иерархическое отображение структуры общегосударственных льгот на основании следующих наборов параметров: тип льготы, вид транспорта, соотношение кодов категории получателя льготы с кодами мер социальной защиты, таблица сопоставления кодов льгот по разным видам транспорта и уровням реестров «Администрирование» Управление учётными записями пользователей регионального сегмента АИС УЛСП, управление правами указанных учётных записей, в том числе в части ограничения информации, доступной той или иной учётной записи. Управление составом и содержанием справочников и классификаторов. «Статистика» Обработка, формирование и представление отчетности об услугах пассажирских перевозок «Типовой портал» Организация доступа к информации о возможностях Системы, порядке привязки платёжных средств. Организация доступа к индивидуальному пространству «Личный кабинет» получателя льгот

На текущий момент в рамках создания и развития Федерального сегмента АИС УЛСП выполнена автоматизация/цифровизация следующих процессов: – сбор сведений о мерах социальной поддержки (защиты), действующих на федеральном (общегосударственном) уровне; – информационное взаимодействие с общегосударственными информационными системами, содержащими сведения о гражданах, получающих меры социальной поддержки и государственной социальной помощи, а также об указанных мерах, доступных тому или иному гражданину; – подтверждение наличия у гражданина РФ права на приобретение авиабилетов по специальным тарифам согласно имеющимся мерам социальной поддержки (защиты) федерального уровня, а также признакам принадлежности к квотируемым категориям, указанным в Постановлении Правительства РФ от 02.03.2018 № 215 «Об утверждении Правил предоставления субсидий из федерального бюджета организациям воздушного транспорта в целях обеспечения доступности воздушных перевозок населению и о признании утратившими силу некоторых актов Правительства Российской Федерации» (с изменениями и дополнениями); АИС УЛСП соответствует Требованиям о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены приказом ФСТЭК России от 11.02.2013 № 17), предъявляемым к информационным системам класса защищенности «К2» и Составу и содержанию организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных 2-го уровня защищенности (утверждены приказом ФСТЭК России от 18.02.2013 № 21). Текущая архитектура АИС УЛСП приведена на рисунке Рис. 1

3.3 Объект автоматизации в рамках настоящего Технического задания Объектом автоматизации в рамках выполнения работ по настоящему Техническому заданию являются процессы: – определения и разработки механизмов для подготовки к переводу функционала Системы на платформу «ГосТех»; – цифрового подтверждения права пассажира на приобретение льготного билета при пользовании транспортными услугами в сфере пассажирских перевозок железнодорожным транспортом разных типов сообщения (пригородное сообщение, дальнее следование); – цифрового подтверждения права пассажира на приобретение билета на воздушный транспорт по специальному тарифу для жителей Калининградской области; – цифрового подтверждения наличия права на приобретение билета на воздушный транспорт по специальному тарифу у гражданина, осваивающего образовательные программы бакалавриата, специалитета или магистратуры в учебных заведениях на территории Калининградской области; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных и перевозочных документов по сниженным, специальным и льготным тарифам для получателей мер социальной поддержки (защиты) разных уровней; – обеспечения обмена данными с организациями железнодорожного транспорта с целью цифрового оформления проездных документов с применением технологии бесконтактной оплаты проезда на основании данных геолокации;

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

Перечень функциональных подсистем, разрабатываемых в рамках настоящего Технического задания: Функция Основное назначение «Сервис сбора, обработки и хранения данных о региональных тарифах и льготах» Взаимодействие с региональными держателями реестров льготных категорий граждан пилотных регионов «Сервис «Личный кабинет региона» Управление данными о применении мер социальной поддержки (защиты) на транспорте в рамках полномочий субъекта РФ, включая отображение информации о действующих транспортных льготах в разрезе видов транспорта, типов сообщения, форматов предоставления, размеров льгот, включая размер скидки от применяемого тарифа на разных видах транспорта, агрегированную информацию о мерах социальной поддержки (защиты) на транспорте федерального уровня, нормативно-правовом регулировании Сервис «Маломобильные» Подтверждение принадлежности пассажира к маломобильным группам населения согласно официальным данным о степени способности к самостоятельному передвижению и наличию рекомендаций в обеспечении креслом-коляской, полученным из ИС Минтруда России с целью цифрового оформления заявки на специальное обслуживание в ходе перевозки железнодорожным транспортом «Сервис льготных перевозок по электронным транспортным требованиям» Обеспечения возможности автоматизированного цифрового подтверждения прав на оформление проездных и перевозочных документов на железнодорожный транспорт в пригородном сообщении и дальнем следовании «Сервис льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы» Подтверждение права на оформление льготных билетов на железнодорожный транспорт в пригородном и дальнем сообщении лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры

«Сервис учета данных Виртуальных социальных карт» Обмен данными по получателям мер социальной поддержки (защиты) разного уровня между федеральной государственной информационной системой «Единая система предоставления государственных и муниципальных услуг (сервисов)», информационными системами органов или организаций, уполномоченных на оформление виртуальных социальных карт с АИС УЛСП для обеспечения применения мер социальной защиты (поддержки) на транспорте с использованием виртуальных социальных карт Требования к целевой архитектуре и схеме внешних взаимодействий приведена на Рис. 2

2 НАЗНАЧЕНИЕ И ЦЕЛИ РАЗВИТИЯ СИСТЕМЫ - 3. Обеспечение возможности информационного взаимодействия: – с цифровыми сервисами, обеспечивающими функционирование виртуальной социальной карты (далее – ВСК) с целью обеспечения межведомственного взаимодействия и обмена данными по федеральным и региональным мерам социальной поддержки (защиты) на транспорте для разных видов транспорта и типов сообщения с целью реализации положений Постановления Правительства Российской Федерации от 31.05.2023 № 884 «О проведении эксперимента по использованию виртуальных социальных карт при предоставлении гражданам за счет средств бюджетов бюджетной системы Российской Федерации мер социальной защиты (поддержки) при пользовании транспортными услугами»; – с информационными системами, включая системы билетных продаж, перевозчиков в пассажирском железнодорожном транспорте дальнего следования и пригородного сообщения с целью перевода в цифровой формат подтверждения права пассажира на проезд по сниженному или безденежному тарифу при применении меры социальной поддержки (защиты) федерального или регионального уровня; - - Значение характеристики не может изменяться участником закупки

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

2.1 Назначение Системы АИС УЛСП предназначена для обеспечения возможности централизованного получения информации о мерах социальной поддержки граждан в части льготного и субсидированного проезда на пассажирском транспорте согласно действующей нормативно-правовой базе, в том числе при мультимодальных и межрегиональных перевозках, а также для подтверждения права гражданина на применение меры социально поддержки (защиты) на транспорте в безбумажный формат

2.2 Цели развития Системы Повышение транспортной доступности территорий и мобильности населения являются ключевыми целями развития транспортного комплекса согласно «Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года», утвержденной распоряжением Правительства Российской Федерации от 27.11.2021 № 3363 р. Обеспечение комфортных мультимодальных поездок, в т.ч. с использованием единого цифрового инструмента оплаты проезда и возможности применения цифровых льгот и субсидий. Недостаточное проникновение бесконтактных средств оплаты проезда, включая полностью цифровые инструменты, а также устаревший формат предоставления льгот на транспорте с «ручной» сверкой реестров для компенсации выпадающих доходов являются одним из барьеров развития пассажирской мобильности, обозначенной на заседании Президиума Госсовета по развитию общественного транспорта 17.08.2023. Целями развития Системы является подготовка для ее размещения на ЕЦП «ГосТех», а также расширение видов обрабатываемых транспортных льгот, субсидий и компенсаций, а также типов перевозочных документов, видов транспорта, типов получателей мер социальной поддержки (защиты), регионов и перевозчиков, подключенных к системе с целью обеспечения сквозного цифрового управления льготными и субсидируемыми пассажирскими перевозками в межрегиональном и внутрирегиональном сообщении, в том числе в рамках мультимодального заказа

2.3 Состав выполняемых задач Для реализации указанных целей развитие Системы должно решать следующие задачи: 1. Развитие АИС УЛСП, проработку механизмов и подготовку к миграции Системы на ЕЦП «ГосТех», предусматривающее: – разработку сервиса сбора, обработки и хранения данных о региональных тарифах и льготах, представляющего собой типовое, тиражируемое решение, предназначенное для взаимодействия с региональными держателями реестров льготных категорий граждан; – разработку сервиса «Личный кабинет региона», предназначенного для отображения статистических данных по тарифам (скидкам) на транспорт и льготам; – разработку сервиса «Маломобильные», предназначенного для обеспечения возможности маломобильным категориям населения оформлять запрос на сопровождение в объектах транспортной инфраструктуры, а также осуществлять заказ парковочного разрешения на объектах транспортной инфраструктуры; – разработку «Сервиса подтверждения льготных перевозок по электронным транспортным требованиям», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов и провоза багажа на железнодорожном транспорте в пригородном сообщении и дальнем следовании по служебным и личным надобностям; – разработку «Сервиса подтверждения льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы», предназначенного для обеспечения возможности автоматизированного цифрового подтверждения прав на оформление льготных билетов на железнодорожный транспорт в пригородном сообщении и дальнем следовании лицам, осваивающим образовательные программы среднего профессионального образования, программы бакалавриата, программы специалитета или программы магистратуры и в соответствии с нормативными правовыми актами РФ имеющим право на льготный проезд;

2. Модификация функционала сервисов АИС УЛСП с целью обеспечения автоматизированного цифрового подтверждения прав на покупку авиабилета по специальному тарифу для новых типов пассажира для региона Калининградская область («житель КГД» и «Студент КГД»);

Обеспечение заявки

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

Размер обеспечения заявки

800000.00 Российский рубль

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

Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, оформленной по типовой форме, утвержденной Постановлением Правительства Российской Федерации от 8 ноября 2013 № 1005. Выбор способа обеспечения заявки на участие в закупке осуществляется участником закупки самостоятельно. В соответствии со статьей 44 Федерального закона № 44-ФЗ обеспечение заявки на участие в закупке предоставляется одним из следующих способов: а) путем блокирования денежных средств, внесенных участником закупки на банковский счет, открытый таким участником в банке, включенном в перечень, утвержденный Правительством Российской Федерации (далее - специальный счет). Требования к таким банкам, к договору специального счета, к порядку использования, имеющегося у участника закупки банковского счета в качестве специального счета, устанавливаются Правительством Российской Федерации. б) путем предоставления независимой гарантии. Независимая гарантия, используемая для целей Федерального закона от 05.04.2013 № 44-ФЗ, информация о ней и документы, предусмотренные ч. 9 ст. 45 Федерального закона от 05.04.2013 № 44-ФЗ, должны быть включены в реестр независимых гарантий, размещенный в единой информационной системе. Обеспечение заявки на участие в закупке должно соответствовать ст. 44 Федерального закона от 05.04.2013 N 44-ФЗ. Участники закупки, являющиеся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением Российской Федерации, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением Российской Федерации, вправе предоставить обеспечение заявок в виде денежных средств с учетом особенностей, установленных Постановлением Правительства Российской Федерации от 10.04.2023 № 579 на счет Заказчика по реквизитам указанным в п. 7.3. Проекта контракта (Приложение № 5 к извещению)

Реквизиты счета для учета операций со средствами, поступающими заказчику

Реквизиты счета для учета операций со средствами, поступающими заказчику

"Номер расчётного счёта"03214643000000017300

"Номер лицевого счёта"20736X21630

"Код поступления" Информация отсутствует

"БИК"004525988

"Наименование кредитной организации"ГУ БАНКА РОССИИ ПО ЦФО//УФК ПО Г. МОСКВЕ, г Москва

"Номер корреспондентского счета" Информация отсутствует

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации)

ИНН получателя

7704116205

КПП получателя

770801001

КБК доходов

00011610000000000140

ОКТМО

45378000

Номер единого казначейского счета

40102810545370000003

Номер казначейского счета

03100643000000017300

БИК ТОФК

004525988

Получатель

УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО Г. МОСКВЕ (ФГБУ "СИЦ МИНТРАНСА РОССИИ")

Обеспечение исполнения контракта

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

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

8000000.00 Российский рубль

Порядок обеспечения исполнения контракта, требования к обеспечению

В соответствии с Разделом 7 Проекта контракта (Приложение № 5 к Извещению).

Платежные реквизиты

"Номер расчётного счёта"03214643000000017300

"Номер лицевого счёта"20736X21630

"Код поступления" Информация отсутствует

"БИК"004525988

"Наименование кредитной организации"ГУ БАНКА РОССИИ ПО ЦФО//УФК ПО Г. МОСКВЕ, г Москва

"Номер корреспондентского счета" Информация отсутствует

Требования к гарантии качества товара, работы, услуги

Требуется гарантия качества товара, работы, услуги

Да

Информация о требованиях к гарантийному обслуживанию товара

Требования к гарантии производителя товара

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги

Гарантийный срок: с даты подписания Заказчиком документа о приемке по Этапу № 3 в течение 12 месяцев. Обеспечение исполнения гарантийных обязательств предоставляется по результатам исполнения Этапа № 3 Контракта. Под гарантией понимается: ­ устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков в результатах работ (включая недостатки в отчетной, технической документации, переданной Заказчику при исполнении Контракта), выявленных после приемки выполненных Работ в срок не более 10 рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); ­ принятие участия в восстановлении работоспособности Системы после сбоев и аварий, если такие сбои возникли в работе функционала (модулей) Системы, создаваемых или разрабатываемых в рамках настоящего Контракта. При этом Подрядчик выполняет работы, связанные с восстановлением целостности данных и устранением проблем (недостатков), повлекших нарушение работоспособности Системы. Гарантийным случаем также признается полное или частичное отсутствие функционала Системы, создаваемого (дорабатываемого) по настоящему Контракту. При обнаружении недостатков в выполненных Работах в период гарантийного срока, возникших по независящим от Заказчика причинам, Подрядчик обязан за свой счет устранить недостатки в срок не более 10 (десяти) рабочих дней с момента обращения Заказчика (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком). Гарантийный срок в этом случае продлевается на период, использованный для устранения недостатков.

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

Требуется обеспечение гарантийных обязательств

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

8000000.00 Российский рубль

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

В соответствии с Разделом 7 Проекта контракта (Приложение № 5 к Извещению).

Платежные реквизиты

"Номер расчетного счета"03214643000000017300

"Номер лицевого счета"20736X21630

"Код поступления" Информация отсутствует

"БИК"004525988

"Наименование кредитной организации"ГУ БАНКА РОССИИ ПО ЦФО//УФК ПО Г. МОСКВЕ, г Москва

"Номер корреспондентского счета" Информация отсутствует

Дополнительная информация

Информация отсутствует

Информация о банковском и (или) казначейском сопровождении контракта

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

Критерии оценки заявок

Цена контракта

Значимость критерия оценки: 60.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Качественные, функциональные и экологические характеристики объекта закупки

Значимость критерия оценки: 25.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Показатели критерия оценки:

1 Качественные характеристики объекта закупки

Значимость показателя: 40.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Порядок оценки по показателю :

1 Детализирующий показатель: Характеристика № 1: «Схема взаимодействия участников сервиса льготных перевозок обучающихся граждан РФ с электронным подтверждением права льготы в соответствии с п. 4.2.6. Технического задания»

Значимость детализирующего показателя: 100.00%

Порядок оценки по детализирующему показателю: Оценка производится по шкале оценки

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

2 Функциональные характеристики объекта закупки

Значимость показателя: 60.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Порядок оценки по показателю :

1 Детализирующий показатель: Характеристика № 1: «Предложения по реализации обеспечения цифрового подтверждения прав пассажиров на приобретение льготных проездных документов организациями, осуществляющими оформление проездных документов на железнодорожного транспорте в соответствии с п. 4.2.1.1.4 Технического задания»

Значимость детализирующего показателя: 100.00%

Порядок оценки по детализирующему показателю: Оценка производится по шкале оценки

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

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

Значимость критерия оценки: 15.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Показатели критерия оценки:

1 Наличие у участников закупки опыта поставки товара, выполнения работы, оказания услуги, связанного с предметом контракта

Значимость показателя: 50.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Порядок оценки по показателю :

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

Значимость детализирующего показателя: 60.00%

Порядок оценки по детализирующему показателю: Лучшим является наибольшее значение характеристики объекта закупки

2 Детализирующий показатель: Общее количество исполненных участником закупки договоров

Значимость детализирующего показателя: 40.00%

Порядок оценки по детализирующему показателю: Лучшим является наибольшее значение характеристики объекта закупки

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

Значимость показателя: 50.00%

В соответствии с Приложением № 4 "Порядок рассмотрения и оценки заявок на участие в конкурсе" к Извещению

Порядок оценки по показателю :

1 Детализирующий показатель: Характеристика квалификации участников закупки №1 «Наличие у участников закупки специалистов и иных работников определенного уровня квалификации»

Значимость детализирующего показателя: 100.00%

Порядок оценки по детализирующему показателю: Лучшим является наибольшее значение характеристики объекта закупки

Перечень прикрепленных документов

Обоснование начальной (максимальной) цены контракта

1 2. Приложение № 2. Обоснование начальной (максимальной) цены контракта

Проект контракта

1 5. Приложение № 5. Проект контракта_развитие АИС УЛСП подготовка к размещению ГосТех

Описание объекта закупки

1 1. Приложение № 1. Описание объекта закупки - Техническое задание_развитие АИС УЛСП подготовка к размещению ГосТех

Требования к содержанию, составу заявки на участие в закупке

1 3. Приложение № 3. Требования к содержанию, составу заявки на участие

Порядок рассмотрения и оценки заявок на участие в конкурсах

1 4. Приложение № 4. Порядок рассмотрения и оценки заявок на участие_развитие АИС УЛСП подготовка к размещению ГосТех

Дополнительная информация и документы

Ссылки

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

Документы

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