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

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

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

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

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

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

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

Наименование объекта закупки: На выполнение работ по развитию Федеральной государственной информационной системы легковых такси

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

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

Номер типовых условий контракта: 1400700000521003

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

Размещение осуществляет: Заказчик

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

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

Место нахождения: 107078, Г.МОСКВА, вн.тер.г. МУНИЦИПАЛЬНЫЙ ОКРУГ КРАСНОСЕЛЬСКИЙ, УЛ САДОВАЯ-СПАССКАЯ, Д. 18, СТР. 1, ПОМЕЩ. 1

Ответственное должностное лицо: Теселкин В. А.

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

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

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

Регион: Москва

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

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

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

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

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

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

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

Начальная (максимальная) цена контракта: 33 000 000,00

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

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

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

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

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

Срок исполнения контракта: 03.12.2026 Сроки исполнения отдельных этапов исполнения контракта определяются на основании заявок заказчика в порядке, предусмотренном контрактом

Количество этапов: 3

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

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

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

- 62.01.11.000 - Этап №1: Техническое проектирование ОКПД2: 62.01.11.000 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям ... 3. Характеристика объекта автоматизации В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 ... 4. Требования к выполняемым работам 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы ... - Условная единица - 1,00 - 3 492 581,60 - 3 492 581,60

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям Значение характеристики не может изменяться участником закупки 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД 3. Характеристика объекта автоматизации В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 Значение характеристики не может изменяться участником закупки 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси 4. Требования к выполняемым работам 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы Значение характеристики не может изменяться участником закупки Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения 5. Сроки выполнения работ Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика Значение характеристики не может изменяться участником закупки Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы. 1. Общие сведения – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; Значение характеристики не может изменяться участником закупки – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива Значение характеристики не может изменяться участником закупки 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы 8. Требования к документированию Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов Значение характеристики не может изменяться участником закупки При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя 9. Источники разработки 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались Значение характеристики не может изменяться участником закупки 6. Порядок контроля и приемки 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения Значение характеристики не может изменяться участником закупки 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки - 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» - Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей - 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД - 3. Характеристика объекта автоматизации - В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 - - Значение характеристики не может изменяться участником закупки - 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси - – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок - – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) - 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 - Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси - 4. Требования к выполняемым работам - 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы - - Значение характеристики не может изменяться участником закупки - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 - При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML - 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» - 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 - Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 - 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования - 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции - 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% - 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ - 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке - 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы - 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы - 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств - 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) - Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом - 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) - 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. - 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня - 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой - 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени - 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления - 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. - 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования - 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. - 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования - 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты - В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования - 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника - 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование - – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается - 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками - 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту - 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования - 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения - 5. Сроки выполнения работ - Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика - - Значение характеристики не может изменяться участником закупки - Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу - 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 - 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия - 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 - 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 - * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы. - 1. Общие сведения - – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; - - Значение характеристики не может изменяться участником закупки - – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». - 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения - 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры - 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» - 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности - ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо - API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений - В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения - Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации - 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; - – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; - – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; - – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; - – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; - – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; - – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; - – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; - 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки - 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы - 8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки - При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке - Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений - 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя - 9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки - 6. Порядок контроля и приемки - 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - - Значение характеристики не может изменяться участником закупки - 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) - 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) - 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию - Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия - 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке - 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний

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

2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки

2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ»

Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей

2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД

3. Характеристика объекта автоматизации - В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 - - Значение характеристики не может изменяться участником закупки

3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси

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

– личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160)

3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580

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

4. Требования к выполняемым работам - 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы - - Значение характеристики не может изменяться участником закупки

Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250

При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML

4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации»

4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000

Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029

4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам

Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования

4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции

4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования

4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7%

4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ

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

4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»

4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы

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

4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств

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

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

4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса)

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

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

4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН)

4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси.

4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня

4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой

4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени

4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

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

4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3.

4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования

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

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

3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6.

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

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

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

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

4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование

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

4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками

4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту

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

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

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

Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу

1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026

2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия

2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026

3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026

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

1. Общие сведения - – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; - - Значение характеристики не может изменяться участником закупки

– ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».

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

1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения

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

1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»

1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

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

ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо

API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений

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

Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации

1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;

– Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»;

– Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»;

– Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»;

– Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»;

– приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»;

– приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»;

– ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»;

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки

7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы

8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки

При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке

Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений

8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации;

26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя

9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки

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

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

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

6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта)

6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

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

6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию

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

6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке

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

- 62.01.11.000 - Этап №3: Этап опытной эксплуатации и приемочных испытаний ФГИС Такси ОКПД2: 62.01.11.000 1. Общие сведения – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; ... 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям ... 3. Характеристика объекта автоматизации 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 ... - Условная единица - 1,00 - 3 133 531,16 - 3 133 531,16

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1. Общие сведения – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; Значение характеристики не может изменяться участником закупки – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям Значение характеристики не может изменяться участником закупки 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД 3. Характеристика объекта автоматизации 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 Значение характеристики не может изменяться участником закупки Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) 4. Требования к выполняемым работам 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ Значение характеристики не может изменяться участником закупки 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции 9. Источники разработки 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались Значение характеристики не может изменяться участником закупки 6. Порядок контроля и приемки 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию Значение характеристики не может изменяться участником закупки Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива Значение характеристики не может изменяться участником закупки 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы 8. Требования к документированию Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов Значение характеристики не может изменяться участником закупки При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя 5. Сроки выполнения работ 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 Значение характеристики не может изменяться участником закупки 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы. Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1. Общие сведения - – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; - - Значение характеристики не может изменяться участником закупки - – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; - – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; - – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; - – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; - – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». - 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения - 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры - 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» - 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности - ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо - API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений - В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения - Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации - 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; - – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; - – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; - – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; - 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки - 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» - Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей - 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД - 3. Характеристика объекта автоматизации - 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 - - Значение характеристики не может изменяться участником закупки - Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси - В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 - 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси - – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок - – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) - 4. Требования к выполняемым работам - 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ - - Значение характеристики не может изменяться участником закупки - 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке - 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы - 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств - 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом - 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% - 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы - 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) - Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления - 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. - 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) - 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. - 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня - 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования - 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой - 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. - 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования - 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты - 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени - 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования - 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника - 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование - – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается - 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками - 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту - 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования - 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения - 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 - При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML - 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» - 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 - Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 - Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования - 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции - 9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки - 6. Порядок контроля и приемки - 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию - - Значение характеристики не может изменяться участником закупки - Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия - 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке - 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний - 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) - 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) - 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки - 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы - 8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки - При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке - Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений - 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя - 5. Сроки выполнения работ - 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки - 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия - 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 - 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 - * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы. - Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика - Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу

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

1. Общие сведения - – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; - - Значение характеристики не может изменяться участником закупки

– приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»;

– приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»;

– ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»;

– ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»;

– ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».

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

1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения

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

1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»

1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

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

ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо

API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений

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

Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации

1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;

– Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»;

– Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»;

– Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»;

2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки

2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ»

Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей

2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД

3. Характеристика объекта автоматизации - 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 - - Значение характеристики не может изменяться участником закупки

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

В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127

3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси

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

– личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160)

4. Требования к выполняемым работам - 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ - - Значение характеристики не может изменяться участником закупки

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

4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»

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

4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств

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

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

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

4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам

4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования

4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7%

4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы

4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса)

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

4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3.

4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН)

4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси.

4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня

4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования

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

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

4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой

4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6.

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

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

4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени

4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

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

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

4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование

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

4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками

4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту

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

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

4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы

Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250

При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML

4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации»

4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000

Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029

Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования

4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции

9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки

6. Порядок контроля и приемки - 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию - - Значение характеристики не может изменяться участником закупки

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

6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке

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

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

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

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

6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта)

6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки

7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы

8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки

При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке

Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений

8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации;

26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя

5. Сроки выполнения работ - 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки

2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия

2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026

3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026

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

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

Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу

- 62.01.11.000 - Этап №2: Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси ОКПД2: 62.01.11.000 1. Общие сведения 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) ... 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям ... 3. Характеристика объекта автоматизации – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок ... - Условная единица - 1,00 - 26 373 887,24 - 26 373 887,24

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1. Общие сведения 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) Значение характеристики не может изменяться участником закупки 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям Значение характеристики не может изменяться участником закупки 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД 3. Характеристика объекта автоматизации – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок Значение характеристики не может изменяться участником закупки – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси 4. Требования к выполняемым работам 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования Значение характеристики не может изменяться участником закупки 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня 9. Источники разработки 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались Значение характеристики не может изменяться участником закупки 6. Порядок контроля и приемки 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию Значение характеристики не может изменяться участником закупки Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива Значение характеристики не может изменяться участником закупки 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы 8. Требования к документированию Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов Значение характеристики не может изменяться участником закупки При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя 5. Сроки выполнения работ Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика Значение характеристики не может изменяться участником закупки Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1. Общие сведения - 1.1. Полное наименование Системы и ее условное обозначение Полное наименование: Федеральная государственная информационная система легковых такси. Условное обозначение: ФГИС Такси, Система. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - - Значение характеристики не может изменяться участником закупки - 1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения - 1.3. Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Подрядчик определяется по результатам проведения закупочной процедуры - 1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» - 1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.7. Термины и сокращения, используемые в настоящем документе В настоящем документе используются следующие сокращения на русском и английском языках: Сокращение Расшифровка АИС НССО Автоматизированная информационная система Национального союза страховщиков ответственности БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИБДД Государственная инспекция безопасности дорожного движения ГИС ГМП Государственная информационная система о государственных и муниципальных платежах ГОСТ Государственный стандарт ГУ Государственная услуга ГРН Государственный регистрационный номер ГЭПС Государственная электронная почтовая система ЕАИСТО Единая автоматизированная информационная система технического осмотра ЕГРИП Единый государственный реестр индивидуальных предпринимателей ЕГРЮЛ Единый государственный реестр юридических лиц ЕПГУ Единый портал государственных и муниципальных услуг ЕСИА Единая система идентификации и аутентификации ЕЦП «ГосТех» Единая цифровая платформа Российской Федерации «ГосТех» ИБ Информационная безопасность ИНН Идентификационный номер налогоплательщика ИП Индивидуальный предприниматель ИС Информационная система КИИ Критическая информационная инфраструктура КТС Комплекс технических средств МВД России Министерство внутренних дел Российской Федерации МЗИ Механизмы защиты информации НПА Нормативно-правовой акт НСД Несанкционированный доступ НССО Национальный союз страховщиков ответственности НСИС Национальная Страховая Информационная Система НФАП Национальный фонд алгоритмов и программ ОГРН Основной государственный регистрационный номер ОИ Защищенный объект информатизации, соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси ОКИИ Объект критической информационной инфраструктуры ОС Операционная система ОСГОП Обязательное страхование гражданской ответственности перевозчика ОСАГО Обязательное страхование автогражданской ответственности - ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо - API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений - В настоящем документе используются следующие термины: Термин Определение Аутентификация Действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» Подрядчик Определяется по итогам закупочной процедуры Код изготовителя Международный идентификационный код изготовителя транспортного Контракт Контракт на выполнение работ по развитию Федеральной государственной информационной системы легковых такси в 2026 году Легковое такси Легковой автомобиль, используемый для осуществления перевозок пассажиров и багажа на основании публичного договора фрахтования Оператор ФГИС Такси Федеральный орган исполнительной власти, осуществляющий функции по выработке государственной политики и нормативно-правовому регулированию в сфере транспорта, или подведомственная ему организация в случае принятия указанным федеральным органом исполнительной власти решения о возложении на эту организацию функций такого оператора Разрешение Электронный документ, предоставляющий в соответствии с ч. 1 ст. 3 ФЗ 580 право на осуществление юридическим лицом, индивидуальным предпринимателем или физическим лицом деятельности по перевозке пассажиров и багажа легковым такси Региональный реестр легковых такси Информационный ресурс, содержащий сведения о транспортных средствах, соответствующих требованиям, предъявляемым к легковым такси Региональный реестр перевозчиков легковым такси Информационный ресурс, содержащий сведения о перевозчиках легковым такси (далее также – перевозчик), в том числе о предоставлении им разрешения, предусмотренного п. 10 ст. 2 ФЗ 580, а также о приостановлении, возобновлении и об аннулировании действия указанного разрешения - Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации - 1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; - – Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»; - – Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»; - – Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; - – Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; - – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»; - – приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»; - – ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»; - – ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»; - – ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». - 2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки - 2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ» - Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей - 2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД - 3. Характеристика объекта автоматизации - – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок - - Значение характеристики не может изменяться участником закупки - – личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160) - 3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580 - Сведения о принятии решения о предоставлении, приостановлении, возобновлении или об аннулировании действия разрешения вносятся уполномоченным органом субъекта Российской Федерации в региональный реестр перевозчиков легковым такси в день принятия такого решения. Если уполномоченный орган осуществляет ведение регионального реестра перевозчиков легковым такси с использованием региональной информационной системы, уполномоченный орган также направляет указанные выше сведения об изменении статусов решений во ФГИС Такси - В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127 - 3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси - 4. Требования к выполняемым работам - 4.2.4.3. Требования к обеспечению возможности предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных о квотах, включая данные об остатках квот, по регионам на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных о квотах и остатках квот по регионам; – для обеспечения обработки информации о квоте и остатке квоты по регионам дополнить текущую модель данных следующими атрибутами: – id региона; – наименование региона; – квота (размер квоты); – остаток квоты (разница между размером квоты и количеством квотированных ТС в региональном реестре легковых такси на момент запроса); – дата расчета квоты; – количество ТС в региональном реестре легковых такси на момент расчета квоты; – процент квоты (процент для расчета размера квоты на дату расчета квоты). Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - - Значение характеристики не может изменяться участником закупки - 4.2.4.4. Требования к обеспечению возможности предоставления данных из справочника локализованных марок и моделей транспортных средств на витрине НСУД СМЭВ4 В рамках развития функции предоставления данных из реестров по запросу в связи с изменениями в нормативной базе в части локализации ТС для целей ЕПГУ и/или ФГИС ПГС требуется реализовать возможность предоставления данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД. Для этого необходимо: – в рамках СМЭВ 4 реализовать регламентированный запрос (или запросы) для получения данных марках и моделях транспортных средств, удовлетворяющих требованиям локализации; – для обеспечения обработки информации о локализованных марках и моделях дополнить текущую модель данных следующими атрибутами: – марка транспортного средства; – модель транспортного средства; – код изготовителя транспортного средства. Техническое решение и детальный состав атрибутов должны быть определены на этапе технического проектирования - 4.2.5. Требования к функциям подсистемы формирования отчетности 4.2.5.1. Требования к функции графического представления аналитических данных в части отображения аналитических данных по метрикам локализации и квотирования В рамках развития функции графического представления аналитических данных для обеспечения возможности отображения аналитических данных федеральных реестров по метрикам локализации и квотирования в связи с изменениями в нормативной базе в части локализации ТС требуется доработать механизмы преобразования и хранения данных реестров для аналитических запросов. Механизмы преобразования и хранения с помощью аналитических запросов должны обеспечить возможность анализа структуры и состава ТС, перевозчиков в разрезе динамики внедрения локализованных ТС для перевозок легковым такси в регионах, проанализировать структуру, состав, динамику ТС, включаемых в региональные реестры на условиях квотирования, проанализировать иные связанные показатели. Состав параметров (метрик), по которым будут строиться аналитические запросы в рамках развития функции графического представления аналитических данных, должен быть согласован и представлен Заказчиком на этапе технического проектирования - 4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой - 4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - 3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6. - 4.1.1.3. Требования к характеристикам взаимосвязей развиваемой Системы со смежными системами Система должна обеспечивать возможность взаимодействия со следующими внешними системами: – ЕСИА в части идентификации и аутентификации пользователей Системы; – Региональными информационными системами в части получения данных об участниках легковых таксомоторных перевозок: – Региональный реестр перевозчиков легковым такси; – Региональный реестр легковых такси; – Региональный реестр служб заказа легковых такси. – ФНС России в части получения данных из ЕГРЮЛ/ЕГРИП; – ФИС ГИБДД-М в части получения данных о регистрации ТС и их владельцах; – ГИС ГМП в части получения данных о штрафах; – НССО в части получения данных о договорах ОСГОП; – НСИС в части получения данных о полисах ОСАГО; – Внешними сервисами и порталами-потребителями открытых сведений о перевозчиках, транспортных средствах и службах заказов такси по единому API; – Уполномоченными органами-получателями юридически значимых сведений о перевозчиках, транспортных средствах и службах заказов такси через СМЭВ. Перечень внешних систем, состав получаемых данных, а также способы взаимодействия должны быть уточнены на этапе технического проектирования - 4.2.6. Требования к подсистеме администрирования 4.2.6.1. Требования к справочнику «Квота» В рамках развития функции управления записями справочников требуется реализовать справочник «Квота». Справочник «Квота» должен обеспечивать следующие возможности: – просмотр квот и остатков квот по регионам в соответствии с правами доступа; – просмотр детальной информации о квоте: – регион; – размер квоты; – остаток квоты; – дата расчета квоты; – количество действующих записей регионального реестра легковых такси на дату расчета квоты (расчетная база квоты); – процент квоты; – редактирование квоты; – ведение истории изменений квоты - В рамках редактирования квоты должны быть обеспечены следующе условия и возможности: – для Уполномоченного органа должна быть реализована возможность редактирования региональной квоты в течение определенного периода с даты расчета квоты, установленной законом, для обеспечения возможности уточнения данных о расчетной базе квоты на основании данных регионального реестра легковых такси на дату расчета квоты; – по истечении указанного периода возможность редактирования квоты для Уполномоченного органа должна быть заблокирована и может осуществляться только после разблокирования в рамках технической поддержки; – редактирование квоты Уполномоченным органом должно осуществляться путем редактирования данных о расчетной базе квоты и последующего пересчета размера квоты в соответствии с установленным законом процентом квоты, дата расчета квоты при этом не меняется; – при изменении данных о расчетной базе квоты должна быть обеспечена валидация: внесенное значение не может быть меньше значения, рассчитанного Системой на основании данных о количестве действующих записей РЛТ на дату расчета квоты; – внесение изменений в региональную квоту Уполномоченным органом может осуществляться только при условии подписания электронной подписью; – квота, рассчитанная автоматически на основании данных Системы, должна сохраняться для обеспечения возможности отображения пользователям. Техническое решение и детальный состав возможностей функционала справочника «Квоты» должны быть определены на этапе технического проектирования - 4.2.6.2. Требования к справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции управления записями справочников требуется реализовать справочник «Локализованные марки и модели транспортных средств» для ведения списка транспортных средств в составе марки, модели и кода изготовителя Международного идентификационного кода изготовителя транспортного средства (далее – код изготовителя), которые соответствуют требованиям локализации. Справочник «Локализованные марки и модели транспортных средств» должен обеспечивать следующие возможности: – ведение справочника: создание, редактирование и удаление записей о транспортном средстве в составе марки, модели и кода изготовителя; – просмотр записей справочника в соответствии с правами доступа; – ведение истории изменений записей справочника - 4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование - – Система и ее части должны функционировать непрерывно в круглосуточном режиме. Допускается временное ограничение полнофункциональной доступности отдельных частей Системы: – в периоды выполнения регламентированных работ по обслуживанию аппаратно-программных и программных средств частей Системы, предусмотренных эксплуатационной документацией; – как результат возникновения внештатных ситуаций, вызванных одиночными отказами в работе аппаратных и/или программных средств частей Системы. Регламентные работы должны производиться с учётом требований о доступности Системы. Функционирование Системы при отказах и сбоях серверного общесистемного, специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается - 4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками - 4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту - 4.3.3. Требования к лингвистическому обеспечению Документация на Систему должна разрабатываться на русском языке. Взаимодействие пользователей с Системой посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Системы должно быть предусмотрено использование языков программирования высокого уровня. Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть определены на этапе технического проектирования - 4.1.1.6. Перспективы развития, модернизации Системы При развитии Системы должны использоваться технические средства, позволяющие оптимизировать ресурсы при создании и развитии модулей. Система должна обеспечивать возможность модернизации и развития при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Дальнейшая модернизация осуществляется на основе дополнительных технических заданий. При доработке программных интерфейсов предпочтение должно отдаваться специфицированным и стандартизированным решениям. Система должна обеспечивать возможность наращивания производительности путем увеличения производительности средств технического обеспечения - 4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250 - При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML - 4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации» - 4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000 - Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029 - Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования - 4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - 4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции - 4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ - 4.1.4. Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами, и должен обеспечивать быстрое (в соответствии с показателями назначения) отображение экранных форм. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Элементы интерфейса сходного функционального назначения должны быть реализованы аналогичным образом. Управление Системой должно осуществляться с помощью набора экранных меню, кнопок и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Экранные формы должны проектироваться с учетом следующих требований: – все экранные формы должны выполняться в едином графическом дизайне; – должно быть обеспечено удобство расположения и представления часто используемых элементов экрана; – для обозначения сходных операций должны использоваться сходные значки, кнопки, другие управляющие элементы; – для каждого пользователя/группы пользователей, в зависимости от прав доступа к Системе, должны отображаться только те элементы интерфейса, которые необходимы для работы данного пользователя; – должно поддерживаться отображение на экране хода выполнения длительных процессов обработки данных. Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения об ошибках, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или недопустимым значениям входных данных. Пользовательский интерфейс программных средств Системы должен быть реализован на русском языке - 4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4.1.6. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Системой транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Системе должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Системе при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Системы - 4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств - 4.1.8. Требования к патентной чистоте 4.1.8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.1.8.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.1.8.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.8.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.1.8.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.8.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом - 4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.8.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - 4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7% - 4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы - 4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса) - Подрядчик обязуется обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного программного обеспечения, приведенных в Руководстве. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы по шаблонам, утвержденным в Руководстве, и исходный код Системы. Предоставление исходного кода Системы осуществляется путем его загрузки в систему контроля версий Оператора Системы в соответствии с пунктом 4.1.13.2. Загруженный исходный код должен сопровождаться необходимым набором тестов и инструкций для развертывания экземпляра Системы и/или опытного образца Системы. Предоставление отчетных материалов Подрядчиком осуществляется путем их направления официальным письмом в адрес Заказчика. Заказчик, при необходимости, предоставляет Подрядчику результаты проведенных контрольных проверок, зафиксированных в артефактах сборочного процесса для устранения Подрядчиком в срок до даты завершения государственного контракта. Уязвимости подлежат устранению Подрядчиком в сроки, обозначенные Заказчиком с учетом приоритизации Заказчиком выявленных уязвимостей. Подрядчик должны устранить уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности, в случае если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени - 4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования - 4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test - 4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (п. 2.2 Технического задания). 4.1. Требования к Системе в целом 4.1.1. Требования к структуре Системы В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: – уровень хранения данных или уровень базы данных (сервер СУБД); – уровень сервера приложений (сервер аналитической обработки); – презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: – сервер баз данных; – сервер приложений; – веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP/HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления - 4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3. - 4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН) - 4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси. - 4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня - 9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки - 6. Порядок контроля и приемки - 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию - - Значение характеристики не может изменяться участником закупки - Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом результатов опытной эксплуатации, утвержден Подрядчиком и Заказчиком до начала приемочных испытаний, при этом проверки Системы в части не устраненных высококритичных недостатков реализации Системы, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». По результатам проведения приемочных испытаний оформляется протокол приемочных испытаний и Акт приемки в промышленную эксплуатацию. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается обработка информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В ходе предварительных испытаний, опытной эксплуатации, приемочных испытаний ПИБ ФГИС Такси запрещается проводить обработку обезличенных и/или обезличивание персональных данных. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия - 6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке - 6.2.2. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Системы. Прочие недостатки (недостатки, которые не противоречат требованиям настоящего ТЗ) могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи Системы в опытную и промышленную эксплуатацию. Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. 6.2.3. Условием для передачи Системы в промышленную эксплуатацию является устранение всех замечаний - 6.2.4. Передача исходных кодов, разработанных в ходе выполнения работ программ для электронных вычислительных машин и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - 6.2.5. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ с использованием средств, указанных в пункте 6.2.4 ТЗ, а также в соответствии с инструкциями, приведенными в рабочей документации на Систему. Документация на Систему и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - 6.2.6. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Системы в контролируемой Заказчиком среде; – установку полученной Системы на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Системы; – оформление Системы в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин. Передача исходных кодов оформляется «Актом о передаче материального носителя», составленного Подрядчиком и согласованного Заказчиком по результатам выполненных работ по настоящему Техническому заданию и условиям Договора. 6.2.7. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает Заказчику дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения - 6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта) - 6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки) - 6.5. Сведения об обслуживании Системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. Системное и прикладное сопровождение, техническое сопровождение аппаратного обеспечения, системное сопровождение средств защиты информации, организация технической поддержки пользователей и другие работы (услуги) производятся на основании контрактов на выполнение соответствующих работ (услуг) - 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки - 7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы - 8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки - При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке - Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений - 8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - 26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя - 5. Сроки выполнения работ - Сдача-приемка результатов Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Сроки выполнения работ в 2026 году приведены в Таблице 9. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Срок согласования Заказчиком документов – не более 3-х рабочих дней с даты предоставления Заказчику таких документов. Своевременное предоставление проектов документов на согласование Заказчику находится в зоне ответственности Подрядчика - - Значение характеристики не может изменяться участником закупки - Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу - 1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026 - 2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия - 2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026 - 3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026 - * Датой предоставления результатов работ в соответствии со сроками исполнения подпунктов в рамках этапов является дата регистрации Заказчиком сопроводительного письма Подрядчика. Работы по развитию Системы (за исключением этапа проведения опытной эксплуатации) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ, подпунктов в рамках этапа) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать работам в рамках очередного этапа (подпункта в рамках этапа) при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. В случае досрочного выполнения Подрядчиком работ Заказчик вправе досрочно принять и оплатить Подрядчику их стоимость в порядке, предусмотренном Контрактом. При этом данные работы подлежат включению в Универсальный передаточный документ того этапа, в каком были завершены работы по развитию Системы.

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

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

1.2. Шифр темы или номер контракта Присваивается Заказчиком в ходе организации закупочных процедур. 1.2.1. Предмет Выполнение работ по развитию Федеральной государственной информационной системы легковых такси (далее – Работы). ОКПД 2: 62.01.11.000 - Услуги по проектированию, разработке информационных технологий для прикладных задач и тестированию программного обеспечения

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

1.4. Перечень документов, являющихся основанием для выполнения работ Основанием для выполнения работ является Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»

1.5. Сроки и место выполнения работ Начало выполнения работ: с даты заключения Контракта. Окончание работ: не позднее 26.10.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с Разделом 5 настоящего Технического задания (далее – Календарный план). Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет

1.6. Сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01)

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

ПИБ Подсистема информационной безопасности ПО Программное обеспечение ППО Прикладное программное обеспечение ПЭВМ Персональная электронно-вычислительная машина СЗЛТ Служба заказа легкового такси СКЗИ Средства криптографической защиты информации СПИК Специальный инвестиционный контракт СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение СрЗИ Средства защиты информации СТС Свидетельство о регистрации транспортного средства СУБД Система управления базами данных ТЗ Техническое задание ТС Транспортное средство УЗ Учетная запись УКЭП Усиленная квалифицированная электронная подпись ФГИС ПГС Федеральная государственная информационная система «Единая система предоставления государственных и муниципальных услуг (сервисов)» ФЗ 580 Федеральный закон от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФЗ 116 Федеральный закон от 23 мая 2025 г. № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» ФИО Фамилия, имя, отчество ФИС ГИБДД-М Федеральная информационная система Государственной инспекции безопасности дорожного движения ФНС России Федеральная налоговая служба ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю Российской Федерации ЦОД Центр обработки данных ЧТЗ Частное техническое задание ЭВМ Электронно-вычислительная машина ЭП Электронная подпись ЮЛ Юридическое лицо

API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными ATT&CK The Adversarial Tactics, Techniques, and Common Knowledge – база знаний, разработанная и поддерживаемая корпорацией MITRE на основе анализа реальных APT-атак. Представляет собой список тактик. Для каждой из них указаны возможные техники, которые помогают злоумышленникам в достижении цели на текущем этапе атаки CAPEC Common Attack Pattern Enumeration and Classification – стандарт описания классов атак и их иерархических отношений, каталог известных кибератак HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure – расширение протокола HTTP, поддерживающее шифрование IAM Identity and Access Management – сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к ресурсам защищенного объекта информатизации соответствующий законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси. IAM контролирует, чтобы все операции над ресурсами выполнялись только пользователями с необходимыми правами MAX Российский кроссплатформенный сервис мгновенного обмена сообщениями на базе одноимённой цифровой системы. OWASP Open Web Application Security Project – это открытый проект обеспечения безопасности веб-приложений REST Representational State Transfer – способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции VIN Vehicle identification number, уникальный код транспортного средства, состоящий из 17 знаков QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») WASC The Web Application Security Consortium Threat Classification – классификация угроз безопасности веб-приложений

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

Региональный реестр служб заказа легкового такси Информационный ресурс, содержащий сведения о службах заказа легкового такси, в том числе о предоставлении им права на осуществление деятельности службы заказа легкового такси, а также о приостановлении, возобновлении и об аннулировании действия указанного права Система, ФГИС Такси, Федеральная государственная информационная система легковых такси Информационно-аналитическая система, обеспечивающая сбор, обработку, систематизацию, хранение сведений из региональных реестров перевозчиков легковым такси, региональных реестров легковых такси и региональных реестров служб заказа легковых такси и предоставление уполномоченным органам возможности ведения данных реестров и доступа к сведениям, содержащимся в указанной информационно-аналитической системе, а также выполнение иных функций в соответствии с ФЗ 580 Служба заказа легкового такси Юридическое лицо или индивидуальный предприниматель, которым предоставлено право на осуществление деятельности по получению от лица, имеющего намерение стать фрахтователем, и (или) передаче лицу, имеющему намерение стать фрахтовщиком, заказа легкового такси в целях последующего заключения ими публичного договора фрахтования легкового такси (далее – деятельность службы заказа легкового такси) Уполномоченные органы Органы исполнительной власти субъекта Российской Федерации, уполномоченные законом или иным нормативным правовым актом субъекта Российской Федерации на осуществление функций по организации перевозок пассажиров и багажа легковым такси и региональному государственному контролю (надзору) в сфере перевозок пассажиров и багажа легковым такси, возлагаемых ФЗ 580 на органы исполнительной власти субъекта Российской Федерации

1.8. Перечень нормативных правовых актов, нормативно-технических документов, методических материалов, регламентирующих создание и развитие системы – Федеральный закон Российской Федерации от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 24 июня 2023 г. № 278-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 23.05.2025 № 116-ФЗ «О внесении изменений в статьи 9 и 10 Федерального закона «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации»; – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 08.11.2007 № 259-ФЗ «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 21.04.2011 № 69-ФЗ (ред. от 02.07.2021) «О внесении изменений в отдельные законодательные акты Российской Федерации», статья 9; – Федеральный закон Российской Федерации от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;

– Федеральный закон Российской Федерации от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; – Федеральный закон Российской Федерации от 11.06.2022 № 156-ФЗ «О внесении изменений в Федеральный закон «О государственной регистрации юридических лиц и индивидуальных предпринимателей» и Федеральный закон «Устав автомобильного транспорта и городского наземного электрического транспорта»; – Перечень поручений Президента Российской Федерации по итогам заседания Президиума Государственного Совета Российской Федерации по вопросам развития общественного транспорта от 17 сентября 2023 г. № Пр-1855ГС; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; Постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201 «Об утверждении Положения о федеральной государственной информационной системе легковых такси»; – Постановление Правительства Российской Федерации от 11 августа 2025 г. № 1194 «О внесении изменений в постановление Правительства Российской Федерации от 24 июля 2023 г. № 1201»;

– Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – Постановление Правительства Российской Федерации от 22.09.2009 № 754 «Об утверждении Положения о системе межведомственного электронного документооборота»; – Постановление Правительства Российской Федерации от 15.05.2010 № 330 «Об особенностях оценки соответствия продукции (работ, услуг), используемой в целях защиты сведений, относимых к охраняемой в соответствии с законодательством Российской Федерации информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, а также процессов ее проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»; – Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; – Постановление Правительства Российской Федерации от 03.02.2012 № 79 «О лицензировании деятельности по технической защите конфиденциальной информации»;

– Постановление Правительства Российской Федерации от 09.02.2012 № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи»; – Постановление Правительства Российской Федерации от 24.07.2021 № 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия»; – Постановление Правительства Российской Федерации от 21.02.2022 № 222 «Об утверждении Правил представления заинтересованным лицам документа о полномочиях физического лица в случае, предусмотренном частью 2 статьи 17.1 Федерального закона «Об электронной подписи»; – Постановление Правительства Российской Федерации от 8 июня 2011 г. № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»;

– Распоряжение Правительства Российской Федерации от 09.06.2014 № 991-р (ред. от 27.09.2014) «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденного распоряжением Правительства Российской Федерации от 25.12.2013 № 2516-р» (с изменениями, внесенными распоряжением Правительства Российской Федерации от 27 сентября 2014 года № 1906-р, распоряжением Правительства Российской Федерации от 11 июня 2016 года № 1202-р, распоряжением Правительства Российской Федерации от 25 мая 2017 года № 1027-р); – Транспортная стратегия Российской Федерации на период до 2030 года с прогнозом на период до 2035 года, утвержденная распоряжением Правительства Российской Федерации от 27.11.2021 № 3363-р; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»;

– приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных; – приказ Минкомсвязи России от 02.09.2011 № 221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения»; – приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия; – приказ Минцифры России от 06.11.2020 № 580 «Об утверждении порядка создания и проверки метки доверенного времени»; – приказ Минцифры России от 19.11.2020 № 603 «Об утверждении требований к порядку действий аккредитованного удостоверяющего центра при возникновении обоснованных сомнений относительно лица, давшего поручение на использование хранимых ключей электронной подписи, а также при приостановлении (прекращении) технической возможности использования хранимых ключей электронной подписи, включая информирование владельцев квалифицированных сертификатов ключей проверки электронной подписи о событиях, вызвавших приостановление (прекращение) технической возможности использования хранимых ключей электронной подписи, об их причинах и последствиях»;

– приказ Минцифры России от 08.11.2021 № 1138 «Об утверждении Порядка формирования и ведения реестров выданных аккредитованными удостоверяющими центрами квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров, включая требования к формату предоставления такой информации»; – Методические рекомендации по составу квалифицированного сертификата ключа проверки электронной подписи, утв. Минкомсвязь России; – Методические рекомендации по реализации Требований к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде (протокол заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 27.12.2016 № 558пр); – ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; – ГОСТ Р 2.102-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Виды и комплектность конструкторской документации»;

– ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации общие Требования к текстовым документам»; – ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации «Текстовые документы»; – ГОСТ Р 2.601-2019 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Эксплуатационные документы»; – ГОСТ Р 15.011-2024 «Национальный стандарт Российской Федерации. Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения»; – ГОСТ Р 59793-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; – ГОСТ Р 59795-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; – ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; – ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; – ГОСТ Р 2.503-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Правила внесения изменения»; – ГОСТ Р 2.504-2021 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Правила внесения изменений»;

– ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; – ГОСТ 28806-90 «Качество программных средств. Термины и определения»; – ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения (с Изменением № 1)»; – ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология (ИТ). Классификация программных средств (с поправкой)»; – ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; – ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология (ИТ). Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; – ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; – ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология (ИТ). Уровни целостности систем и программных средств»; – ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения»; – ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»;

– ISO/IEC 14756:1999 «Информационные технологии – измерение и оценка производительности компьютерных программных систем – первый выпуск»; – ГОСТ Р 2.051-2023 «Национальный стандарт Российской Федерации. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения»; – ГОСТ 19.101-2024 «Межгосударственный стандарт. Единая система программной документации. Виды программ и программных документов»; – ГОСТ Р ИСО/МЭК 27001-2021 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования»; – ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»; – Национальный стандарт Российской Федерации ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».

2. Цели и назначение развития Федеральной государственной информационной системы легковых такси - 2.1. Назначение Системы Система предназначена для комплексного обеспечения следующих процессов: – сбор, обработка, систематизация и хранение сведений из: o региональных реестров перевозчиков легковым такси; o региональных реестров легковых такси; o региональных реестров служб заказа легковых такси; – предоставление уполномоченным органам возможности ведения указанных реестров и доступа к содержащимся в реестрах сведениям - - Значение характеристики не может изменяться участником закупки

2.2. Цели развития Системы Развитие Системы осуществляется на основе имеющейся у Заказчика Федеральной государственной информационной системы легковых такси (разработанной в 2023 году по Контракту от 02.06.2023 № ОК/23_01 и развитой в 2025 году по Контракту от 15.05.2025 ОК/25_04) в рамках приведения в соответствие с требованиями Федерального закона от 29.12.2022 № 580-ФЗ «Об организации перевозок пассажиров и багажа легковым такси в Российской Федерации, о внесении изменений в отдельные законодательные акты Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации» (далее - ФЗ 580). Выполнение работ по развитию системы предусмотрено мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ»

Целями выполнения работ по развитию ФГИС Такси являются: – Поддержка централизованного контроля за выполнением участниками автомобильных перевозок легковым такси требований законодательства Российской Федерации к деятельности перевозчиков легковым такси, служб заказа легковых такси, а также допуск физических лиц – самозанятых к перевозкам легковыми такси; – Повышение прозрачности и легальности рынка легковых таксомоторных перевозок на федеральном уровне; – Повышение уровня контроля за действиями участников автомобильных перевозок легковым такси, деятельностью перевозчиков легковым такси, служб заказа легковых такси; – Повышение безопасности перевозок за счет контроля наличия обязательного страхования гражданской ответственности перевозчика за причинение вреда жизни, здоровью, имуществу; – Снижение временных затрат на проверку ТС и перевозчика и в рамках выполнения контрольно-надзорной деятельности и регуляторных функций государственными органами власти; – Расширение состава сведений, содержащихся в Системе, в рамках информационного взаимодействия со смежными ведомствами и внешними информационными системами; – Обеспечение возможности получения расширенных сведений, в том числе аналитической информации, об участниках автомобильных перевозок легковым такси, перевозчиков легковым такси, служб заказа легковых такси; – Предоставление новых возможностей для пользователей Системы, за счет разработки новых подсистем/модулей

2.3. Задачи развития Системы В рамках развития ФГИС Такси в 2026 году необходимо решить следующие задачи: 1) Обеспечить доступ к открытым данным ФГИС Такси через чат-бот в мессенджере MAX для проверки легальности и актуальности сведений о перевозчиках, транспортных средствах и службах заказа легкового такси. 2) Реализовать взаимодействие чат-бота в мессенджере MAX с открытой частью ФГИС Такси для отправки запроса в закрытую часть ФГИС Такси обновление результатов межведомственной проверки сведений по договорам ОСАГО и ОСГОП. 3) Ведение справочника транспортных средств, удовлетворяющих требованиям 116-ФЗ. 4) Реализация проверки сведений о транспортных средствах на соответствие требованиями 116 ФЗ. 5) Обеспечение возможности передачи данных о транспортных средствах, удовлетворяющих требованиям 116-ФЗ, из справочника во ФГИС Такси в витрину данных НСУД. 6) Реализовать сервис динамического расчета остатка квоты для реестра легковых такси. 7) Реализовать новые графические представления аналитических данных на виджетах для отображения данных реестров по метрикам локализации и квотирования. 8) Обеспечить возможность ведения справочника квот. 9) Обеспечить возможность передачи данных о квотах и остатках квот по регионам в витрину НСУД

3. Характеристика объекта автоматизации - – подсистема архивации реестров – обеспечивает хранение удаленных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси. – подсистема администрирования – обеспечивает выполнение функций: – управления записями справочников; – управления учетными записями пользователей; – управления правами доступа пользователей к функциям Системы. – подсистема формирования отчетности – обеспечивает выполнение функций: – настройку и построение отчетов для контроля исполнения требований к ведению реестров; – графическое представление аналитических данных. – подсистема уведомлений – обеспечивает выполнение функций: – информирования пользователей о событиях в Системе; – создания отдельных предупреждений для пользователей Системы в виде баннера; – создания новостей для пользователей о произошедших изменениях в функционале Системы. – подсистема полнотекстового поиска – обеспечивает возможность полнотекстового поиска по записям реестров. – подсистема открытой части федеральных реестров – обеспечивает выполнение функций: – передачи на сайт, на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок - - Значение характеристики не может изменяться участником закупки

– личный кабинет пользователя – обеспечивает выполнение функций: – создания обращений в службу технической поддержки; – просмотра и отслеживания раннее созданных обращений в техподдержку; – интеграции по API с внешней системой учета заявок Байтим; – возможности ведения интерактивного чата с сотрудником техподдержки. – подсистема информационной безопасности – предназначена для обеспечения защиты информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации, законодательством Российской Федерации в области персональных данных. Система разработана (функционирует) с использованием следующего системного ПО: Общесистемное программное обеспечение · Альт 8 СП (реестровая запись РРПО №369); · РЕД ОС 7.3 (реестровая запись РРПО № 3751). Прикладное программное обеспечение • Система управления базами данных Postgres Pro Enterprise 15 (реестровая запись РРПО № 104) · СМЭВ 3 адаптер 2.7.1 (реестровая запись РРПО № 24726); · СМЭВ 4 адаптер 3.15 (реестровая запись РРПО № 23615); · Витрина данных 2.0 (реестровая запись РРПО № 23615); · Кибер Бэкап 17.3 (реестровая запись РРПО № 4160)

3.1. Краткие сведения об объекте автоматизации Предметом автоматизации является объединение в едином информационном пространстве данных по организации перевозок пассажиров и багажа легковым такси на федеральном уровне. Объектом автоматизации являются процессы консолидации информации из: – региональных реестров перевозчиков легковым такси; – региональных реестров легковых такси; – региональных реестров служб заказа легковых такси. – Ведение регионального реестра перевозчиков легковым такси, регионального реестра легковых такси и регионального реестра служб заказа легкового такси в соответствии с ФЗ 580 должно осуществляться уполномоченным органом субъекта Российской Федерации в электронной форме одним из следующих способов: – с использованием региональной информационной системы легковых такси и передачей сведений, содержащихся в региональных реестрах, из указанной информационной системы во ФГИС Такси; – с использованием ФГИС Такси. Деятельность по перевозке пассажиров и багажа легковым такси осуществляется на основании разрешения, предоставляемого юридическому лицу, индивидуальному предпринимателю, физическому лицу и подтверждаемого записью в региональном реестре перевозчиков легковым такси, с использованием транспортных средств, сведения о которых внесены в региональный реестр легковых такси, при условии, что действие такого разрешения не приостановлено. Порядок внесения сведений в региональный реестр легковых такси, их изменения и исключения из указанного регионального реестра устанавливается законом или иным нормативным правовым актом субъекта Российской Федерации с учетом требований ФЗ 580

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

В соответствии с Актом классификации ФГИС Такси от 23.09.2025 № АК.23092025.01: – ФГИС Такси является государственной информационной системой (в соответствии с подпунктом 1 части 1 статьи 13, статьи 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»); – установлен второй класс защищенности (К2) в ФГИС Такси (руководствуясь Приложением № 1 «Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», утвержденных приказом ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 7», а также с учетом классификационных признаков); – установлен третий уровень защищенности персональных данных в ФГИС Такси (в соответствии с подпунктом «д» пункта 11 «Требований к защите персональных данных при их обработке в информационных системах персональных данных», утвержденных постановлением Правительства Российской Федерации «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» от 01.11.2012 № 1119, а также с учетом классификационных признаков). Актом категорирования от 23.09.2025 № АК.23092025.02 ФГИС Такси присвоена вторая категория значимости объектов критической информационной инфраструктуры (КИИ) на основании оценки, произведенной в соответствии с Перечнем показателей КИИ Российской Федерации и их значений, утвержденным постановлением Правительства Российской Федерации «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» от 08.02.2018 № 127

3.2. Текущее состояние объекта автоматизации В рамках работ по контракту от 02 июня 2023 года № ОК 23_01 была разработана ФГИС Такси для централизованного ведения реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси на федеральном уровне. В составе ФГИС Такси реализованы следующие подсистемы: – подсистема взаимодействия — обеспечивает выполнение функций: – получения выписок ЕГРЮЛ/ЕГРИП от ФНС России; – получения данных о ТС из ГИБДД; – получения данных о штрафах ТС из ГИС ГМП; – получения данных из региональных реестров и внешних систем; – получения данных об ОСГОП из АИС НССО; – получение данных об ОСАГО из АИС Страхования (НСИС); – предоставления данных из реестров по запросу; – хранения истории информационного взаимодействия; – уведомления Заявителей посредством ГЭПС; – формирования онлайн-выписок; – отправка межведомственных запросов пользователем в ручном режиме по кнопке для проверки данных записи реестров. – подсистема ведения реестров – обеспечивает выполнение функций: – ведения федерального реестра перевозчиков легковым такси; – ведения федерального реестра легковых такси; – ведения федерального реестра служб заказа легковых такси; – хранения данных о связке ТС и перевозчика; – индикации сверки по данным межведомственных запросов; – хранения аннулированных записей реестра перевозчиков легковым такси, реестра легковых такси, реестра служб заказа легковых такси

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

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

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

4.2.3. Требования к функциям подсистемы ведения реестров 4.2.3.1. Требования к функции распознавания ГРЗ на фотографии Требуется реализовать в подсистеме ведения реестров сервис с использованием технологий машинного обучения и графических вычислений для распознавания данных по фотографическому изображению. Для этого необходимо: – Разработать модуль с использованием готовых библиотек при необходимости, способный в автоматическом режиме распознавать государственный регистрационный знак (номер) транспортного средства из фотоснимков. Функционал модуля: – анализ изображения транспортного средства и выделение границ номерного знака; – распознавание символов и чисел на номере; – проверка соответствия распознанного текста формату ГРН РФ; – предоставление результата в удобной для дальнейшей обработки форме (строке или файле). – – Реализовать сервис, использующий современные технологии машинного обучения и GPU-вычисления для эффективного извлечения необходимой информации с цифровых фотографий. Возможности сервиса: – автоматизированное определение и выделение областей интереса на фотографиях (ГРН); – применение методов глубокого обучения для точного распознавания текста и образов; – масштабируемая архитектура, поддерживающая обработку большого количества изображений одновременно; – использование аппаратных ускорителей (GPU) для ускорения вычислительных процессов. Структура сервиса: – модуль предварительной обработки изображений (резайзинг, улучшение качества, фильтрация шумов); – нейронная сеть для выделения объектов и распознавания текстовых элементов; – логика вывода результатов распознавания с контролем точности и полнотой

4.2.3.2. Требования к обеспечению возможности динамического учета остатка квоты при квотировании записей федерального реестра легковых такси В рамках развития функции ведения федерального реестра легковых такси требуется реализовать сервис динамического расчета остатка квоты для реестра легковых такси. Сервис должен обеспечивать динамический учет остатка квоты при одновременном внесении транспортных средств в реестр легковых такси несколькими пользователями и блокировать возможность создания записи при условии нулевого остатка квоты. 4.2.3.3. Требования к обеспечению возможности проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств» В рамках развития функции ведения федерального реестра легковых такси требуется реализовать возможность проведения сверки транспортных средств в реестре ФГИС Такси со справочником локализованных марк и моделей транспортных средств, индикации результатов сверки. Необходимо обеспечить фиксирование результата проверки (соответствие/несоответствие) в региональном реестре легковых такси с указанием даты, статуса и детального результата при выявлении несоответствия марки, модели или кода изготовителя. При получении расхождений в проверяемых параметрах результат расхождения должен сохраняться в БД. Необходимо разработать механизмы представления полученных атрибутов в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

3 Подсистема взаимодействия (развитие) Подсистема предназначена для обеспечения взаимодействия с внешними системами. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси; - реализации механизма сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М; - предоставления данных о квотах и остатках квот по регионам на витрине НСУД СМЭВ 4; - предоставление данных справочника «Локализованные марки и модели транспортных средств» на витрине НСУД СМЭВ 4. п.п. 4.2.4. 4 Подсистема формирования отчетности (развитие) Подсистема обеспечивает выполнение функций формирования отчетов, отображения интерактивных виджетов, настройки отчетов. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - доработка механизмов преобразования и хранения данных реестров для аналитических запросов по метрикам локализации и квотирования. п.п. 4.2.5 5 Подсистема администрирования (развитие) Подсистема предназначена для управления справочниками, учетными записями пользователей, правами доступа к Системе. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - реализации нового справочника «Квоты» для хранения, просмотра и редактирования параметров квот по регионам; - реализация нового справочника «Локализованные марки и модели транспортных средств» для проверки соответствия транспортных средств федерального реестра легковых такси требованиям локализации. п.п. 4.2.6.

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

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

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

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

4.1.1.4. Требования к режимам функционирования Системы Все компоненты Системы должны поддерживать функционирование в трех основных режимах: – штатный режим работы; – режим технического обслуживания; – аварийный режим работы. Режимы работ предполагают полную или частичную доступность сервисов. Ниже приводится описание режимов функционирования частей Системы: – штатный режим работы – данный режим является основным режимом функционирования частей Системы и предполагает полнофункциональную доступность их сервисов; – режим технического обслуживания – данный режим предполагает полную или частичную остановку сервисов, предоставляемых частями Системы с целью выполнения обслуживающим Систему персоналом регламентных операций, направленных на обеспечение технического обслуживания аппаратно-программных средств, обеспечивающих их функционирование; – аварийный режим работы – данный режим предполагает полное или частичное ограничение полнофункциональной доступности сервисов частей Системы, явившегося следствием одиночного отказа аппаратно-программных средств, обеспечивающих их функционирование

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

4.1.1.5. Требования по диагностированию Системы Диагностирование Системы должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного программного обеспечения серверов Системы; – сбои и нарушения функционирования прикладного программного обеспечения серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Система и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с базовыми сервисами защищенного объекта информатизации соответствующего законодательству Российской Федерации в сфере защиты информации применимой к ФГИС Такси (далее – ОИ) журналирования, мониторинга функционирования и аудита. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

4.3. Требования к видам обеспечения 4.3.1. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2. Требования к информационному обеспечению Системы 4.3.2.1. Требования к организации ввода данных в Систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления. 4.3.2.2. Требования к справочникам и классификаторам и информации, хранящейся в них Состав и назначение справочников, классификаторов и информации, хранящейся в них, должны быть определены и согласованы с Заказчиком на этапе технического проектирования. Порядок использования справочников, управляемых внешними системами, должен соответствовать рекомендациям производителя таких систем. При этом в Системе должны быть обеспечены возможности разовой загрузки и последующей периодической синхронизации (или синхронизации по запросу от внешней системы) в соответствии с нормативными документами, определяющими порядок работы с такими справочниками

4.3.2.3. Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов. – наличие сертификата соответствия ФСТЭК России не ниже 5 класса защиты системы управления базами данных, в соответствии с приказом ФСТЭК России от 14.04.2023 № 64*; – наличие сертификата соответствия ФСТЭК России не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России от 02.06.2020 № 76*. Примечание: требования к требуемому классу защиты и уровню доверия системы управления базами данных должны быть уточнены в рамках выполнения работ по Контракту

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

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

4.1.2. Показатели назначения 4.1.2.1. Количество пользователей К показателям количества пользователей относятся: – расчетное количество пользователей; – расчетное количество одновременно работающих пользователей; – максимальное количество пользователей; – максимальное количество одновременно работающих пользователей. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (Таблица 2). Таблица 2. Определения показателей, связанных с количеством пользователей в Системе № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечить Система к моменту сдачи-приемки результатов выполненных работ по Контракту с учетом достижения всех показателей назначения 3 Максимальное количество пользователей Максимальное количество пользователей, работу которых должна обеспечить архитектура Системы 4 Максимальное количество одновременно работающих пользователей Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура Системы

Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 3). Таблица 3. Значения показателей количества пользователей № Показатель Значение 1 Расчетное количество пользователей 250 2 Расчетное количество одновременно работающих пользователей 80 3 Максимальное количество пользователей 1000 4 Максимальное количество одновременно работающих пользователей 250

При разработке и развитии Системы допустимо использование следующих языков программирования: C/C++ – компилируемый статически типизированный язык программирования общего назначения; C# – объектно-ориентированный язык программирования для платформы .NET Core; Groovy – объектно-ориентированный язык программирования, дополнение к языку Java; Java – строго типизированный объектно-ориентированный язык программирования общего назначения; JavaScript – мультипарадигменный встраиваемый язык программирования; PL/pgSQL – процедурное расширение языка SQL, используемое в СУБД PostgreSQL; Python – высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью; о Scala – мультипарадигменный язык программирования; о Ruby – интерпретируемый высокоуровневый язык программирования с открытым исходным кодом; Perl – высокоуровневый интерпретируемый динамический язык программирования общего назначения; Go – мультиплатформенный компилируемый язык; о Shell – язык написания скриптов в ОС семейства Linux; о Lua – скриптовый язык программирования. Языки разметки: HTML – стандартизированный язык разметки для браузеров; XML – расширяемый язык разметки. Форматы сериализации: JSON – текстовый формат обмена данными, основанный на JavaScript; YAML – формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования; TOML – формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой. Языки запросов: HiveQL – язык запросов на основе SQL для Apache Hive; SQL – язык структурированных запросов к реляционным данным; SPARQL – язык структурированных запросов к графам в формате RDF; XPATH – язык структурированных запросов данным в формате XML

4.3.4. Требования к программному обеспечению 4.3.4.1. Общие требования Общесистемное ПО, используемое в составе Системы, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации»

4.1.2.2. Число обрабатываемых объектов К показателям количества обрабатываемых объектов относятся: – расчетное количество объектов предметной области, обрабатываемых за час; – расчетное количество объектов предметной области, обрабатываемых за год; – максимальное количество объектов предметной области, обрабатываемых за час; – максимальное количество объектов предметной области, обрабатываемых за год. Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (Таблица 4). Таблица 4. Перечень объектов, в отношении которых применяется показатель «количество обрабатываемых объектов» № Объект Краткое описание 1 Запись о транспортном средстве Данные о транспортном средстве, используемом для легковых таксомоторных перевозок и внесенные в федеральный реестр легковых такси 2 Запись о перевозчике Данные о перевозчике, внесенные в федеральный реестр перевозчиков легковым такси 3 Запись о службе заказа Данные о службах заказа, внесенные в федеральный реестр служб заказа легковых такси Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (Таблица 5). Таблица 5. Значения показателей количества обрабатываемых объектов № Объект Количество объектов предметной области, обрабатываемых системой Расчетное Максимальное За час За год За час За час 1 Запись о транспортном средстве 200 200 000 400 500 000 2 Запись о перевозчике 50 50 000 100 100 000 3 Запись о службе заказа 5 500 10 1 000

Описание ключевых результатов (далее – ОКР) и эффекты, достигаемые в соответствии с мероприятием по развитию ФГИС Такси, приведенных в ВПЦТ Минтранса России на 2026-2028 гг: № 103.012 «ФГИС Такси» в составе ИТ расхода 103.26.000014 «Развитие Федеральной государственной информационной системы легковых такси» в части реализации ОКР «Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ» и «Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ», указанном в п. 2.2, приведены в таблице ниже (Таблица 6). Таблица 6. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Эффекты Дата эффекта 1 Проверка легальности легкового такси по ГРН (фото/ручной ввод) в мессенджере МАХ Сокращено время проверки легальности легкового такси гражданами, использующими мобильные устройства с 4 до 1 минуты 31.12.2029 2 Во ФГИС «Такси» реализован учет ТС в соответствии с графиком локализации, приведенном в Федеральном законе от 23.05.2025 № 116-ФЗ Возможность учета во ФГИС «Такси» легковых такси с учетом требований к локализации ТС (рост поступлений за счет штрафов, тыс. руб.: от 0,00 в 2026 до 16,80 в 2027) 31.12.2029

Применяемое в информационной/автоматизированной системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – работа программного обеспечения должна быть основана на использовании трехзвенной технологии «сервер БД – сервер приложений – «тонкий» клиент»; – клиентская часть Системы должна функционировать в интернет-браузерах: Яндекс Браузер, в последних официально выпущенных версиях на момент подписания Контракта. Необходимое для эксплуатации Системы СПО должно быть определено на этапе технического проектирования

4.3.5. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе технического проектирования. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»

4.1.2.3. Быстродействие К показателям быстродействия относятся: 1) Расчетное время отклика при обращении к Системе. 2) Максимальное время отклика при обращении к Системе. Пояснения по показателям, связанным с быстродействием Системы, приведены в таблице ниже (Таблица 7). Таблица 7. Определения показателей, связанных с быстродействием № Показатель Определение 1 Расчетное время отклика при обращении к Системе Расчетное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Максимальное время отклика при обращении к Системе Максимальное время отклика при обращении пользователей к модулям Системы, которое должна обеспечить архитектура Системы Значения показателей быстродействия Системы, достижение которых необходимо обеспечить, представлены в таблице ниже (Таблица 8). Таблица 8. Значения показателей быстродействия Системы № Показатель Значение 1 Расчетное время отклика при обращении к Системе, сек. 3 2 Максимальное время отклика при обращении к Системе, сек. 10 При этом отдельные операции могут иметь большую длительность или носить отложенный характер. При длительности таких операций более 1 мин пользователю должна предоставляться дополнительная информация о возможной продолжительности проводимой операции

4.1.3. Требования к численности и квалификации персонала Системы и режиму его работы Структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала. Персонал Системы должен (может) состоять из следующих категорий: – Пользователи; – Обслуживающий персонал: – Администратор Системы; – Администратор информационной безопасности; – Администратор средств криптографической защиты информации (СКЗИ); – Администратор баз данных; – Специалист по техническому обслуживанию/поддержке. Количество администраторов Системы, баз данных, администраторов информационной безопасности и специалистов по техническому обслуживанию должно быть достаточным для обеспечения функционирования Системы во всех режимах работы (не менее одной штатной единицы). Численность персонала должна определяться, исходя из количества необходимых автоматизированных рабочих мест на всех уровнях управления Системы и объемов выполняемых работ, и должна быть достаточной для функционирования Системы в соответствии с требованиями, приведенными в настоящем ТЗ

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

4.1.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»

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

4.1.7. Требования к защите от влияния внешних воздействий Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика и площадкой размещения технических средств

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

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

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

4.1.8.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.8.8. Независимо от использования/не использования Подрядчиком при выполнении Работ программного обеспечения, указанного в п. 4.1.8.6 Технического задания, функциональность Системы передается в объеме и в сроки, установленные Техническим заданием. 4.1.8.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.8.10. В случае, если в соответствии с пунктом 4.1.8.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.8.11. В случае, если при выполнении Работ положения пунктов 4.1.8.5-4.1.8.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.9. Требования по стандартизации и унификации К Системе предъявляются следующие требования в части стандартизации и унификации: – Работы по развитию Системы должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – При модернизации элементов Системы следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – Используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Системы должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – Применяемые при развитии Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – Термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – Взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам

4.1.10. Требования к надёжности Должно быть предусмотрено сохранение работоспособности Системы при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Системы (отказ рабочей станции, потеря сетевого доступа и т.п.). Система должна предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы – допустимое время на восстановление работоспособности Системы (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования

4.1.11. Требования к доступности В документации Системы должен быть указан максимальный уровень доступности, который Система может обеспечить, а также необходимые для этого условия. Доступность измеряется в процентах и рассчитывается по формуле: (СВД – ВН) / СВД) х 100, где: СВД – согласованное время доступности Системы; ВН – время недоступности Системы (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации). В целях защиты общедоступной информации, размещаемой в ФГИС Такси в соответствии с приказом Минкомсвязи России от 27.06.2013 № 149 «Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети «Интернет» в форме открытых данных, а также для обеспечения ее использования», в отношении общедоступной информации должны быть заданы требования и уточнены/конкретизированы проектные решения, полученные в ходе технического проектирования ФГИС Такси, направленные на сохранение указанной информации не менее 10 лет. Спроектированные/предложенные механизмы/средства должны обеспечивать восстановление информации в ФГИС Такси, модифицированной или уничтоженной вследствие неправомерных действий в отношении такой информации. Время восстановления процесса предоставления информации пользователям не должно превышать 8 часов. Значение доступности Системы: не менее 99,7%

4.1.12. Требования к информационной безопасности Подсистема информационной безопасности разработана в рамках контракта от 02.06.2023 № ОК/23_01 на выполнение работ по созданию Федеральной государственной информационной системы легковых такси и актуализирована в рамках контракта от 13.05.2025 № ОК/25_05 «На оказание услуг по подготовке и проведению повторной аттестации объектов информатизации ФГБУ «СИЦ Минтранса России» на соответствие требованиям по защите информации (Идентификационный код закупки: 251770411620577080100100140027490244). Работы по развитию Системы не должны привести к закупке дополнительных средств защиты информации, необходимых для обеспечения информационной безопасности модернизированной (развитой) Системы. Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры будут проведены в рамках исполнения отдельного контракта (далее – Работы по ИБ). В ходе выполнения Работ по ИБ, осуществляемых в рамках исполнения отдельного контракта, будут проведены работы по актуализации/доработке созданной подсистемы информационной безопасности (далее – ПИБ) Системы. Работы по ИБ будут включать формирование/актуализацию требований информационной безопасности (включая определение актуальных угроз безопасности и требований к ПИБ), непосредственно работы по актуализации/доработке созданной ПИБ, проектирование и разработку/актуализацию существующей документации на ПИБ, испытания ПИБ и аттестационные испытания Системы

4.1.13. Требования к безопасности исходного кода и разработке Системы 4.1.13.1. Требования к безопасности исходного кода Процесс разработки исходного кода Системы должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, в том числе Требованиям о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденным приказом ФСТЭК России от 11.04.2025 № 117, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», и локальным нормативным правовым актами Оператора Системы в области информационной безопасности, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее - Руководство), применяемое при разработке исходного кода Системы. Руководство должно соответствовать положениям ГОСТ Р 56939-2024 и в обязательном порядке содержать: – описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников; – описание процесса моделирования, оценки и формирования мер предотвращения угроз, модель угроз веб-приложения в качестве приложения к Руководству; – описание методик, применяемых при разработке исходного кода (правила написания кода); – описание методик и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающий критерии отбора релизных версий ПО; – описание применяемых механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды) – утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса)

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

4.2.4. Требования к функциям подсистемы взаимодействия 4.2.4.1. Требования к функции получения в закрытой части ФГИС Такси запросов на выполнение межведомственной проверки по ОСГОП и ОСАГО из открытой части ФГИС Такси В рамках развития функций чат-бота в мессенджере MAX требуется реализовать взаимодействие с открытой частью ФГИС Такси для передачи запросов на выполнение межведомственной проверки сведений по страховым договорам ОСАГО и ОСГОП в закрытой части ФГИС Такси. Для этого необходимо: – разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX в части получения запросов на проверку договоров ОСАГО и ОСГОП; – реализовать передачу, полученных открытой частью ФГИС Такси, запросов на проверку договоров ОСАГО и ОСГОП в закрытую часть ФГИС Такси; – В закрытой части ФГИС Такси доработать механизм выполнения межведомственных проверок договоров ОСАГО и ОСГОП путем запуска проверки по событию получения запроса из открытой части ФГИС Такси; – Обеспечить ограничение частоты запросов в единицу времени

4.2.4.2. Требования к функции получения данных о транспортном средстве из ГИБДД в части нормализации марок и моделей транспортных средств В рамках развития функции получения данных о транспортном средстве из ГИБДД для повышения точности автоматической верификации данных транспортного средства при межведомственном взаимодействии требуется доработать механизм сопоставления нормализованных значений полей «Марка», «Модель» с данными, полученными от ФИС ГИБДД-М. Необходимо разработать механизм, позволяющий, повысить процент успешных автоматических проверок и снизить количество ложных несоответствий, возникающих из-за вариативности написания одних и тех же марок и моделей в разных системах. Для этого необходимо: Реализовать алгоритм предобработки значений «Марка» и «Модель», полученных от ГИБДД: Набор методов может включать в себя: – приведение к единому регистру; – удаление лишних пробелов и специальных символов; – транслитерация кириллицы в латиницу; – замена сокращений и аббревиатур на полные названия – удаление стоп-слов и модификаторов; – использование нечеткого поиска и фонетических алгоритмов. Реализовать прохождение атрибутов «Марка», «Модель», полученных в результате межведомственной проверки через алгоритм нормализации данных. Разработать механизм сопоставления с эталонными значениями марок и моделей. На основе результатов алгоритма должен быть определен статус проверки параметров. Необходимо разработать механизмы представления полученных атрибутов и механизмы индикации полученных расхождений в интерфейсе Системы. Техническое решение и описание используемых программных средств должны быть определены на этапе технического проектирования

4.1.13.2. Требования к разработке Системы 4.1.13.2.1. Требования к инструментам разработки и процессу контроля версий 4.1.13.2.1.1. Система контроля версий Для управления исходным кодом должна использоваться распределенная система контроля версий, развернутая в инфраструктуре Заказчика. Все работы с кодовой базой по проекту ведутся исключительно в данной системе. 4.1.13.2.1.1.1. Правила именования веток Имя ветки должно соответствовать следующему формату: release/v Порядковый номер версии исходного кода Системы – три цифры, разделенные точками: · Первая цифра – мажорная версия (MAJOR), добавление новых функций системы, существенные изменение существующих функций или изменения схемы данных, влекущие за собой отсутствие обратной совместимости версий Системы; · Вторая цифра – минорная версия (MINOR), изменения в существующих функциях системы или схемы данных, обеспечивающих частичную или полную обратную совместимость версий Системы; · Третья цифра – патч версия (PATCH), небольшие изменения в существующих функциях системы, исправление ошибок или оптимизация, гарантирующие полную обратную совместимость версий Системы; Примеры именования веток: · release/v1.0.0 · release/v1.5.0 · release/v2.0.3 4.1.13.2.1.1.2. Модель ветвления В процессе разработки используются следующие основные ветви: · main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах. · test — ветка для интеграции версий исходного кода Системы, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из test

4.1.13.2.2. Требования к используемым зависимостям (библиотекам) 4.1.13.2.2.1. Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. 4.1.13.2.2.2. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock · Для Java: pom.xml или build.gradle · Для Go: go.mod и go.sum · Для .Net: *.csproj 4.1.13.2.2.3. Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. 4.1.13.2.2.4. Все используемые зависимости перед применением проходят обязательное сканирование на наличие известных уязвимостей. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest). · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.1.13.2.3. Требования к процессу непрерывной интеграции (CI) 4.1.13.2.3.1. Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.1.13.2.4. Требования к хранению артефактов сборки 4.1.13.2.4.1. Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.1.1.1. Перечень подсистем, их назначение и характеристики Перечень существующих подсистем приведен в п. 3.2 данного документа. В Таблице 1 приведен перечень развиваемых подсистем Системы в рамках Контракта, их назначение и ссылки на пункты, в которых раскрываются функциональные требования к ним. Таблица 1 – Перечень развиваемых подсистем при выполнении работ в 2026 году № Наименование подсистемы Назначение Требования 1 Подсистема открытой части федеральных реестров (развитие) Подсистема обеспечивает выполнение функций: – передачи на сайт. на котором размещена открытая часть федеральных реестров, актуальных сведений из реестров перевозчиков легковым такси, легковых такси, служб заказа легковых такси; – создания двухмерного штрихового кода (QR-кода), содержащего ссылку на страницу сайта, определённого в соответствии с нормативно правовыми актами, регулирующими деятельность в сфере таксомоторных перевозок. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - обеспечения взаимодействия с открытой частью ФГИС Такси с помощью чат-бота в мессенджере MAX для получения информации легковом такси по ГРН (фото/ручной ввод); - ведения истории взаимодействия с чат-ботом ФГИС Такси; - получения обратной связи граждан о нелегальных перевозках легковым такси. п.п. 4.2.2. 2 Подсистема ведения реестров (развитие) Подсистема обеспечивает функции ведения федеральных реестров перевозчиков, легковых такси и СЗЛТ. В рамках настоящих работ предусмотрено развитие функций подсистемы в части: - распознавания ГРЗ на фотографии; - реализации сервиса динамического расчета остатка квот в регионах для федерального реестра легковых такси; - реализации проверки транспортных средств федерального реестра легковых такси на соответствие требованиям локализации по справочнику «Локализованные марки и модели транспортных средств». п.п. 4.2.3.

4.2. Требования к содержанию работ 4.2.1. Требования к совместимости с ЕЦП «ГосТех» В рамках работ по развитию Системы должно обеспечиваться сохранение совместимости с ЕЦП «ГосТех», предусмотренными работами по контракту от 02 июня 2023 года № ОК 23_01. 4.2.2. Требования к функциям подсистемы открытой части федеральных реестров 4.2.2.1. Требования к функции чат-бота ФГИС Такси Требуется реализовать взаимодействие с открытой частью ФГИС Такси с мессенджером MAX, которое позволит осуществлять проверку легальности транспортного средства при осуществлении перевозок пассажиров и багажа легковым такси по сведениям о транспортном средстве по ГРН, включая привязку к действующему разрешению перевозчика. Для этого необходимо разработать сервис в открытом контуре ФГИС Такси для взаимодействия по API с мессенджером MAX. Чат-бот должен предоставлять следующий функционал: – Проверка легкового такси по: – ГРН ТС; – Номер записи; – Фотографическое изображение ГРН ТС; – Возвращаемая информация по легковому такси: – Регион; – Номер записи; – Дата внесения записи; – ГРН; – Марка; – Модель; – Статус; – Наличие включения ТС в разрешение перевозчика с отражением атрибутов перевозчика (номер разрешения, дата начала и дата окончания разрешения, статус разрешения, наименование, регион, ИНН и ОГРН, тип перевозчика, признак проверки перевозчика по ФНС (статус в реестре ЕГРЮЛ/ЕГРИП ФНС)); – Признак наличия оформленного ОСАГО; – Признак наличия включения ТС в договор ОСГОП; – Признак проверки ТС по данным ГИС ГМП; – Признак проверки ТС по данным МВД; – Наличие действующего договора с СЗЛТ (при наличии) (статус договора, наименование СЗЛТ, ОГРН)

4.2.2.2. Требования к функции ведения истории взаимодействия с ФГИС Такси Требуется реализовать сервис ведения и хранения данных мониторинга событий и запросов на проверку транспортных средств, поступивших через мессенджер МАХ результатов ответов. Техническое решение и состав получаемых данных должны быть определены на этапе технического проектирования. 4.2.2.3. Требования к функции получения обратной связи граждан о нелегальных перевозках легковым такси Требуется разработать и внедрить интерактивную форму обратной связи в мессенджере MAX, позволяющую гражданам оперативно передавать информацию о случаях выявления нелегальных перевозок легковым такси Уполномоченным органам для своевременного приостановления или аннулирования записей региональных реестров перевозчиков и легковых такси. Система должна обеспечивать удобное заполнение пользователями ключевых полей и предоставление возможности прикреплять подтверждающие фотографии. Для пилотного тестирования система предусматривает настройку функционала применительно к отдельным регионам. Требования к форме обратной связи: – Сбор контактной информации гражданина: – поле ввода адреса электронной почты; – поле ввода номера мобильного телефона. – Обязательные поля заполнения: – регион совершения поездки; – название перевозчика/службы заказа легкового такси. – Приложения подтверждающих материалов: – возможность загрузки фотографий (например, фото автомобиля, водителя, ситуации нарушения). – Настраиваемость функционала: – предусмотреть настраиваемый функционал для выборочных регионов (пилотные регионы). Требуется разработать сервис обработки данных обратной связи граждан о нелегальных перевозках легковым такси в части получения данных по api с возможностью хранения во ФГИС Такси.

4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня

9. Источники разработки - 9.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 9.2. Нормативно-методические документы Специальные нормативно-методические документы для разработки ТЗ не использовались - - Значение характеристики не может изменяться участником закупки

6. Порядок контроля и приемки - 6.1. Виды, состав, объем и методы испытаний Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены испытания в следующем порядке: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний». По результатам предварительных испытаний оформляется протокол предварительных испытания и акт приемки в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации». Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию для последующего уточнения требований к вычислительным мощностям при запуске ФГИС Такси в промышленную эксплуатацию - - Значение характеристики не может изменяться участником закупки

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

6.2. Общие требования к приемке работ по стадиям По результатам выполнения 3-го этапа должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. 6.2.1. Проведение и сдача работ (результатов работ) осуществляется в соответствии с Контрактом и разделом 6 настоящего Технического задания. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке

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

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

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

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

6.3. Сведения о гарантийном обслуживании Системы Под гарантией понимается надлежащее функционирование Системы в соответствии с требованиями, установленными Техническим заданием. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Системы, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Гарантийные обязательства на выполненные работы исчисляются с даты ввода Системы в эксплуатацию. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения контракта в целом (дата подписания Заказчиком документа о приемке по 3-му этапу исполнения Контракта)

6.4. Порядок выполнения доработок и устранения допущенных ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Подрядчиком в рамках выполнения работ по Контракту. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания, устраняются Подрядчиком в сроки, установленные Заказчиком. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пункте 5 настоящего ТЗ), связанные с устранением замечаний к работе Системы или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. Доработанная документация должна быть передана Заказчику во время приемочных испытаний или до завершения срока гарантийного обслуживания (в зависимости от периода, в котором выявлены такие недостатки)

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие - 7.1. Развертывание и конфигурирование Система должна быть развёрнута Подрядчиком на мощностях, согласованных с Заказчиком. Должен быть установлен передаваемый на машинных носителях дистрибутив и осуществлена предварительная конфигурация. В случае необходимости Подрядчиком должны быть предоставлены обновления, выпущенные по итогам испытаний, если эти обновления не включены в состав дистрибутива - - Значение характеристики не может изменяться участником закупки

7.2. Изменения, которые необходимо осуществить в объекте автоматизации 7.2.1. Развитие условий функционирования объекта автоматизации, при которых гарантируется соответствие развиваемой Системы требованиям При подготовке к вводу в эксплуатацию Системы Заказчик должен: – определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации Системы; – обеспечить присутствие персонала Заказчика на подготовке к работе с Системой. Заказчиком должна быть обеспечена реализация со стороны смежных систем разработанных форматов и протоколов взаимодействия, обеспечена возможность сетевого доступа к смежным системам. 7.2.2. Развитие необходимых для функционирования Системы подразделений и служб Дополнительный перечень мероприятий, который необходимо осуществить в объекте автоматизации, выявляется и уточняется на этапе технического проектирования. Результаты проведенного анализа должны быть отражены в документе «Пояснительная записка к техническому проекту». 7.2.3. Сроки и порядок комплектования штатов персонала Комплектование штатов и подразделений, необходимых для функционирования Системы должно быть проведено Заказчиком до начала опытной эксплуатации Системы

8. Требования к документированию - Техническая и эксплуатационная документация должна быть разработана в составе, указанном в разделе 6 ТЗ, с использованием комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 – в части терминологии; – ГОСТ 34.201-2020, ГОСТ 19.101-2024* (СТ СЭВ 1626-79), ГОСТ 19.103-77 ? в части наименования и обозначения документов; – ГОСТ Р 59793–2021– в части определения стадий и этапов работ; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание»; – ГОСТ 2.503-2023, ГОСТ Р 2.504-2021 – в части внесения изменений в документацию; – ГОСТ Р 59792-2021 – в части определения видов испытаний. Документы должны оформляться с использованием ГОСТ Р 2.105-2019 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Формальное полное соответствие документов требованиям классам стандартов ГОСТ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы классами стандартов ГОСТ 19 для отдельных документов - - Значение характеристики не может изменяться участником закупки

При разработке документов должно быть учтено следующее: – Корректность предоставленных сведений проверяется при приемке Системы в эксплуатацию, при этом неполнота или ложные сведения являются основанием для отказа в приемке Системы; – Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе пользователя, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему; – Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34; Документация должна передаваться Заказчику в 2-х экземплярах в бумажном (1-й экземпляр – Заказчику, 2-й экземпляр – Подрядчику) и электронном виде, на USB-флеш-накопителе или DVD-диске, на русском языке

Документация в бумажном виде должна быть сброшюрована, в том числе прошита, с наклейкой шильдика на обороте последнего листа документа с указанием количества листов и подписью уполномоченного лица. При передаче программного обеспечения и баз данных, созданных при выполнении работ, в виде исполняемого или объектного кода, Подрядчик передает Заказчику их исходные коды. Передача исходных кодов и дистрибутивов программного обеспечения осуществляется на USB- накопителе или DVD-диске и должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, описания процесса сборки, специальной среды разработки (если сборка может быть выполнена только в среде разработки). Документы по каждому этапу работ, передаются Заказчику в редактируемом (doc/docx, xls/xlsx, ppt/pptx, vsd, mpt и пр.) и нередактируемом (pdf, и пр.) форматах, в том числе форматы свободно распространяемых приложений

8.1. Состав документации на Систему В соответствии с п. 6 ТЗ в результате выполнения работ по развитию Системы должны быть разработаны следующие документы: 1. Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; 2. Пояснительная записка к техническому проекту; 3. Ведомость технического проекта; 4. Описание информационного обеспечения; 5. Ведомость машинных носителей информации; 6. Описание автоматизируемых функций; 7. Описание программного обеспечения; 8. Схема функциональной структуры; 9. Спецификация на Систему; 10. Руководство по безопасной разработке программного обеспечения; 11. Руководство пользователя; 12. Руководство администратора; 13. Регламент управления доступностью и непрерывностью; 14. Регламент резервного копирования; 15. Руководство по установке программных средств; 16. Ведомость эксплуатационных документов; 17. Ведомость машинных носителей информации; 18. Инструкция по установке; 19. Инструкция по сборке исходного кода; 20. Паспорт; 21. Формуляр; 22. Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; 23. Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; 24. Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; 25. Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации;

26. Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия; 27. Исходные коды и дистрибутивы на физическом носителе; 28. Акты инструментальных проверок на уязвимости исходного кода; 29. Акт выполнения пусконаладочных работ; 30. Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; 31. Программа и методика предварительных испытаний; 32. Отчет о проведении опытной эксплуатации; 33. Акт о завершении опытной эксплуатации; 34. Журнал опытной эксплуатации; 35. Протокол приемочных испытаний; 36. Акт приемки в промышленную эксплуатацию; 37. Акт о передаче материального носителя

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

Таблица 9. Сроки выполнения работ в 2026 году (Календарный план) № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа * Результат Срок выполнения Подрядчиком работ по этапу

1 Техническое проектирование 1.1. Разработка Частного технического задания (п.п.4.2 ТЗ, п.8 ТЗ) Начало: с даты заключения контракта; Окончание: не позднее 18.06.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: – Частное техническое задание на выполнение работ по развитию Федеральной государственной информационной системы легковых такси; – Пояснительная записка к техническому проекту. 1.2. Разработка документации на Систему (п.8 ТЗ) Начало: с 19.06.2026; Окончание: не позднее 31.07.2026 В срок, установленный настоящим подпунктом, Подрядчик разработал, согласовал с Заказчиком и предоставил Заказчику сопроводительным письмом: - Ведомость технического проекта; - Описание информационного обеспечения; - Ведомость машинных носителей информации; - Описание автоматизируемых функций; - Описание программного обеспечения; - Схема функциональной структуры; - Спецификация на Систему; - Руководство по безопасной разработке программного обеспечения. Начало: с даты заключения контракта; Окончание: не позднее 31.07.2026

2 Разработка, адаптация и проведение пусконаладочных работ ФГИС Такси 2.1. Разработка и адаптация программного обеспечения, разработка рабочей документации ФГИС Такси (п.4, п.8 ТЗ) Начало: 01.08.2026 Окончание: не позднее 11.09.2026 Разработано программное обеспечение. Сопроводительным письмом предоставлено Заказчику: - Руководство пользователя; - Руководство администратора; - Регламент управления доступностью и непрерывностью; - Регламент резервного копирования; - Руководство по установке программных средств; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Инструкция по установке; - Инструкция по сборке исходного кода; - Паспорт; - Формуляр; - Инструкция по организации информационного взаимодействия с региональным реестром перевозчиков легковым такси; - Инструкция по организации информационного взаимодействия с региональным реестром легковых такси; - Инструкция по организации информационного взаимодействия с региональным реестром служб заказа легковых такси; - Инструкция по организации информационного взаимодействия с единой системой идентификации и аутентификации; - Инструкция по организации информационного взаимодействия с единой системой межведомственного электронного взаимодействия

2.2. Проведение пусконаладочных работ ФГИС Такси (п.6, п.8 ТЗ) Начало: 12.09.2026 Окончание: не позднее 21.09.2026 Сопроводительным письмом направлены Заказчику: - Исходные коды и дистрибутивы на физическом носителе; - Акты инструментальных проверок на уязвимости исходного кода; - Акт выполнения пусконаладочных работ; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. Согласованы (утверждены) Заказчиком: - Программа и методика предварительных испытаний. На технических средствах заказчика развернута версия Системы с учетом доработок по настоящему ТЗ 2.3. Предварительные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 22.09.2026 Окончание: не позднее 02.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения предварительных испытаний - Протокол проведения предварительных испытаний; - Акт приемки в опытную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа опытной эксплуатации. Начало: 01.08.2026 Окончание: не позднее 02.10.2026

3 Этап опытной эксплуатации и приемочных испытаний ФГИС Такси 3.1. Опытная эксплуатация ФГИС Такси (п.6, п.8 ТЗ) Начало: 03.10.2026 Окончание: не позднее 16.10.2026 Согласованы с Заказчиком и направлены сопроводительным письмом в течение 2-х рабочих дней с даты завершения опытной эксплуатации: - Отчет о проведении опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Журнал опытной эксплуатации; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды. По результатам выполненных работ этапа должны быть согласованы (утверждены) Заказчиком: - Программа и методика приёмочных испытаний. 3.2. Приемочные испытания ФГИС Такси (п.6, п.8 ТЗ) Начало: 17.10.2026 Окончание: не позднее 26.10.2026 Предоставляется в течение 2-х рабочих дней с даты завершения приемочных испытаний: - Протокол приемочных испытаний; - Акт приемки в промышленную эксплуатацию; - Акты инструментальных проверок в соответствии с Руководством по безопасной разработке программного обеспечения, включая артефакты сборочной среды; - Акт о передаче материального носителя. Документы в соответствии с разделами 4.1.8, 4.1.13, 6.2 Технического задания. Начало: 03.10.2026 Окончание: не позднее 26.10.2026

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

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

Преимущества: Не установлены

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 2.1 ст. 31 Закона № 44-ФЗ 1.1? Требования в соответствии c пунктом 4 ПП РФ от 29.12.2021 №2571 Дополнительные требования Наличие у участника закупки опыта исполнения (с учетом правопреемства) в течение трех лет до даты подачи заявки на участие в закупке контракта или договора, заключенного в соответствии с Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не менее двадцати процентов начальной (максимальной) цены контракта. Информация и документы, подтверждающие соответствие участника закупки дополнительному требованию, установленному в соответствии с частью 2.1 ст. 31 Закона о контрактной системе, являются информация и документы, предусмотренные хотя бы одним из следующих подпунктов: а) номер реестровой записи в предусмотренном Законом о контрактной системе реестре контрактов, заключенных заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной системы в информационно-телекоммуникационной сети "Интернет"); б) выписка из предусмотренного Законом о контрактной системе реестра контрактов, содержащего сведения, составляющие государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в установленном порядке в такой реестр); в) исполненный контракт, заключенный в соответствии с Законом о контрактной системе, или договор, заключенный в соответствии с Федеральным законом "О закупках товаров, работ, услуг отдельными видами юридических лиц", а также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену поставленных товаров, выполненных работ, оказанных услуг. 2. Требование к поставщику (подрядчику, исполнителю), не являющемуся субъектом малого предпринимательства или социально ориентированной некоммерческой организацией, о привлечении к исполнению контракта субподрядчиков, соисполнителей из числа субъектов малого предпринимательства, социально ориентированных некоммерческих организаций в соответствии с ч. 5 ст. 30 Закона № 44 ФЗ Дополнительные требования Объем привлечения 40% от цены контракта в соответствии с пунктом 3.4.16. Приложения № 5 Проект контракта к Извещению о проведению открытого конкурса в электронной форме 3. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 4. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ Показать все (5)

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

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

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

Размер обеспечения заявки: 330 000,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 к извещению)

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988

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

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

Номер типовых условий контракта: 1400700000521003

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

Право заключения контрактов с несколькими участниками закупки в случаях, указанных в части 10 статьи 34 Федерального закона 44-ФЗ: Не установлено

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

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

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

Размер обеспечения исполнения контракта: 3 300 000,00 ? (10 %)

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

Платежные реквизиты для обеспечения исполнения контракта: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988

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

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

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

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

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

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

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

Размер обеспечения гарантийных обязательств: 3 300 000,00 Российский рубль

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

Платежные реквизиты для обеспечения гарантийных обязательств: p/c 03214643000000017300, л/c 20736X21630, БИК 004525988, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/с 40102810545370000003

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

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

Документы

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

Документы

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